Nof S.Y. Springer Handbook of Automation

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

Modeling and Software for Automation 22.3 Reuse-Driven Software Development 375

tion through abstract coupling as their chief adaptation

techniques.

These two adaptation techniques are brieﬂy illus-

trated in Fig. 22.12. The framework components are

implemented as reusable classes. Inheritance (left-hand

class diagram in the ﬁgure) allows a user to modify only

a subset of the reusable class behavior. Object compo-

sition (right-hand class diagram in the ﬁgure) lets the

reusable class delegate part of its behavior to an ex-

ternal class that is characterized through an abstract

interface. It is notable that, in both cases, the behav-

ior of the reusable class is adapted without touching its

source code. This is important because it means that the

reusable class can be qualiﬁed once at framework level

and can then be adapted to different operational situ-

ations without having to undergo a full requaliﬁcation

process because its source code was not changed. Some

delta qualiﬁcation effort will always be required be-

cause of the different operational context but its extent

will be more limited than would be the case if the adap-

tation had required manual modiﬁcations to the source

code.

Object-oriented techniques provide adaptability

with respect to functional requirements only. Control

applications however are characterized by the presence

of nonfunctional requirements covering issues such as

timing, reliability, observability, testability,and soforth.

The lack of techniques to model nonfunctional adapt-

ability was one of the prime causes of the low level of

reuse in the control domain. Recently, aspect-oriented

programming (AOP) has emerged as a remedy for this

problem.

Aspect-oriented programming [22.18] is a software

paradigm that allows cross-cutting concerns to be ex-

pressed and implemented in a modular manner. At the

most basic level, aspect-oriented techniques can be seen

as a means to perform automatic transformations of

some base source code. An aspect-oriented environ-

ment consists of two primary items: an aspect language

and an aspect weaver. The aspect language allows the

cross-cutting concerns to be speciﬁed and encapsu-

lated in self-contained modules. The aspect weaver is

a compiler-like tool that reads an aspect program and

projects the changes it speciﬁes onto some base code.

This is illustrated in Fig.22.13.

Current software engineering practice privileges

the modeling of the functional aspects of an appli-

cation. Most software modeling tools are accordingly

designed to decompose a software system into func-

tional units (which, depending on the implementation

technology, can be modules, classes, objects, etc.).

Aspect

weaver

Aspect

program

Specifies a mocification

of the base code

Code to be modified

Base

code

Modified

code

Fig. 22.13 Adaptability through aspect-oriented techniques

Nonfunctional issues tend to cross-cut such functional

models and cannot therefore be easily dealt with.

Aspect-oriented techniques can be used to encapsulate

them and to facilitate their modeling and implemen-

tation. The use of aspect-oriented techniques, in other

words, allows the application of the principle of sep-

aration of concerns to the nonfunctional aspects of

a software system. As such, aspect-oriented techniques

provide the means to achieve adaptability to nonfunc-

tional requirements. Aspect-oriented techniques are

very powerful but they are comparatively new and tool

support is weak. One AOP tool that deserves mention

because it is speciﬁcally targeted at critical systems is

XWeaver [22.19]. XWeaver is a source-level weaver

that allows source code to be modiﬁed in a controlled

way that is designed to mimic the effect of man-

ual modiﬁcations and to allow code inspections and

other quality checks to be performed on the modiﬁed

code.

22.3.4 An Example: The OBS Framework

The on-board software (OBS) framework was partly

developed at ETH and partly at P&P Software GmbH

(a research spin-off of ETH) to investigate the ap-

plication of advanced software engineering techniques

to the development of embedded control systems.

The framework currently exists only as a research

prototype that has been instantiated in laboratory exper-

iments.

The OBS framework was intended to demonstrate

the industrial maturityof object-orientedtechniques and

generative technique [22.19, 20] for software frame-

works for embedded control systems [22.20,21].

The OBS framework was designed in 2002. The

OBS framework is a software framework that aims to

cover the onboard satellite application domain and in

particular the attitude and orbit control system (AOCS)

Part C 22.3

376 Part C Automation Design: Theory, Elements, and Methods

XSLT

program

XML-based

specification

Application

specific

building

blocks

Building

blocks

Application model

Generator

meta-component

Fig. 22.14 Conceptual structure of a framework-based generative

system

and data handling subsystems. The OBS framework is

designed to offer reusable assets of four different types:

•

Design patterns that describe high-level design

solutions to recurring design problems in the frame-

work domain

•

Abstract interfaces that deﬁne abstract services that

have to be provided by the framework

•

Concrete components that provide default imple-

mentations for some of the services deﬁned by the

framework interfaces

•

Generator metacomponents that encapsulate pro-

grams to generate application-speciﬁc implementa-

tions for some of the framework interfaces.

The design patterns are the vehicle through which the

architecture predeﬁned by the framework is captured.

The architecture of a target application to be instan-

tiated from the framework is derived by instantiating

one or more framework design patterns. The abstract

interfaces and the concrete components support the in-

stantiation of the design patterns and will normally

directly appear in the target application. The metacom-

ponents do not directly enter the ﬁnal application but

are instead used to generate components that do, or

to modify existing components so as to make them

compatible with the requirements of a particular target

application.

Generator metacomponents are perhaps the most in-

novative element of the OBS framework. They were

introduced to partially automate the adaptation pro-

cess whereby the assets provided by the framework

are modiﬁed to match the needs of a target applica-

tion. In theOBS framework, generator metacomponents

are implemented as extensible stylesheet language

transformation (XSLT) programs that process a speci-

ﬁcation written in extensible markup language (XML)

and generate either code for the application-speciﬁc

component or the conﬁguration code for clusters of

components. Their mode of operation is illustrated in

Fig.22.14.

The code generation process is driven by a set

of speciﬁcations that are expressed in an XML docu-

ment. This is the so-called application model which is

a speciﬁcation of the target application expressed in an

XML-based language that is speciﬁcally tailored to the

needs of the OBS framework.

One concrete example of generator metacompo-

nents provided by the OBS framework is a set of XSLT

programs that can automatically generate a wrapper

for the code generated by the Matlab tool. The wrap-

per transforms the C routines generated by Matlab into

components that are suitable for integration with other

OBS framework components.

The architecture of the OBS framework is fully ob-

ject oriented. The basic principles of this architecture

are summarized in [22.21,22]. Implementation is done

using a restricted subset of C/C++. TheOBS framework

is packaged as a website which gives access to all the

items provided by the OBS framework and to their doc-

umentation (www.pnp-software.com/ObsFramework).

22.4 Current Research Directions

As already indicated, the reuse- and model-driven ap-

proaches are complementary and are often used to

realize different parts of the same application. Current

research strengthens this complementarity because it

tries to ﬁnd ways to merge them. There are several

ways in which such a merge can be done and the next

two sections describe two ways that have been explored

at ETH.

22.4.1 Automated Instantiation

Environments

The effectiveness of the product family approach de-

rives from the fact that the level of design abstraction

is raised from that of individual applications to that

of domains of related applications. This allows invest-

ment in the design and development of software assets

Part C 22.4

Modeling and Software for Automation 22.4 Current Research Directions 377

to be reused across applications. Current research at-

tempts to extend the effectiveness of product families

further by automating their instantiation process. The

objective is to arrive at a generative environment of the

kind shown in Fig.22.15. The environment automati-

cally translates a speciﬁcation of an application in the

family domain into a conﬁguration of the family assets

that implements it.

An environment of the type shown in Fig.22.15

would represent a synthesis of the model- and reuse-

driven approach because it would allow the target

application to be constructed automatically from its

speciﬁcation while at the same time taking advantage

of the existence of predeﬁned building blocks that im-

plement part of the application functionality.

No practical generativeenvironment isyet available,

but some work has already been done in developing

graphical user interface (GUI)-based tools where prede-

ﬁned components can be conﬁgured and linked together

to form a complete application. A research prototype

has been realized at ETH [22.23] and is described

in [22.24,25]. This tool is based on a modiﬁed version

of a standard JavaBeans composition environment.

The JavaBeans standard [22.22] supports the deﬁni-

tion of components to create GUI-based applications.

Several commercial environments are available in

which users can create GUI-based applications by com-

posing JavaBean components. At their most basic, these

environments offer a palette where the predeﬁned com-

ponents are shown, a canvas where the components

can be linked together, and a property editor where

the components can be conﬁgured. The user selects the

components required forthe application fromthe palette

and pulls them down onto the canvas, where they can be

linked through graphical or semigraphical operations.

The attributes of the component are set in a wizard-like

property editor.

Generative environment

Application

implementation

Application

specification

Family model

Family software assets

Family-independent infrastr.

Fig. 22.15 Automated instantiation environment for soft-

ware product families

In our project, we modiﬁed a JavaBeans composi-

tion environment to handle the components provided by

the AOCS framework (a predecessor of the OBS frame-

work described in Sect.22.3.4, see also [22.26]). The

objective was to allow users to instantiate the frame-

work without writing any code. The user selects the

components required for the target application from

a palette and composes and conﬁgures them in a GUI-

based canvas and editor. When the task is completed,

the framework instantiation code is automatically gen-

erated by the environment. The code is designed to be

legible to allow manual modiﬁcations if required.

22.4.2 Model-Level Reuse

Automated instantiation environments represent one

way in which the model- and reuse-driven paradigms

can be merged. A second attempt to achieve the same

goal of merging the two approaches and thus reaping

the beneﬁts of both is model-based reuse. In virtually

all industrial applications of the framework approach,

reuse takes place at code level: the reused entities are

the framework components and the framework inter-

faces expressed as source code (or, sometimes, as binary

entities). In reality, reuse could also take place at model

level.

With referenceto Fig.22.8, in a framework develop-

ment process, the output of the domain design phase is

a set ofdesign modelsthat describethe framework inter-

faces and components. In practice, such design models

are often expressed as generic universal modeling lan-

guage (UML) design models [22.27,28]. The semantics

of UML isin manyrespects ambiguous.This means that

the models can, at most, have a descriptive/informative

role. Reusability can only take place at the code level

because it is only the code that unambiguously de-

scribes the reusable assets provided by the framework.

The latest version of UML (UML2) includes proﬁl-

ing facilities that allow users to create their own version

of the language with a precise semantics [22.29, 30].

This in turns means that the design models can be made

as precise as code. In fact, it becomes possible to fully

generate the implementation of the framework assets

from their models. In this case, reuse can take place

at the model level since the models contain the same

information as the code.

Such a model-driven approach is being explored at

ETH in the ASSERT project [22.31] and is described

in [22.32]. It is being applied to industrial applications

by P&P Software in the currently ongoing CORDET

project (www.pnp-software.com/cordet). The approach

Part C 22.4

378 Part C Automation Design: Theory, Elements, and Methods

Framework

software

component

Application

software

component

Framework-level properties

capturing domain-invariant

behavior and functionalities

Framework-level properties

(inherited from framework

component)

Application-level properties

capturing application-specific

behavior and functionalities

(introduced by adaptation process)

Adaptation

process

Fig. 22.16 Property-preserving framework adaptation

is based on a UML2 proﬁle, the framework (FW)

proﬁle, that is speciﬁcally targeted at framework devel-

opment [22.33]. This proﬁle uses UML2 class diagrams

to describe the interfaces of the framework components

and UML2 state machines to describe their internal

behavior. The proﬁle also deﬁnes adaptation mecha-

nisms that are based on both class and state machine

extension.

A framework is conceptualized as a repository

of models (not code) of adaptable components. The

framework-level models guarantee certain properties

that represent functional invariants in the frameworkdo-

main. Since the properties are associated to the design

models, they can, if desired, be formally veriﬁed on the

models.

The FW proﬁle constrains the adaptation mecha-

nisms of the models toensure that the propertiesthat are

Class Base {

. . .

}

Class Derived

extends Base {

. . .

}

Framework-level

functional

properties

Framework-level

functional

properties

Application-level

functional

properties

Adaptation

process

State A

State C

State B

State A

State C

State B

Fig. 22.17 Class extension and state

machine extension

deﬁned at framework level still hold at applicationlevel.

This ensures that all applications that are instantiated

from the framework will satisfy the properties deﬁned

at framework level. At application level, developers are

of course free to add new properties that encapsulate

application-speciﬁc behavior (Fig.22.16).

Space does not permit to explain in detail how prop-

erty invariance can be combined with extensibility and

adaptation, but Fig.22.17 gives a ﬂavor of the approach.

The top halfof the ﬁgurerepresents the framework-level

models which, as mentioned above, consist of class

diagrams and state diagrams describing the internal be-

havior of the framework classes.

The framework-level properties express logical re-

lationships among the variables that deﬁne the state of

one or more framework components. Formally, func-

tional properties may be expressed as formulas in linear

temporal logic. Physically, they encapsulate functional

invariants in the framework domain. In practice, the

framework properties are deﬁned as properties on the

behavior of the state machines associated to the frame-

work classes.

During the framework instantiation process, the

framework-level models are extended to capture

application-speciﬁc behavior. Both the framework

classes and their state machines must be extended.

However, since it is desired to ensure that applications

that use the extended models still satisfy the properties

deﬁned at framework level, the extension mechanism

must be such that the new classes and their state ma-

chines still satisfy the properties that were deﬁned at

framework level.

Part C 22.4

Modeling and Software for Automation References 379

The properties deﬁned on the base state machine

capture aspects of the state machine topology and of

its state transition logic. Hence, the simplest way of

preserving them during the extension process is to

constrain the extension process to deﬁne the internal be-

havior of one or more of the states of the base state

machine without altering its topology and transition

logic. This is illustrated in Fig.22.17, where the de-

rived state machine differs from the base state machine

only in having an embedded state machine added to one

of the base states. The derived state machine, in other

words, deﬁnes the internal behavior of a state that was

initially deﬁned as being a simple state.

The FW proﬁle adopts the extension approach of

Fig.22.17 and forbids all other kinds of state machine

extensions that are allowed by UML2 (redeﬁnition of

transitions, deﬁnition of new transitions between exist-

ing states, deﬁnition of new states or regions, etc.).

The extension mechanism sketched above, though

very simple, corresponds to a realistic situation that of-

ten arises in framework design. This is the case that

is described by the well-known template design pat-

tern of [22.34]. This design pattern describes the case

of a class that deﬁnes some skeleton behavior that of-

fers hooks where application-speciﬁc behavior can be

added by overriding virtual methods or by providing

implementation for abstract methods. The behavior en-

capsulated in the skeleton is intended to be invariant.

In terms of the model underlying the FW proﬁle,

the invariant skeleton behavior is encapsulated by the

base state machine, whereas the variable hook behavior

is encapsulated by the nested state machines added by

the derived class.

The modeling and adaptation concept sketched

above is formally captured by the FW proﬁle. The pro-

ﬁle can also be seen as a domain-speciﬁc language that

is targeted at the deﬁnition of the functional behavior of

software frameworks. This approach thus has all the ba-

sic elements of both the model-based approach (design

expressed through models with unambiguous seman-

tics and use of domain-speciﬁc languages to express

the models)and of the reuse-driven approach(deﬁnition

of domain-speciﬁc, reusable, and adaptable software

assets).

22.5 Conclusions and Emerging Trends

Software for automation has some inherent difﬁculties,

such as real-time conditions, distributed and parallel

operation, easy-to-use interfaces, data storage and re-

porting, etc.. The software often has to be implemented

on one-of-a-kind processes or plants requiring a highly

automated development. Two possible routes, which are

often combined in practical solutions, have been pre-

sented in this chapter. One consists of automatically

generating code from a textual or graphical description

of the software (model driven) and the other consists of

the use of frameworks (reuse driven). Both have their

application domains; the framework approach seem to

be better suitedfor the development of softwarefor fam-

ilies of systems because of its inherent possibility of

adaptation. Examples of both approachesfrom ourwork

at ETH are given. Design of software is a challeng-

ing task; easy recipes and cookbooks are in our view

not appropriate, and no attempt has been made in this

direction.

While consulting tasks with industry are propri-

etary, a considerable shift has been noted over the last

few years in the area of software development towards

outsourcing and consulting services. Many small com-

panies offer solutions, which often compete favorably

with in-house solutions. In such circumstances, it may

be advisable to order a framework instead of a program.

To use existing frameworks provided under free or open

software licences it may also be advisable to organize

some training or consulting to speed up the develop-

ment. The management of such software projects with

several contributing teams is, however, still a challeng-

ing task.

References

22.1 W. Schaufelberger, P. Sprecher, P. Wegmann:

Echtzeit-Programmierung bei Automatisierungs-

systemen (Teubner, Stuttgart 1985), in Ger-

man

22.2 G.E. Maier, W. Schaufelberger: Simulation and im-

plementation of discrete-time control systems on

IBM-compatible PCs by FPU, 11th IFAC World Congr.

(Pergamon, Tallinn 1990)

Part C 22

380 Part C Automation Design: Theory, Elements, and Methods

22.3 P.Kolb,M.Rickli,W.Schaufelberger,G.E.Maier:

Discrete time simulation and experiments with FPU

and block-sim on IBM PC’s, IFAC ACE (Pergamon,

Boston 1991)

22.4 M. Kottmann, X. Qiu, W. Schaufelberger: Simula-

tion and Computer Aided Control System Design

using Object-Orientation (vdf ETH, Zürich, 2000)

22.5 D. Dori: Object-Process Methodology (Springer,

Berlin, Heidelberg 2002)

22.6 A.H. Glattfelder, W. Schaufelberger: Control Sys-

tems with Input and Output Constraints (Springer,

Berlin, Heidelberg 2003)

22.7 A.Benveniste,P.Caspi,S.A.Edwards,N.Halb-

wachs, P. Le Guernic, R. de Simone: The syn-

chronous languages 12 years later, Proc. IEEE 91(1),

64–83 (2003)

22.8 P. Caspi, A. Curic, A. Maignan, C. Sofronis, S. Tri-

pakis: Translating Discrete-Time Simulink to Lustre.

In: ACM Transactions on Embedded Computing Sys-

tems (TECS) 4(4) (New York 2005)

22.9 Esterel Technologies: http://www.esterel-

technologies.com/ (last accessed February 6, 2009)

22.10 T.A. Henzinger, B. Horowitz, C.M. Kirsch: Giotto:

a time-triggered language for embedded pro-

gramming, Proc. IEEE 91(1), 84–99 (2003)

22.11 J. Chapuis, C. Eck, M. Kottmann, M.A.A. San-

vido, O. Tanner: Control of helicopters. In: Control

of Complex Systems, ed. by A. Åström, P. Al-

bertos, M. Blanke, A. Isidori, W. Schaufelberger,

R. Sanz (Springer, Berlin, Heidelberg 2001) pp. 359–

392

22.12 N. Wirth: Tasks versus threads: An alternative mul-

tiprocessing paradigm, Softw.-Concepts Tools 17(1),

6–12 (1996)

22.13 N. Wirth: Digital Circuit Design (Springer, Berlin,

Heidelberg 1995)

22.14 T.A. Henzinger, M.C. Kirsch, M.A.A. Sanvido,

W. Pree: From Control Models to Real-Time Code

Using Giotto, IEEE Control Syst. Mag. 23(1), 50–64

(2003)

22.15 P. Donohoe (ed): Software Product Lines – Expe-

rience and Research Directions (Kluwer, Dordrecht

2000)

22.16 M. Fayad, D. Schmidt, R. Johnson (Eds.): Building

Application Frameworks – Object Oriented Foun-

dations of Framework Design (Wiley, New York

1995)

22.17 V. Cechticky, A. Pasetti, W. Schaufelberger: The

adaptability challenge for embedded system soft-

ware, IFAC World Congr. Prague (Elsevier, 2005)

22.18 G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda,

C.VideiraLopes,J.Loingtier,J.Irwin:Aspect-

Oriented Programming, Eur. Conf. Object-Oriented

Program. ECOOP ‘97 (Springer, 1997)

22.19 I. Birrer, P. Chevalley, A. Pasetti, O. Rohlik: An as-

pect weaver for qualiﬁable applications, Proc. 15th

Data Syst. Aerosp. (DASIA) Conf. (2004)

22.20

J. Cleaveland: Program Generators with XML and

Java (Prentice Hall, Upper Saddle River 2001)

22.21 K. Czarnecki, U. Eisenecker: Generative Program-

ming (Addison-Wesley, Reading 2000)

22.22 R. Englander: Developing JavaBeans (Java Series)

(O’Reilly and Associated, Köln 1997)

22.23 A. Pasetti: http://control.ee.ethz.ch/˜ceg/

AutomatedFrameworkInstantiation/index.html,

(last accessed February 6, 2009)

22.24 V. Cechticky, A. Pasetti: Generative programming

for space applications, Proc. 14th Data Syst. Aerosp.

(DASIA) Conf. (Prague 2003)

22.25 V. Cechticky, A. Pasetti, W. Schaufelberger: Agen-

erative approach to framework instantiation.In:

Generative Programming and Component Engi-

neering (GPCE), Lecture Notes in Computer Science,

Vol. 2830, ed. by F. Pfenning, Y. Smaragdakis

(Springer, Berlin, Heidelberg 2003)

22.26 A. Blum, V. Cechticky, A. Pasetti: A Java-based

framework for real-time control systems, Proc. 9th

IEEEInt.Conf.Emerg.Technol.Fact.Autom.(ETFA)

(Lisbon, 2003)

22.27 M.R. Blaha, J.R. Rumbaugh: Object-oriented Mod-

eling and Design with UML (Prentice Hall, Upper

Saddle River 2004)

22.28 D. Rosenberg, M. Stephens: UseCaseDrivenObject

Modeling with UML: Theory and Practice (Apress,

Berkeley 2007)

22.29 S.W. Ambler: The Elements of UML 2.0 Style (Cam-

bridge University Press, Cambridge 2005)

22.30 R. Miles, K. Hamilton: Learning UML 2.0 (O’Reilly

Media, Köln 2006)

22.31 European Space Agency: http://www.assert-

project.net/assert.html (last accessed February 6,

2009)

22.32 M. Egli, A. Pasetti, O. Rohlik, T. Vardanega: A

UML2 proﬁle for reusable and veriﬁable real-time

components. In: Reuse of Off-The-Shelf Compo-

nents (ICSR), Lecture Notes in Computer Science,

Vol. 4039, ed. by M. Morisio (Springer, Berlin, Hei-

delberg 2006)

22.33 P&P Software GmbH: http://www.pnp-

software.com/fwproﬁle/ (last accessed February 6,

2009)

22.34 E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design

Patterns, Elements of Reusable Object-Oriented

Software (Addison-Wesley, Reading 1995)

Part C 22

381

Real-Time Au

23. Real-Time Autonomic Automation

Christian Dannegger

The world is becoming increasingly linked, inte-

grated, and complex. Globalization, which arrives

in waves of increasing and decreasing usage, re-

sults in a permanently dynamic environment.

Global supply networks, logistics processes, and

production facilities try to follow these trends and

– if possible – anticipate the volatile demand of

the market. This challenging world can no longer

be mastered with static, monolithic, and inert

information technology (IT) solutions; instead it

needs autonomic, adaptive, and agile systems –

living systems. To achieve that, new systems not

only need faster processors, more communication

bandwidth, and modern software tools – more

than ever they have to be built following a new

design paradigm. As determined by the industrial

and business environment, systems have to mirror

and implement the real-world distribution of data

and responsibility, the market (money)-driven

decision basis for all stakeholders in the (real or

virtual) market, and the goal orientation of people,

which leads to on-demand, loosely coupled, com-

munication with relevant partners (other players,

roles) based on reactive or proactive activities.

This chapter provides an insight into the core

challenges of today’s dynamics and complexity,

brieﬂy describes the ideas and goals of the new

concept of software agents, and then presents and

discusses industry-proven solutions in real-time

environments based on this distributed solution

design.

23.1 Theory ................................................. 382

23.1.1 Dig into the Subject.................... 382

23.1.2 Optimization: Linear Programming

Versus Software Agents ............... 383

23.1.3 Classiﬁcation

of Agent-Based Solutions............ 384

23.1.4 Self-Management ...................... 385

23.2 Application Example:

Modular Production Machine Control...... 385

23.2.1 Motivation ................................ 385

23.2.2 Case Environment ...................... 386

23.2.3 Solution Design.......................... 387

23.2.4 Advantages and Beneﬁts............. 389

23.2.5 Future Developments

and Open Issues......................... 391

23.2.6 Reusability ................................ 391

23.3 Application Example:

Dynamic Transportation Optimization .... 391

23.3.1 Motivation ................................ 391

23.3.2 Business Domain........................ 392

23.3.3 Solution Concept ........................ 394

23.3.4 Beneﬁts and Savings .................. 396

23.3.5 Emerging Trends:

Pervasive Technologies ............... 398

23.3.6 Future Developments

and Open Issues......................... 401

23.4 How to Design Agent-Oriented Solutions

for Autonomic Automation...................... 402

23.5 Emerging Trends and Challenges ........... 402

23.5.1 Virtual Production

and the Digital Factory................ 402

23.5.2 Modularization .......................... 403

23.5.3 More RFID, More Sensors,

Data Flooding ............................ 403

23.5.4 Pervasive Technologies ............... 403

References .................................................. 404

The following examples are discussed in detail in this

chapter, covering the solution approach, challenges, and

customer demand as well as relevant pros and cons:

•

An autonomic machine control system applied to

the adaptive control of a modular soldering ma-

chine. The particular case is concerned with the

Part C 23

382 Part C Automation Design: Theory, Elements, and Methods

creation of a novel modular production machine

with an integrated distributed agent control system,

which has been sold worldwide since the middle of

2008. The agent model is described in terms of the

speciﬁc customer requirements and the advantages

of the approach.

•

A solution to real-time road freight transportation

optimization using a commercial multiagent-based

system, LS/ATN (living systems adaptive trans-

portation networks), which has been proven through

real-world deployment to reduce transportation

costs for both small and large ﬂeets. After describ-

ing the challenges in this business domain and the

real-time optimization approach, we discuss how

the platform is currently evolving to accept live data

from vehicles in the ﬂeet in order to improve opti-

mization accuracy. A selection of the predominant

pervasive technologies available today for enhanc-

ing intelligent route optimization is described.

Both examples reﬂect their speciﬁc history and back-

ground, which motivated the customer and the develop-

ers to apply an autonomous automation approach.

Although software agents are a core principle of

the autonomous automation examples in this chapter

we only touch this ﬁeld slightly, as other chapters in

this book focus and elaborate on agent-based automa-

tion.

23.1 Theory

23.1.1 Dig into the Subject

First let us brieﬂy delve deeper into the title of this

chapter Real-Time Autonomic Automation, from right to

left.

Automation always has been – and still is – the ba-

sic starting point to relieve workers of routine tasks and

increase the utilization of resources, because of pro-

duction machinery, transportation capacity, and limited

material stock. Automation means using any kind of

mechanical device or program to carry out a repeti-

tive job faster, more reliably, and with higher quality

than human beings can normally achieve. According to

Wikipedia [23.1]:

Automation (ancient Greek: self dictated) ... is the

use of control systems such as computers to con-

trol industrial machinery and processes, reducing

the need for human intervention.

Autonomic is already a term very close or even

similar to the term agent-based. In many aspects both

describe the same characteristics. Autonomic systems

ﬁrstly have sensing capabilities to keep in touch con-

stantly with their environment and know what’s going

on (belief). Then they know what they want – their

purpose – their goals (desire). And ﬁnally autonomic

systems are able to derive and decide what to do (in-

tention) based on the current situation and predeﬁned

goals. Putting together these terms results in belief–

desire–intention (BDI), which is a software model

developed for programming intelligent agents. To again

cite Wikipedia:

An autonomic system is a system that operates and

serves its purpose by managing its own self without

external intervention even in case of environmental

changes.

The last part of this deﬁnition gives the important hint

that autonomic systems in particular are able to adapt

to changes in the environment (making use of their sen-

sors) in order to decide constantly on the best action

according to the current situation.

Real time is a critical term, as it is used ambigu-

ously and greatly depends on the environment in which

it is applied. The main differentiation made is between

hard and soft real-time systems. Hard real-time systems

guarantee a conﬁgured time from an event to system re-

sponse, since otherwise the whole system will fail, e.g.,

in brake control for cars or tail plane ﬁn control for a jet

ﬁghter. However, hard real-time control could also ap-

ply to comparably slow systems as long as the response

is guaranteed, such as a heating control where the re-

action may take several minutes. Soft real-time control

means that a system is typically fast enough to react in

due time. Deadlines are normally met, but if not kept

the system will not fail, but at most lose some quality;

for example, in dispatching systems real-time reaction

is important, but if a decision (to reshufﬂe order allo-

cations) is delayed there might be a loss of efﬁciency

and increased costs, but the system does not fail as

a whole.

Since distributed systems such as those discussed

speciﬁcally in this chapter require solutions supporting

heterogeneous environments, developers of such sys-

Part C 23.1

Real-Time Autonomic Automation 23.1 Theory 383

tems areattracted bythe platformindependency of Java.

Since its invention, Java has become increasingly fast,

but does not have built-in real-time capabilities. Thus

the real-time speciﬁcation for Java (RTSJ, JSR-001

(Java speciﬁcation request)) has been developed and

implemented by Sun and others as an add-on to stan-

dard Java, and offered to the market as real-time Java

or the Java real-time system (Java RTS). On their web-

site Sun gives another short and concise deﬁnition of

real time, which again emphasizes the difference be-

tween speed and predictability: “Real-time in the RTSJ

context means the ability to reliably and predictably re-

spond to a real-world event. So real-time is more about

timing than speed.” Additionally to a real-time pro-

gramming environment a real-time operating system is

needed, like Solaris 10, SUSE Linux Enterprise Real-

Time 10 (SP2) or Red Hat Enterprise MRG 1.0.1 Errata

releases.

Both examples described in this chapter do not

fulﬁll and do not need to fulﬁll the hard real-time

speciﬁcation. Why? The second example is a decision

support systemfor transport optimization wherethe dis-

patchers can still decide and become active independent

of the systems, as with a navigation system. The ﬁrst

example has to fulﬁll hard real-time requirements, but

the system design succeeded in keeping the critical real-

time parts within the local controller of each module

of the machine and thus outside the Java-based control

logic. With this approach the control system where the

system is normally fast enough to trigger the actuators

and the reaction guarantee is given by the lowest-level

controllers, the machine manufacturer could save sig-

niﬁcant costs by being able to use standard hardware,

a standard operating system, and a standard runtime

environment (Java SE).

Real Time through Autonomy

If hard real-time support will be needed in the future,

this does not conﬂict with the system layout – quite the

contrary: autonomous agent-based systems are initially

designed to build real-time control systems. The major

design principle to enhance real-time capabilities is the

natural and elementary separation of responsibilities,

and thereby the distribution of tasks. This design for

scalability allows making use of all (local) processing

power available in a solution and system environment.

Keeping local tasks and local decisions entirely local

results in high reactivity, independent of the overall sys-

tem load.

23.1.2 Optimization: Linear Programming

Versus Software Agents

To make things even more complex the real world has

given us not only the challenge of real-time reactivity

but also the parallel goal of optimal decisions (or at

least decision support). This means that a software sys-

tem not only has to cope with very complex, normally

NP-hard (nondeterministic polynomial-time hard), op-

timization problems, but also should solve them again

and again, building on the second by second changes in

the environment. Unfortunately new design paradigms,

such as software agents, are always compared with

traditional approaches in terms of solution quality, de-

spite the fact that traditional mathematical operation

research (OR) methods are not designed to handle real-

time events. For this reason the following descriptions

summarize the major differences and objectives of both

approaches; a more detailed discussion can be found

in [23.2].

Linear Programming

Pro. Current optimizers, which means traditional OR

methods such as linear programming, are designed to

ﬁnd the optimum for a problem, independent of the

processing duration.

Con. However, it is very hard and time consuming to

cover the full real-world complexity and map all differ-

ent aspects into a linear equation system, not to mention

changes of requirements, processes or business goals.

Despite many traditional optimizers try to achieve real-

time response, their basic intention to ﬁnd the absolute

optimum works against it. The optimization interval,

even combined with tricks and workarounds, is nor-

mally too long to be considered real-time.

Result. The optimum can be found, but too late. The

world might already have changed dramatically. The

optimum was only valid for the past, when the optimiza-

tion started. The difference between the calculated and

the current optimum is large, and the accumulated error

between the optimal curve and the found(to be optimal)

curve increases signiﬁcantly over time.

Software Agents

Con. The distributed negotiation approach with its

bottom-up search space expansion is not designed to

ﬁnd the optimum.

Part C 23.1

384 Part C Automation Design: Theory, Elements, and Methods

Pro. Rather, it permanently strives for the optimum,

as the optimization interval is very short and the

approach maps the real-world complexity in all its

details and can be customized to nearly any speciﬁc

need without touching the core optimization princi-

ple.

Result. A close-to-optimal result is found every second

or faster. The difference from the theoretical optimum

is relatively small and the total error over time is kept to

a minimum.

Conclusion

The optimum should not be seen and understood as

a single point in time, but instead as the difference be-

tween the continuously calculated optimization curve

and the real-world volatile optimum. This short ex-

cursion to real-time optimization and its application

in automated systems is properly summarized in the

following two statements: How does it help know-

ing what would have been the optimum one hour

ago? Or: Better be roughly right instead of precisely

wrong.

Decide ActSense

Performance

results

Proposal

Actuator

Sensor

“Agent-based reasoning”

Simulation

Control system

Decision support

Simulated

sensor data

Fig. 23.1 Solution classiﬁcation: depending on the existence of real-world or simulated sensors and actuators you can

distinguish between three system types: simulation, decision support or control system

23.1.3 Classiﬁcation

of Agent-Based Solutions

To understand and correctly apply agent-based solu-

tions it is important to follow a clear classiﬁcation of

software systems. Based on the short agent deﬁnition as

a sense–decide–act loop it is straightforward to classify

agent-based solutions (Fig. 23.1) depending on the exis-

tence of real-world or artiﬁcial interfaces for the sensors

and actuators.

Simulation System

If you input only simulated, recorded historical data or

forecasted data into an agent solution and only use the

system output for analysis but not for direct decisions,

then it is a simulation system. This applies, e.g., if real-

time captured order data for a dispatching systems are

fed into the dispatching system again, mostly for the

purpose of verifying the system conﬁguration (i.e., the

cost model, see below). The result of the simulation is

stored within databases, data warehouses or presented

in business graphs, but not used directly to control or

Part C 23.1