New-generation software technologies impact operational stability, safety

Operational stability, safety, and security remain critical requirements in industrial applications.

By Marcos Taccolini, CEO, Tatsoft LLC, Houston, TX March 28, 2013

Regardless of the changes in industrial applications, one fact holds: operational stability, safety, and security remain critical requirements. A variety of new technologies are helping ensure and promote these features. In field instrumentation, for example, safety and security are not guaranteed just by internal procedures or the manufacturer’s warranty, but by a system architecture that uses voltages and currents that are intrinsically safe in the environment in which the instrumentation will operate. 

An analogous concept applies with software. The previous generation used C/C++, pointers, multiple modules sharing the same memory area, and direct access to hardware and operating system resources that were considered intrinsically unsafe. New generation software, on the other hand, uses computational environments—such as the .Net framework. Here, processes are natively isolated from the operating system, allowing better use of multiple processor cores and greater operational stability, even in the face of driver and hardware errors or individual system module failures. 

Similarly with user scripting in an application, previous generation software used proprietary scripts or interpreted languages such as VBScript, VBA, or proprietary expressions editors. Today, new generation software relies on modern, compiled languages such as C# or VB.Net with object-orientation and execution control. Legacy interpreted languages do not permit a complete code validation during the development stages, allowing it only when the final verification is made. As a result, it may be possible to test problems or concerns only when the project is running, not earlier during engineering configuration. 

In a typical project, code may have hundreds to thousands of possible execution paths. Scenarios cannot test all those paths and all possible cases. The ability to detect potential errors during engineering configuration, and the ability to recover and isolate the errors during runtime, are key elements for safety and operational stability. They are possible only by fully migrating legacy interpreted scripts to new compiled and managed languages.

The table below lists some typical real-time, industrial automation systems features and components, and how legacy and new-generation software technologies affect them.

Feature or component

New-generation technologies

Legacy technologies

Internal programming

C#/VB.Net/Java

Automatic, protected memory management; independent of hardware and operating system protection.

C++/C

Extensive use of pointers; required validation for each device; direct access to hardware and operating system.

Graphics programming

WPF, XBAP, Silverlight, XAML

Uses hardware acceleration regardless of resolution (vector); greater performance, native capacity for 3D, multi-touch.

GDI/GDI+

Pixel-oriented; dependent on monitor resolution, distorts in conversion, limitations of dynamic animations and use of graphical card.

Editing and project execution

Multi-user, remote editing, and execution of multiple projects.

Single-user and mono project. Remote access requires external tool.

Remote access to runtime

Smart-client technology with centralized installation on a server or Web, or in Cloud, without installation of additional components. Standardized, secure protocols such as WCF.

Local installation required for clients and Web clients. Dedicated protocols with frequent need to open firewall ports. Custom protocols and need for often unsafe Active-X components.

Traceability of version control and configuration

Client-server architecture, SQL, databases centered with native traceability of project versions and settings.

Configuration split in multiple files with no built-in ties. Traceability performed manually or through external programs.

Functional modules and scripts at runtime

Native multiple processes and threads; each module and script execution thread .Net natively protected from others. Architecture designed for effective use of multi-core processors. Exception control and memory protection by the operating environment.

Single process multi-threaded or manually programmed logical and sequential execution of unified environment. Insulation of modules, parallel execution of scripts and protection exceptions, when they existed, were done through dedicated programming with higher level of complexity.

Scripts

Compiled (Vb.Net/C#)

Implementation of logic is 10 to 40 times faster than an interpreted script or owner. Performs more checks during configuration, is multi-threaded and handles exceptions, ensuring isolation of errors and increased performance. Full access to all functions in .NET framework.

Interpreted (VBA/VBScript or logical and mathematical proprietary).

Detection of many errors possible only when the system is run. Most were mono-thread with slower functions, possible compromise of system errors, and sometimes limited access to Windows functions.

Native platforms

64-bit native; support for 32-bit. Better use of hardware; more compatibility. System originally designed for 64-bit to use components already present in the operating system.

32-bit native; support for 64-bit. When and where possible, support for 64-bit required the installation of many additional components not native to the operating system.

Communication drivers

Parallel execution with a capacity for multiple connections to each node. Automatic statistics, diagnostics, redundancy, syntax validation on the addresses field, and exception recovery are standard.

No parallel requests or multi-threading. Statistics, diagnostics, redundancy partially available. Typically a driver exception halts the driver execution, sometimes the whole system.