Model Driven Engineering in Operative

Industrial Process Control Environments

- Overview -

Ulrich Epple

Lehrstuhl fur Prozessleittechnik, RWTH AachenTurmstr. 64, 52064 Aachenepple@plt.rwth-aachen.de

Abstract. Industrial process control is a profitable field for model drivenapproaches. The paper presents an overview and discusses the basic con-cepts and architectural principles. In future an increasing demand forengineering and reengineering activities in the operative phase is ex-pected. In the industrial process control environment the necessary soft-ware changes in the operative phase often have to be performed withoutstopping the execution of the control system. The paper presents ideasand concepts to improve the model driven approaches and outlines waysto an assisted and partially automated control engineering.

1 Introduction

In process industry every plant is unique. Even ”exact plant copies” are differ-ent. Improved functionality, necessary adaptations to actual and local regula-tions, the usage of new equipment and the deficiency of the old documentationrequire a complete new engineering project. The reusability of process controlsoftware can be seen as being zero. Process control software is written for onlyone application and under heavy time and cost pressure. Process control softwareis written by ”normal” automation engineers and poorly tested. On the otherhand, strong requirements with respect to software quality and functional safetyhave to be kept. To master this problem the control engineers try to keep thingssimple. They follow a traditional model-based engineering procedure. Standard-ized and vendor-supported components are assembled in accordance to a world-wide common design schema. The components are defined one after the otherand assembled by connecting them via designated communication associations.Powerful engineering tools support the control engineering process. They offera comfortable graphical interface, they support a consistent specification of theinter-component communication, they allow the building of macros, they preventbasic design faults, they assist to distribute the specified functionality to the de-centralized hardware allocations, they offer integrated simulation functionalityand so on. Due to these powerful tools and the simple and intuitive architecture,the engineering of the control software was not stated as a critical problem. Butthe situation is changing. The rapidly increasing amount of functionality, the

G. Engels et al. (Eds.): Nagl Festschrift, LNCS 5765, pp. 749–765, 2010.c© Springer-Verlag Berlin Heidelberg 2010

750 U. Epple

required flexibility even in the operational stage, the need of verification andthe loss of competence within the engineering teams cannot be equalized by anadditional improvement of the classical tools. New approaches are required.

This paper starts with a short presentation of the structure of the produc-tion control task and the respective software architecture principles. Currentlyupcoming new requirements and challenges will be presented. The applicationof model-based concepts to manage these requirements will be discussed. Thepaper ends with a vision of the control architecture of the future.

2 Production Control Architecture

Figure 1 shows a so-called P&I Diagram (P&I =Pipe and Instrumentation) ofa chemical reactor. This is a typical example of a plant section in the processindustry.

Fig. 1. Example of a P&I-Diagram

In this reactor different chemical processes can be performed. Manufacturingexecution functions deal with all aspects of the control and supervision of suchtype of plants and production processes. In this section we focus on the mainproduction control task. The production control task can be divided into twoparts: the plant- or resource-related part and the product- or recipe-related part.

2.1 Plant-Related Control Tasks

In many cases, the basic levels of control are independent of the special pro-duction process. In figure 1 for example we find pumps, valves and a stirrer asactuators. As shown in figure 2, for every actuator an individual control modulecan be specified which captures all control requirements concerning this spe-cific actuator. In a second step we can look for coordination tasks, which arean intrinsic part of the functionality of a plant unit. The feed unit for input A

Model Driven Engineering 751

Fig. 2. Plant related control modules

in figure 1 is a typical example. The following plant elements are part of thisfunctional group: on/off-pump N21, control valve Y 22 and the flow meter F23.The coordination functions, which are necessary to control the flow-rate or tocarry out a dosing of input A, are independent of the specific production process.Following a hierarchical control concept, we can comprise these group controlfunctions in a separate group control module as shown in figure 2. The hierar-chical concept assumes that the lower level modules provide complete controlservices that can be used by the upper level control modules.

On the base of this schema we can implement a bottom-up approach forthe specification of the control task. Starting with the single unit level we canspecify the actuator control modules. In the next step we define the group controlmodules, then the section control modules and so on. We can go further aslong as we find control functions, which are intrinsic parts of the technologicalplant and we have to stop if the specification of a functional interrelationshiprestricts the flexibility of the plant in an undesired way. Obviously the limitof the bottom-up approach strongly depends on the character of the plant. Thecontrol tasks of plants which are designed to support exactly one specific process(power plants, refineries..) can be structured nearly completely by the bottom-up approach while in plants designed for flexible production (chemical plants,pharmaceutical plants..) only a small part of the control task can be specifiedby the bottom-up approach.

2.2 Product-Related Control Tasks

From a product-oriented point of view the structuring of the control task can bestarted by a top-down specification of the production process. Processes can bestructured by partitioning into consecutive or parallel sub-processes. The controlfunction types that are needed to run the respective processes are described in

752 U. Epple

form of recipes. The recipes can be partitioned related to the partitioning of theprocess. Recipes are formulated on different abstraction levels. As described inthe batch control standard [7] recipes can be specified as general recipes, siterecipes, master recipes or control recipes. The most specific form is the controlrecipe. The control recipe contains the complete instruction sequence, which isnecessary to run a specific process within a specific plant. It is possible to specifythe complete control functionality in the control recipe, but this would not be agood idea. The definition of a motor logic is not a matter of a recipe specification.Therefore, the overall control solution is a combination of the bottom-up andthe top-down approach.

2.3 Complete Structure

Figure 3 shows the complete structure of the control functionality as a com-bination of the two approaches. The concept assumes, that every productionmeasure can be realized by an autonomous control module. This module has tobe dynamically implemented as planned in the production schedule. Besides themeasures to produce products, there are other measures like logistic measures,diagnostic measures and so on that can be realized by the same concept.

Fig. 3. The complete structure of the control functionality

Obviously control is the main aspect of process control engineering. But thereare other aspects to be regarded, for example cross-cutting aspects like optimiza-tion, monitoring etc. and system functional aspects like HMI, alarming, archiv-ing, etc. Currently service oriented approaches are discussed to realize thesefunctionalities as standard blocks available for all applications of all hierarchicallevels.

Model Driven Engineering 753

3 Software Architecture

The languages to describe control functions for industrial process control sys-tems are defined in the international standard IEC61131 [6]. This is the leadingstandard. All important international process control systems support the lan-guages defined in this standard. The defined languages are: Instruction List (IL),Ladder Diagram (LD), structured Text (ST), Function Block Diagram (FBD)and Sequential Function Charts (SFC). These languages serve for modeling aswell as for coding. In process control engineering typically there is no distinctionbetween modeling and coding.

In this paper only the FBD and the SFC-languages will be referenced. Themain architectural principles can be explained on the base of these two languages.

Fig. 4. The single-device technology

The FBD-language realizes the function block model. The function blockmodel is the basic software-modeling concept in industrial process automation.The characteristic features of the function block model can be explained clearlyby the old single-device technology. Figure 4 shows a central control room typi-cal for the period around 1970. The figure on the right side shows the front andthe backside of a panel. In the functional model every device corresponds to afunction block and every electrical signal line to a communication connection.Some of the characteristic features can be seen directly:

– Each device executes its internal functionality independent of the other de-vices.

– The overall functionality is a result of the interaction of the single devices.– The devices execute their functionality in a quasi-continuous way.

Each device calculates permanently its state values and output values. The per-manent calculation can be realized by an analog circuit or by a μ-controllerrunning a program in a fast cycle. With the adjective ”quasi-continuous” it shallbe expressed, that the execution cycle is very short in comparison with the tech-nological time constants. In this case the time discreteness of the output variablescan be neglected and the behavior of the device can technologically be seen tobe continuous.

754 U. Epple

– The communication between the devices is realized by signal connections.– Signal connections are separate elements (wires) and can be handled indi-

vidually and independently of the devices.– Signal connections don’t affect the output value by reading

By abstracting the devices to their automation functionality we get the func-tion block model. Figure 5 shows the automation functionality of the panelin figure 4 in form of a function block model. The one-to-one correspondenceis obvious. Function blocks have inputs, internal states, outputs and a quasi-continuously executed block-method. The block-method supplies the outputsand the internal states quasi-continuously with actual values. Every block doesthis at every point of time, independent of the control and data flow of theapplication, independent of the state and the existence of other blocks and in-dependent of existing or unexisting communication connections at the in- andoutputs. Function blocks act independently and concurrently. Communicationconnections are separate active units. They have to assure that the values of theinputs are set to the values of the respective outputs. The signal model requiresthat the transmission is executed quasi-continuously and the read output valueis not affected.

Fig. 5. Function block model

The language FBD is a graphical language to specify such a function blocknetwork. But this is not the main feature. The main feature is, that in pro-cess control systems the function block network remains explicitly visible andΔ-changeable in the execution structure of the control system. Software function

Model Driven Engineering 755

blocks are components that can be manipulated online like the devices in thesingle device technology. The possibility to correct and reengineer the functionblock network during runtime was one of the main reasons for the success of thismodel in the industrial practice.

If we realize the plant-related control modules in figure 3 as well as theproduction-related control modules by function blocks or compounds of func-tion blocks, we get a clear programming model for the ”programming in thelarge”. The process control systems software architecture basically supports thisprogramming model and allows a flexible dynamic change of the engineeredstructure even at the operating stage.

Function blocks are instances of function block types. The functionality ofa block-type is either given or has to be specified explicitly by one of the au-tomation languages IL, ST, LD, FBD or SFC. In the first ”black box model” wedenominate the types as standard block types , in the second ”white box model”as derived block types. Figure 6 shows a valve control module. A compound ofblocks as shown on the left side realizes the valve control. The compound con-sists of a special valve type block and a network of standard blocks to realizethe role specific locking and wiring. The valve type block can be seen either asa standard block, if there is a respective type available, or has to be specifiedas a derived block, for example by a FBD specification as shown on the right side.

Fig. 6. Block types and compounds

756 U. Epple

For the model based engineering of production-related control modules derivedblocks by SFC-specifications are of special interest. Figure 7 shows the principleof a SFC-specification. In addition to the shown structure in figure 7 the SFCsyntax allows alternative and parallel branching. A SFC can be modeled as agraph with steps, transitions and action blocks as nodes. To prevent undesirableand inconsistent behavior [2] the graph has to fulfill structural restrictions.

Fig. 7. Elements of a SFC

4 Control Engineering in the Operation Phase

In the next years the amount of functionality to be implemented in the processcontrol environment will increase extensively. Requirements from the manufac-turing execution level like asset management, performance monitoring, processoptimization, quality assurance etc. have to be supported by the functionalityof the process control level. These new functions are typically cross functions.They do not fit into the classical hierarchical architecture and the classical in-tuitive engineering process. New architectural principles are needed as well asnew engineering processes. The already existing model driven approaches haveto be improved significantly. A second trend can be stated. Figure 4.1 showsthe three main phases of a plant: the process development phase, the plant-engineering phase and the operative phase. Within the process developmentphase the production process has to be designed and specified. To master suchcomplex development processes model-driven approaches seem to be the rightanswer. The results of the IMPROVE project [12] determine the current stateof the art. An engineering process is much less complicated than a developmentprocess. Within the engineering process the concrete plant design, the methods

Model Driven Engineering 757

to implement the required functionality and the technical realization are speci-fied, as well as the procedures to operate and to maintain the plant. The controlengineering process starts when the principle design of the plant is fixed. TheP&I-diagram as shown in figure 1 is a typical starting point. In the past, controlengineering took place primarily in the engineering phase. Modifications of thecontrol software within the operating phase, caused for example by migrationsof the control system (ca every 10 years) or by revamps of the production plant(ca every 5 years) were very seldom. But this situation is changing.

1. The migration cycles become much shorter. Most importantly, the computercomponents change rapidly. The software systems have to be adapted con-tinuously to new system versions.

2. The improvement of the process performance causes a permanent need foroptimization and adaptation of the control functionality.

3. Flexible plant structures, fast changing output requirements and dynami-cally changing optimization goals cause unplanned modifications in the con-trol solutions.

Fig. 8. Life cycle phases and control engineering activities

In the future we have to accept the control engineering process as a permanentprocess along the life cycle of an industrial plant. As shown in figure 8, controlengineering starts with the engineering phase and will not end until the plantis removed. The implementation of a permanent control engineering process inthe operating phase is a special challenge. Contrary to the situation in classicalsoftware maintenance, in the process industry the change of control software hasto be realized typically without stopping the technical process and consequentlythe execution of the overall control system. Besides the technical problem torealize such an online changeability, it must be assured that the unconcernedparts of the software will not be affected by the change. The correctness of theconcerned parts cannot be checked by a start up test, they become operativeimmediately.

758 U. Epple

The need for a highly formalized and systematic engineering process is obvi-ous. In the next section current approaches to improve the engineering processare discussed.

5 Towards a Methodical, Rule Assisted and AutomatedEngineering

In this section some ideas will be presented on how the engineering process of in-dustrial control software can be improved systematically. The focus is especiallyon the modification of existing software during the operation phase.

5.1 Modeling the Engineering Process as a Series of SingleTransformation Steps

The engineering process can be seen as a series of single transformation steps.At the left side in figure 9 a function block network is shown. To change this net-work, for example, a new block can be created or deleted, a connection line canbe created or deleted or changed and so on. All these changes can be seen as ele-mentary transitions from a pre-step model to a post step model. Interpreting thefunction block model as a graph, the engineering process can be seen as a sequen-tial graph rewriting. It has been shown that only a few rewriting types are neededto manipulate a function block system completely. Adding rewriting rules guar-antees that if the pre-transformation graph is correct, the post-transformationgraph is correct too. At the right side of figure 9 the rewriting rule for the imple-mentation of a new communication connection is shown in PROGRES notation.PROGRES is a graph grammar programming environment developed by the

Fig. 9. Engineering as a sequential graph rewriting process

Model Driven Engineering 759

Chair of Comp. Science III at the RWTH Aachen University [11, 3]. The PRO-GRES environment was used by [4] to specify the function block system. Up tonow the transformation of the function block network as a system of instanceshas been discussed, but the same procedure can be used to change the methods ofderived block types declared by a SFC or FBD network. The modification of theSFC-declarations is of special interest in order to adapt the control sequencesof the production-related measure types to frequently changing requirements.Currently there is no rule declaration available describing allowed and forbiddentransformations of SFC-networks. Of course the commercial ”recipe” systemshave intrinsic rules to guarantee correct SFC-declarations but this is not suffi-cient. It is necessary to specify the rules explicitly and to notate them in a formalway. The formal analysis of SFC networks shown in [2] is a solid starting point.

The vision is a formally specified complete set of elementary transformationtypes with their respective application rules for function block networks as wellas for the SFC or FBD specification of derived function block types. With thisset it becomes possible to modify the control software by a sequence of correctelementary step instances.

5.2 Implementing an Engineering Service Architecture

The discussed change by elementary transformations is an operative concept.The engineering process can be realized as a sequential process. Each step canbe performed separately. After each step the system is in a correct form. Withthis background we can implement a special service architecture to structurethe engineering process. The basic system architecture is shown in figure 10.The realization of the function block model is completely hidden from the engi-neering process. Interaction with the model is only possible via the engineeringservice interface. The engineering service interface offers services to explore themodel and services to realize the discussed basic transformations. For every basictransformation type a service is specified which is able to carry out the trans-formation with respect to the defined rules. The system divides the engineeringproblem into two different parts: The conception and realization of the func-tion block management system and the design of the engineering process as asequence of transformation service calls. These systems can be developed com-pletely independently. They are coupled by the defined transformation services,which realize the basic transformation steps.

For the industrial process control environment the concept offers the enablingof new possibilities. The function block model can be stored in a passive datarepository but it can also be stored in an active object management system andeven in the online execution system. Hidden by the services, the same engineeringprocess can be used for the classical offline engineering but also for a real-timeonline engineering with or without an immediate change of the active controlsoftware. Modern control systems provide object-handling services as a basic partof their runtime system. With this functionality, the realization of the engineeringservices for the runtime environment becomes very easy.

760 U. Epple

Fig. 10. The engineering service architecture

5.3 Automated and Assisted Engineering Functionality

To assist the engineer in the implementation of partially automated engineeringfunctions is one of the hot topics in the industrial process control environment. Amanifold of control functions can be specified in a rule based manner. Rules havea premise and a conclusion. Here the conclusion is always a complex transition ofthe function block system. This implies that the conclusion affects the functionblock system only. On the other hand, the premises typically need informationof the structure and the characteristics of the technical plant, the processes, theconfiguration of the control system and so on. An important precondition torealize automated engineering functions is a formal and explicit readable formof these specifications. To get an integrated concept we define a common meta-model for all these different models and we equip all the models with the sameservices for exploration and data acquisition. This concept is shown in figure 11.The figure shows the models and meta-models and the possibility to change themonline by engineering service requests. The architecture is hierarchical. Startingwith the (meta-meta-) model ACPLT [10, 1], at the next level the (meta-) modelCAEX as defined in the international standard [8] specifies a unique understand-ing of role-systems, components etc. Now the models split. PandIX is the basefor the description of chemical plants. The FBD and SFC models are the basesfor the description of the control software. Logically, the exploration services areconnected to the basic object model level, but the engineering services discussedhere are linked directly to the FBD, SFC-model level (they need the FBD, SFCsemantics to be able to check the transformation rules).

Model Driven Engineering 761

Fig. 11. Basic concept of the model landscape

5.4 Towards “Correct” Models

From model based engineering two advantages are expected: A significant in-crease of efficiency of the engineering process and a higher quality of the result-ing control functionality. Adressing the second goal, transformation rules shallbe specified to generate always ”correct” models. But what is a ”correct” model?This question can be split into three aspects:

- operating system levelOn a basic ”operating system level” it is required that the application mustremain executable without any system failures and that the unconcerned partsof the software will not be affected by the transformation. This is a strong re-striction. After every single transformation step we need a correct executablesystem. But this is the thinking of process control engineers and modern controlsystems support this feature. If for example only FBD and SFC constructs areused, the systems themselves allow only ”correct” transitions and guarantee theirnon-interruptible execution. This is possible even for transitions in a real-timeenvironment as all these transitions are small and can be executed very fast.

- meta model conformence levelOn a second ”meta model conformence level” the engineered models have to bekept in accordance with the design rules of the respective metamodels by thetransformation process. In figure 11 for example, the ”FBD/SFC model” andthe ”hierachical control model” are metamodels to be regarded by the controlengineering process. The goal is to define general types of transformation steps -or chains of transformation steps - which guaranty that the transformed control

762 U. Epple

model remains correct in accordance with the FBD/SFC and hierachical con-trol design rules. At the meta model conformence level it can be tolerated, thatcorrectness is not guaranteed until the final transformation step of a chain isfinished.

- application levelCorrect operation and meta model consistency are an important base, but theydo not guarantee a meaningful application functionality. To understand an appli-cation functionality, a broad and semantic complex knowledge of the goals andthe nature of the application is necessary. A general rule system would be toocomplex. But, as shown in figure 11, most of the work is already done by defin-ing the functionality of the plant (P&ID) and the processes (recipes). As shownin chapter 2, this information can be translated methodically into the controlmodel. So it’s not possible to assure the correctness of the application, but it ispossible to assure the correct translation of the P&ID plant model informationinto the control model.

5.5 Rule Integration

The vision of future control concepts is an integrated decentralized real-timeruntime environment with the FBD and SFC constructs as exclusive concepts.The idea is to integrate functionalities like diagnosis, engineering and so on inthis concept. This seems to be possible, but there is still a problem. In any casewe need rules. So we have to formulate rules within a FBD or SFC concept. Herewe propose a model to describe rules by function block networks [13]. Figure 12shows a detail of the premise test part of a rule. The shown function blocks areinstances of special ”rule” function block types. The ”AND” type is not a simplelogic type, the rule type ”AND” also organizes the execution of the sub-chainsto get the needed logic result at its input. A rule function block has two roles:when activated, it executes a special search or comparison question in a givencontext. It solves the question by own iteration and comparison methods and byactivating subordinated chains to solve subordinate questions. When the answerof the question is completely ascertained, the function block stores the answerand signals its completion. The rule execution can be interrupted to fulfill real-time requirements. The last state remains stored in the involved blocks. Withonly a handful of ”rule-block types” a powerful rule system can be establishedby means of usual FBD language constructs. With this concept rules become anintegral part of the control software:

– rules can be engineered like other automation functions,– rules can be engineered by other rules,– rules can be executed in the runtime environment of the process control

system.

Engineering processes can be integrated as measures in the concept shown infigure 3.

Model Driven Engineering 763

Fig. 12. Formulating rules as function-block networks

6 Summary

Industrial process control is a profitable field for model-driven approaches. Thereis a broad and traditional feeling for the value of models. The design problemsare challenging but not too complex. Basic functions are already realized withincommercial systems. The international language standards fit to model-basedconcepts. Engineering and maintaining industrial control software addresses abig market. The users are interested in getting more flexibility especially in theoperating phase, but they are also conservative. They are interested in keepingthings plain and understandable and they like their well-known language con-structs like FBD or SFB. The presented concepts are fragments of an improvednew concept for the process control software design. There is a realistic possibil-ity to take a big step in this direction within the next years. But we also haveto state that there are still substantial deficits in the model development and inthe formal description of the specifications. Up to now, there exists no complete,verified and formally specified set of the basic transformations for FBD andSFC structures. On the other hand, the automated implementation of add-on-functions like balance supervision, asset monitoring or performance optimizationby model-based transformation processes become more and more usual in thechemical industry. To encourage the users to implement such new concepts intheir production plants, it is helpful to organize the software in function integritylevels. In figure 13 the function integrity model is shown. At the left side we seea two-level model. Currently this is the usual model. The control functional-ity is divided into two classes: safety-relevant functions and normal, non-safety

764 U. Epple

Fig. 13. Functional integrity levels

relevant functions. Guard-functions assure that changes or errors in the normalfunction level never affect the functionality of the underlying safety level. Safetyfunctions have prior access to the actuators. To fulfill the discussed new flex-ibility requirements it seems helpful to expand the two-level model to a threelevel model. The safety level remains unchanged but the normal level is splitinto two new levels: a ”protected” level and a ”flexible changeable” level. Theprotected level contains the basic functionality that is necessary to run the plantin a normal ”protected” mode, to guard the plant hardware and the productand to fulfill warranty requirements. The flexible level contains add-on functionslike KPI-calculations, advanced asset diagnosis and optimization functions, orhooks up advanced control modes. The flexible and changeable level gives anideal playground to test model-driven approaches in industrial environments.

References

[1] Albrecht, H.: On Meta-Modeling for Communication in Operational Process Con-trol Engineering. Fortschr.Ber. VDI Reihe 8 Nr.975 VDI-Verlag Dusseldorf (2003)

[2] Bauer, N.: Formale Analyse von Sequential Function Charts. Shaker Verlag,Aachen (2004)

[3] Schurr, A.: PROGRES: A VHL-Language Based on Graph Grammars. In: Ehrig,H., Kreowski, H.-J., Rozenberg, G. (eds.) Graph Grammars 1990. LNCS, vol. 532,pp. 641–659. Springer, Heidelberg (1991); also: Technical Report AIB 90-16,RWTH Aachen, Germany (1990)

[4] Enste, U., Kneissl, M.: Development of standardized process control software -avoiding bugs by using graph grammars. In: 3rd Mathmod Vienna, IMACS Sym-posium on Mathematical Modeling, Wien S., pp. 381–384 (2000)

[5] Enste, U.: Generische Entwurfsmuster in der Funktionsbausteintechnik und derenAnwendung in der operativen Prozessfuhrung. VDI Fortschr.Ber., Reihe 8, Nr.884. VDI-Verlag Dusseldorf (2001)

Model Driven Engineering 765

[6] IEC61131-3: Programmable controllers - Part 3: Programming languages. Publi-cation IEC

[7] IEC61512: Batch control. Publication IEC[8] IEC62424: Representation of process control engineering-requests in P&I diagrams

and data exchange between P&ID tools and PCE-CAE tools. Publication IEC[9] IEC62264-1: Enterprise-control system integration. Part 1: Models and terminol-

ogy. Publication IEC (2003)[10] Meyer, D.: Objektverwaltungskonzepte fur die operative Prozessleittechnik.

Fortschr.Ber. VDI Reihe 8 Nr.940 VDI-Verlag Dusseldorf (2002)[11] Nagl, M. (ed.): Proc. WG 1989 Workshop on Graph-Theoretic Concepts in Com-

puter Science. LNCS, vol. 411. Springer, Heidelberg (1989)[12] Nagl, M., Marquardt, W. (eds.): Collaborative and Distributed Chemical Engi-

neering. LNCS, vol. 4970. Springer, Heidelberg (2008)[13] Schmitz, S., Epple, U.: Automatisiertes Engineering leittechnischer Funktionen

durch integrierte Regeln. Entwurf komplexer Automatisierungssysteme (EKA)2008: Beschreibungsmittel, Methoden, Werkzeuge und Anwendungen; 10. Fach-tagung, S. 241–S. 252, April 15-17 (2008)