Control.com - Nerds in Control
from the Forum department...
Will Cloud-based SCADA come? 
  |
Will Cloud-based SCADA come?
Nowadays, Cloud Computing, SaaS is very popular in nearly all software solution.
Will SCADA also move to Cloud?
Is there any major SCADA vendor has Cloud product?
Nowadays, Cloud Computing, SaaS is very popular in nearly all software solution.
Will SCADA also move to Cloud?
Is there any major SCADA vendor has Cloud product?
|
I hope not, I can't think of a much worse idea for
either reliability or security.
Regards
cww
either reliability or security.
Regards
cww
|
I consider Cloud computing is just a renaming of Mainframe computing where instead of an enormous monolithic computer serving many dumb terminals we have an array of servers that appear to be a monolithic device serving web based clients. What I see as a benefit to the SCADA environment is the utilisation of server farms with virtualisation which can be used to improve the way redundancy works. Virtualise the software, abstract it from the hardware and make it appear seamless to the client. I believe Emerson are working on getting DeltaV to work in a virtualised environment but I don't work with any DeltaV systems at the moment so I'm out of the loop.
Considering how conservative the control industry is I wouldn't be holding my breath for the cloud to come to SCADA.
Chris Jennings
Considering how conservative the control industry is I wouldn't be holding my breath for the cloud to come to SCADA.
Chris Jennings
| Posted by Bright  on 10 June, 2011 - 2:22 am |
> I consider Cloud computing is just a renaming of Mainframe computing where
> instead of an enormous monolithic computer serving many dumb terminals we
> have an array of servers that appear to be a monolithic device serving web based clients.
---- snip ---
There are some SCADA vendor who claim their architecture is "Cloud" ready or "in the Cloud".
https://www.gotomyhmi.com/
https://www.daqconnect.com/daq/company/products.html
Any comments?
I am wondering whether the SCADA server can be moved to the Cloud and there is only a data collector device or PC sit in the factory floor. All the real-time data and real-time control command will be go through data collector device and the cloud-based SCADA server.
SCADA client will just be a web browser which can support reading the real time data and send command anywhere at the edge of the Internet.
The downside of Cloud SCADA I can imaging is:
1. Real-time ability. It may take more time to view the data or sending command. How long it will take in today's Internet? maybe not so long, <2s?
2. Accessibility of the Server.(How if we have a redundant Internet link?)
3. Security. (can it be solved by state of art Cloud security best practice?)
4 Availability (No, I think Cloud Server will be robust enough)
BTW: Will OPC UA make the cloud SCADA happen?
> instead of an enormous monolithic computer serving many dumb terminals we
> have an array of servers that appear to be a monolithic device serving web based clients.
---- snip ---
There are some SCADA vendor who claim their architecture is "Cloud" ready or "in the Cloud".
https://www.gotomyhmi.com/
https://www.daqconnect.com/daq/company/products.html
Any comments?
I am wondering whether the SCADA server can be moved to the Cloud and there is only a data collector device or PC sit in the factory floor. All the real-time data and real-time control command will be go through data collector device and the cloud-based SCADA server.
SCADA client will just be a web browser which can support reading the real time data and send command anywhere at the edge of the Internet.
The downside of Cloud SCADA I can imaging is:
1. Real-time ability. It may take more time to view the data or sending command. How long it will take in today's Internet? maybe not so long, <2s?
2. Accessibility of the Server.(How if we have a redundant Internet link?)
3. Security. (can it be solved by state of art Cloud security best practice?)
4 Availability (No, I think Cloud Server will be robust enough)
BTW: Will OPC UA make the cloud SCADA happen?
|  | Posted by Wassim Daoud on 15 June, 2011 - 11:18 am |
> BTW: Will OPC UA make the cloud SCADA happen?
Interesting, we just blogged about this OPC UA and Clouds:
http://blog.matrikonopc.com/index.php/clouds-bunch-fluff/
Wassim Daoud
Global Solutions Architect
Interesting, we just blogged about this OPC UA and Clouds:
http://blog.matrikonopc.com/index.php/clouds-bunch-fluff/
Wassim Daoud
Global Solutions Architect
|
But look how far we have come! We now replace that mainframe with a room full of servers, each with several orders of magnitude more computing power, usually running only one task each, because of software limitations. They serve files to a bunch of clients, each nearly as powerful as the servers, that struggle to run the display portion, again due to software limitations. And now, to meet some ill-defined and rather dubious "need", they want you to add a vast array of someone else's server farms and storage, running God knows what, for God knows who, often offered by data mining companies.
Sounds like a great idea, sign me up. It's so bad, it's sure to be a hit.
Regards
cww
Sounds like a great idea, sign me up. It's so bad, it's sure to be a hit.
Regards
cww
|
Or a single server running vmware esxi doing virtualization (hypervisor) running 15 of those servers to eliminate what you are talking about......sort of like we do it.....
I'm back
Dave
I'm back
Dave
|
Yes, it is more convenient to crash instances rather than servers. But my guess would be that very few plants would have people that grok that kind of setup. At least in this part of the world. I'm curious, do you still have to reboot periodically to recover speed, etc.?
Regards
cww
Regards
cww
|  | Posted by Kevin Cooper on 13 June, 2011 - 6:52 am |
With window$ it is necessary to reboot long before there is a speed issue....well, an abnormal loss of speed anyway. (When you're processing billions of lines of code, patches, patches to the patches, antivirus software (which I believe is as bad as a virus), viruses, other assorted malware etc, we're always on the edge anyway)
|
Define "Cloud". Every Cloud vendor still has a slightly different definition depending on what they want to sell you.
Do you mean Cloud, like an anonymous google server farm somewhere on the internet? Someone will probably try it one day and find it to be a very unsatisfactory solution.
Do you mean Cloud, like a VMWare server farm in the rack room in the middle of the plant running several virtual servers with dedicated HMI software and thin clients on the operator desktops, all under the control of the DCS engineers? Its already here and we're already doing it.
Rob
www[.]lymac.co.nz
Do you mean Cloud, like an anonymous google server farm somewhere on the internet? Someone will probably try it one day and find it to be a very unsatisfactory solution.
Do you mean Cloud, like a VMWare server farm in the rack room in the middle of the plant running several virtual servers with dedicated HMI software and thin clients on the operator desktops, all under the control of the DCS engineers? Its already here and we're already doing it.
Rob
www[.]lymac.co.nz
|
> Define "Cloud". Every Cloud vendor still has a slightly different
> definition depending on what they want to sell you.
---- snip ---
Thanks for u reply. Rob!
What I want to say is Cloud Computing platform, such Google AppEngine, Amazon EC2 or MS Azure, etc. Can we create a SCADA service on top of these framework?
I agree security is a big issue. Then can part of SCADA function move to Cloud, such as historical data archiving, event logging, trending, report, etc?
> definition depending on what they want to sell you.
---- snip ---
Thanks for u reply. Rob!
What I want to say is Cloud Computing platform, such Google AppEngine, Amazon EC2 or MS Azure, etc. Can we create a SCADA service on top of these framework?
I agree security is a big issue. Then can part of SCADA function move to Cloud, such as historical data archiving, event logging, trending, report, etc?
|
> -----Snip------
> What I want to say is Cloud Computing platform, such Google AppEngine, Amazon
> EC2 or MS Azure, etc. Can we create a SCADA service on top of these framework?
No, these apps are designed for general IT applications, like storage and document sharing They simply cannot offer the level of security and safety required for a SCADA or HMI system. Fukushima on Google? Your plant protected by Sony's Security systems?
Maybe one day, but until we get to grips with the fundamental lack of security in the internet its a really bad idea.
Rob
www[.]lymac.co.nz
> What I want to say is Cloud Computing platform, such Google AppEngine, Amazon
> EC2 or MS Azure, etc. Can we create a SCADA service on top of these framework?
No, these apps are designed for general IT applications, like storage and document sharing They simply cannot offer the level of security and safety required for a SCADA or HMI system. Fukushima on Google? Your plant protected by Sony's Security systems?
Maybe one day, but until we get to grips with the fundamental lack of security in the internet its a really bad idea.
Rob
www[.]lymac.co.nz
|
> Will Cloud-based SCADA come?
I would see big security issues with that.
In times of Stuxnet we should have become aware of security issues.
My opinion is that SCADA should be client/server.
That is a server within the plant with access to PLC and fieldbus hardware. The client should be some kind of "browser" (not necessarily a standard webbrowser). Thus you could connect to your SCADA server from the Intranet/Internet and "surf" from one SCADA server to the next.
The client should be running on a large number of devices from a big PC up to smartphones and on practically every available operating system.
I think that AJAX based SCADA within a standard webbrowser will not provide enough performance and security.
We should use as much standard techniques as possible (SVG, OpenGL, XML, SQL ...)
We should not expose direct access to OPC and Databases to the public. This should be guarded by the SCADA server.
But the big problem is security.
Here standard techniques like ssh should be the minimum. But it should be possible that a specific plant could add more custom security mechanisms that are not known to the public because they are different for each customer.
If you connect through the internet it will be a good idea to allow only watching the plant but no control. If you need control from remote it would be a good idea to make a phone call to the operators and open access to 1 specific IP addres only (temporary for 1 connection). Thus it will also be advisable to use a connection oriented and encrypted communication between client and server.
Ok, some small plants might not need such security mechanisms but they should be available.
PS: With this in mind our http://pvbrowser.org has been designed.
I would see big security issues with that.
In times of Stuxnet we should have become aware of security issues.
My opinion is that SCADA should be client/server.
That is a server within the plant with access to PLC and fieldbus hardware. The client should be some kind of "browser" (not necessarily a standard webbrowser). Thus you could connect to your SCADA server from the Intranet/Internet and "surf" from one SCADA server to the next.
The client should be running on a large number of devices from a big PC up to smartphones and on practically every available operating system.
I think that AJAX based SCADA within a standard webbrowser will not provide enough performance and security.
We should use as much standard techniques as possible (SVG, OpenGL, XML, SQL ...)
We should not expose direct access to OPC and Databases to the public. This should be guarded by the SCADA server.
But the big problem is security.
Here standard techniques like ssh should be the minimum. But it should be possible that a specific plant could add more custom security mechanisms that are not known to the public because they are different for each customer.
If you connect through the internet it will be a good idea to allow only watching the plant but no control. If you need control from remote it would be a good idea to make a phone call to the operators and open access to 1 specific IP addres only (temporary for 1 connection). Thus it will also be advisable to use a connection oriented and encrypted communication between client and server.
Ok, some small plants might not need such security mechanisms but they should be available.
PS: With this in mind our http://pvbrowser.org has been designed.
|
I think the points you are mentioning are valid, but why limit yourself to a system that can serve everyone? I think cloud hmi can serve a purpose for a niche, namely:
- Small companies that don't have a IT department to backup and maintain a PC/Windows based hmi node
- Companies that have process view pages that they want to access from office PC's
- Someone who wants to serve a web image for a TV or thin client shoing a fixed web page
- Someone who doesnt want to deal with licenses and client installations, but instead a yearly subscription fee
For these smaller projects, a cloud based HMI will save money in maintenance and I believe actually dramatically increase uptime and the ability to avoid/recover massive failure of the system (think hard drive crash or virus)
Of course, they might not be the best option for:
- People with real-time requirements (IMHO big name systems I have used don't fare too well in this category either)
- People with sensitive data
- Wherever you have installed robust systems that can be extended to cover the functionality of the smaller system
- When you need interoperability between systems
- Where you cant tolerate that the system drops out for a few hours/days
I believe that there should be quite a few systems that fall mainly in the first group, perhaps even the majority?
- Small companies that don't have a IT department to backup and maintain a PC/Windows based hmi node
- Companies that have process view pages that they want to access from office PC's
- Someone who wants to serve a web image for a TV or thin client shoing a fixed web page
- Someone who doesnt want to deal with licenses and client installations, but instead a yearly subscription fee
For these smaller projects, a cloud based HMI will save money in maintenance and I believe actually dramatically increase uptime and the ability to avoid/recover massive failure of the system (think hard drive crash or virus)
Of course, they might not be the best option for:
- People with real-time requirements (IMHO big name systems I have used don't fare too well in this category either)
- People with sensitive data
- Wherever you have installed robust systems that can be extended to cover the functionality of the smaller system
- When you need interoperability between systems
- Where you cant tolerate that the system drops out for a few hours/days
I believe that there should be quite a few systems that fall mainly in the first group, perhaps even the majority?
|
Don't get me wrong, it could be useful in certain situations if carefully planned and executed by someone who truly understands the implications and you know your partners. Unfortunately, in most automation and especially in the first group, someone will load the software and putz around until they get picture and declare it done. That's the scary part.
Regards
cww
Regards
cww
|
In reply to Tallak Tveide:
>- Small companies that don't have a IT
>department to backup and maintain a
>PC/Windows based hmi node
>
>- Companies that have process view
>pages that they want to access from
>office PC's
>
>- Someone who wants to serve a web
>image for a TV or thin client shoing a
>fixed web page
>
>- Someone who doesnt want to deal with
>licenses and client installations, but
>instead a yearly subscription fee
I think creating screen masks for such applications should be done like you do ordinary web pages today. You should have a framework that provides the necessary infrastructure.
The framework could (should) be open source and free of license fees. The implementation for an individual customer should be done by experts who also know about security issues.
The framework should be tested, used and extended by those experts.
Many customers want/need the sources of their SCADA solution anyway. Thus an open source solution also for the framework should be the best.
The experts implementing the SCADA system for an individual customer earn their money by doing so.
The whole solution becomes competitive because you do not need runtime/developer licenses and the framework becomes well tested and new features can be contributed by all these experts and as a response to feature requests from the customers.
>- Small companies that don't have a IT
>department to backup and maintain a
>PC/Windows based hmi node
>
>- Companies that have process view
>pages that they want to access from
>office PC's
>
>- Someone who wants to serve a web
>image for a TV or thin client shoing a
>fixed web page
>
>- Someone who doesnt want to deal with
>licenses and client installations, but
>instead a yearly subscription fee
I think creating screen masks for such applications should be done like you do ordinary web pages today. You should have a framework that provides the necessary infrastructure.
The framework could (should) be open source and free of license fees. The implementation for an individual customer should be done by experts who also know about security issues.
The framework should be tested, used and extended by those experts.
Many customers want/need the sources of their SCADA solution anyway. Thus an open source solution also for the framework should be the best.
The experts implementing the SCADA system for an individual customer earn their money by doing so.
The whole solution becomes competitive because you do not need runtime/developer licenses and the framework becomes well tested and new features can be contributed by all these experts and as a response to feature requests from the customers.
| Posted by Bright on 12 June, 2011 - 11:57 am |
Security issue is always there for Web-based SCADA, or other IT system such as Bank system. But imaging we move the SCADA server to Cloud, specialists will take care of the security issues. For example, security solution used in Bank(such as Two-Factor Authentication) can be used in the cloud based SCADA. It may be safer than a SCADA Web Server hosted in the factory by itself.
I agree with Tallak that Cloud based SCADA could not fit for all customers. It mainly for SMEs which don't have enough budget or IT professionals, for example the energy management for a building/a small factory. They only need a collector device or PC to send data to the Cloud Server. All the SCADA functions such as HMI, alarming, trending, Event logging, reports, historical data archiving can be provided by the Cloud servers.
If real-time control is a security concern, the Cloud SCADA can leave the control function in the factory Internal network, all the other functions can move to cloud.
I agree with Tallak that Cloud based SCADA could not fit for all customers. It mainly for SMEs which don't have enough budget or IT professionals, for example the energy management for a building/a small factory. They only need a collector device or PC to send data to the Cloud Server. All the SCADA functions such as HMI, alarming, trending, Event logging, reports, historical data archiving can be provided by the Cloud servers.
If real-time control is a security concern, the Cloud SCADA can leave the control function in the factory Internal network, all the other functions can move to cloud.
|
Check out these... not SCADA as such but getting real close...
Izondata.com
And
ProFicient on Demand from InfinityQS
Cloud apps... I can't imagine remote SCADA per se, but using acquired data remotely - absolutely!!
Cheers from: Jeremy Pollard, CET The Caring Canuckian!
Crisis, necessity, change
www(.)tsuonline.com
Control Design www(.)controldesignmag.com
Manufacturing Automation www(.)automationmag.com
3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0
Izondata.com
And
ProFicient on Demand from InfinityQS
Cloud apps... I can't imagine remote SCADA per se, but using acquired data remotely - absolutely!!
Cheers from: Jeremy Pollard, CET The Caring Canuckian!
Crisis, necessity, change
www(.)tsuonline.com
Control Design www(.)controldesignmag.com
Manufacturing Automation www(.)automationmag.com
3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0
|
Our company Fielding Systems has a cloud-based SCADA application called ScadaVisor that serves the oil and Gas industry. We just released our newest version of ScadaVisor that runs on Windows Azure, which makes it the first of its kind. A cloud platform offers significant benefits in terms of scalability and reliability. You can read more about it by going to
http://www.fieldingsystems.com/Products/ScadaVisor.aspx.
http://www.fieldingsystems.com/Products/ScadaVisor.aspx.
| Posted by Bright on 19 July, 2011 - 9:11 pm |
Hi Shawn,
Does your ScadaVisor support remote control? Is there any pricing info on your website?
Thanks
Bright
Does your ScadaVisor support remote control? Is there any pricing info on your website?
Thanks
Bright
|
> Does your ScadaVisor support remote control? Is there any pricing info on your website?
Yes, ScadaVisor does support remote control for a few types of devices. We have built our communication and polling engine so that we can do this type of thing, especially from the mobile devices. We do not have pricing information on our site because it does vary depending on the requirements of the project. I would be happy to discuss this in more detail with you. You can find all of our contact information at http://www.fieldingsystems.com/Contact.aspx.
Yes, ScadaVisor does support remote control for a few types of devices. We have built our communication and polling engine so that we can do this type of thing, especially from the mobile devices. We do not have pricing information on our site because it does vary depending on the requirements of the project. I would be happy to discuss this in more detail with you. You can find all of our contact information at http://www.fieldingsystems.com/Contact.aspx.
|
> Will Cloud-based SCADA come? Nowadays, Cloud Computing, SaaS is very popular in nearly all software solution.
> Will SCADA also move to Cloud? Is there any major SCADA vendor has Cloud product?
Maybe, but not many will stay there.
The "Clouds" are too unpredictable and unsecurable. Like the weather they are just plain too random. Remember the debate on the predictability of I/O updates?
> Will SCADA also move to Cloud? Is there any major SCADA vendor has Cloud product?
Maybe, but not many will stay there.
The "Clouds" are too unpredictable and unsecurable. Like the weather they are just plain too random. Remember the debate on the predictability of I/O updates?
|
I would not be real surprised to see some kind of cloud based HMI/SCADA. But I suspect the cloud will be a server farm that is onsite as opposed to on the other side of the world. The communications networks are just not stable or secure enough at present for anything else.
We already have a bunch of web based HMIs out there, both as standalone and as add ons to other packages. No reason they could not be hosted in India.
It will never be reliable or secure enough to be of serious use for direct control though. How do you calculate a negative SIL number?
The thing is does anyone really think it is appropriate for the control system software for a chemical plant to be hosted in some server farm in China or India?
The thing is that computing power is so cheap that there is no reason for the cloud other than to leverage the computing expertise of the people maintaining the servers. And for the most part, that can be done remotely, and commonly is, so where the hardware is physically located is not as much of an issue as some try to make it.
--
Bob
We already have a bunch of web based HMIs out there, both as standalone and as add ons to other packages. No reason they could not be hosted in India.
It will never be reliable or secure enough to be of serious use for direct control though. How do you calculate a negative SIL number?
The thing is does anyone really think it is appropriate for the control system software for a chemical plant to be hosted in some server farm in China or India?
The thing is that computing power is so cheap that there is no reason for the cloud other than to leverage the computing expertise of the people maintaining the servers. And for the most part, that can be done remotely, and commonly is, so where the hardware is physically located is not as much of an issue as some try to make it.
--
Bob
|
I have Java based SCADA PLC and a logging/remote access server. PLC connects to server using 256-bit encryption, symmetric. Remote access done via central cloud server, updates every 60 seconds. Client software used to view historical data and cache data on client machine. Also working now on the web interface.
Java PLC can be installed on a SBC, to make a field controller. It is scriptable, and support MODBUS RTU. It also stores logs localy, synchronizing with the server.
http://www.java-scada.com
Java PLC can be installed on a SBC, to make a field controller. It is scriptable, and support MODBUS RTU. It also stores logs localy, synchronizing with the server.
http://www.java-scada.com
|
Hello,
there are wrong URLs on your download page. The www.java-scada.com/jar\Java-Scada-4.10-Install doesn't work ...
it must be www.java-scada.com/jar/Java-Scada-4.10-Install.
IMHO ... the clouds technology is in alternative against OPC.
Regards
Armin Steinhoff
there are wrong URLs on your download page. The www.java-scada.com/jar\Java-Scada-4.10-Install doesn't work ...
it must be www.java-scada.com/jar/Java-Scada-4.10-Install.
IMHO ... the clouds technology is in alternative against OPC.
Regards
Armin Steinhoff
|
Wrt reliability one shouldn't be too focused on the network link for all cases. I can name a few cases where you would most definitely gain reliability due to the fact that properly administrating servers is hard, and many organizations depending on scada systems are unable and/or unwilling to do so. This is mostly because of the expense in getting someone to do it, inability to hire someone with correct qualifications, or even not knowing that this is necessary
So when the server crashes, you have downtime of days and weeks. In the big picture, the impact is bigger than a missed 10 seconds of update now and then
So when the server crashes, you have downtime of days and weeks. In the big picture, the impact is bigger than a missed 10 seconds of update now and then
Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2013 Nerds in Control, LLC. All rights reserved.
Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.
Fortune
Job Placement, n.:
Telling your boss what he can do with your job.
