Device Emulation

The separation of application and communication has always been a conceptual design tool in automation. However, this is done almost exclusively at design time. Although the structures of the field devices are therefore modular, this modularity of application and communication is largely only used by the field device manufacturer for further development. The flexibility and also the duration of the development of the devices therefore hardly change. In this context, it is desirable to have a capabilities and flexible platform for the implementation of application functions. This platform should make it possible to significantly shorten the design time of the applications and thus also that of the entire field device in order to be able to simulate and test the functionality of a complex overall system at an early stage of development. Against this background, the Generic Device was developed, which makes it possible to implement any application software in modules of virtual field devices in a distributed manner.

Structure of the Generic Device

The Generic Device is a modular, freely configurable software field device. The structure of the device is shown in Figure 1. It consists of three functional parts and a part, not shown here, which is responsible for internal management and configuration. Configuration is carried out using an XML file, which must be transferred to the generic device as a start parameter. It contains all the essential configuration data for the start-up of the field device.

The fieldbus device stack is independent of the applications used and is encapsulated by the generic data container. It is responsible for communication in accordance with the configuration in the XML file. The Application Process Objects (APOs) in the Data Container can be accessed from the stack via a generic interface.

The Data Container is a generic container for the APOs. It has a generic interface for accessing the APOs. Access is either exclusive or concurrent, depending on the desired time window and data consistency. Excluding accesses are used for cyclical communication to ensure that a complete snapshot is transmitted to the controller. For acyclical communication, on the other hand, other data in the data container can still be changed and read at the same time without the process data being corrupted. Furthermore, authorizations can also be set for the individual data in the data container so that certain accesses and therefore unwanted changes to the data can be excluded from the outset.

The field device applications are another component of the generic device. These are implemented as software components (dynamically linked libraries), which implement the core functionality of the software field device and are loaded as required. They are fieldbus-independent and can, in principle, be operated by the generic data container on any fieldbus stack integrated into the generic device. Field device applications are instantiated in a similar way to a modular device by dynamically plugging and unplugging modules. The configuration of the individual plugged-in applications is carried out on the one hand by an XML node, which is transferred when the application is created, and on the other hand by the usual, acyclical parameterization of the device to establish a connection. When implementing the concept of bus-independent applications, the focus was on ease of implementation and the future expandability of the device with additional applications.

Some examples of field device applications on the generic device are listed below. One possibility is the connection to a real process using PC-IO hardware (e.g. digital IO). Devices with a USB connection are preferred here, as these can be integrated into commercially available IT virtualization solutions without considerable effort. A logging application for process values and events is also provided. A generic device application can also be implemented, which enables parts of the control system application to be outsourced and distributed using IEC 61499 function blocks. A connection to external data sources via the Message Oriented Middleware Active MQ enables simulation data to be fed into a real fieldbus environment so that sub-systems can also be simulated in a real system.

Field device virtualization

The increasing capabilities of PC components make it possible to use hardware virtualization solutions. This is an abstraction layer that makes the resources of a host system available to several special and adapted guest systems. The hardware used plays a subordinate role here, as it merely represents the platform for virtualization.

A key aspect of the virtualization of the devices is the reduction of the effort required to simulate (partial) systems, whereby real and virtual devices can be mixed as required. An application for the generic device is available for this purpose, which connects simulation software. An application is also available that enables a real process connection via the PC's peripherals

Thanks to a powerful virtualization environment from the IT environment, a very large number of virtual field devices can be achieved in an Ethernet segment. This allows load distribution to be realized, which means that normal fluctuations in the requirements of the application can be dealt with dynamically without having to allocate additional resources preventively.

The virtual field devices created in this way can be integrated and used in a test scenario alongside the real devices. A simplified example setup for this is shown in Figure 2. This example setup realizes the integration of a real controller and a real field device and three connected virtual hosts, on each of which a generic device is executed. The data packets on the network - shown in Figure 2 with the colored squares - are assigned to the individual generic devices by the bridge. It is not relevant for the fieldbus controller of the control system whether it communicates with virtual or real devices, as both field device types are transparent for the control system. With the aid of a virtualization solution, it is therefore possible to create almost any number of software field devices, which are prototypes for field devices to be installed later, and make them available for testing the control system application.