So I've been tasked with redesigning/rewrite our SCADA system for the systems we are currently developing. The current control system runs on simple WinXP PC and is completely custom and developed largely on a contract/service basis and has proven to be a headache.
We would like to use a soft PLC runtime engine probably also running WinXP for simplicity as hard rt control is not required and embedded systems are to restrictive. We require specialized IO drivers as well as a system where the logic is remotely upgradeable while the process is running. We have looked at several vendors and unfortunately cost is an issue especially around distribution royalties.
ISaGRAF seems to fit many of our requirements on paper but it seems to be lacking in the usability front though I'm sure there are worse products. Some of the bigger vendors look to have the proprietary integration problem where to get a full solution you end up spending 2/3 of your budget on there stuff just to get all of the required pieces and if you don't then you spend even more working around the limitations.
Would anyone using Soft PLCs wish to share any experiences or recommendations? Has anyone used it in a continuous process successfully for more than 6 months to a year or longer without issue?
If you mentioned your requirements it'd be easier to describe other systems. I'm quite familiar with Beckhoff TwinCAT. We (company I work for) use it for different projects in machinery field. It covers typical PLC tasks as well as motion control.
Thanks for responding. Fair enough, I was hoping to start a discussion and see if I got any responses. Basically, I've got a lot of flexibility with the exception of cost. We are an OEM of fairly large systems so space for a PLC or PC is not really an issue (dont really want to go into detail of the equipment if its not needed). Basically these systems will be interfaced with approximately 600 I/O points (much of which are analog input for Thermocouples) and need to log all that data in rates of about 20Hz in several scenarios otherwise logging rates will be about 1Hz or less. The data should be logged to a central server over the internet regularly as the remote operator stations need sufficient time to respond to upset events. Its possible that the systems may not be able to connect to the central data centers so it needs to be able to log the data offline until it can connect again.
The systems are remotely deployed and will be operated through the internet most of the time. Using traditional IO options has proven to be very expensive especially the Thermocouple boxes so we are designing our own distributed I/O system which will use TWI as the physical layer and one of the open systems CANopen, I2C for data and transport. Because of the open system requirements, its also perceived as difficult to interface with the standard suppliers in an efficient way.
Traditional PLCs (aka AB, Siemens) were investigated but have been determined to be too expensive mostly because of IO and the data logging. Ideally, the runtime cost per system is less than $2000 or so. Embedded PC based PLCs are a secondary option to the PC as they can typically run WinCE and allow us to write custom interfacing we may need.
The deployed system does not require any HMI but should be controllable from the field when commissioning or servicing which means that we may need direct access.
ISaGRAF looked promising as the core control engine and interface to I/O as we can buy a development kit and write our own drivers. Not a lot of vendors seem to let you write a custom driver. The control logic can be handled by IEC 61131-3 systems but some engineers indicate that they may want the ability to write custom logic. Its desirable that the control logic be upgradeable while the process is running and in under one cycle. (This is mostly for development systems but potentially also for deployed system).
We could write our own control engine but that will only add a lot of time and overall cost and probably not be as easy to use. Plus the runtime update maybe tricky.
I'll take a look at the suggestions already posted.
I can't recommend a specific soft logic ("SoftPLC" is a trademark) solution, but I have a few points you may wish to consider.
A) You stated that you have 600 I/O with "much" of it being analogue. You have a maximum acquisition rate of 20 Hz, but typical is 1 Hz. You also need to not lose any of that data if network connectivity is lost. If we assume you have 300 analogue inputs, that results in about 600 bytes per second of data, or somewhat more than 2 megabytes per hour that you may have to buffer for an unspecified period of time. That seems to be outside of what typical conventional PLC could handle and suggests a computer with mass storage is required.
B) You seem to have a fairly large data acquisition requirement. I don't know your application, but is it feasible to split the data acquisition from the control? This might simplify the problem instead of looking for something that does both well.
C) You said you are considering as one option using an embedded PC with WinCE. I wouldn't suggest this in your position however. WinCE and the various hardware it runs on tend to be very proprietary with short product cycles. This wouldn't be such a problem if you controlled the hardware platform, but you are looking at buying a third party system. Both what is included in the OS and the design of the hardware tend to be different from vendor to vendor and from model to model. This is especially a problem for you as you intend to write your own drivers. You may find yourself having to re-develop the application over and over again to chase a moving target. Instead, I would suggest sticking with a more mainstream operating system and PC compatible hardware (not necessarily an ordinary desktop PC though).
D) Microsoft Windows XP is obsolete today and falling out of support in 2 years. That is a relatively short period of time for something you are designing today. "Extended" support for it will go a few years beyond that, but that requires you have an extended support contract with Microsoft which can be rather expensive, and it still isn't a long term solution. In general, if you are looking at using Microsoft Windows, you are going to have to plan on not using MS-Windows XP.
E) The replacement for Microsoft Windows XP is Vista. The copy protection requirements for this are much more stringent than they were for XP. There is no more "corporate" version which doesn't need "authorisation". Instead, you have to "re-authorise" the installation every few months. Large companies are expected to install "authorisation servers" to do this automatically (and to calculate the licensing bill). If you decide to use Microsoft Windows Vista you are going to have to figure out how you are going to deal with this. You will also have to come up with a plan on what to do if MS-Vista suddenly decides that a legitimate installation is actually "pirated" (this problem crops up due to software bugs) and shuts down the application (it leaves you with just enough OS functionality to manually run the re-authorisation procedure).
F) You are planning on putting the system on the Internet in an unattended installation. The security requirements for this should be a central part of any plan. Hooking up an MS-Windows box directly to the Internet and counting on anti-virus software and a firewall for protection for this application sounds like a recipe for trouble. If an update to the anti-virus software knocked out your application (which wouldn't be unusual), every installation you have would be down and may require an on-site visit to fix. If you held off on installing virus updates until you tested them, your equipment would be vulnerable during the peak of the virus problem (with the same result as before). Using an operating system that isn't as vulnerable to virus problems begins to sound more attractive for the Internet interface when looked at in that light.
G) You said you wished to have the "control logic be upgradeable while the process is running and in under one cycle". Is that one *machine cycle*, or one *logic scan*. There is quite a bit of difference. I've done logic changes between machine cycles using a conventional computer programming language, and it wasn't difficult. Doing it between *scans* though (on-line programming) is a more difficult matter (you would have to save and restore some of the variables).
As I said at the beginning, I don't have any specific product recommendations for you. I hope the above observations though will help you in evaluating whichever ones you decide to look at.
First, thanks for the response.
Michael Griffin:> A) You stated that you have 600 I/O with "much" of it being analogue. You have a maximum acquisition rate of 20 Hz, but typical is 1 Hz. You also need to not lose any of that data if network connectivity is lost.
With the data logging it would eventually be forwarded to a historian. This would expected to be report-by-exception most of the time. The only non-PC PLC I could find that could do this would be the SoftPLC were a PCMCIA card could be added. Adding a computer+PLC adds to cost and logistic issues at the site. Unfortunately these will tend to be remote sites so a common data logger PC between equipment is not an option.
We actually already have a data store-and-forward, report-by-exception logger but it only runs on Windows.
> B) You seem to have a fairly large data acquisition requirement. I don't know your application, but is it feasible to split the data acquisition from the control? This might simplify the problem instead of looking for something that does both well.
Indirectly, part of this exercise was to see if such a solution existed. It does not seem to.
Michael Griffin: C) You said you are considering as one option using an embedded PC with WinCE. I wouldn't suggest this in your position however.
Good advice. I figured this supply chain could be a difficulty in the future if the vendor disappears or the OS is no longer supported then thats a major issue. I'm strongly leaning toward keeping the industrial PCs which are not desktops and keeping Windows.
Michael Griffin: D) Microsoft Windows XP is obsolete today and falling out of support in 2 years. That is a relatively short period of time for something you are designing today. "Extended" support for it will go a few years beyond that, but that requires you have an extended support contract with Microsoft which can be rather expensive, and it still isn't a long term solution. In general, if you are looking at using Microsoft Windows, you are going to have to plan on not using MS-Windows XP.
Another good point. Its getting more difficult to strip the Windows OS down to barebones execution.
Linux seems to be the best alternative with this and your Vista points. Not crazy about it as a platform as it increases the requirements on the developers/control engineers involved with the project. Other RTOS flavors are even worse from what I can see.
Michael Griffin: > F) You are planning on putting the system on the Internet in an unattended installation.
Agreed. I'd like dedicated hardware between anything and the PC regardless of the OS. Even a cheap router is sufficient for this. That of course introduces additional complexity and cost but this is a reasonable spot for it if there ever was.
Michael Griffin: > G) You said you wished to have the "control logic be upgradeable while the process is running and in under one cycle". Is that one *machine cycle*, or one *logic scan*.
Logic scan. I'm sure I have more time than that in practice and it can take as much time to prepare itself as needed to make the switch. There is not much time before the safety hardware triggers an emergency stop but its definitely more than one logic scan. I agree its tricky.
Saving and restoring variables can be achieved through shared memory if control is done through separate processes.
Michael Griffin: > As I said at the beginning, I don't have any specific product recommendations for you. I hope the above observations though will help you in evaluating whichever ones you decide to look at.
Thanks for the input its quite useful and your points are very articulate.
I have some additional responses to you, which I have interspersed with your reply.
> Todd: Good advice. I figured this supply chain could be a difficulty in the
> future if the vendor disappears or the OS is no longer supported then thats
> a major issue. I'm strongly leaning toward keeping the industrial PCs
> which are not desktops and keeping Windows.
Something you might consider besides the regular industrial PCs is the newer low power embedded formats (such as Mini-ITX). The market for these is in point of sale, kiosks, entertainment systems, firewall/security appliances and vehicle use as well as industrial applications. The cost is lower than the typical "industrial" prices because they sell into a bigger market.
Motherboards are 150 $CND to 300 $CND (including CPU, but not including RAM). They will run MS-Windows, Linux, BSD, or whatever 32bit x86 PC OS you want to use.
They tend to be slower than the latest desktop or server PCs, but you can get them in fanless versions. The fanless ones have a big heat sink instead of CPU fan (they use a VIA or Geode CPU) and they take a lap-top style external
power supply (again, no fan and you can change them without major PC surgery). If you get rid of the fans, you get rid of a major point of
failure. Power consumption on a Mini-ITX board is a fraction of that on a conventional motherboard (less than 15 watts is typical), which is why they don't need a fan.
Another thing to consider is using flash memory instead of a regular hard drive. You could have a 1GB flash drive for the OS and application, and another for the data (so you can do a complete on site application "upgrade" by just swapping a flash device without having to transfer the data over). You'll need flash compatible software though (I will come back to this later).
Getting rid of the hard drive gets rid of the other main point of failure. If you have no fans and no hard drive, you have a generic hardware package that should have reliability comparable to a PLC.
Also, if you are using a UPS (which I would recommend), you can use a smaller and cheaper one if you have low power consumption. UPS cost seems to be closely proportional to battery size, at least for the smaller ones. You will
need to oversize the UPS by quite a bit (by several times the nominal power consumption), so size matters. One reason is that battery capacity drops off with age. Another is that you need enough capacity for several shut-down cycles (power interruptions often come close together without time for battery re-charge).
> Todd: Linux seems to be the best alternative with this and your
> Vista points. Not crazy about it as a platform as it increases the
> requirements on the developers/control engineers involved with
> the project. Other RTOS flavors are even worse from what I can see.
As a minor point, a "standard" distributions of Linux is not an RTOS. There are RTOS versions of it, but I don't think you need one (according to what you said). The same applies to BSD unix. As to whether developing for Linux is "difficult", that may be true for the real time versions, just as it is for any RTOS. That though is because real time is difficult, not because of
the OS itself.
Normal Linux distributions are not real time though, and they don't have the difficulties associated with an RTOS. Application development is about the same for either MS-Windows or Linux (although it is usually easier to get useful information for Linux than it is for MS-Windows). Whatever major programming language you wish to use is available for both (C, C++, Java, Python, C#, PHP, etc.). Most modern programming languages are either descended from 'C' or draw a lot of their syntax from C, and a lot of the standard C library is just a list of standard Unix OS calls.
I'll point out that a modern Mac runs on BSD unix, and the target market for the Mac is people who find MS-Windows too hard to use. The guts down inside BSD unix look pretty much the same as the corresponding bits in Linux. If
your software developer doesn't have the technical ability to handle either platform, I'm not really sure they are the right person for the job in any case.
If you want to create a "stripped down" OS installation, it is probably easier (and cheaper) to do this for Linux than for the latest version of MS-Windows. If you want to create a fanless, driveless PC (as discussed above), you should be able to do this for Linux in a straight forward fashion. You can get off the shelf Linux distributions that boot and run from a USB key (e.g. Mandriva, Ubuntu) for about the cost of the USB key. There are also instructions on the Internet on how to make your own. As long as you don't include someone else's proprietary software, you can copy these to your
heart's content without worrying about license fees or copy protection. Doing this for MS-Windows may be possible, but I doubt that it is as easy and it certainly isn't free.
> Todd (on internet connectivity): I'd like dedicated hardware
> between anything and the PC regardless of the OS. Even a cheap
> router is sufficient for this. That of course introduces additional
> complexity and cost but this is a reasonable spot for it if there ever
The router is a good idea. It's not a complete solution on its own though. People can still hack you through the router if your OS is open to it. The router idea is also only going to work if you can get an ADSL connection in
that location. If you can only get a dial-up connection in some locations, you are going to have to deal with security without a router.
For dial up modems, I would recommend external RS-232 (not USB) ones. For the router, use one with an Ethernet connection, not USB. The USB connected stuff tends to not be as reliable because of driver problems.
Also, you should have some way to automatically reset the router or modem. Sometimes the routers don't sync on start up, or the modems freeze, and they need to be reset manually. A relay in the router's or modem's power line that is controlled by the control system would probably do. You might also need to tell the OS to "try again" on its connection with the router if you have to reset it (this part of it possibly might not be a problem if you can use a fixed IP instead of DHCP on the Ethernet connection).
> Todd: Logic scan. I'm sure I have more time than that in practice and
> it can take as much time to prepare itself as needed to make the switch.
> There is not much time before the safety hardware triggers an emergency
> stop but its definitely more than one logic scan. I agree its tricky.
> Saving and restoring variables can be achieved through shared memory if
> control is done through separate processes.
You might want to talk to Jiri Baum or Curt Wuollet (both use this list). They have been working on a free/open soft logic system, and they might have some suggestions for you.
I don't know your application in detail, so I can't give you a real recommendation. At some point though, you have to make the trade off between using an off the shelf product and living with its limitations and cost, or putting in the additional work in advance to come up with something you control which is tailored to your needs and budget.
One thing to keep in mind though is to not get hung up on just the control software too early in the evaluation. Sit back and look at the whole picture - hardware reliability, power and cooling requirements, security, software licensing and copy protection, etc. These are fundamental criteria that you can't just paper over later. Put them up front where they belong.
Creating the overall software platform is a cost and pain that you go through once, while the others are costs and pains that you will have to live with throughout the service life of the product.
It's a pretty tall order just for XP to _run_ for a single month without issues. I've heard good things about SoftPLC (the company) for stability. You kinda have conflicting requirements, the RTOS requirements are restrictive because that is how you achieve reliability. 200k of audited code active is generally going to be a lot more reliable than 40 million lines of secret code never intended to be high-rel that stresses user interaction and appearance above all else. Maybe someday there will be a general purpose OS that meets your needs. In the meantime, the best solution seems to be a system that you can pare down to only what you need.
Have you used XP? I know that you are very pro-linux, and commend you for that, but my XP experience has been far better than the 9x and NT 4 life. My home machines run XP pro on one and XP home on the other. Even with all the gaming, programming, downloading, installing, un-installing, etc. that goes on, they have been up for close to a year without reboot.
I am right there with you questioning the determinism of Windows and the suitability of the OS for industrial application, but I think the
crash-frequency horse has been ridden as far as it can...
In reply to Joe Jansen: You've done "installing, un-installing, etc." (I assume that includes MS-Windows updates) on multiple PCs that have been running non-stop with MS-Windows XP for a year without a single re-boot? I must admit being a bit surprised at hearing this. Most installations and updates that I have seen require at least one (and sometimes several) re-boots. Perhaps you would like to tell us how you do this.
Tut tut, this means you haven't been applying the security patches. At least six of them in the last year required reboots :) Seriously, I think we all agree that XP is much more stable than earlier systems, but still far short of the level required to control automation processes. The systems (2 - running data collection) that I have out there running XP, can manage a respectable 27 days uptime average.
I would partially disagree that XP is inherently unstable as we have had a field systems currently deployed using XP with uptimes of several months and the shutdowns would have been the same for other OSes. I would expect XP to have more security issues though and to be more difficult to configure properly but an RTOS brings with it its own issues. Custom C code while potentially tighter also tends to be more difficult to deal with in some deployment scenarios and requires significantly more skill. If a lot of engineers had high regard for the current soft PLC control software I would be happier but I'm not getting that feeling. Most of it seems to have peaked around 2000 and real development stopped by 2003.
I have looked at SoftPLC and it has some desirable flexibility and certainly is lower cost.
You could try with Visual PLC and Visual I/O from http://www.arsoft.eu
You will not need to pay royalties or runtime licences for any application you will develop
This company can offer you several products to solve your project. If you want to offer your e-mail address I will can communicate with you. Or send me an email st autcon20ATyahooDOTcomDOTar
I Hope this helps you.
For Independant Liquor, for their product blending tanks, I used a Panel PC with a Siemens Profibus DP card plugged into the PCI slot. Then I used Siemens WinCC to program the SCADA, which was talking to Siemens WinLC Soft PLC. This was communicating to the Profibus DP card which in turn, on the Profibus network, had all the analog I/O and digital I required, the network also had 2 ASi network masters as DP slaves.
All ran fine, it's now been in for 5 years.
I`ve been doing some research lately into finding nice open soltuions to automation on a couple of projects. I`ve more a computer/ electronics background than control, but...
- Windows XP embedded could be a good one to look at for keeping your installation to the minimum.
- If you could find a SoftPLC that runs on WinXP (hence win XP embedded) developed in Java or using dot net (i.e. interprative languages) hardware and hopefully windows OS obsolescence should be easier to do. Granted speed performance may not be so good in interpretive land, but for a single task, non RT, it may be acceptable.
Regarding stability etc. of Windows - freeze a configuration once it's running and limit updates etc... Sure, it's not guaranteed, but should perform fairly well. Add a flash drive rather than disk and reliability will be fairly good.
We had been using PC Based Controls at United States Postal Service for a number of years.
About 3 years ago we switched to Cleveland Motion Controls FALCON-Runs great 24/7/365 days
Code portability from the older controller to the new one saved a lot of time.