Slashdot Mirror

I'm confused about what, exactly, is supposed to run on top of this new operating system.

Is it supposed to be a new OS for devices with physical-layer control capability like PLCs (Programmable Logic Controllers), DCSs (Distributed Control Systems) and RTUs (Remote Terminal Units)?

If so, I don't see how it would help, since each of these devices has its own unique proprietary hardware architecture. It's highly unlikely Kaspersky could effectively support the hardware.

Or is it supposed to be for hosting central SCADA servers, and historian/MES server type applications?
This is probably the easiest place to gain some traction, although most of the SCADA servers, historians and MESs I've ever worked with have been based to a lesser or greater extent on Microsoft technologies. For example, the OPC APIs are one of the most common ways of interconnecting server-side ICS software from different vendors, and that's based on COM/DCOM - so it's unlikely to be supported on non-Windows platforms. One way you can make it work is to have the SCADA server itself run on a non-Windows platform which then communicates using a proprietary protocol to a Windows data interchange "gateway" which runs an OPC interface. But if your data interface gateway gets pwned, you might not have gained much from having the main server process running on some kind of ultra-hard OS.

Or is it supposed to be for hosting client applications that humans interact with directly (HMI) for control, monitoring, data analysis, or engineering (configuration/programming/diagnostics/troubleshooting) purposes?
At the moment, the actual operator interface for most SCADA systems are proprietary desktop apps, although there does seem to be a trend towards using HTML5 and other web technology for the operational HMI. That eliminates the need to deploy & manage client software and reduces the dependency on Windows. With appropriate access controls on the SCADA server (DON'T allow access from the internet!), that's not necessarily a problem. But right now, an operator generally interacts with their SCADA server by running a desktop (usually Windows) application which connects to the server. The desktop apps are maintained by the ICS software vendors and for reasons of cost and market penetration, almost all the "modern" ones target Windows primarily and other OSs secondarily if at all.

But aside from the fact that most of the client apps are Windows apps, the operator interfaces generally need to run on a general-purpose OS because analysts need to be able to collate & correlate data from ICS and non-ICS sources, and plant operators need to be able to access other business systems like maintenance planning & dispatch tools, weather data, security camera systems, work plans, enterprise reporting systems, etc. There's no point in collecting extensive data about your operations if you can't actually use it to improve your business's operations!

Basically, you need to be able to run Excel, a web browser, and (for the engineers) more proprietary tools from your hardware vendors for things like configuring/troubleshooting the SCADA hardware.

Web browsers are of course very cross-platform, and non-Excel spreadsheet software does exist (although Excel basically owns corporate data analysis at the low to middle end, at least in the West). But web browsers on all platforms are pretty flakey from a security perspective and almost all the configuration, programming and diagnostic software tools which come with industrial hardware are, again, based on the Win32 or .NET APIs because that's what corporate computers have. There is little likelihood that industrial hardware vendors will be enthusiastic about rewriting all these tools for an exotic new OS. And since the primary design objective of the exotic new OS is security, it presumably doesn't use existing complex and bug-riddled desktop environment software stacks.

Is a WINE + Mono compatibility layer on

While I detest the whole IE 6 fiasco, and generally IEs before that were useless, mixing "the whole COM idiocy" into the discussion shows you're, well, clueless. COM is a way of instantiating and calling methods on objects. Nothing more, nothing less It comes with a bunch of OLE APIs for other things (say structured storage, control embedding, ...), but nobody forces those upon you. I'd say there's nothing to complaing about w.r.t. COM, apart from the fact that the design has some unnecessary idiosyncracies and complexities that weren't properly hidden away. Some of the complexity in COM is needed simply for it to do what it does -- for example the threading model is what you need to do in order to be explicit about how instances are shared among threads and to avoid the fiascos of running threading-usafe methods from multiple threads. COM is slightly obsolete at this point, and pretty much a necessary evil. If you're developing a windows application, you can either use COM and be out-of-the-box compatible with C/C++ code out there, or you can expose SOAP interfaces and pay the performance penalty, or you can provide .net interface. Otherwise you're irrelevant, pretty much. There are of course various ad-hoc and industry-specific things out there, like, say, OPC, but they either use COM or are conceptually quite simple (say a fixed-packet-format remote control interface).

Eek, that's no joke, it's real:
http://www.opcfoundation.org/Default.aspx/01_about/01_whatis.asp?MID=AboutOPC
---
OPC is a series of standards specifications. The first standard (originally called simply the OPC Specification and now called the Data Access Specification) resulted from the collaboration of a number of leading worldwide automation suppliers working in cooperation with Microsoft. Originally based on Microsoft's OLE COM (component object model) and DCOM (distributed component object model) technologies, the specification defined a standard set of objects, interfaces and methods for use in process control and manufacturing automation applications to facilitate interoperability. The COM/DCOM technologies provided the framework for software products to be developed. There are now hundreds of OPC Data Access servers and clients.

Everyone's favorite analogy for needing the original Data Access Specification is printer drivers in DOS and then in Windows. Under DOS the developer of each application had to also write a printer driver for every printer. So AutoCAD wrote the AutoCAD application and the printer drivers. And WordPerfect wrote the WordPerfect application and the printer drivers. They had to write a separate printer driver for every printer they wanted to support: one for an Epson FX-80 and one for the H-P LaserJet, and on and on. In the industrial automation world, Intellution wrote their Human Machine Interface (HMI) software and a proprietary driver to each industrial device (including every PLC brand). Rockwell wrote their HMI and a proprietary driver to each industrial device (including every PLC brand, not just their own).

Perhaps there is an OPC driver available for your meters? Then you can use your skills as a dev to read the meter's binary output directly!

• PLC's are notorius for having poorly written ethernet communications code. They can really screw up your network. We keep them on separate VLANs.
• Make sure your control software can talk to everything you need on the plant floor.
• OPC compliance can help, but it can be buggy. Make sure you test all components thouroughly.
• We had many custom VB6/VB5 programs running on NT. For those that could not be updated easily, or we did not have source code for, or were too expensive to upgrade, we moved them to VMWare ESX Server with the P2V assistant. It was a lifesaver.
• We use GEFanuc's product iFix for our HMI. There are many other similar products out there from many different vendors. Most of them have very restrictive and expensive licensing. iFix fit us the best at the time.
• We moved all of the old junk desktop/tower server machines to proper rack mount servers and virtual machines.
• Develop a good relationship with a good automation integrator. They can help you more than you think.

We're about to start on a big database backend for scientific and engineering frontends, and I'm having the damndest time trying to find a product that was designed with an eye towards what I'd call "basic mathematics".

Our short-term needs:

1) True 64-bitness in the access language, so that we can take advantage of our AMD64 hardware & Win64 OSes with an eye towards very large data sets in the future. Java is a no go here, because it will NOT take something as trivial as a 64-bit counter in a "for"-loop. [Recent versions of C++ and C# will, however].

2) A very strong sense of type in the access languages, and preferably in the underlying database itself. For instance, ideally the database would know [inherently] how to deal with primitives such as

a) all variety of 16-bit & 32-bit Unicode characters
b) 96-bit Intel & AMD extended doubles
c) 128-bit Sparc extended doubles
d) 128-bit Altivec extended doubles
e) 128-bit LabVIEW timestamps
etc

Classical business-oriented programming languages, like SQL, are very ASCII oriented, and typically everything gets dumped in the database as strings of ASCII [8-bit] characters, with proprietary logic added afterwards to lend a sense of type to the data. We want the underlying database to understand type, however.

3) A sane, stable, and rather fast transport protocol to move data from client workstations to a centralized repository. Candidates might include DSTP, OPC, SOAP/SOAP+, etc. Preferably the transport protocol would have a strong sense of type as well, so that you wouldn't need to add extra logic on the client end to encode the type, followed by extra logic on the server end to un-encode the type.

4) Solid, stable, and fast replication for redundancy purposes.

5) Good, solid integration with an industry standard user authentication system, such as Novell Directory Services, or Microsoft Active Directory.

Long term, a future interest will be in the area of what I might call a systematized approach to scientific data analysis, and particularly things that go under the guise of e.g.

They are on it!

(Note that the last references OPC, apparently a sensor standard)

I'm writing this from work, so I'm an AC.

You need to look at the SCADA systems market. According to most utilities managers, Bill Gates can do no wrong. They use things like Invesys's Wonderware, Citect, and all sorts of things, as long as they're OPC capable. Of course, this ties them to NT platforms and the like. And that's just where Chairman Bill likes them.

Now don't get me wrong, we work very hard to ensure that NOTHING ties in to our SCADA system which doesn't need to be there. However, the number of twits who see the steaming heaps of data that a SCADA generates is not small, and they all want a piece of it --on their network. So we're constantly fighting this battle and sometimes we lose. Enter the opportunity for a virus.

I have argued strenuously against Windows. I have argued till I'm blue in the face to stay the hell off the intranet. That doesn't stop these idiots. Nothing will --until we have a massive disaster caused by something like this.

And when it blows up, guess who gets to fix it and take all the heat? Welcome to my nightmare.

Interesting.

But it doesn't seem MS-centric from what I can tell and couldn't you use;

http://www.opcfoundation.org/Downloads/White%20Pap ers/DCOM%20on%20Non-Microsoft%20Platforms.pdf?

they do it because it's easy, thanks to OPC (OLE for Process Control). It's very popular for interfacing different computing platforms and control devices using Windows. Just get an OPC driver from the manufacturer of the PLC, analyzer, flow computer, etc. Maybe if there were a comparable Linux/other solution, and manufacturers supported it, the control systems engineers would use it. Until then, expect this kind of stuff...

http://www.matrikon.com/drivers/opc/whatisopc.asp

OLE for Process Control (OPC) is a new technology designed to bridge Windows based applications and process control hardware. It is an open standard that permits a consistent method of accessing field data from plant floor devices. This method remains the same regardless of the type and source of data. Therefore, end users are free to choose the software and hardware that meets their primary production needs, without having to consider the availability of proprietary drivers.

OPC components fit into two categories: OPC clients and OPC servers. A client is typically a data sink -- an application that uses data in some way, such as an MMI or SCADA package. A server is a data source -a device specific program that collects data from a field device, and then makes it available to an OPC client.

and DCOM definately appears to be in the mix as well:

http://www.opcfoundation.org/Downloads/White%20Pap ers/OPC,%20DCOM%20and%20Security.pdf

Perhaps the lusers who are uneducatedly blaming the blaster virus aren't entirely wrong.

I work in a Microsoft only shop. We are an integrator that develops systems for manufacturers. The single most important technology we deal with are OPC (OLE for Process Control) servers, which are a Windows only technology. With .NET, I can create a client to connect to the OPC server, get the status of the machine, and relay that information to our MES and ERP systems.

Once Mono reaches a full, stable release, I'll be able to switch over to developing under Linux. Mono will allow me to interoperate with the components on a Windows application server, which we will still need to run the OPC server, but the client will now be able to run on any machine.

Until Mono is ready, I'll continue to use Ant, Vim, and Visual Studio.