Control.com - Nerds in Control

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:wboyes@putman.net
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

Harsh, but one hundred percent true. Btw, are you sure your manager is not an old enemy? :D
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.

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

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.

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.

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.

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.

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

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.

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.

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

In reply to Patrick Barker: That is not what I meant by "MBLogic is not a SCADA". What I meant was that it doesn't (currently) log time series data to a database and produce reports on it and do other similar SCADA-like things. It is focused on discrete control (IO scanning, soft logic, and HMI). It could be extended to do SCADA-like things (the framework already has database APIs), but it doesn't do them at present. It's open source, so anyone who wants to do that is welcome to go ahead. It's just not my focus for it at this time.

As for your product, I just followed your suggestion and had a look at your web site and I really don't see what your software could add to the system. So far as I can tell, my software already does everything yours does, so adding your stuff to the mix wouldn't turn it into a SCADA.

I'm sure you have a nice product, but I don't see why I would want to spend thousands of dollars on per seat licenses for a web based HMI when I've already got that.

Hi Wes,

First of all, I don't think developing a SCADA system should be that hard if you are very familiar with a programming language. If not, then the situation is a bit more complicated.

I myself have plans on, with the help of others I hope, developing an open source SCADA because I'm very dissatisfied with the situation today which means I'm forced to use proprietary software. I wish I could totally move away from MS Windows and do all my work in GNU/Linux, but there's still a lot of work to be done before we get there.

Second, there actually is a swedish open source SCADA system, altough I haven't looked at it yet:
http://www.proview.se/

So, anyone up for developing an open source SCADA?

Well, it just so happens that I have some time on my hands.......The Printing Industry is tanking and my employer has decided they don't need Automation and Controls!!!??? Or at least they need someone younger and cheaper to do them. What Language?

Regards

cww

Great idea Kurt, to offer to help this guy.  Sorry to hear about your job though. 

Come to think of it, I am in a similar job situation and could help out also.  For me, I would like to work in a .Net environment, such as C#.  It has most everything one would need if you add a few third party products such as PLC drivers and maybe some charting tools. 

Bill Sturm

Abbeytronics LLC

First of all, I missed the part that stated that every post has to be controlled by some moderator so I wrote an identical second post before I understood how it works.

And I cannot delete my post if I would like.

Second, I program in Java but since the JVM isn't Open Source the problem with proprietary software still exists, altough in another shape.

I'm aiming at learning C this year.

You should try in the infrastructure sector, in Sweden... We are up to our ears with work and there's more to come. Every company I have worked with are looking for people. We need more people. We are in minority in Sweden, that's for sure.

/M

In reply to Michael: I believe that Java is open source (Free Software) now (GPL). I believe that Sun offers it under two licenses. There is the regular GPL license and Sun also sells proprietary licenses to companies (e.g. IBM) who create proprietary derivatives. Linux distros are now packaging it as a result of this change, which has greatly improved their support for Java.

As for how to write the software, I would suggest settling on some ideas about how the thing would work (in general) and what it would do before deciding on what language to write it in.

I didn't know that Java is licensed under GPL.
I have heard that there was a license changing process going on but that they have come so far was a nice surprise.

When it comes to ideas I can say that I have plenty. I fear though that I lack both programming experience and that I have not been in the business long enough.

First of all there should be some sort of "whiteboard" on the net where brainstorming and idea exchanging can take place.

In reply to Michael I.: The usual way of brainstorming on the Internet is either mailing lists or wikis. A wiki is the closest thing to a white board, but it's not the best way to get started.

The best thing to do would be to get yourself a gmail address that you intend to use specifically for this project and post it here. Anyone who is interested can then contact you. I would suggest doing this right away while people are still following this topic.

What you do then is just send emails back and forth with everyone on the list getting cc'd. Once you have a direction established, you can register a project at some place like Sourceforge, Google Code, Launchpad, or Berlios. These have wikis, mailing lists, forums, etc.

In reply to Michael and Curt Wuollet: I have my hands fairly full with my own open source soft logic projects at this time, but there are likely a number of areas of mutual interest we could cooperate on. In particular: communications, HMI, and artwork for screens (e.g. pumps, fans, valves, etc.) are likely things we could both use. You can look at my project (MBLogic) on Sourceforge if you want to see what I've done so far in that area (or just ask, and I can tell you).

What did you have in mind? What type and size of applications are you targeting? I have suggestions about how such a thing could be created, but I will reserve my comments until I know what your target is.


P.S. - Some other existing open source SCADA projects are:

http://pvbrowser.de/ This is a framework to develop your own applications in C++ rather than a stand alone SCADA. The author posts here regularly. You have to know what you're doing to do anything with this software, so it's not for the average SCADA user. Customers are using it though.

http://www.likindoy.org/ This one is also seeing actual commercial use, but I don't know where development is headed at this time.

http://openscada.org/ They have some screen shots, but I can't tell how much they have actually working though. They talk about their releases, but I couldn't find the software.

http://www.free-scada.org/ They've got a nice looking web site, but when I downloaded the software I couldn't figure out how to use it. I don't know what is working and what isn't. It's also MS Windows only. The author posts here occasionally.

We are still alive :-) At the moment we are updating our website, so there is still a lot of stuff to migrate from our old pages to the new ones. We also just switched to maven2 so our maven repository is to find here http://repo.openscada.org/maven2/ the other (old) downloads are at http://www.openscada.org/download/

You can also subscribe to our twitter feed http://twitter.com/openscada

Hey Everyone,

This is the original poster of this thread. I really appreciate everyone's advice.

To give everyone an update, after doing a more thorough examination of our requirements, we have decided to purchase a vendor solution. Most likely it will be an HMI that provides a user interface that we can build on. Hopefully it would have alarm, monitoring, and other basic functionality built it.

On our side, mainly we will need to develop some custom reports, logs, statistical analysis, etc. Potentially we will need to create a communication driver for our specific PLCs and maybe fine tune the database for our needs.

While there are some expensive vendor solutions like Wonderware's Intouch and GE's SCADA, we will probably select a cheaper vendor solution without a lot of bells and whistles. I know a lot of people have mentioned some vendor solutions earlier in this post, so I will take a further look into them.

Thanks again and good luck to those who might be starting up a new open source solution.

Sounds like a good plan, keep us posted...

Bill Sturm

Abbeytronics LLC

Hi Wes,
What type of turbines are in your farm? Which PLC are you currently using and what existing scada is in place? I think I can help you, or at least give you additional resources. We have engineered a 'fix' for some of the older turbines including the Zond 750, Micons, Kenetechs and V27s and V47s. The biggest problem we've seen with most of these older models is the comm. We've installed a hybrid (fiber and smart radio) at one farm that was very reliable.

Drop me an email if you would like to discuss further: merhab@scadasolutions.com -Good luck.

Wes,

Have you ever considered a vendor hosted, web-based SCADA platform? My company provides device agnostic SCADA data and controls solutions. If you are looking for a low cost option with no need for systems integration it might be an option to consider. The system is prebuilt and user configurable. It doesn't include a lot of fancy graphics but rather focuses on the data, control, alarms, and reporting functions.

If you haven't already made a decision I'd welcome the opportunity to speak with you.

Thanks,
Jason
jason@elynxtech.com

Hi Wes,

Try Proview at http://www.proview.se/
It's an Open Source SCADA system. I have never tried it myself but it seems promising.

I myself would like to develop an Open Source SCADA, with the help of others if someone is interested. I'm very disatisfied with the situation today, forced to use proprietary software and working in MS Windows. The best would be if I could do all my work in GNU/Linux but there's still a bit to go before we get there.

Anyone interested in developing an Open Source SCADA system?

/M

Hi dear,
yes dear i am interested [in] Open Source SCADA system.
presently i am working in seimens.

Writing your own HMI/SCADA solution can be a long and daunting ask. Perhaps you might get the results you need with an Off-The-Shelf solution like ICONICS Genesis64 or Genesis32. These products have Alarming, Trending, and Graphics capabilities, and are OPC enabled. They provide capabilities for remote access via a Web interface for monitoring and controlling the system (Supervisory Control).

Check out www.iconics.com for more information. Or you may contact me directly at j.brown@iconics.com. I will be pleased to help.

Jon Brown

Is Iconics free, that is what the original post requested since they were moving away from a costly licensed system.

For this wind farm system, consider looking for a system that has:

1. Easy ability to define multiple identical units.

2. Consider a GUI that supports the same screen definition being used for different identical units

3. Consider a base SCADA system that supports other operating systems for stability and security as these are systems that need to be solid.

4. Consider a base SCADA system that has a little history so that you do not find yourself debugging the fundamentals of the system.

Good luck with the project!

Peter Clout
Vista Control Systems

Wes, I see you have been recommended to Indusoft for SCADA development. Indusoft has some significant advantages for Wind SCADA in it's windows based OS and catalog of available i/o for reading data from PLC's and other devices.

Indusoft works with CCS-Inc. on wind SCADA and I can provide you with more info on the offering.

Scott McMahon CCS-Inc. smcmahon@ccs-inc.com

Wes,

First of all we wish you well on your journey of choosing a HMI/SCADA package! Second, let me make it clear that I work for InduSoft (and a big thanks to Walt and Scott at CCS for mentioning us in this post).

Here are some additional things to consider when choosing a HMI/SCADA package for windpower:

1. Scalability: Do you have the need to deploy solutions from Windows CE (on PDAs, mobile phones or Industrial displays), embedded XP, desktop environment (XP, Vista) including "industrial PCs" all the way up to a server type environment all with one package? Your training and experience are valuable assets; don't abandon them just because you have a wind farm today and a "small wind" project next. A package that can work across all Microsoft supported platforms, including scripting and database connectivity, should be evaluated.

2. If you need to log data to a relational database (Oracle, MySQL, MS SQL Server, and more), which one will it be used now and in the future? The operating system you choose today may not be suitable for the next project. Choose software that will not only run on a desktop operating system such as Windows XP or Vista and even Server Editions, but down to Windows CE as well. And as you get into the typically smaller or remote systems that Windows CE can offer, make sure the database you choose is supported by the HMI/SCADA vendor even from an embedded environment like CE.

3. Watch out for "hidden costs". Does the vendor make you pay for extra modules like trending, alarming, recipes or reporting? What about a required support contract? Is there an added cost to support the local language where your system will be deployed? Drivers: InduSoft has over 200 built-in at no extra cost!

4. Connectivity: Not only PLC or your own controller, but the flexibility to support OPC for drivers that aren't built-in yet. What about displaying video to remotely view the wind farm (or catch vandalism)? Displaying information on a mobile phone should be a "must have" as we all know the service staff just sit at their desk eagerly waiting to go on the next service run. What about showing a wind forecast so system adjustments can be scheduled automatically?

5. Remote connectivity: Can the system be updated remotely over the internet? What about over a radio system or satellite link? Can the system email reports to web enabled phones or send reports in XML format as an attachment? And when the link fails, can the system be configured in a "store and forward" mode?

6. If the system doesn't have the built-in functionality in the on screen objects (alarming, trending, buttons, 3D graphics) does the system support a scripting language that will give you the flexibility to do just about anything you need? And, will this scripting language run on all platforms (even in Windows CE)?

7. Ease of configuring the database connection and remote web browser. Some systems can be quite difficult and others make it very easy (and less time consuming).

You can download a full-featured demo. Or, visit www.indusoft.com for more information

Good luck in your decision process.

I see InduSoft is listed as a "Legacy" product on Nematron's web site. I assumed Nematron had purchased InduSoft like they did with Intec's Paragon software only to let it waste away.

Peter

(I have a dozen Paragon apps that I need to upgrade to something else. Arg!)

Hi,

Are you located in INDIA. I am also intersted in Developing this knid of system. If you are intersted you can contact me.

Regards,
Arun T K
Director
Softapps IT Solutions (P) Ltd.

Search for X-Force brand SSM InfoTech, they are developing customized SCADA software with your brandname and its royalty free for future distribution to your customer.

Looks like you are getting a lot of good advice.
I think you should talk to PCI - company, has done so many project, the system is open source, No runtime royalties. Using .Net technology.

www.parijat.com
I am sure this will help.

Thanks
Sam T

Wes- I did do this for a customer one time.

We did a private Label of National Instruments Software (www.ni.com)

It worked out OK.

the price ended up being $ 100 a RT for 500 data points. From that Runtime we could actually attach other applications by OPC and via Web Browsers.

So you can have one node right at the Wind Farm with the live data and then update or "push" data to people looking at the same screen in a browser like Fire Fox, that way you can have as many "FREE" screens as you need , and still have one that is secured and has the alarms and trending protected. no one really wants to build a "scada" from scratch since there is no profit in it. You would have to sell Hundreds of farms a year to make it worthwhile. It makes more sense to buy one SCADA Runtime per farm and then share the data from the browser. And at that point you can customize the browser screens and have web page programmers under contract to do that type of work as much as is needed. You want to avoid taking on a support headache that will eat away at the companies reputation and time with your customers. Most Wind Farms are many millions of dollars so spending $ 500 a farm for one lic should not break the bank.!!

sean

If you have a Plc why not just use ip21 (infoplus 21). http://www.aspentech.com/core/aspen-infoplus21.cfm

depending on your objectives it may be the perfect solution. Email me if you are interested in investigating.

You may want to have a look at this framework:

www.controlsystemworks.com

In brief:
- .NET/Silverlight (yes, web-based client);
- currently supports only OPC and SQL database data sources;
- data logging: requres some programming on your side;
- alarms: basic functionality, history to SQL database;
- unlimited UI flexibility (use any third-party silverlight controls)
- open architecture - you can write your own extensions;
- small company - your questions are usually answered promptly.

Best way would be to take a look on what already exists. SAMTECH company already works on WIND turbine software since several years and developed SCADA systems in its own environment.

Please don't hesitate to contact me to have more information or please visit our website (www.samtech.com)

I would be pleased to answer to any question