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.
Festo's BionicKangaroo combines pneumatic and electrical drive technology, plus very precise controls and condition monitoring. Like a real kangaroo, the BionicKangaroo robot harvests the kinetic energy of each takeoff and immediately uses it to power the next jump.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.