You're right about 64-bit as a future prospect. NRT OS should have been staring me in the face, but I assumed such broad use of real-time kernels, it just sort of passed by me as a don't care - which is silly. Thanks for comments.
Loring, The part I do find interesting is where you mention about controllers changing to 64-bit. Even though there appears to be development in this area considering that most plant floors just recently moved from Windows CE to Windows XP for OS, 64-bit is not supported on an OS until you get to Vista or higher.
You also mentioned two of the three communication needs within an industrial network. Real-time and hard-real-time. There is a third in between the two extremes which is non-real-time. These three communication needs each have timing associated with them and therefore must be processed differently. In today's designs an OEM is locked into one vendor for most products so they interact well within the network or the other option is using bridges which create latency in the communications. Therefore leapfrogging may work for some parts of the network process but not for all areas of need.
You have really given some good 'food for thought' here.
What Jack R. mentioned is one reason why leapfrogging may be inevitable. It seems that application software is often developed with an eye to what sounds cool, rather than the sense it makes to the overall SCADA environment. A perfect example is the forementioned apps for Android and iPhone. Even in the IT community, client smartphone apps are being developed for corporate access, and even some military-security applications, that don't seen to take into account the shakier security and stability environment of the self-invoking smartphone app. When one hears of monitoring or security apps developed for SCADA systems, allowing process managers to check on a power system via an iPhone, there's something that screams "Ooops! Don't want to go there!" But we'll only learn of the hazards after the fact, requiring one or several more rounds of leapfrogging.
The unfortunate thing with SCADA security is that the big hole is still the application software that in many cases is not being maintained (or possibly even developed) by people with an eye toward security. A lot of the customers at my previous employer required access to the application to make "updates" online as well as download the program. While in some cases, this type of access was regulated through a more secure method provided by their own IT department, in other cases they were not involved, opening up the same doors that STUXNET came through.
On the one hand, it's always good news when vendors are able to cut the bad guys off at the knees, in this case by going to more advanced kernels, then beefing up networking protocols, and now looking at encryption. OTOH, one gets weary over the constant need to upgrade to stay that one little step ahead of the bad actors. Are we stuck with this leapfrogging scenario from here on out, Loring?
Really interesting, timely post, Loring -- as if industry and governments were sufficiently sensitized to the security issues you raise, Stuxnet made it abundantly clear what sort of havoc embedded malware could wreak. A larger security sensibility at this level is long overdue.
A new service lets engineers and orthopedic surgeons design and 3D print highly accurate, patient-specific, orthopedic medical implants made of metal -- without owning a 3D printer. Using free, downloadable software, users can import ASCII and binary .STL files, design the implant, and send an encrypted design file to a third-party manufacturer.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.