Software architecture

The sections above focussed on the abstract and functional aspects of automation components. In the following, we introduce some general ideas about their software implementation. A more detailed discussion will be given in chapter 5 in the context of geographically distributed monitoring and control systems.

A distributed automation application is preferably developed from various components without constraints regarding on how they are allocated to several nodes or how the communication links between them are established. This is especially important, since it should be possible to deploy the same application for several clients and to modify or extend existing installations.

The goal is to let an organisation encapsulate its intellectual property into a library of reusable components. New deliveries are then simply a matter of selecting the necessary components and configuring them onto a standard platform. Depending on the needs of the application and the available hardware resources, it is possible to include only those parts of the platform that are really needed.

A component-based application needs an execution environment that provides services for the lifecycle management and interaction of components. Using existing components from a library and defining their distributed configuration and communication links should be as automatic and simple as possible. Every effort must be made to avoid “hard coding” that limits reusability.

As described in the previous sections, the logical nodes of our platform host two types of automation components, platform components and application components. Both should be able to run on top of common hardware and (real-time) operating systems, utilising general-purpose communication and data storage techniques. This leads to a layered architecture shown in Figure 21. On the level of system software, we only need a loose framework that enables combination of existing platform components like web servers and data distribution services. Their purpose is to provide a safe and controlled environment for application components.

General-purpose communication protocols Application components

Domain specific framework for system level components

Control-oriented distribution services

Application components

Domain specific framework for system level components

Control-oriented distribution services

Figure 21. System levels: Basic software, platform and application.

As there are security and configuration control issues in industrial applications, it’s a natural and common approach to put the components (written by various vendors) into a “sandbox” where they can be easily managed. In a logical node the component containers take this job (Figure 22). Firstly, the logical node itself is a container for platform components. The node, represented, for example by a platform component called “root”, should provide a set of interfaces that serve the other, contained platform components. Accordingly, all platform components should implement certain interfaces to qualify as platform components. Secondly, it is possible to implement one or more inner containers for application components, for example in order to execute IEC 61131 function blocks as a “soft PLC”. Again, there is an agreement about interfaces between the container and application components. However, it is probably different from the interfaces of platform components.

Hardware + operating system + utility software Logical node

Application component container

Component Component Component

Containers and components should be independent of the implementation details of other components. For example, components should be portable between different container implementations. Therefore, interfaces are the key issue in the architecture. They form the central part of the contract between the container and components. In our case, the components in a logical node typically represent system software and are developed and tested by an experienced vendor. Therefore, the platform components can be allowed to have some freedom, such as starting their own threads. The node should, however, be able to monitor and manage their execution, if this doesn’t lead to excessive complexity and overhead.

Node root E-mail agent User interface server (session) Process IO server Component loader

Security server Component_repository

Web server

Distribution server (data, services, events)

Other communications Historical database SNMP management agent Engineering agent Application component Application component Container

Figure 23. Examples of potential platform components in a logical node.

Figure 23 gives some ideas about platform components that could be installed in a logical node. The components and containers should provide following services:

• management of component life-cycle • installation, removal

• starting, stopping, updating

• propagation of configuration events to interested listeners

• searching the properties and optional services implemented by the container • directory services (publish/register, find, update)

• components

• data published by components (data ports) • event notifications (event ports)

• access to the underlying operating system and hardware and their properties • receiving propagating events generated by components and the container itself. To enable adaptation to application requirements and available hardware resources, the logical node itself should be modular and configurable. Some basic services are mandatory but others might be optional. In addition, some services may consist of a group of interfaces, only some of which need to be implemented. For example, Quality of Service attributes might be provided as an extension to the basic data distribution. This creates the need for some sort of negotiation mechanisms and compatibility checks during component installation and operation.