Nof S.Y. Springer Handbook of Automation

Подождите немного. Документ загружается.

Software Management References 795

45.7 LANDesk Software Ltd.: Solutions Brief (LANDesk,

South Jordan 2007), http://www.landesk.com

45.8 Akamai Electronic Software Delivery: Business Ben-

eﬁts and Best Practices (Akamai, Cambridge 2007),

http://www.akamai.com/dl/whitepapers

Akamai_ESD_Whitepaper.pdf

45.9 B.W. Boehm: Software Engineering Economics

(Prentice Hall, Upper Saddle River 1981)

45.10 C. Jones: Software cost estimating methods for

large projects, Crosstalk (2005), http://www.stsc.

hill.af.mil/crosstalk/2005/04/0504Jones.html

45.11 S. McConnell: After the Gold Rush, 2004 Systems

and Software Technology Conference (Salt Lake City

2004)

45.12 C.A. Dekkers: Creating requirements-based esti-

mates before requirements are complete, Crosstalk

(2005), http://www.stsc.hill.af.mil/crosstalk/2005/

04/0504Dekkers.html

45.13 T.L. Saaty: The Analytic Hierarch Planning Pro-

cess: Planning, Priority Setting, Resource Allocation

(McGraw-Hill, New York 1980)

45.14 L.H. Putnam, D.T. Putnam, D.H. Beckett: A method

for improving developer’s software size estimates,

Crosstalk (2005), http://www.stsc.hill.af.mil/

crosstalk/2005/04/0504Putnam.html

45.15 B.W. Boehm, R. Valerdi, J.A. Lane, A.W. Brown:

COCOMO suite methodology and evolution, Crosstalk

(2005), http://www.stsc.hill.af.mil/crosstalk/2005/

04/0504Boehm.html

45.16 L. Fischman, K. McRitchie, D.D. Galorath: Inside

SEER-SEM, Crosstalk (2005), http://www.stsc.hill.af.

mil/crosstalk/2005/04/0504Fischman.html

45.17 R.D. Patton: What can be automated? What cannot

be automated?. In: Springer Handbook of Automa-

tion, ed. by S.Y. Nof (Springer, Berlin, Heidelberg

2009), Chap. 18

Part E 45

“This page left intentionally blank.”

797

Practical Auto

46. Practical Automation Speciﬁcation

Wolfgang Mann

This chapter speciﬁes equipment-based control

system structures for complex and integrated

systems and describes the approach to and im-

plementation of an equipment-based control

strategy. Based on a view of subsystems in a pro-

duction, process or a single machine the control

system has to abstract the subunits in an object-

oriented manner to obtain their methods and

properties. The base subunits will run as sep-

arate state machines (either on centralized or

decentralized control devices) representing them-

selves to the next control hierarchy level only by

said methods and properties. These base sub-

units form functional subsystems in the same

way.

Advantages of such a modular speciﬁcation

are: easy replacement of different base units with

the same functionality to the next hierarchy level,

high efﬁciency in construction kit engineering of

systems, easy integration of systems to vertical

integration attempts – especially in the ﬁeld of

networking and data concentration. The challenge

is the implementation on standard industrial

programmable logic controller (PLC) systems with

a standard industrial-like programming language

(e.g., EN 61131). An example demonstrates the

implementation in a modern test stand for heat

meters for the German Physikalisch-Technische

Bundesanstalt (PTB) institute, a system with about

46.1 Overview.............................................. 797

46.2 Intention ............................................. 798

46.2.1 Encapsulation............................ 798

46.2.2 Generalization (Inheritance)........ 799

46.2.3 Reusability ................................ 799

46.2.4 Interchangeability...................... 799

46.2.5 Interoperability.......................... 800

46.3 Strategy............................................... 800

46.3.1 Device Drivers ............................ 800

46.3.2 Equipment Blocks ...................... 801

46.3.3 Communication ......................... 802

46.3.4 Rules ........................................ 802

46.4 Implementation ................................... 803

46.5 Additional Impacts ............................... 803

46.5.1 Vertical Integration and Views ..... 803

46.5.2 Testing...................................... 804

46.5.3 Simulation ................................ 804

46.6 Example .............................................. 804

46.6.1 System...................................... 806

46.6.2 Impacts..................................... 807

46.6.3 Succession................................. 807

46.7 Conclusion ........................................... 807

46.8 Further Reading ................................... 807

References .................................................. 808

1000 physical input/output (I/O) and measurement

points.

46.1 Overview

Complex systems with many dozens of subsystems

become increasingly challenging in terms of program-

ming, interfacing, andcommissioning, inboth operation

and maintenance.

The reasons for this intricacy are multifarious and

include [46.1]:

1. Product lifecycles getting shorter, and even techno-

logical cycles getting shorter.

2. Orders to stock are replaced by short orders to

delivery.

3. Change form self-production to integration of sub-

suppliers.

Part E 46

798 Part E Automation Management

4. Decentralized stock and service.

5. High price pressure.

6. Change form manually process integration to inte-

grated processes.

7. Change from product supplier to system supplier.

8. Production processes control multiple enterprises.

9. e-Commerce and quality management systems ad-

ditionally produce enormous quantity of data and

force the introduction of data management through-

out the company.

These requests can be covered by a horizontal

and vertical integration of process and production

systems and subsystems within the company and ex-

tending thenetwork tosuppliers and evencustomers. So

the systems become more complex, open, distributed,

and heterogeneous. Dataﬂow often has to be imple-

mented throughout the complete enterprise hierarchy

form the shop ﬂoor area to enterprise management

level.

To address these attempts, new software concepts

have to be implemented throughout the complete infor-

mation chain within an enterprise, starting at the I/O

level of the production line.

Although there are well-developed methods and

strategies to produce well-structured, reusable, and so-

phisticated code in the information technology (IT)

personal computer (PC)-based environment, industrial

control at its base level is still done using standard PLC

systems with EN 61131-like programming language us-

ing functional blocks, structured text or instruction lists

at large scale [46.2].

As long as the projects are small and centralized

a programming technique limited to the I/Os of indus-

trial controllers and their periphery is applicable, with

some restrictions.

However, with the above-stated imperative demands

in mind, conventional I/O-based engineering attempts

leads to unstructured, error-prone code, resulting in cost

overruns during installation and operation.

We consider the traditional PLC programming style

more as an expression of old-fashioned thinking, hav-

ing its tradition as far back as relay-based times, rather

than an exigency coming from existing hardware and in

particular software systems.

Before the implementation strategy is described, we

look for the must-haves to overcome the shortcomings

of traditional industrial control programming.

46.2 Intention

Many of the following topics have been implemented

for years on IT-based systems using C++, Java or other

object-oriented (OO) languages. Some of these have

found their way into the International Electrotechnical

Commission (IEC) 61499 function blocks (with a lack

of practical implementations untill now), but actually

the bulk of industrial control applications is still done

on EN 61131-based systems. So, in the following, fo-

cus is placed on the implementation on these existing

systems [46.3].

46.2.1 Encapsulation

The most important part of changing the thinking in the

traditional control programming approach isto leavethe

physical I/O connections as the primary way of compo-

sition and interaction of systems.

Normally an object in the real world is experienced

by humans through its properties, attributes, features

(however named), and the possibilities it offers or what

we can do with this object (called methods). In general

we realize this object only in a certain abstracted layer.

The level of this abstraction is chosen according to our

actual demands.

As an example we take a human being (a car me-

chanic). If our car is broken, we abstract him as an

object: human with the attributes educated, skilled on

certain brand, available, etc., and his methods: takes

order, repairs car, renders account, etc. We are not in-

terested in how the blood ﬂows through his veins, how

his heart functions, etc. His doctor on the other hand is

interested in exactly these methods and attributes. He

will abstract him as object: human with the attributes:

sex, age, blood pressure, etc. and methods: sees, smells,

tastes, etc.

Coming back to automation. We are interested in

automated systems for production and processes, con-

trol and testing, etc. Usually complex systems are built

as a network of subsystems (objects) based again on

a network of subsystems.

In our namespace these subsystems are called

equipment. The term equipment could lead to some

unaesthetic grammar constructs in the following, but

we have chosen it intentionally: ﬁrstly, equipment ex-

Part E 46.2

Practical Automation Speciﬁcation 46.2 Intention 799

presses things we need for some activities, especially in

production, and secondly it is already a plural expres-

sion, although it could be a single device or the whole

factory. So it represents the modularity of the method

downto thesmallest base modules (that in general again

consist of parts).

We differentiate between base equipment and ab-

stracted equipment. A motor, a valve or a pump is

a single base equipment. A pump station, for example,

is a single abstracted equipment.

What is the deﬁnition of base equipment in contrast

to abstracted equipment? A base equipment implements

interface access via physical I/Os to the real world,

whereas an abstracted equipment implements interface

access to physical I/Os only via base equipment. Nev-

ertheless base equipment can of cause host other base

equipment (see Sect.46.2.2 as well).

The intention for building equipment is to en-

capsulate the actual physical implementation of one

subsystem from the collaboration with other subsys-

tems, as well as to support the abstraction of these

systems for different service subscribers (with different

interests, e.g., production, service, and management) to

its methods and/or properties.

The encapsulation consists of three layers: the in-

terface layer (providing abstracted methods and proper-

ties), the implementation layer (running the algorithms,

the event routines, and the exception routines), and

the base layer. The base layer is the interface to the

physical I/Os and the access to the implementation

layer of subequipment for base equipment and the

same without direct access to physical I/Os for abstract

equipment.

Access from one single equipment to another is al-

lowed only by use of its interface layer. This strict

access method allows one to change the implementa-

tion layer as well as the base layer of equipment without

affecting how it is accessed.

46.2.2 Generalization (Inheritance)

In the implementation of object-oriented languages

the method of inheritance is an important feature. It

describes the deployment from more generic objects

to more specialized ones. As in the following im-

plementation we have no special software tools in

standard EN 61131-based systems for constructing

strict inheritance (as is possible in C++), we talk about

generalization and bear in mind the underlying ideas.

So, for our needs, generalization allows hierarchical

structures and establishes a relationship between a more

general equipment and a more speciﬁc one, without

redeﬁning all the speciﬁc methods and properties, al-

though if required it is possible to override the generic

methods and properties of the generic equipment with

more speciﬁc ones.

To follow our ﬁrst example, a woman inherits all

the methods and properties of the object human, but has

of course more speciﬁc attributes and methods, most

importantly to give life to new humans. We will give

more technical examples in the implementation sec-

tion.

46.2.3 Reusability

Probably it is the basic idea of every engineer to built

up a system (whichever) out of already existing, used,

and tested parts coming from a toolbox (as children do

when playing Lego) to create new systems and projects.

By doing this an engineer mostly thinks about saving

time, lowering risks, and reducing overall costs.

The basis for doing this is encapsulation and the

concept of instances. As a single equipment is the

implementation of methods and at the same time its

abstraction, and the base layer is the interface to the

physical world, it is only a general construct. The base

equipment, e.g., is brought to life when it is con-

nected via its interface to deﬁned physical I/O points

and placed as a deﬁned instance in the state machine

call (see the implementation section); for example,

we deﬁne an equipment pump with all its methods

and properties, but only when we have certain pumps

(FreshwaterPump01, WasteWaterPump01, ...) instan-

tiated in our project will water ﬂow.

So with these concepts we are able to forget the

internal details of the equipment for all future im-

plementations of the same sort of pump and can

concentrate on the method and property interface.

46.2.4 Interchangeability

Interchangeability has a strong relation to reusability as

it is based on the same concepts, although it describes

another topic.

Reusability refers to the ability to use the same

equipment without major efforts again in the same

or another project. Interchangeability applies when we

want to replace existing equipment with another type

of equipment, but with the same functionality. Accord-

ing to our encapsulation approach, equipment with the

same functionality should have the same interface layer,

although the implementation layer and the base layer

Part E 46.2

800 Part E Automation Management

are different. We advise strict application of this rule, at

least for base equipment.

Consider, for example, that one has to change

a pump with all its control and monitoring periphery

for any reason (customer demand, unavailability, etc.)

with one from another manufacturer. It is evident that

often the physical implementation of the machine will

be different, even though it has the same functionality.

Having two equipments describing the two pump

systems with the same interface layer makes software

changes possible in a matter of minutes.

46.2.5 Interoperability

As long as the deﬁned equipment runs on a central-

ized system, communication between them leads to no

trouble. As we pointed out in the Introduction systems

nowadays are highly complex and distributed, so we

need implementation concepts to simplify access be-

tween equipment even in high-grade networked and

heterogeneous environments,starting at low controllev-

els with existing equipment.

We will not describe all the systems and attempts in

hardware and software that exist or are in development,

which could ﬁll books. We only want to focus on the

way we structure the issue.

As pointed out in the paragraph on encapsulation,

the only way of accessing other equipment is by using

the interface layer. As a fetch-ahead of the implemen-

tation, we will see that this interface is not part of

the equipment functions, but is a separate, generally

available data structure. For the time being, this data

structure is only composed of basic data types.

As a paradigm we do not allow the implementation

layer of a single equipment to be spread over sev-

eral controllers. This seems like a strong restriction on

ﬁrst reﬂection, but it enforces well-elaborated encap-

sulation, and good and ﬁne-structured systems. As an

additional advantage, it simpliﬁes equipment communi-

cation, which is one of our aims.

46.3 Strategy

46.3.1 Device Drivers

As we deﬁned in the paragraph on encapsulation the

basis of every system is its base equipment – the equip-

ment connected directly to the physical world. We

consider this equipment like device drivers in the PC

environment. In the same way that a program in Win-

Equipment

Control

valve

Discrete

configuration:

Motor

Status pot

Limit switches

Discrete

Digital I/O

Analog I/O

µC based

positioner

Bus based

Profibus

Fieldbus

Methods:

GoPosition 50%

Open

Close etc.

Properties:

Position 50%

Status

FailureNr etc.

Equipment interface

Electric Pneumatic

Physical interface

Physical

implementation

SW implementation

Implementation layer

Communication

Base layer

Device driver

Fig. 46.1 Example of a single base equipment (control valve)

dows does not care about the actual physical mouse

type connected to the computer, but only the abstracted

events, other base or abstracted equipment does not

care about the physical implementation of the accessed

equipment.

All base equipment, at least, is implemented in the

implementation layer as a state machine, executing the

functions necessary to the actual state and checking all

allowed transitions to switch to another. Typically an-

other cycle is used to catch all possible exceptions.

Figure 46.1 shows the example of a control valve

(base equipment) with two possible physical and

software implementations. The left column in the im-

plementation part depicts a discrete built-on electric

valve with a motor, a potentiometer providing feed-

back, and limit switches for the end positions. In this

case the implementation layer has to build up the com-

plete functionality of the valve, such as the control of

the motor, the control loop with the feedback poten-

tiometer, etc. In the right column a micro controller

(µC) positioner-based pneumatic valve is represented.

Here the implementation layer has to manage mainly

the communication to the µC positioner, as the control

itself is done by the external logic.

Additionally the independency of the physical im-

plementation is visible. As the electrical valve is

Part E 46.3

Practical Automation Speciﬁcation 46.3 Strategy 801

Interface

layer

Discrete

Bus based

Central

Decentral

Equip 01

Methods: Meth01, Meth02, ...

Properties: Prop01, Prop02, ...

Physical I/O:

Algorithms State machine

Implementation

layer

Base

layer

State

Trans01

Trans02

Trans03

Fig. 46.2 Example of a specifying single base equipment

(equipment block diagram); Equip01 does not use other

equipment, accessing only physical I/O

connected via the base interface to discrete I/O,the

pneumatic valve is running on a bus system.

Nevertheless the interface layer is the same, and we

can control both valve types from higher-level equip-

ment with a handful of methods and properties. So we

fulﬁll at least the demands for encapsulation, reusabil-

ity, and interchangeability.

46.3.2 Equipment Blocks

To model a complex system a graphical representa-

tion of its equipment is helpful. We choose a uniﬁed

modeling language (UML) class-like representation, al-

though the diagram has an additional area for the base

layer [46.4].

Figure 46.2 shows an equipment block for a sin-

gle base equipment interfacing the base layer singly to

Interface

layer

Motor 01

Methods: Start, stop, break, ...

Properties: Running, stopped,

break status, error,

errorNO

Physical I/O:

Motor relay on, break on,

relay/protection feedback

Base

layer

Fig. 46.3 Specifying implementation of single base equip-

ment (relay/motor protection controlled motor)

Interface

layer

Meth01, Meth02, ...

Prop01, Prop02, ...

Central

Decentral

Discrete

Bus based

Equip 11

Methods: Meth11, Meth01, ...

Properties: Prop11, Prop01, ...

Interface Equip01: Physical I/O:

Physical I/O

Equip01

Algorithms State machine

Implementation

layer

Base

layer

State

Trans01

Trans02

Trans03

Fig. 46.4 Specifying generalization of single base equip-

ment

physical I/O and not to other equipment. The implemen-

tation layer is not a must for the diagram representation,

but can be used for clariﬁcation of the actual execution

of the equipment.

Figure 46.3 depicts the diagram for a simple motor

with a brake controlled only by a relay–motor protec-

tion switch combination with feedback contacts.

Figure 46.4 shows a more speciﬁc equipment inher-

ited from a general one. Equip11 will use the methods

and properties of Equip01, adding some speciﬁc new

methods and properties by implementing additional

Interface

layer

Motor 11

Methods: Start, stop, break, hold,

changeDirection, changeFrequency

Properties: Running, stopped, direction,

frequency, break status,

error, errorNo

Physical I/O:

DirectionInput,

FrequencyAl,

FrequencyAO, ...

Interface Motor01:

Start, stop, break,

running, stopped,

error, errorNo

Base

layer

Fig. 46.5 Specifying implementation of single base equip-

ment based on generalized base equipment (motor con-

trolled by frequency converter)

Part E 46.3

802 Part E Automation Management

physical IO and/or by implementing new algorithms

and transitions in the interface of Equip01.

Figures 46.4 and 46.5 demonstrate the generaliza-

tion (inheritance) of equipment in general based on the

example of a more sophisticated implementation of the

motor controlled by a frequency converter unit. Bear

in mind that there are no automatic mechanisms for

inheritance in EN 61131 as in object-oriented program-

ming (OOP) languages.Nevertheless, we implementthe

underlying idea and call the method generalization to

indicate the difference.

Equip11 can forward the interface layer of Equip01

to its own interface layer or can override certain

methods and properties of Equip01 as its own imple-

mentation.

Figure 46.5 depicts a motor controlled via an intel-

ligent frequency converter. It is derived from the more

general Motor01 shown in Fig.46.3. Depending on the

actual implementation, the interface of Motor01 can be

forwarded directly to the interface layer of Motor11, or

some methods and/or properties have to be overridden.

Figure 46.6 represents a single abstract equipment,

built up on two sublevels, as Equip02 accesses another

equipment. Euip21 is abstract, as it does not access

physical I/O directly.

Interface

layer

Meth11, Meth12, ...

Prop11, Prop12, ...

Equip 21

Methods: Meth21_1, Meth11, Meth21, ...

Properties: Prop21_1, Prop11, Prop21, ...

Interface Equip01:

Meth21, Meth22, ...

Prop21, Prop22, ...

Interface Equip02:

Phys. I/O

Equip02

Interface

Equip0X

Physical I/O

Equip01

Algorithms State machine (optional)

Implementation

layer

Base

layer

State

Trans01

Trans02

Trans03

Fig. 46.6 Abstract equipment (does not access physical

I/O directly)

46.3.3 Communication

As stated above, communication between equipment is

allowed only through use of the interface level. For

communication between equipment on the same con-

trol unit, shared data blocks are used in general. For

homogenous distributed systems all open or proprietary

transfer mechanisms are allowed, ensuring coherent

data transfer.

For data communication between heterogeneous

distributed systems a standardized communication pro-

tocol has to be used. As object linking and embed-

ding (OLE) for process control (OPC) data access

(DA) is widespread, we normally use this proto-

col. As version 2 of this protocol does not support

well-structured data, the interface layer data has to

built up by basic data types only when using OPC

DA 2.

With broad distribution of OPC DA 3orOPC ex-

tensible markup language (XML) data access (OPC

XML-DA) this constriction will vanish in the fore-

seeable future, reducing implementation time for the

interface communication [46.5].

Special attention has to paid to access to the inter-

face layer of a single equipment by another equipment.

As indicated in Figs. 46.4 and 46.6, in general, a sin-

gle subequipment is embedded into another equipment

only via connecting the interface layer of subequipment

to the base layer of theaccessing equipment. In this way

we will obtain a well-structured and strictly hierarchical

system.

An exception to this rule has been implemented

for accessing data of interest to a group of equipment,

bypassing this strict hierarchical system. A separate

handler extracts ﬁltered data from the interface layer of

deﬁned equipment, stores it in separated data blocks,

and present these to a certain interface of the imple-

mentation layer. In general we use this outlier only for

exception handling.

46.3.4 Rules

As the following implementation will be done on stan-

dard EN 61131-based systems, the following rules have

to be implemented as a design guide, as these ex-

isting systems do not force the engineer to act in

an equipment-oriented way. On the other hand, only by

Part E 46.3

Practical Automation Speciﬁcation 46.5 Additional Impacts 803

using a C++ compiler, nobody is barred from writing

unstructured code in an objectless method. The rules

are:

1. Encapsulation is a must: no direct access to the

physical level other than by distinctive base equip-

ment.

2. Abstraction has to be forced to the highest level

possible, which makes especially interchangeability

simple.

3. Interequipment communication has to be done only

by use of the interface level (methods and proper-

ties).

4. Generalization has to be used whenever possible.

5. The use of abstract equipment should be done in the

lowest possible level.

6. Implementation of one single equipment on a single

controller (no implementation of algorithms or state

machines in the implementation layer via more then

one controlling unit).

46.4 Implementation

As pointed out at the beginning, in this chapter we want

to focus on the implementation of the topics elaborated

so far for EN 61131-based PLCs, since this poses a par-

ticularly challenge.

We have chosen the implementation in instruction

list form, as the ﬂexibility of this method in general

is the largest for most control systems. Nevertheless

one can use structured text or function block diagrams;

ladder diagrams or sequential function charts are not

adequate [46.2].

All equipment is implemented in function blocks;

each instanceof the function block represents a physical

unit for base equipment or a certain virtual or composed

unit for abstract equipment.

The baselayer is represented by the function block’s

own encapsulated data block, whereas the interface

layer is represented by a separate, general data block,

unique for each implementation of the equipment. This

allows simple data communication and easy multiple

access for different higher-level equipment.

For base equipment a state-machineimplementation

is a must, although abstract equipment should also use

this method if it makes sense.

All base equipment function block are called cycli-

cally by a service routine and run their state-machine

functions. Implementing this approach, at least er-

ror handling is done for all devices, independently of

whether the device is actually used or not. This is a ma-

jor advantages for early failure detection. The way of

connecting physical I/Oto baseequipment is not limited

and could be either discrete on a centralized unit or via

ﬁeldbuses, Ethernet or even wireless for decentralized

peripherals.

As mentioned earlier, one homogenous control unit

is responsible for implementing the algorithms and

state-machine functions for a single equipment, i.e.,

such a control unit can of course host a large number

of equipments, but the implementation layer of one sin-

gle equipment cannot be executed by several control

devices.

So, considering the communication aspect, even in

heterogeneous networked systems different communi-

cation methods simply have to map the interface data

blocks to the participating control units in a coherent

manner.

Practically we use system-speciﬁc communication

methods, as long we are working in homogenous plat-

forms, because they are in general more efﬁcient. If

we leave the homogenous domain, we normally use

OPC DA and OPC AE (alarms and events) [46.5].

Because we do not mix data with data com-

munication in our strategy, functional engineering

and data communication setup can be handled sepa-

rately.

46.5 Additional Impacts

46.5.1 Vertical Integration and Views

In the Introduction of this chapter we found that ver-

tical integration of processes is an answer to many of

the demands of modern business [46.6]. Figure 46.7

represents the business as well as the communica-

tion pyramid in a contemporary enterprise. Nowadays

the control level is the domain of PLCs, whereas

Part E 46.5

804 Part E Automation Management

Enterprise planning

Factory management

Production management

Process level

ERP

MES

Control

Data

Field

SCADA

Fig. 46.7 Business and communication pyramid in a modern enter-

prise

supervisory control and data acquisition (SCADA),

manufacturingexecutionsystems (MES),and enterprise

resource planning (ERP) are the domains of PC-based

devices [46.7].

With the implementation of an equipment-based

programming structure at the control level we overcome

the existing gap between the ﬁeld and the data/IT level.

As many enterprise MES and ERP solutions are

already object oriented, equipment-based control struc-

tures can easily be mapped to objects in higher-level

applications, as the equipment constructs are built up

in a class-like manner [46.7].

The hierarchical structure of the equipment imple-

mentation follows the natural business pyramid, and

the encapsulation and abstraction support the inherent

enforcement of data reduction in the lower ﬁeld level.

46.5.2 Testing

A major part of resources during the development of

a system is spent on testing its functionality and excep-

tion handling. By using software strategies with a clear

hierarchical structure, a modular concept with a strictly

deﬁned interface layer architecture, these resources can

be dramatically reduced, concurrently increasing per-

formance and stability.

46.5.3 Simulation

Another attempt to reduce testing resources is the

simulation of systems or subsystems of a project. If

a simulation is connected to real hardware, we speak of

hardware in the loop simulation. In testing developed

equipment, one can differentiate between two cases.

The higher-level equipment accessing the part to be

tested is simulated, or a lower-level part we want to

access is simulated.

In both cases the concept of equipment-based

structures simpliﬁes the simulation part. Firstly, most

simulation tools are object oriented, so we are able

to map our equipment easily to their classes. Second

the simulation environment has to model only the ab-

stracted interface layer of the simulated subsystem,

rather than simulating all the necessary I/Os.

46.6 Example

Profactor, amongst others, has been a supplier of test

stands for heat and ﬂow meters for 20 years; addition-

ally theautomation group of ARC-srdelivers innovative

automation solutions for the process and production in-

dustry and also develops new automation processes for

a couple of sectors [46.8].

In 2000 Profactor was put in charge of building

one of the largest and most modern test stands for heat

meters in Berlin. The customer was the well-known

Physikalisch Technische Bundesanstalt (PTB) [46.9].

In addition to building up the mechanics and mea-

surement system, challenging the frontiers of today’s

realizability, the test stand had to be embedded into an

overall test administration system. This started with the

management of customers, test orders, and devices un-

der test, and ended with management of test reports

and quality management for the test stand with its own

subsystems.

As the system for the PTB was the most complex

test stand ever, incorporating about 1000 physical I/O

and measurement points, including dozen of subsys-

tems, and has to be vertically integrated into the testing

hierarchy of the PTB, Profactor decided to implement

the described system for the actual and future system

as well as for other complex systems in their ﬁeld of

activities [46.10].

Part E 46.6