DEVICE INTEGRATION INTO AUTOMATION SYSTEMS WITH

CONFIGURABLE DEVICE HANDLER

Anton Scheibelmasser, Udo Traussnigg

Department of Automation Technology,CAMPUS 02, Körblergasse 111, Graz, Austria

Georg Schindin, Ivo Derado

Test Bed Automation and Control Systems, AVL List GmbH, Hans List Platz 1, Graz, Austria

Keywords: Measurement device, automation system, Configurable Device Handler, test bed

Abstract: One of the most important topics in the field of autom

ation systems is the integration of sensors, actuators,

measurement devices and automation subsystems. Especially automation systems like test beds in the

automotive industry impose high requirements regarding flexibility and reduced setup and integration time

for new devices and operating modes. The core function of any automation system is the acquisition,

evaluation and control of data received by sensors and sent to actuators. Sensors and actuators can be

connected directly to the automation systems. In this case they are parameterised using specific software

components, which determine the characteristics of every channel. In contrast to this, smart sensors,

measurement devices or complex subsystems have to be integrated by means of different physical

communication lines and protocols. The challenge for the automation system is to provide an integration

platform, which will offer easy and flexible way for the integration of this type of devices. On the one hand,

a sophisticated interface to the automation system should trigger, synchronise and evaluate values of

different devices. On the other hand, a simple user interface for device integration should facilitate the

flexible and straightforward device integration procedure for the customer. Configurable Device Handler is

a software layer in the automation system, which offers a best trade-off between the complex functionality

of intelligent devices and their integration in a simple, fast and flexible way. Due to a straightforward

integration procedure, it is possible to integrate new devices and operation modes in a minimum of time by

focusing on device functions and configuring the automation system, rather than writing software for

specific device subsystems. This article gives an overview of Configurable Device Handler, which was

implemented in the test bed automation system PUMA Open developed at the AVL. It provides an insight

into the architecture of the Configurable Device Handler and shows the principles and the ideas behind it.

Finally, new aspects and future developments are discussed.

1 INTRODUCTION

The general task of an automation system is to

control a system in a defined mode of operation. In

order for the automation system to perform this task,

a number of sensors and actuators have to be

evaluated and controlled. Since the timing of the

automation system is critical, its software has to

establish real time data acquisition and control. A

further requirement is to evaluate and calculate

results based on the acquired data and to store them.

Particularly, automation systems used in the field of

CAT (Computer Aided Testing, e.g. combustion

engine development), called test beds, have to store

the acquired data during the test run into a database,

so that the developer can calculate specific quantities

for quality assurance or optimisation. Systems under

test are monitored and controlled by various devices

connected to the automation systems.

Concerning the complexity of the data

acq

uisition and control, devices can be divided into

two categories. The first category of devices can be

described as simple actuators (e.g. valves) or sensors

(e.g. temperature sensor Pt100), which are connected

to an input/output system as part of the automation

198

Scheibelmasser A., Traussnigg U., Schindin G. and Derado I. (2004).

DEVICE INTEGRATION INTO AUTOMATION SYSTEMS WITH CONFIGURABLE DEVICE HANDLER.

In Proceedings of the First International Conference on Informatics in Control, Automation and Robotics, pages 198-205

DOI: 10.5220/0001126501980205

 SciTePress

system. Since the sensors and actuators are under the

control of the real time system, they are usually

completely integrated into the automation system.

Depending on the use of the sensor/actuator, specific

parameterisation (e.g. acquisition rate, filtering or

buffering) has to be performed by the customer.

The second category could be described as

intelligent subsystems (e.g. measurement devices).

In contrast to the first category, they are controlled

by a local microprocessor, which provides functions

comparable to those of the automation system (e.g.

real time data acquisition or statistical calculation).

Devices of this group could be qualified as finite

automata with several internal states and transitions.

Usually they are connected to the automation system

via physical line (e.g. RS232, Ethernet).

Consequently, data acquisition and control is

possible only via this physical line and by using

diverse communication protocols on it.

These various types of devices have to be

uniformly integrated into the automation system, so

that data acquisition and device control can be

performed in a common way. Thus, automation

systems typically contain a software layer, with the

main task to make device specific functions

available via standard automation interfaces. We

refer to this software layer as Device Handler (see

figure 1). Specifically, there are two main

automation interfaces in PUMA Open (AVL, 2004),

which are used by Device Handler, i.e., Platform

Adapter and Device Framework.

Figure 1: Device Handler

The former interface offers functions compatible

to those of the ASAM-GDI Platform Adapter

(ASAM, 2001). There are two main advantages of

the Platform Adapter. Firstly, it abstracts the

complexity of lower ISO/OSI layers 1-6 (ISO, 1990)

and it provides to the client a generic interface where

common read/write commands from/to the device

are independent from the specific lower ISO/OSI

layers (TCP/IP over Ethernet, RS232, CAN, etc.).

Secondly, it provides standard OS-services (e.g.

memory handling and synchronisation) and thus

enables the client to be independent from the

specific OS. Consequently, the client, i.e. the Device

Handler, deals exclusively with device specific

functions and it is therefore robust to changes of

lower communication layers and/or OS’s.

The later interface must be implemented by the

Device Handler and it contains services that are to

be used by the automation system, i.e., user. This

comprises services, such as: handling of device

channels (System Channels), device

parameterisation, support of the standard Device

Handler’s state machine, data storage, etc.

2 DEVICE HANDLER TYPES

One of the most important aspects of the automation

system is the synchronisation of all test bed

components (software and hardware) in order to

perform specific control and/or measurement tasks

(e.g. power-up all devices or get ready to start the

measurement of the system under test). As

mentioned in the previous chapter, all devices are

synchronised due to the fact that all Device Handlers

behave in a uniform way, which is ensured by

supporting the state machine, i.e., states and

transitions of the Device Framework interface. For

instance, if the automation system wants to perform

a measurement, it simply invokes the transition

StartMeasurement of each Device Handler. The

Device Handler interprets this command in a device

specific way and accordingly sends one or more

protocol frames to the device. Depending on the

physical connection (e.g. RS232, CAN), the protocol

mode (e.g. bus, peer to peer), the communication

mode (e.g. master-slave, burst-mode) and the

functionality (e.g. measure, calibrate), one could

distinguish between various families of devices, i.e.,

Device Handlers.

Device2

Automation System

Device Framework

Device Handler

Device1 Device3

Platform Adapter

As a result of this, the device is switched to the

intended state (e.g. measurement mode) and is able

to perform the specific activities. Acquired data are

analysed and accordingly the transition is performed,

the values of System Channels are updated, etc.

DEVICE INTEGRATION INTO AUTOMATION SYSTEMS WITH CONFIGURABLE DEVICE HANDLER

199

A vital part of the Device Handler is its

visualisation, or graphical user interface (GUI).

Typically, it is implemented as a separate

component and provides a visualisation for services,

such as device parameterisation, maintenance, or

visualisation of on-line values.

From the implementation’s point of view, we can

identify two types of Device Handler (see figure 2).

Figure 2: Device Handler types

2.1 Device specific handler

In case of very specific and high complex devices,

with sophisticated GUI requirements, it is hardly

possible to specify the device functions in a generic

manner. For this kind of devices, it is more

appropriate and efficient to implement the

corresponding Device Handler within traditional

software development projects. This implies that all

device functions (e.g. protocol, logic, GUI, state-

machine) are implemented hard-coded at compile

time. Therefore, the functions of the handler are

fixed. In case of changing customer requirements or

firmware changes on the device, the software has to

be modified and compiled again. Hence, there is no

flexibility concerning customer or application

specific modification. Only device parameters which

are handled in the automation system as System

Channels, can be customized.

Moreover, a person responsible for the

integration of the device into the automation system

has to be not only familiar with the device specifics,

but also with programming language and the

software object model behind the automation

interfaces.

2.2 Configurable Device Handler

The idea behind the Configurable Device Handler

(CDH) is to simplify and speed up the integration of

devices by configuring the automation systems and

thus allowing the responsible person (e.g. customer)

to focus on device functions and not on object

models behind automation interfaces. In order to

achieve this, a generic Device Handler was

implemented, which can cover general device

functions, such as RS232 or TCP/IP connection,

master-slave protocol, ASCII protocol, etc. During

the configuration procedure specific device

functions are identified. The mapping of device

functions to automation interfaces is done

automatically with the instantiation of the generic

Device Handler including device specific

information. Therefore, there is no need for

programming or learning a programming language

and object models behind automation interfaces. The

information gained during the configuration

procedure is stored in a so called Measurement

Device Description (MDD) file. As the content of

this file incorporates only the necessary device

specific information, platform independent device

integration is achieved. The MDD file can be saved

as an ASCII file and it could be used on other

operating system platforms, if similar generic

handlers are installed.

Device2

Automation System

Device Framework

Device1 Device3

Platform Adapter

Device Specific

Handler

CDH

(Configurable

Device Handler)

The generated MDD file is stored together with

all the other parameters in the automation system’s

database.

For each MDD file in the database exists a

corresponding instance of the generic Device

Handler, which is instantiated at start-up time of the

automation system. The automation system does not

distinguish between generic and specific Device

Handlers.

2.3 Related work

In the past the integration of devices in automation

systems was performed typically by developing the

device handler in the specific programming

language and development environment. This work

was done as a part of the service provided by the

developer of the automation system. The cost of the

integration was significant, especially if the device

was developed by the customer or third party.

In the 90

the scripting technology (Clark, 1999)

(Schneider, 2001) (Wall, 2000) (Hetland, 2002)

emerged in most automation systems in the

ICINCO 2004 - INTELLIGENT CONTROL SYSTEMS AND OPTIMIZATION

200

automotive industry. Its popularity was primarily

due to the fact that the customisation of automation

systems was possible at the customer site. However,

although the flexibility has increased, the costs of

the integration were lower only at the first sight. The

changes done in the automation system, at the

customer site, had to be integrated back into the

product, i.e., the product development process had to

be followed to support the customer also in the

maintenance phase. In addition, the changes could

only be done by people with the skills in

programming and automation system, which is again

the personal of the provider of the automation

system.

Exactly these problems were the motivation for

the development of the CDH. The authors are not

aware of any similar concept for the integration of

devices in any other automation system, i.e., in test

beds, especially in the automotive industry.

The concepts, as introduced in the product

LabVIEW (National Instruments, 2003) with the

graphical programming language G or TestPoint

(Capital Equipment Corporation, 2003), offers an

easy-to-use graphical environment to the customer

for the development of instrumentation panels,

device drivers and monitors of technical processes

on the PC-based platform. Nevertheless, these tools

are suitable only for the development of simple

automation systems and not for the integration in

large automation systems. Moreover, the graphical

programming languages require more than a

moderate amount of programming skills.

Standards, such as ASAM-GDI or IVI (IVI

Foundation, 2003), specify interfaces between the

Device Handler and the automation system. The art

of the development of Device Handlers is out of the

scope of these standards. CDH is compatible with

these standards, because it identifies similar

interfaces and functions in the automation system. In

the chapter 6.5 we discuss the possibility of CDH

supporting the ASAM-GDI standard.

3 CDH DEVICE INTEGRATION

Figure 3 shows the component view of the CDH. It

comprises the following components: Configurable

Device Generator (CDG), Configurable Device

Engine (CDE), Configurable Device Panel (CDP),

and finally the MDD file. The main features of these

components are described in the following sections.

In order to achieve a device integration using the

CDH, first the configuration procedure has to be

performed, i.e., the device functions must be defined

and saved in the MDD file. There are two main

prerequisites for this task to be fulfilled. Firstly, the

person responsible for the device integration (in the

following: device integrator) has to have the

knowledge about the device functions. This implies

that the device states, the intended device modes and

the necessary protocol frames are well known.

Secondly, it is necessary to understand the standard

Device Handler’s state machine (see fig. 5) defined

within the Device Framework in order to integrate

the device functions into the automation system

appropriately. This enables the correct

synchronisation of the device by the automation

system. With the help of the CDG component, the

device integrator can perform the creative part of the

device integration in a straightforward manner.

Device 2

Automation System

Device Framework

Device 1 Device 3

Platform Adapter

ConfigurableDevice Handler (CDH)

Engine(CDE)

Generator (CDG)

Panel (CDP)

Measurement

Device

Description

File (MDD)

Figure 3: CDH components

4 OFFLINE CONFIGURATION

The main part of the device integration using the

CDH is the configuration procedure, where the

device specifics are defined and saved in form of the

MDD file. These activities are supported with the

CDG, which conducts the device integrator by

dividing the integration in several precise and clear

defined steps. Hence, the configuration procedure

can be mastered after a short time and in an intuitive

way, and it is therefore especially suitable for

customers with good knowledge of the device, but

less of the automation system. At the beginning, the

CDG steps are followed in a sequential way. Later

as the configuration procedure progresses, it makes

sense to use these steps interchangeably. In the

DEVICE INTEGRATION INTO AUTOMATION SYSTEMS WITH CONFIGURABLE DEVICE HANDLER

201

following sections the steps are described in more

details. However, it is out of the scope of this

document to describe each attribute and feature, and

therefore only excerpts are shown.

4.1 Physical Line

First, the device name used internally in the

automation system is specified, followed by the

definition of the parameters for the physical line

(e.g. RS232). The following structure shows an

example for the RS232 parameter definition.

Type: RS232

Baudrate: 9600

Bits: 8

Parity: None

Stop bit: One

Port number: COM1

TimeOut: 1000 [msec]

An excerpt from the definition of a physical line

4.2 Device Variables

For every value from the physical device, which

should be available in the automation system, a

name and several characteristics, such as Unit,

Minimum, Maximum, data Type, and Initial Value

have to be defined. The following description gives

an example:

Value: FB_Temperature

Unit: °C

I/O-Type: Output

Type: Float

Initial Value: 0

Minimum: -10

Maximum: 70

An excerpt from the definition of a Device Variable

The attribute I/O-Type denotes the device

variable either as Output (device defines its value) or

Input (device needs a value from the automation

system, i.e., from some other SW or HW

component). This attribute is set automatically by

the CDG as described in the following section 4.3.

4.3 Telegrams

Since the access to the physical device occurs

exclusively via the communication line, each value

and command has to be transmitted by the

appropriate communication telegram. Therefore,

each telegram, which is used for control or data

acquisition has to be defined in this configuration

step. The following example shows the definition

structure of a command and a data inquiry telegram,

using AK protocol commands (Arbeitskreis, 1991):

Telegram: SetToRemote

Type: Send and receive

Send: <02> SREM K0<03>

Receive: <02> SREM #ERROR_Status#

$AK_Error$<03>

Telegram: GetMeasResult

Type: Send and receive

Send: <02> AERG K0<03>

Receive: <02> AERG #ERROR_Status#

#FB_MeasCycle# #ignore#

#FB_MeasTime# #FB_MeasWeight#<03>

Simplified example for two telegrams

The telegram definition can contain the definition

for two protocol frames (one to send and one to

receive), or for only one (only send or only receive).

A minimum syntax is used to define a protocol

frame. This includes, e.g., the definition of fixed (#

#) and optional ($ $) position for a device variable’s

value and the definition of not-readable ASCII

characters (< >). This syntax could be extended with

the more powerful pattern-matching techniques for

text processing, such as regular expressions (Friedl,

2002).

A device variable is denoted as an Output variable,

if it used exclusively in receive protocol frames,

otherwise it is an Input variable (see 4.2).

Using telegram definitions, CDH can send, receive

and analyse protocol frames at run-time. Failures in

terms of transmission timeout or parsing error are

handled within the execution model of the CDH

(within CDE) and are mapped to an error handler as

described later.

4.4 Sequences

Transitions in the Device Framework’s state

machine that trigger and synchronise complex

device activities are usually implemented by the

Device Handler with more than one communication

telegram. The order of the different telegrams and

their correct invocation ensures the right device

behaviour. Therefore, there is a need to define the

logical order.

From the programming point of view three

elementary software constructs are sufficient to

support this, i.e., the commands, the conditional

branches, and the jump commands or loops.

ICINCO 2004 - INTELLIGENT CONTROL SYSTEMS AND OPTIMIZATION

202

According to this fact, the CDG offers elements to

define telegram invocation orders without the need

for classic programming.

Figure 4: Simplified model of the Sequence execution

Moreover, to facilitate the typical order patterns

in the automation, the telegram invocation order is

organised in three blocks, which together constitute

the CDH Sequence (see fig. 4).

The first block called Start defines a sequence of

telegrams, which is executed only once. The second

block, called Cyclic, allows the execution of

telegrams cyclically until the end loop condition is

fulfilled. A third, optional End block is used to

concatenate Sequences, depending on whether a

current Sequence ended with success or failure. The

End block and Global Conditions (see section 4.5),

support the error handling in the CDH handler.

At run-time, the invoked transition in the Device

Framework triggers the execution of the Sequence

by the CDE component. The execution is done

according to the execution model for the MDD

structures (Sequence, telegram,…). The description

of the execution model is out of the scope of this

document. Hence, the Sequences specified by the

user are actually implementations of the transitions

in the Device Framework’s state machine. The

following description gives an example for a

Sequence Measure, which is invoked, when the

automation system triggers the start of a

measurement:

Sequence: Measure

Start Block:

If Condition:

IF RequestArgument <= 0 THEN

Invoke Sequence NotOk AND

Display INFO Message:

“Measurement mode not supported”

Function:

SetChannelValue(PARA_MeasTime,

#RequestArgument)

Cyclic Block:

If Condition:

START

CYCLIC

End Condition

fulfilled?

END

Yes

IF FT_ControlSystem < 0 THEN

Invoke Telegram ADAT_cascade

Cycle Time: 1000 msec

End Condition: TIME = PARA_MeasTime

End Block:

Sequence if OK: Online

Sequence if NOT OK: AnalyseFailure

Example of a Sequence

4.5 Global Conditions

A number of protocol frames require the same

reactions (e.g. error handling). Therefore, every

protocol frame has to be checked whether, e.g., an

exception has occurred or not. In order to reduce the

effort of writing a number of same conditions, the

CDG offers an additional definition step called

Global Condition.

Conditions defined in this step are checked

automatically at run-time whenever a telegram is

executed. If the condition is true the corresponding

reaction is invoked (e.g. telegram or Sequence

execution).

5 ON-LINE USAGE

At run-time the automation system loads MDD files

from the database and generates a CDH instance for

each of them. The communication to the device is

established according to the parameters of the

corresponding physical line. Every state transition in

the Device Handler’s state machine triggers the

execution of the corresponding CDH Sequence.

Figure 5 shows the simplified description of the state

machine.

The CDE component interprets the content of the

corresponding MDD file and executes Sequences

according to the specified execution model.

Consequently, the defined telegrams, conditions and

functions are executed, in order to control the

physical device appropriately. Additionally, for

every device variable defined in the MDD file, the

CDE generates a System Channel if needed, and

provides them with values received from the

telegram frames.

DEVICE INTEGRATION INTO AUTOMATION SYSTEMS WITH CONFIGURABLE DEVICE HANDLER

203

Figure 5: Simplified Device Handler’s state machine

The CDP component provides a graphical view

on active System Channels and their values and the

possibility to trigger each Sequence manually. As

shown in figure 6, the CDP offers a common GUI

for all CDH instances, which can be used for service

or maintenance reasons.

Figure 6: CDP visualisation

6 FURTHER DEVELOPMENT

The first implementations of the CDH were

successfully done for a number of measurement

devices and subsystems with RS232 or Ethernet

(TCP/IP, UDP/IP) connection. The common

protocol of these devices was restricted to ASCII

protocol communication. Experience gained with the

integration of these devices was the base for the

further development issues described in the

following sections.

Running

Not Ready

Ready

Idle

Remote

Busy

Initialise

Release

Measure

Complete

StartDevice

StopDevice

Connect

Device Handler instantiated

Parameters loaded

Device Handler connected to

device

Device Handler ready

Device Handler polls device

Device in remote control mode

Device executes function

6.1 Calculation Capability

The execution model of the CDE is restricted on

simple value extraction or insertion in protocol

frames. Since there are a number of protocols, which

use checksums or CRC’s, because of data security, it

is necessary to perform such calculations inside the

Device Handler. An additional aspect is the

arithmetical calculation of different device values.

By introducing a formula interpreter in the CDH,

both examples can be solved.

6.2 Automatic Detection of Devices

The idea behind the automatic detection of devices

is to automatically detect known devices on different

communication lines. This feature reduces the

logistical effort on test beds and it enables users to

hook up optional devices on demand.

This requirement is fulfilled by introducing an

appropriate Sequence in the CDH, which allows the

automation system to detect known devices on

arbitrary lines. Depending on the device

identification, the automation system is able to link

the appropriate Device Handler to the port where the

device is connected.

6.3 Multi-Line Connection

At the moment, every CDH instance can be

connected to the physical device only via one

communication line. In order to support devices and

subsystems, which communicate over more than one

line (e.g. the communication via TCP/IP and

UDP/IP port), it should be possible to define

telegrams for different communication lines.

6.4 Binary Protocols

Currently, the CDH supports only ASCII protocol

frames. Since there are a number of devices, which

communicate with a binary protocol, this family of

devices cannot be integrated using the CDH.

Extending CDH with a capability to support binary

protocol frames would significantly increase its

versatility.

ICINCO 2004 - INTELLIGENT CONTROL SYSTEMS AND OPTIMIZATION

204

6.5 Capability Profiles

The CDH provides a minimum set of Sequences

mapped to the transitions of the standard state

machine of the Device Handler via the Device

Framework interface, which is enough to

synchronise devices (e.g. connect, start cyclic data

acquisition, start/stop measurement). However,

additional standard Sequences could be provided

that would support standard profiles, such as device

independent profiles (ASAM-DIP, 2002) defined by

ASAM-GDI standard. This profile defines a general

state model of a test run and the required transitions.

Implementing this profile would imply that the

Device Handler is interoperable on test bed systems

of different vendors supporting this standard.

7 CONCLUSION

The integration of devices in automation systems is

typically a complex procedure that requires not only

a good knowledge of the device and the automation

system, but also requires programming skills.

The concept of the CDH offers an alternative

approach for the integration of less complex devices.

The device integrator is able to focus on device

functions and to integrate them into the automation

system using a simple configuration procedure

described in this document. Not only that the

integration can be done at the customer site, but also

the customer himself is in the position to integrate

his or a third-party device and to maintain it.

The CDH was implemented in the automation

system PUMA Open developed at AVL and has

shown excellent results in the practice. The major

number of in-house devices, specifically

measurement devices, were integrated into the

PUMA Open using the CDH and are productively in

use by a number of OEM’s and suppliers in the

automotive industry. Moreover, customers have also

integrated devices by means of the CDH by

themselves and are using them in research and

production.

The costs and the effort for the integration were

significantly reduced and, at the same time, the

quality of the integration has increased, since it was

possible to focus on device capabilities and to work

in the office with a device emulator.

Using this integration method, the device

integration got very easy, if the device integrator

understands the device well!

REFERENCES

Arbeitskreis der deutschen Automobilindustrie, 1991. UA

Schnittstelle und Leitrechner, V24/RS232 Schnittstelle

– Grundsätzliches

ASAM e.v., 2001. Introduction to ASAM-GDI, rev.

1.0, www.asam.net/03_standards_05.php

ASAM e.v., 2001. ASAM-GDI Part A: Specification of the

Device Capability Description of an ASAM-GDI

Driver, rev. 4.2

ASAM e.v., 2001. ASAM-GDI Part B: Specification of the

Interface of an ASAM-GDI Driver, rev. 4.2

ASAM e.v., 2002. Device Independent Profile (DIP)

Specification, rev. 4.2

AVL List GmbH, 2004. PUMAopen Test Bed Automation

Software,

www.avl.com

Capital Equipment Corporation, 2003. Test Point, version

5, www.cec488.com

Clark, S., 1999. VBScript : Programmer’s Reference,

Wrox

Friedl, J.E.F, 2002. Mastering Regular Expressions, 2

ed., O’Reilly & Associates

Hetland, M.L., 2002. Practical Python, 1

ed., APress

ISO, 1990. Overview and Architecture, IEEE Std 802-

1990

IVI Foundation, 2003. Driver Architecture Specification,

rev. 1.2, www.ivifoundation.org

National Instruments, 2003. LabVIEW, version 7,

www.labview.com/labview

Schneider, F., 2001. T.A. Powell, JavaScript: The

Complete Reference, McGraw-Hill Osborne Media

Wall, L., Christiansen, T., Orwant, J., 2000. Programming

Perl, 3

ed., O’Reilly & Associates

DEVICE INTEGRATION INTO AUTOMATION SYSTEMS WITH CONFIGURABLE DEVICE HANDLER

205