I just started a job at a wind power company. They want me to determine what is required to develop a SCADA system of our own to save from the licensing expense of their current vendor. I have no experience in this area and hope that I can draw from the collective experience on this forum.

Our turbines already have the hardware in place: sensors, PLC, controller, etc. They have a working solution now, but as mentioned, the vendor software is expensive and not open to other controllers, communication protocols, new reports, or any other further development.

So in this case, the work that needs to be done is mostly software:
- Networking/communication to the turbine (protocol, servers, etc.)
- HMI (alarms, receive data, send control signals, monitoring, data analysis, reports, etc.)

Basically, can anyone provide an estimation of how many programmers would be needed and how long the project would take?

Any recommendations or best practices would be greatly appreciated, such as programming language to use, software libraries, good resources or books about how to do build a SCADA system, etc. Any other advice or recommendations would be great as well.

I would really appreciate any advice since I am working alone on this. Thanks!

 

Tell your manager it cannot be done by one person working alone for any reasonable values of quality, features and time-to-market. There's a reason why all the HMI companies have dozens, sometimes hundreds, of coders and software architects.

It is far cheaper to explore a private label arrangement with somebody like Indusoft, or one of the other smaller HMI vendors than to try to reinvent the wheel like this.

This kind of project is a career-limiter, because they won't remember that they asked you to do the impossible with nothing, they'll only remember the failure with your name attached.

Good luck,

Walt Boyes
Editor in Chief
Control and Controlglobal.com
www.controlglobal.com

Mailto:[email protected]
Read my blog SoundOFF!! At www.controlglobal.com/soundoff

 

This depends on alot of things. If you are really trying to develop a full blown customizable SCADA package, I agree with Walt. If you are trying to display some fixed values from each turbine on a couple different controllers (Depending on what you are talking to) his might be easily do-able by one person in a short amount of time.

Basically SCADA means alot of things to alot of people. If you are shipping something as a product that has fixed functionality and will talk to the same devices for every customer, you don't need a commercial SCADA package, you can write something int C++ or C# fairly quickly (Depending on functionality).

If your customer wants to get in there and add their (unplanned for)device to the package you could be looking at a nightmare scenario.

Often times most PLC brands will have a library you can purchase as a one time fee for communicating to their PLCs over some common connection such as ethernet. You then build your application around this dll or ActiveX/.NET item.

You have to feel out management with a specification and try to get a sense of exactly what they want to accomplish with this software. If they want to nickel and dime you with add-ons you could get into bad situation, so make this clear to them, and account for the time it would take a development team to continually add items (and the framework code to maket he software extensible).

IT might make sense to look at open source projects as well if you do need a generic SCADA. I don't know how far these things have come.

KEJR

 

I would investigate investing with CitectSCADA for your needs, this is exactly why we went this way because of the fact they have many, many drivers built in that talk to different vendor io devices.

Julian Kovacic
Onesteel whyalla south australia

 

Harsh, but one hundred percent true. Btw, are you sure your manager is not an old enemy?
A suggestion for your problem (communication to the turbine and HMI) is Integraxor. It is a completely free (for maximum 128 tags) Web-based software with everything a SCADA solution should provide.

 

Hello,

Take a look at PeakHMI. http://www.hmisys.com/

Good luck,

Mark

 

The first thing you need to do is to write a description of what the software needs to do. Describing it as a "SCADA system" doesn't tell us much, because it doesn't tell us what features you need. It's like saying "how long does it take to wire up a control panel"? The answer to that is "it depends on how much stuff you put in the panel".

The things to consider are:

1) Is the system supposed to be end user programmable, or do you ship it as a finished turn-key system? This is a very important detail, as it determines the entire nature of what you need.

2) What protocols do you need to support? This is a big deal because many protocols are proprietary and drivers are only available from the OEM or from the OEM's licensees. Buying a big collection of drivers for each installation can make the cost of your existing software look cheap. If you stick with genuinely open protocols (as opposed to the ones that just like to call themselves open) then your costs are much lower (zero in many cases).

3) How is the system supposed to be accessed? From a local (on site) PC only? Remotely via a web browser? If you need remote access, is this just for reports or do you need to change set points and do other control functions securely from a remote (off site) location?

4) What about remote service access by your company? Is this needed? If so, to what degree?

5) How many reports are needed?

I suspect that what you want isn't a traditional SCADA. Rather, you want a custom program that does things like read values from equipment, changes set points, logs data to a database, and prepares reports (wind speed, power produced, etc.).


I am going to make some assumptions about what you need.

1) You need live readings and control signals for controlling the system. How many screens to you need for this? One? Two? Many? Is someone controlling a wind farm, or just an individual wind turbine?

2) You need to log data to a database in order to produce reports on things such as wind speed and power produced.

3) You need to produce historical reports on demand from the database.

These are three different things that don't all have to be done by the same program.

The key to doing a successful large software project is to not do a large software project. Break it down into several smaller projects. It's just like any other engineering project. Start writing things down. Ask what features you really need. Look at what each feature costs. Write up a software bill of material for known components (protocols, databases, etc.). Look at how you can simplify the system.

To deal with your questions of "how many programmers would be needed and how long the project would take?":

1) That question can't be answered based on the information you have provided. We don't even know if you are talking about a 1000 MW wind farm that is feeding into the grid, or just something to run the lights for someone's cottage.

2) Don't assume that adding more programmers to a project results in getting more work done faster. You will reach diminishing returns very quickly for something like this. If its a small system, you really only want one guy working on it.

3) If you intend to contract this out to someone, be careful of dealing with a someone whose experience lies in writing typical business software. They won't understand what you are trying to do, and you will have to explain even the most basic things to them. The project will go drastically over schedule, and in the end they will be just looking at how to cut their losses and bail out. Deal with somebody who has some industrial or other related experience.

4) Don't write specifications that say something like "the program must be written in language xyz because that's the only one that I've heard of". Talk to each potential programmer and listen to their suggestions. They will probably have reasons that you didn't think of for doing it a particular way.

5) On the other hand, make sure your contract with them is specific that *they* are responsible for ensuring that no components with run time fees get included in the finished product. There are a lot of dubious deals that go on in the software business. Some third party software vendors give consultants sales commissions (kickbacks) for including their software components in projects. Also, often the consultant gets to use the development software for free (or for a annual flat rate), while the customer (you) is responsible for (steep) run time fees after the system is in service.

6) Make sure you get source code for everything, whether you are talking about third party software components, or contracted custom source code. You are looking at a long term maintenance commitment for your systems, and you don't want to be left holding the bag if the original software owner loses interest in supporting it or if there comes a time when you no longer want to deal with them.


Take the following with a very large grain of salt, but I'll give you my concept for a small system for a single stand alone turbine, where the actual control is done by a PLC.

1) Programming language - Python.
2) Application framework - Twisted.
3) Database - PostgreSQL or SQLite.
4) Protocols - All are integrated into the application, assuming that you are using genuinely open protocols (e.g. Modbus).
5) All operator screens are web based. Live update is via AJAX type methods. The web server is part of the application.
6) All historical reports are web based with traditional static HTML. The web server is part of the application or a separate application (the choice depends on some technical details).
7) The web pages and art work can be customised for each system, but the rest of the functions are fixed.
8) Operating system for the application itself - Linux or MS Windows - your choice. Linux is recommended to make the next point more practical.
9) Your company ships each system pre-installed and tested on a lower power fanless system with a solid state drive.

All software comes with no run time fees (except for MS Windows, if you decide to go that route).

All software is written by one person. The time to create this would be somewhere between 4 months and 1 year, depending on what features you want. I'm picking this number out of the air though, so don't base a budget on it.

 

Thanks for everyone's advice. I think our SCADA system would be more on the simple side. Basically, the only units we have are the wind turbines themselves. The PLC and controller would be standard for almost all units, maybe only 1 or 2 different types, although it would be nice to use open standards if we need to make changes. In essence, the system would only require the following:

- Receive data from turbine (less than 100 different data measurements)
- Send control signals to turbine (5 or less, such as on, off, etc.)
- Provide real-time data monitoring
- Alarm checking
- Provide capability for historical data analysis
- Ability to model system in hierarchy (site->plant->cluster->unit)

A lot of the more sophisticated control functionality is performed automatically by a separate control system, so our system would mostly be about sending/receiving data. In the beginning, the interface would not need to be that graphical. As long as a basic functioning system is available and can be expanded upon, that would be enough.

I realize that there are probably a million little details and technical challenges to creating a SCADA system from scratch, but I want to wrap my head around the problem as much as possible before I recommend that we abandon a custom development and buy a solution from a vendor.

Anyone have any last words of advice or any suggestions for approaches that I could take for a custom development? Thanks a lot for your help.

 

What you need is a programming environment which allows access to the VGA interface (from a single pixel to virtual instruments and controls), to raw hardware interfaces or fieldbus IOs, and to databases for the handling of e.g. historical data. DACHSview-SDL is such a tool which supports the cross development of SCADA or visualization applications.

If your target system is PC and QNX 6 based please have a look to
http://www.dachs.net/DviewSDL.htm

Best Regards

Armin Steinhoff

 

http://pvbrowser.org

 

As an alternative of starting from scratch would be to use components from companies like Open Automation Software

http://www.opcsystems.com/main.htm

Which I would imagine are run-time free.
Tommy

 

In reply to Wes: You said "Ability to model system in hierarchy (site->plant->cluster->unit)". If I understand you correctly, somehow we went from "controlling a wind turbine" to "controlling a large wind farm". Please note that the responses so far have all be directed at the former, and not the latter.

You also said: "In the beginning, the interface would not need to be that graphical. As long as a basic functioning system is available and can be expanded upon, that would be enough." Designing a basic system that can be expanded upon without having to rip out and rewrite large pieces of it is non-trivial. Even if you don't implement all the features now, you better have a clear description now of what these later features will be so that the software design can accommodate them.

As for what constitutes "custom development", I should point out that it's not a black and white choice. Using a traditional SCADA package still involves a lot of work, and even a completely custom program still uses a lot of off the shelf components (in many cases, the same ones the SCADA uses). The question is, what are the trade offs each makes in *your* application?

Finally, talk to some people in your company and find out what features your market wants but aren't being served by your existing system. You will probably find out that a lot of things are being done the way they are because of the limitations of the existing package. If you are looking at starting over, you should be looking at whether the correct needs are being served.

 

To M Griffin:

Thanks a lot for your detailed response. As you can probably tell from my posts, I am very new to this area. I literally started 7 working days ago with no idea what a SCADA system is and have been asked to figure out the details of creating our own solution, so I'm obviously scrambling a bit.

Sorry I didn't provide enough detail of what my system needs in the earlier posts. You were correct in your assumptions of what my system would need, but I neglected to specify that it would need to control wind farms instead of individual turbines.

______________________________________________

In response to your questions:

"1) Is the system supposed to be end user programmable, or do you ship it as a finished turn-key system?"

Our system will be a finished turn-key system.

"2) What protocols do you need to support?"

Since we will be packaging this software with our own wind turbines, we will have a small list of protocols. I think Modbus and IEC 104 are the two that are used now. We prefer to use the open protocols, if possible.

"3) How is the system supposed to be accessed? From a local (on site) PC only? Remotely via a web browser? If you need remote access, is this just for reports or do you need to change set points and do other control functions securely from a remote (off site) location?"

The system will need to be accessed remotely. The remote access will be required to change set points and perform other control functions (although only around 5 control functions).

"4) What about remote service access by your company? Is this needed? If so, to what degree?"

Right now I'm not 100% sure about our requirements in this area.

"5) How many reports are needed?"

We will need a relatively large number of reports. Probably about 10 "need-to-have" reports in the beginning and expanded to 20-30 if we were able to develop all the reports we wanted.

"1) You need live readings and control signals for controlling the system. How many screens to you need for this? One? Two? Many? Is someone controlling a wind farm, or just an individual wind turbine?"

The current solution has just one "current operation" screen for live reading and control signals. I think that should suffice. However, there is one "Current Operation" screen for each wind turbine in the wind farm.
___________________________________________

Since my background is not in programming and my skills are perhaps too weak for a project of this scope, I think I would prefer to go with a vendor solution since our project timeframe is about 1 year and I am as of now working alone.

I appreciate the time you took to provide suggestions. I really think your comments will help me frame up my project and provide evidence in terms of cost and time requirements that it might be more advantageous to use a vendor solution. I think what I really need is a project manager like yourself with some experience to guide me on this first attempt and then next time I could do it on my own, haha! Thanks again.

 

Can you really compete with a free and feature rich system like MBLogic? I would ask mr Griffin for a quote on a prototype system. If you are worried about long term maintainability, get another Python programmer to have a look at the code.

I don't actually know Mr Griffin or have used the MBLogic system (although I have studied it briefly), but to me it seems to be a really good alternative.

 

Once you are out of the realm of individual wind turbines and into large wind farms, the idea of a simple custom application becomes less attractive. The simple custom program concept was based on the idea that every customer would get an identical package. With large wind farms, every installation could be unique.

I think that you need to sit down and write up some clear and detailed specifications as to what the system needs to do. You won't be able to do this in less than 50 pages. Once you have that, you'll have something you can take to people in order to discuss solutions.

 

In reply to Tallak Tveide: MBLogic is oriented towards discrete control applications. It's not really a SCADA system. If I was writing a SCADA system, I would use a lot of the same components, ideas, and libraries that went into MBLogic. However, the focus of the system and the balance of features would be different.

 

How does status display of multiple identical wind turbines become that much more difficult? Obviously each unit would have to have network addresses set up, etc, but that is the case with anything involving multiple slave units.

 

I've been following this thread, and I think it's gotten out of line with the original post.

As I read the original post, the originator has been hired to work at a wind farm and has been charged with developing a simple SCADA system for multiple wind turbines on the site.

I don't think this is someone wanting to produce a marketable software package, though that might be an option if it's simple and elegant, and inexpensive, and scalable, and easily configurable. And all of those things mean something different to everyone.

I've seen it talked about here on control.com on other posts, but Trihedral Engineering, Ltd's. (www.trihedral.com) VTS and VTScada are pretty popular for SCADA applications. I've seen it in use as a very power HMI application for some PLCs and I recently saw an implementation on a turbine control platform, and it was pretty impressive.

It has lots of drivers for different types of communication protocols and is easily programmable. Screen development is relatively easy. Lots of report capabilities. And, from what I was told, good Customer support.

They're located near Halifax, Nova Scotia, and have thousands of running licenses around the world. Very popular in the water treatment industry, with far-flung plants. Also, power generation implementations all over at least one province in Canada. And the CBC, Canadian Broadcasting Corporation, use their software as well. I believe it's even been used on maritime and naval applications.

 

In reply to Ken Emmons Jr.: The point was not so much the multiple turbines themselves, as much as that a large wind farm is likely to be a custom engineering project. That might include customised software for each installation. I wanted to point out that my previous reply (26 February, 2009 - 7:26 pm) was based on the assumption of a single turbine operating independently.

And having made some fairly detailed suggestions and then suddenly finding all new requirements popping out of nowhere, I felt the need to point out that my previous suggestions were based on assumptions that were no longer valid.

That doesn't mean that the approach to the problem is necessarily the wrong one. It does mean though that the whole problem needs to be re-evaluated in light of the revised requirements.

As to whether dealing with an undefined (and changeable) number of multiple turbines is more work than dealing with only one, it *is* more work. It is going to need a more flexible configuration system and the display screens will need to automatically adapt themselves to new units. Whoever is doing the project is going to need more time to write it.

There are probably a lot of questions that the originator hasn't even thought of yet. With a single wind turbine, you are probably talking about someone providing power for their cottage. With a wind farm, you are talking about a business selling electric power to the grid. Is the software supposed to handle anything to do with revenue records (i.e. how much power and at what time)? That could be a real can of worms, because it probably has to be handled a very specific way and getting the details of that out of anyone who actually knows can be like pulling teeth. What about load dispatching from the grid manager? Does it need to handle that? If so, how do you do it? There are no doubt many more such questions which would have to be answered.

 

I work for a company that developed an inexpensive HMI designer. This might be what you could use, doesn't hurt to check it out. It has built in connectivity to OPC, and is easy to use and can publish to Silverlight. www.StatusVision.com