atp edition Automatisierung mit FASA (Vorschau)

12 / 2012 

54. Jahrgang B3654 

DIV Deutscher Industrieverlag GmbH 

Automatisierungstechnische Praxis 

Virtualisierung im Kontext 

eines Prozessleitsystems | 28 

Integriertes Engineering mit 

Automation Service Bus | 36 

Feldgeräte und semantische 

Informationsmodell | 44 

Automatisierung mit FASA | 52 

Effizienz durch ergonomische 

Benutzungsschnittstelle | 62 

Semantikvielfalt mit 

AutomationML beherrschen | 72

Danke! 

atp edition ist vom Verband Deutsche 

Fachpresse als Fachmedium des Jahres 

2012 in der Kategorie Industrie/Produktion/ 

Design ausgezeichnet worden. atp edition 

ist eine Gemeinschaftsleistung aus der 

Branche für die Branche. Hinter der hochwertigen 

Publikation für Automatisierungstechnik 

stecken viele kluge Köpfe. Nicht 

nur Chefredakteur, Herausgeber und Beiräte 

tragen mit ihrem Agenda-Setting dazu bei, 

dass atp edition in ihrer seit über 50-jährigen 

Tradition die maßgeblichen Themen der 

Automatisierungstechnik bestimmt. Auch 

die Fachredaktion leistet mit einem Peer- 

Review-Verfahren für wissenschaftlich 

fundierte Veröffentlichungen einen unverzichtbaren 

Beitrag. Nicht möglich wäre dies 

ohne unsere zahlreichen Fach-Autoren. Ein 

großes Dankeschön an alle, die hinter atp 

edition stehen und das Fachmagazin zu 

einem Erfolg machen – und nicht zuletzt 

an Sie, unsere Leser. 

Ihre Entscheidung für die hochwertige 

Publikation atp edition stärkt die Bedeutung 

wissenschaftlicher Forschungsarbeiten 

in der Automatisierungstechnik.

Print wirkt 

„atp edition“ ist ein Printtitel auf höchster 

Qualitätsstufe und mit Nachhaltigkeit im 

Sinne wiederkehrender Nutzung. Der Titel 

erfüllt den selbstgestellten Anspruch eines 

anspruchsvollen und seriösen Magazins für 

Top-Entscheider zwischen Wissenschaft 

und Praxis konsequent. 

Entsprechend der journalistischen Konzeption 

ist Online hintenangestellt. Die Jury 

sah hier „die beispielhafte Umsetzung einer 

wissenschaftlich ausgerichteten Fachzeitschrift 

mit Magazincharakter“.

EDITORIAL 

Die Wettbewerbsfähigkeit sichern 

mit den Architekturen der Zukunft 

Warum haben Sie zu diesem Magazin gegriffen? Aus Neugier? Aus Interesse? 

Zur Weiterbildung? Und wann lesen Sie es? Gleich nach dem Posteingang? 

Schnell noch kurz vor Feierabend? Nach Hause mitgenommen? Oder schon gut 

abgelegen auf dem Eingangsstapel? Vielleicht sogar mit etwas schlechtem Gewissen, 

weil Ihr Job Ihnen eigentlich keine Zeit mehr für Fachzeitschriften lässt? 

Nur Mut: Mit der Lektüre steigern Sie Ihre Kompetenz. Sie wissen mehr als 

andere, Sie wissen es eher. Und: Kompetenz ist kein Selbstzweck, sondern sie 

steigert Ihre Wettbewerbsfähigkeit und vielleicht auch die Ihres Unternehmens. 

Im Deutschen sind die Worte „Kompetenz“ und „Wettbewerbsfähigkeit“ sehr 

unterschiedlich, das Englische hilft: Nur „competence“ erhält die „competitiveness“, 

steigert Ihre Chance im Wettbewerb, der „competition“. 

Das vorliegende Heft widmet sich dem Schwerpunkt „Zukünftige Architekturen 

von Automatisierungssystemen“ und enthält sechs spannende Beiträge zu 

diesem Thema, wobei der Begriff „Architektur“ nicht nur auf die Hardware, 

sondern auch auf das Engineering bezogen ist. Da werden zukünftige Technologien 

für Automatisierungssysteme vorgeschlagen und bewertet. Da geht es um 

Verbesserungen im Dialog des Menschen mit dem Prozess. Und es werden verschiedene 

Möglichkeiten zur Integration in heterogenen Systemlandschaften 

präsentiert. Zugegeben: Das sind nicht die Themen, die dem Projekt- oder Betriebsingenieur 

ab sofort das Leben erleichtern. Aber es ist ein Blick auf die 

Zukunft, auf neue Möglichkeiten, auf das, was wir in drei oder fünf Jahren für 

unsere Projekte und Betriebe kennen und bewerten können müssen. 

Und neben den eigentlichen Themen gibt es auch noch Impulse zu entdecken, 

die über den im Beitrag genannten Fall hinaus interessant sind. So zum Beispiel 

die Beobachtung von Draht et al., dass Standardisierung und praktischer Einsatz 

sich gegenseitig bedingen – und gleichzeitig behindern: Eine gute Standardisierung 

setzt praktische Einsatzerfahrung und damit Verbreitung voraus – und die 

Verbreitung setzt häufig erst ein, wenn ein Standard existiert. Der Lösungsansatz 

eines gemischten Datenmodells, in dem sowohl standardisierte als auch noch 

proprietäre Daten übertragen und ausgewertet werden können, hat etwas Geniales. 

Vielleicht ist eine solche Idee auf andere Deadlock-Situationen von Standarisierung 

und Einsatz übertragbar und verhindert jahrelanges Warten auf „den 

perfekten Standard“. 

Wenn Sie also dieses Heft lesen und Ihr Chef oder Ihr Controller fragt, warum 

Sie sich denn die Zeit nehmen, die „gute alte atp“ zu lesen, geben Sie ihm dieses 

Editorial oder gleich das ganze Heft zu lesen. Auch Chefs oder sogar Controllern 

kann es nicht schaden, Kompetenz und Wettbewerbsfähigkeit zu steigern – dafür 

werden sie sogar bezahlt. 

DR. THOMAS 

TAUCHNITZ 

Leiter Technik am Standort 

Frankfurt Pharma, Sanofi- 

Aventis Deutschland GmbH, 

Mitglied des Namur-Vorstands 

atp edition 

12 / 2012 

3

INHALT 12 / 2012 

VERBAND 

6 | IEC würdigt 22 deutsche von insgesamt 

139 Normungsexperten mit dem IEC 1906 Award 

Umsätze der Elektroindustrie gehen um sechs Prozent zurück 

7 | GMA wählt Beirat neu und bestätigt seinen Vorsitzenden 

8 | Automatisierungsanwender der Prozessindustrie 

wagen mehr Internationalisierung 

10 | Goldene Namur-Ehrennadel für Gerhard Rehn und Martin Schwibach 

11 | Bouaswaig und Yin ausgezeichnet 

BRANCHE 

12 | AALE 2013: Mehr über Energieeffizienz, Systeme und 

Lehre&Forschung in der Automation erfahren 

Die IEC 61508 richtig anwenden 

Dechema-Preis 2012 für Prof. Dr. Joachim Groß 

13 | Neue Richtlinie VDI/VDE 2632 Blatt 2 vereinfacht 

Kommunikation zwischen Anbietern und Anwendern 

FORSCHUNG 

14 | PENG erzeugt Energie aus minimalen Temperaturunterschieden 

Modularisierung fördert schnellere Produktion 

Mikrochips sollen Raubkopien verhindern 

15 | Flinker Modulator: Baustein für effiziente 

Datenübertragung gelangt zur Marktreife 

Roboter Hytaq fliegt oder fährt je nach Bedarf 

Call for Experts: Digitale Anlage im Lebenszyklus 

4 


12 / 2012

PRAXIS 

16 | Vernetzte Sicherheitscontroller überwachen 

die komplette Montage von Flugzeugrumpf-Schalen 

20 | Punktschweißen von Aluminium-Türen des 

Porsche Panamera prozesssicher automatisiert 

24 | Energiekonzern ENI setzt erstmals in neuer 

italienischer Raffinerie auf Foundation Fieldbus 

HAUPTBEITRÄGE 

28 | Virtualisierung im Kontext eines Prozessleitsystems 

S. RUNDE, M. SCHNEIDER, M. GLASER UND S. THIEME 

36 | Integriertes Engineering mit Automation Service Bus 

S. BIFFL, R. MORDINYI UND T. MOSER 

44 | Feldgeräte und semantische Informationsmodelle 

S. HODEK, M. LOSKYLL UND J. SCHLICK, 

52 | Automatisierung mit FASA 

M. WAHLER, T. GAMER, M. ORIOL, A. KUMAR UND M. NAEDELE 

62 | Effizienz durch ergonomische Benutzungsschnittstelle 

L. GLATHE UND S. KEMPF 

72 | Semantikvielfalt mit AutomationML beherrschen 

R. DRATH UND M. BARTH 

RUBRIKEN 

3 | Editorial: Die Wettbewerbsfähigkeit sichern 

mit den Architekturen der Zukunft 

82 | Impressum, Vorschau 


12 / 2012 

5

VERBAND 

IEC würdigt 22 deutsche von insgesamt 

139 Normungsexperten mit dem IEC 1906 Award 

EINIGE DER PREIS- 

TRÄGER und Michael 

Teigeler, Mitglied der 

Geschäftsführung 

der DKE Deutsche 

Kommission Elektrotechnik 

Elektronik 

Informationstechnik 

im DIN und VDE 

(VDE|DKE). Bild: DKE 

Unter insgesamt 139 Preisträgern des IEC 1906 Awards 

können sich in diesem Jahr 22 deutsche Normungsexperten 

über die internationale Auszeichnung freuen. 

Die Internationale Elektrotechnische Kommission würdigt 

mit dem Award jährlich besondere Verdienste bei 

der Bearbeitung aktueller Normungsprojekte. 

Geehrt wurden Dr. Reinhard Salffner (TC 1 „Terminology“), 

Dr. Gabriela Fleischer, (TC 3 „Information structures, 

documentation and graphical symbols“), Dr.-Ing. Egid 

Schneider, (TC 9 „Electrical equipment and systems for 

railways“), Dr.-Ing. Volker Rees (TC 17 „Switchgear and 

controlgear“), Dr. rer. nat. Ulrich Spindler, (TC 17 „Switchgear 

and controlgear“), Hubert Knapp (TC 27 „Industrial 

electroheating and electromagnetic processing“, Dr. Martin 

Thedens (TC 36 „Insulators“), Thomas Schmid (TC 46 

„Cables, wires, waveguides, R.F. connectors, R.F. and microwave 

passive components and accessories“), Leo Stuehler 

(TC 47 „Semiconductor devices“ ), Dr.-Ing. Hubert Becker 

(TC 56 „Dependability“), Thierry Dufaure (TC 57 „Power 

systems management and associated information exchange“), 

Dr. Bernd Jäkel (TC 65 „Industrial-process mea- 

surement and control“ ), Eckehardt Klemm (TC 65 „Industrial-process 

measurement and control“), Eckhard Schwendemann, 

(TC 72 „Automatic controls for household use“), 

Frank Jetzschmann (TC 77 „Electromagnetic compatibility“), 

Prof. Dr.-Ing. Werner Daum (TC 86 „Fibre optics“), Arno 

Bergmann (TC 96 „Transformers, reactors, power supply 

units and combinations thereof“), Werner Menger (TC 96 

„Transformers, reactors, power supply units and combinations 

thereof“), Hermann Ruoss (TC 104 „Environmental 

conditions, classification and methods of test“), Matthias 

Meier (TC 106 „Methods for the assessement of electric, 

magentic and electromagnetic fields associated with human 

exposure“), Prof. Dr. Werner Bergholz (TC 113 „Nanotechnology 

standardization for electrical and electronic products 

and systems“), Dr.-Ing. Stephan Kloska (CISPR „International 

Special Committee on Radio Interference“). 

VDE VERBAND DER ELEKTROTECHNIK 

ELEKTRONIK INFORMATIONSTECHNIK E.V. 

Stresemannallee 15, D-60596 Frankfurt am Main, 

Tel. +49 (0) 69 630 84 61, Internet: www.vde.com 

6 

Umsätze der Elektroindustrie gehen 

um sechs Prozent zurück 

Sechs Prozent unter Vorjahresniveau blieben die Umsätze 

der deutschen Elektroindustrie im September. 

Nach bis zuletzt sehr solider Entwicklung haben die 

Elektroexporte damit jetzt einen Dämpfer erhalten, der 

Rückgang war der stärkste seit Oktober 2009“, sagte 

ZVEI-Chefvolkswirt Dr. Andreas Gontermann. „Aber in 

den ersten drei Quartalen 2012 sind die Branchenausfuhren 

insgesamt um drei Prozent auf 119,8 Mrd. Euro 

gestiegen und steuern so weiter ein neues Jahresallzeithoch 

an.“ Der Exportumsatz belief sich im September 

2012 auf 12,6 Milliarden Euro. 

Die Einfuhren von Elektroerzeugnissen nach Deutschland 

gaben um vier Prozent gegenüber Vorjahr auf 11,2 

Milliarden Euro nach. Von Januar bis September hatten 

sie um zwei Prozent auf 102,7 Mrd. Euro zugelegt. Entsprechend 

haben die Ausfuhren die Einfuhren in den 

ersten neun Monaten 2012 um 17,1 Mrd. Euro übertroffen. 


12 / 2012 

Der Exportüberschuss lag so drei Prozent 

höher als vor einem Jahr. 

Eine gute Nachricht kommt von 

den Exporten außerhalb Europas. Sie 

stiegen um acht Prozent auf 42,1 Milliarden 

Euro. 13 Prozent der Branchenunternehmen 

gehen von insgesamt 

anziehenden Ausfuhrgeschäften 

in den nächsten drei Monaten 

aus. 64 Prozent der Firmen erwarten 

ANDREAS 

GONTERMANN: 

Dämpfer für 

Elektroexporte. 

Bild: ZVEI 

stabile Exporte, zwölf Prozent rückläufige. Elf Prozent der 

Unternehmen sind derzeit unentschieden. 

ZVEI – ZENTRALVERBAND ELEKTROTECHNIK- UND 

ELEKTRONIKINDUSTRIE E.V., 

Lyoner Straße 9, D-60528 Frankfurt/Main, 

Tel. +49 (0) 69 630 20, Internet: www.zvei.org

GMA wählt Beirat neu und 

bestätigt seinen Vorsitzenden 

Für weitere drei Jahre im Amt bestätigt wurde Dr.-Ing. 

Kurt Dirk Bettenhausen. Der Vorsitzende der VDI/ 

VDE-Gesellschaft Mess- und Automatisierungstechnik 

(GMA) wurde am 20. November auf der konstituierenden 

Beiratssitzung für die Amtsperiode 2013 bis 2015 wiedergewählt. 

„Das Projekt ‚Industrie 4.0’ aktiv vorantreiben, 

die GMA als Forum für Wissens- und Informationsaustausch 

sowie den Kongress Automation weiter ausbauen“, 

so Bettenhausen nach seiner Wahl, „darauf 

kommt es in den drei nächsten drei Jahren an.“ Außerdem 

sei es wichtig, die Fachgebiete der GMA der breiten 

Öffentlichkeit noch näher zu bringen. Bettenhausen ist 

hauptberuflich in der Corporate Technology von Siemens 

verantwortlich für die Region USA sowie weltweit für 

das Technologiefeld Automation & Control. 

Die neuen Beiratsmitglieder wurden von den GMA-Mitgliedern 

für die Amtsperiode 2013 bis 2015 gewählt. Der 

Beirat setzt sich aus den Leitern der GMA-Fachbereiche 

und acht gewählten Vertretern zusammen. Zu den acht 

gewählten Vertretern gehören Prof. Dr.-Ing. Dirk Abel 

(RWTH Aachen), Prof. Dr.-Ing. Jürgen Beyerer (Fraunhofer 

IOSB), Prof. Dr.-Ing. habil. Gerald Gerlach (TU Dresden), 

Dipl.-Ing. Martin Müller (Phoenix Contact Electronics 

GmbH), Dr. rer. nat. Günter Reusing (Bosch Rexroth Mechatronics 

GmbH), Dr.-Ing. Eckardt Roos (Festo AG&Co KG), 

Prof. Dr.-Ing. Klaus-Dieter Sommer (PTB Braunschweig) 

und Dipl.-Inf. Christoph Winterhalter 

(ABB AG). Die acht Fachbereiche der GMA werden 

in der kommenden Amtsperiode geleitet 

von Prof. Dr.-Ing. Frank Allgöwer (Universität 

Stuttgart, Fachbereich 1, „Grundlagen und Methoden“), 

Prof. Dr.-Ing. Werner Daum (BAM 

Berlin, Fachbereich 2 „Prozessmesstechnik 

und Strukturanalyse“), Prof. Dr.-Ing. Robert 

Schmitt (RWTH Aachen, Fachbereich 3 „Fertigungsmesstechnik“), 

Prof. Dr.-Ing. Klaus Janschek (TU 

Dresden, Fachbereich 4 „Mechatronik, Robotik und Aktorik“), 

Dipl.-Ing. Heiko Adamczyk (Knick Elektronische 

Messgeräte GmbH & Co. KG, Fachbereich 5 „Industrielle 

Informationstechnik“), Prof. Dr.-Ing. Alexander Fay (HSU 

Hamburg, Fachbereich 6 „Engineering und Betrieb“), Prof. 

Dr.-Ing. Dr. med. Steffen Leonhardt (RWTH Aachen, Fachbereich 

7 „Anwendungsfelder der Automation“) und Dr.- 

Ing. Michael Thomas Kramer (LED Linear GmbH, Fachbereich 

8 „Optische Technologien“). 

(ahü) 

VDI/VDE-GESELLSCHAFT MESS UND 

AUTOMATISIERUNGSTECHNIK (GMA), 

VDI-Platz 1, D-40468 Düsseldorf, 

Tel. +49 (0) 211 621 40, Internet: www.vdi.de 

DR. KURT D. 

BETTENHAUSEN 

bleibt an der Spitze 

der VDI/VDE-GMA. 

Foto: VDI 

Freelance Leitsystem. 

So einfach ist Prozessautomatisierung. 

Freelance kombiniert den günstigen Preis einer SPS mit der höheren Funktionalität eines Prozessleitsystems. 

Eine komfortable und intuitive Bedienung und nur ein Werk zeug für das gesamte 

Engineering von Inbetriebnahme bis zur SystemDiagnose senken Kosten und sparen Zeit. Dieses 

LeitsystemKonzept bewährt sich in weltweit mehr als 14.000 Applikationen in sehr vielen Industriebereichen. 

www.abb.de/controlsystems 

ABB Automation GmbH 

Email: marketing.controlproducts@de.abb.com 


12 / 2012 

7

NAMUR-HAUPTSITZUNG 2012 

Automatisierungsanwender der Prozessindustrie 

wagen mehr Internationalisierung 

Heinrich Engelhard wird neuer Namur-Geschäftsführer/Arbeitskreis „Automation Security“ gegründet 

WILHELM OTTEN, 

Namur-Vorsitzender, 

eröffnete die Namur- 

Hauptsitzung 2012 

mit einem Vortrag 

über die Arbeitsergebnisse 

des Jahres. 

JÖRG KIESBAUER, 

Vorstandsmitglied 

der Samson AG, des 

Hauptsponsors der 

Namur-Hauptsitzung 

2012, stellte einen 

historischen Abriss 

der Aktorik vor. 

Mit rund 550 Teilnehmern fand am 8. und 9. November 

die Namur-Hauptsitzung 2012 unter dem Motto 

„Aktorik – von der Handdrossel zum smarten Stellgerät“ 

statt. Die Namur, der Verband von Automatisierungsanwendern 

in der Prozessindustrie, hatte Experten 

der Automatisierung nach Bad Neuenahr geladen. 

Auf der Sitzung wurde bekannt, dass Heinrich Engelhard 

(Bayer Technology Services) Dr. Wolfgang Morr 

als Namur-Geschäftsführer ablösen wird. Ab Januar 

2013 startet der 49-Jährige in dem Amt. Dr. Peter Zgorzelski 

(Bayer Technology Services) wird als technischer 

Referent in der Namur tätig. Bislang war er Geschäftsstellenleiter 

der Namur-Projektgruppe „Merkmalleisten“ 

und Obmann des Arbeitskreises 1.2 sowie 

Leiter in Arbeitskreisen von IEC und DKE. Dr. Ulrich 

Christmann (Bayer Technology Services) übernimmt 

das Arbeitsfeld „Planen und Errichten“ 

ab 1. Januar 2013. Bei den 

Arbeitsfeldern wurde ebenfalls 

neu sortiert. Das Arbeitsfeld 4 

wird zukünftig „Betrieb und 

Instandhaltung“„Operation Support 

und Maintenance“ heißen. In 

diesem Arbeitsfeld wird der Arbeitskreis 

„Automation Security“ 

gegründet. Diskutiert wird derzeit 

die Einberufung eines fünften Arbeitsfeldes 

mit Arbeitskreisen, die 

nicht technik- oder prozessorientiert 

sind. Dazu gehören etwa 

Hochschulkontakte oder Normenbeobachtung 

und -beeinflussung. 

Zur Eröffnung der Veranstaltung, 

die von Aktorik-Anbieter 

HEINRICH 

ENGELHARD 

wird ab 1. Januar 

2013 Namur- 

Geschäftsführer. 

Er löst Wolfgang 

Morr ab. Bild: Namur 

Samson gesponsert wurde, berichtete der Namur-Vorsitzende 

Dr. Wilhelm Otten über die Ergebnisse der 

Verbandsarbeit des vergangenen Jahres. Die Namur, die 

die Interessen der Betreiber in der Prozessindustrie vertritt, 

will den Dialog mit Herstellern weiter internationalisieren. 

Dazu gab es im September diesen Jahres eine 

erste konstituierende Sitzung mit den Verbänden Wib, 

Eemura, Exera und Isa. Schon lange tauschen diese Verbände 

untereinander Experten in einzelnen Arbeitskreisen 

aus. Mit der Isa sei darüber hinaus eine intensivere 

Zusammenarbeit angedacht. Die Verbände erfassen 

derzeit die Aktivitäten, die Potenzial für mehr 

Kooperation bieten. Außerdem sind gegenseitige Besuche 

bei Veranstaltungen geplant. Gemeinsame Arbeitsgruppen 

sind überdies mit den europäischen Verbänden 

für die Bereiche Funktionale Sicherheit, Wireless Automation, 

IT-Security, Auswahl 

von Durchflussmessern und 

Alarm-Management angedacht. Zu 

dem Thema fand ebenfalls auf der 

Namur-Hauptsitzung ein Workshop 

unter dem Titel „Internationale 

Kooperation“ statt. 

Otten wies auf die Neuerscheinungen 

unter den Namur-Empfehlungen 

und -Arbeitsblättern hin. 

PETER 

ZGORZELSKI 

wird als 

technischer 

Refernt bei der 

Namur tätig. 

Bild: Namur 

Die NE 139 (Informationsschnittstellen 

in der Prozessautomatisierung 

Betriebliche Eigenschaften), 

NE 140 (Vorgehensweise zur Steigerung 

der Energieeffizienz in 

chemischen Anlagen – Beitrag der 

Automatisierungstechnik), NE 141 

(Schnittstelle zwischen Batch- 

8 


12 / 2012

ETWA 550 TEILNEHMER waren der Einladung auf die Namur-Hauptsitzung 2012 gefolgt. Bilder: Anne Hütter 

und MES-Systemen), NE 142 (Funktionale Sicherheit 

elektrotechnischer Elemente) und die NE 144 

sind neu im Portfolio des Verbandes. Überarbeitet 

wurden die NE 21, NA 82, NA 101 und NE 112. 

In China traf sich die Namur am 21. November 

2012. Das Sponsoring übernahm ABB. Im kommenden 

Jahr versammeln sich die Automatisierungsanwender 

in Bad Neuenahr am 7. und 8. November. 

Hauptsponsor der Veranstaltung, die dann unter 

dem Motto „Integriertes Engineering“ steht, ist die 

Siemens AG. 

AUTORIN 

ANNE HÜTTER 

ist verantwortlich für 

die Redaktion und das 

Programmmanagement 

der atp im Deutschen 

Industrieverlag. 

DIV Deutscher Industrieverlag GmbH, 

Arnulfstraße 124, D-80636 München, 

Tel. +49 (0)89 203 53 66 58, 

E-Mail: huetter@di-verlag.de, 

Internet: www.di-verlag.de 


12 / 2012 

9

NAMUR-HAUPTSITZUNG 2012 

Goldene Namur-Ehrennadel für 

Gerhard Rehn und Martin Schwibach 

MARTIN SCHWIBACH (li., BASF) erhält die 

Auszeichnung von Wilhelm Otten und Monika Reek 

(Assistentin der Namur-Geschäftsführung). 

GERHARD REHN (li.) 

freut sich über die 

Namur-Ehrennadel, die 

Wilhelm Otten (re.) 

überreicht. Bilder: Anne Hütter 

Gerhard Rehn (Bayer Technology Services) und Martin 

Schwibach (BASF) sind mit der Goldenen Ehrennadel 

der Namur (Verband von Automatisierungsanwendern 

in der Prozessindustrie) für ihre besonderen 

Verdienste in den Arbeitskreisen des Verbandes 

ausgezeichnet worden. 

Der Namur-Vorsitzende Dr. Wilhelm Otten überreichte 

die Auszeichnungen auf der Namur-Hauptsitzung 

2012 Anfang November in Bad Neuenahr. Martin 

Schwibach erhielt die Auszeichung für seine Unterstützung 

bei der Wireless-Thematik. Er ist Obmann der Arbeitskreise 

2.6 (Feldbus) und 4.15 (Wireless) sowie Initiator 

der Heathrow-Gruppe. Schwibach schloß 1991 sein 

Duales Studium an der Berufsakademie Mannheim ab 

und begann im selben Jahr bereits bei der BASF. Er leitete 

ab 2001 die Fachgruppe IT-Lösungen in der PLT und 

fünf Jahre später die Gruppe „Industrielle Kommunikationstechnik“. 

Seit 2011 ist er verantwortlich für IT- und 

Automation-Security am Standort Ludwigshafen. 

Gerhard Rehn ist Mitglied in den Arbeitskreisen 2.6 

(Feldbus) und 2.8 (Internettechnologien in der Prozessautomatisierung). 

Seit 2004 ist er als Koordinator 

für das Arbeitsfeld 1 (Planung und Errichtung) verantwortlich. 

Rehn hat bis 1976 an der TU Ilmenau Informationstechnik 

studiert. 1989 begann er bei der Bayer 

AG und war dort zuständig für die „Systemwelt Prozessleitsysteme“. 

Seit 2000 verantwortet er die prozessleittechnische 

Planung im Pharma-Bereich und ist derzeit Leiter der 

PCT-Planung für die Werke Elberfeld und Bergkamen. 

 

(ahü) 

NAMUR-GESCHÄFTSSTELLE, 

c/o Bayer Technology Services GmbH, 

Gebäude K 9, D-51368 Leverkusen, 

Tel. +49 (0) 214 307 10 34, 

Internet: www.namur.de 

10 


12 / 2012

Bouaswaig und Yin 

ausgezeichnet 

Dr.-Ing. Ala Eldin Bouaswaig 

und Dr.-Ing. Shen Yin wurden 

auf der Namur-Hauptsitzung 

2012 mit dem Namur- 

Award ausgezeichnet. Bouaswaig 

erhielt die Auszeichnung 

für seine Doktorarbeit an der 

TU Dortmund zum Thema „Simulation, 

control, and inverse 

problems in particulate processes“. 

Nach seinem Studium 

an der Bright Star University of 

Technology (1993-1997) und 

dem Master an der TU Dortmund 

(2004-2006) sowie der 

dortigen Promotion (2009-2011) 

arbeitet Bouaswaig heute in 

Ludwigshafen als Automation 

Engineer bei BASF. 

Dr.-Ing. Shen Yin erhielt die Auszeichnung für 

seine Promotion „Data-driven design of fault diagnosis 

system“, die er zwischen 2007 und 2012 an 

der Universität Duisburg-Essen verfasst hat. Der 

Dozent am Harbin Institut of Technology konnte 

die Arbeit nicht entgegen nehmen. Sein betreuender 

Professor Ding nahm sie an seiner Stelle in 

Empfang. Yin hat einen Bachelorstudiengang am 

Harbin Institut of Technology (2000-2004) absolviert. 

Anschließend blieb er für ein Jahr an der 

Technischen Universität Bergakademie Freiberg, 

um danach bis 2007 seinen Master an der Universität 

Duisburg-Essen in Control and Information 

Systems zu absolvieren. Seit 2012 hat er die Dozentur 

am Harbin-Institut inne. 

(ahü) 

NAMUR-GESCHÄFTSSTELLE, 

c/o Bayer Technology Services GmbH, 

Gebäude K 9, D-51368 Leverkusen, 

Tel. +49 (0) 214 307 10 34, 

Internet: www.namur.de 

SHEN YIN wurde 

ebenfalls mit dem 

Namur-Award 

ausgezeichnet. Er 

konnte den Preis 

jedoch nicht 

persönlich in 

Empfang nehmen. 

ALA ELDIN 

BOUASWAIG 

stellte seinen 

ausgezeichneten 

Beitrag „Simulation, 

control, and inverse 

problems in 

particulate 

processes“ vor. 

Bild: Anne Hütter 

Mit Sicherheit 

kompetent 

Mit den Stellventilen Typ 3241 von 

SAMSON sind Sie immer auf der 

sicheren Seite. Dank ihrer hohen 

MTBF brauchen Sie sich um einen 

Ausfall nicht zu sorgen. 

Noch mehr Sicherheit garantieren die 

Stellungsregler der Bauarten 3730 und 

3731. Mit ihrem zertifizierten Magnetventil 

und dem induktiven Grenzkontakt 

führen sie die Sprung antworttests 

automatisch durch und dokumentieren 

die Ergebnisse. 

Gehen Sie auf Nummer sicher mit 

SAMSON. 

SIL 

SIL SIL 

A01039DE 

SAMSON AG · MESS- UND REGELTECHNIK 

Weismüllerstraße 3 · 60314 Frankfurt am Main 

Telefon: 069 4009-0 · Telefax: 069 4009-1507 

E-Mail: samson@samson.de · www.samson.de 

SAMSON GROUP · www.samsongroup.net

BRANCHE 

AALE 2013: Mehr über Energieeffizienz, Systeme, 

Lehre und Forschung in der Automation erfahren 

EXPERTENFORUM: Studenten und Praktiker der 

Automatisierungstechnik tauschen sich in Stralsund zur 

AALE-Fachtagung 2013 aus. Bild: Sebastian Bernhard/pixelio.de 

Ans Meer geht es im kommenden Jahr mit der Angewandten 

Automatisierungstechnik in Lehre und Entwicklung 

an Fachhochschulen (AALE). Die 10. AALE- 

Konferenz findet vom 28. Februar bis 1. März 2013 an der 

Fachhochschule Stralsund statt. Sie wird vom Fachbereich 

Elektrotechnik und Information organisiert und 

vom Verein der Freunde und Förderer der Angewandten 

Automatisierungstechnik an Fachhochschulen (VFAALE 

e.V.) unterstützt. Themen wie Trends der Automatisierungstechnik, 

Forschungs- und Entwicklungsarbeiten, 

Kooperationen in der Automation zwischen Hochschule 

und Industrie sowie Lehre und Ausbildung, Didaktik und 

MINT-Projekte stehen auf dem Programm. Am 28. Febru- 

ar beginnt der Expertentreff bereits um 9 Uhr mit der 

Begrüßung durch Veranstaltungsleiter Prof. Bernd Büchau 

(FH Stralsund). Es folgt ein Grußwort von Stefan 

Sagert vom VDMA Robotik+Automation. Ab 9.40 Uhr 

starten dann die Plenarvorträge unter Vorsitz von Prof. 

Büchau. Nach der ersten Pause starten drei Sessions zum 

Thema Lehre und Ausbildung, Automatisierungssysteme 

I und Robotik I. Steuerungstechnik und die Forführung 

der Sessions Automatisierungssysteme und Robotik 

stehen danach auf dem Plan. In den Sessions 7, 8 und 9 

befassen sich die Vortragenden mit Energieeffizienz, Modellbasierten 

Entwürfen und Adaptiven Systemen. Ab 

15.45 Uhr wird dann der AALE Student Award 2031 verliehen. 

Den Vorsitz führt hier Prof. Viktorio Malisa. Gesponsert 

wird der Preis von Bayer Technology Services 

und GmbH und Evonik Industries AG. Die besten drei 

Abschlussarbeiten erhalten die Chance sich kurz vorzustellen. 

Am Ende wird der Gewinner bekannt gegeben. 

Zur Abendveranstaltung geht es dann auf einen Exkurs 

in die Tiefsee. Am nächsten Tag starten die Teilnehmer 

mit der Postersession. Weitere Sessions sind bis kurz nach 

12 Uhr geplant. Um 12.30 Uhr werden dann alle mit einem 

gemütlichen Ausklang verabschiedet. 

(ahü) 

ANGEWANDTE AUTOMATISIERUNGSTECHNIK 

IN LEHRE UND ENTWICKLUNG (AALE) , 

c/o Fachhochschule Düsseldorf, 

Fachbereich Elektrotechnik, 

Josef-Gockeln-Straße 9, D-40474 Düsseldorf, 

Tel. +49 (0) 211 435 13 08, 

Internet: www.aale2013.fh-stralsund.de 

Die IEC 61508 

richtig anwenden 

Eine Tagung zur funktionalen Sicherheit 

bietet der Verband der Elektrotechnik 

Elektronik und Informationstechnik (VDE) 

am 12. und 13. März 2013 in Erfurt an. Die 

Sicherheitsgrundnorm für funktionale Sicherheit 

IEC 61508 erschien erstmalig 

1998, mittlerweile liegt die zweite Ausgabe 

SICHERHEIT IN DER vor. Etliche fachspezifische Normen, die 

INDUSTRIE definiert die diese umsetzen, sind erschienen. Literatur 

IEC 61508. Bild: Katharina und zahlreiche Veranstaltungen befassen 

Bregulla / pixelio.de 

sich bereits mit ihrer Auslegung. Die Erfahrungen 

des GK 914, das bei der DKE für 

die IEC 61508 zuständig ist, zeigen, dass die Lücke zwischen 

dem Text der Norm und dem konkreten Anwendungsfall 

noch groß ist. Das DKE-Komitee GK 914 wird zu 

diversen Fragen am 12. und 13. März 2013 in Erfurt Rede 

und Antwort stehen. Erstmalig werden auch VDE-Experten 

aus der Medizintechnik ihre Sicht einbringen. (ahü) 

VDE-VERBANDSGESCHÄFTSSTELLE, 

Stresemannallee 15, D-60596 Frankfurt am Main, 

Tel. +49 (0) 69 630 80, Internet: www.vde.com 

Dechema-Preis 2012 für 

Prof. Dr. Joachim Groß 

Prof. Dr. Joachim Groß von der 

Universität Stuttgart erhält den 

diesjährigen Dechema-Preis der 

Max-Buchner-Forschungsstiftung 

für seine guten Forschungsarbeiten 

zur Thermodynamik von Gemischen. 

Dank seiner Erkenntnisse 

ist es Verfahrenstechnikern möglich, 

Eigenschaften von Stoffgemischen 

mit polaren Wechselwirkungen 

oder am kritischen Punkt 

vorauszu erechnen. Die Verleihung 

des mit 20.000 Euro dotierten 

Preises fand am 30. November 2012, 

im Rahmen eines Festkolloquiums, 

in Frankfurt am Main statt. (ahü) 

DECHEMA E.V., 

Theodor-Heuss-Allee 25, 

D-60486 Frankfurt, 

Tel. +49 (0) 69 756 40, 

Internet: www.dechema.de 

PROF. DR. 

JOACHIM GROSS 

forschte zu 

Thermodynamik 

von Gemischen. 

Bild: Dechema 

12 


12 / 2012

Neue Richtlinie VDI/VDE 2632 Blatt 2 vereinfacht 

Kommunikation zwischen Anbietern und Anwendern 

Die soeben als Entwurf veröffentlichte Richtlinie VDI/ 

VDE 2632 Blatt 2 „Industrielle Bildverarbeitung – 

Leitfaden für die Erstellung eines Lastenhefts und eines 

Pflichtenhefts“ unterstützt Anwender und Anbieter von 

Machine-Vision-Systemen bei der Kommunikation miteinander, 

um Missverständnisse und eine unvollständige 

Aufgabenbeschreibung zu vermeiden. Die Richtlinie 

hilft, Bildverarbeitungsprojekte im vollen Funktionsumfang 

und innerhalb des geplanten Zeit- und Kostenaufwands 

zu realisieren. Viele Methoden, die für die 

industrielle Bildverarbeitung entwickelt wurden, sind 

längst in den Alltag eingezogen. Moderne Fotoapparate 

erkennen das Lächeln von Personen und wählen automatisch 

den optimalen Aufnahmezeitpunkt für das 

Bild. Handykameras nehmen Fotos einer Plakatwand 

auf, finden und lesen den dort abgedruckten Text, erkennen, 

dass der Text eine Internet-Seite angibt und 

bieten dem Benutzer an, die entsprechende Website zu 

öffnen. 2-D-Codes mit Informationen von Flugtickets 

werden nicht mehr ausgedruckt, sondern direkt vom 

Handy-Display gelesen. 

Die hier aufgeführten Beispiele könnten bei den Anwendern 

der industriellen Bildverarbeitung den Eindruck 

erwecken, dass die modernen bildgestützten Positionier-, 

Prüf- und Messeinrichtungen quasi von alleine ihre Aufgaben 

erfüllen. Das ist aber nicht so. Eine veränderte 

Oberflächenrauheit kann beispielsweise für ein Produkt 

nicht qualitätsrelevant sein, ein anderer Farbton dagegen 

schon. Bei anderen Produkten können die Qualitätskriterien 

genau umgekehrt definiert sein. Daher ist in der 

industriellen Bildverarbeitung genau festzulegen, was die 

Prüfaufgabe ist, wie die Prüfobjekte aussehen, und wie 

die Umgebungsbedingungen sind, um zum Beispiel die 

Verständnisschwierigkeiten hinter folgenden Anwenderaussagen 

zu vermeiden: 

Wir hatten spezifiziert, dass das größte zu inspizierende 

Produkt 15 mm lang ist. Unsere neue Produktgeneration 

ist 17,5 mm lang. Das ist doch kein Problem, 

oder? 

Bei der Anlagenreinigung am Schichtende wird 

Staub aufgewirbelt. Was dachten Sie denn? 

Das war doch von vorne herein klar, dass die Anlage 

nach dem erfolgreichen Probelauf hier bei uns im 

Werk anschließend nach Indonesien geschickt werden 

soll. Wussten Sie das nicht? 

Diese frei erfundenen, aber realitätsnahen Aussagen können 

ein komplettes Anlagenkonzept infrage stellen: 

Wenn telezentrische Objektive in dem Bildverarbeitungssystem 

eingesetzt werden, kann das sichtbare 

Objektfeld nicht ohne weiteres vergrößert werden: Es 

werden andere Objektive mit anderen Einbaumaßen 

für größere Produkte gebraucht. 

Nicht berücksichtigte Staubeinwirkungen können 

zusätzliche Einhausungen und Filter erforderlich 

machen. 

Der Betrieb bei extrem hohen Temperaturen und hoher 

Luftfeuchtigkeit kann zusätzliche Kühlvorrichtungen 

und Luftentfeuchter erfordern. 

LASTEN UND PFLICHTEN beim Anlagenmagement in der industriellen 

Bildverarbeitung erläutert die Richtlinie VDI/VDE 2632 Blatt 2. 

Bild: Fraunhofer IOSB/Manfred Zentsch. 

In allen Beispielen verlängert die nachträgliche Änderung 

der Anforderungen die Lösungserstellung für die Bildverarbeitungsaufgabe 

und macht das System teurer. Daher 

ist es wichtig, die Anforderungen an ein Bildverarbeitungssystem 

möglichst früh, präzise und umfassend zu 

beschreiben, damit das fertige System zur vollen Zufriedenheit 

aller Beteiligten arbeitet. 

Die Richtlinie VDI/VDE 2632 Blatt 2 gibt Hinweise zur 

Erstellung eines Lastenheftes und führt detailliert Einflussgrößen 

auf, die bei der Spezifikation einer Bildverarbeitungsaufgabe 

vom Anwender berücksichtigt werden 

sollen. Die hier aufgeführten Aspekte lassen sich auf fast 

alle Bildverarbeitungsaufgaben anwenden, seien es Sortier-, 

Positionier-, Prüf- oder Messaufgaben. Die Richtlinie 

schlägt zudem mögliche Inhalte eines Pflichtenheftes vor, 

in dem ein Anbieter dem Anwender seinen Lösungsvorschlag 

unterbreitet. Damit erleichtert sie es den Anbietern, 

den Leistungs- und Funktionsumfang der angebotenen 

Lösung vollständig und für den Anwender transparent zu 

beschreiben. Die als Entwurf veröffentlichte Richtlinie 

VDI/VDE 2632 Blatt 2 ergänzt die Richtlinienreihe zur 

„Industriellen Bildverarbeitung“ des Fachausschusses 

3.51 im GMA-Fachbereich 3 „Fertigungsmesstechnik“. 

Einsprüche zur Richtlinie können bis zum 28. Februar 

2013 über das VDI-Richtlinien-Einspruchsportal (www. 

vdi.de/einspruchsportal) eingereicht werden. Das bereits 

veröffentlichte Blatt 1 dieser Richtlinie behandelt die 

Grundlagen und Begriffe der industriellen Bildverarbeitung. 

Weitere Blätter sind in Planung. 

VDI/VDE-GESELLSCHAFT MESS- UND 

AUTOMATISIERUNGSTECHNIK (GMA), 

Dr.-Ing. Erik Marquardt, 

VDI-Platz 1, D-40468 Düsseldorf, 

Tel. +49 (0) 211 621 43 73, 

E-Mail: marquardt@vdi.de, 

Internet: www.vdi.de/2632 


12 / 2012 

13

FORSCHUNG 

PENG erzeugt Energie aus minimalen 

Temperaturunterschieden 

Schon Temperaturunterschiede durch einen Luftzug 

oder einen Sonnenstrahl können Strom erzeugen. 

Doch reicht dieser, um ganze Komponenten dauerhaft 

zu versorgen? Forscher des Georgia Institute of Technology 

haben einen solchen PENG, einen pyroelektrischen 

Nanogenerator, erfunden. Er ist halb so groß wie eine 

Briefmarke und kann nach Angaben der Wissenschaftler 

Elektronik-Kompontenten mit ausreichend Strom 

versorgen. Der pyroelektrische Effekt erlaubt die Erzeugung 

von Strom aus zeitlichen Temperaturänderungen, 

ist bisher aber kaum erforscht. Bisherige Generatoren 

auf dieser Grundlage haben lediglich Spannungen unter 

0,1 Volt geliefert. Der PENG besteht aus einer 175 

Mikrometer dicken Folie aus Blei-Zirkonat-Titanat. Ein 

Stück mit den Maßen 21 x 12 Millimeter liefert bei einer 

Temperaturänderung um 45 Kelvin mit einer Geschwindigkeit 

von 0,2 Kelvin pro Sekunde bis zu 22 Volt Spannung 

bei 430 Nanoampere. Die Stromdichte beträgt 171 

Nanoampere pro Quadratzentimeter. Das reicht aus, um 

ein kleines LCD mit Energie zu versorgen, wie die Forscher 

bewiesen. Auch zum Laden eines Lithium-Ionen- 

Akkus kann der erzeugte Storm genutzt werden, allerdings 

muss der Output hier für einen sinnvollen Einsatz 

noch erhöht werden. 

(ahü) 

GEORGIA INSTITUTE OF TECHNOLOGY, 

North Ave., Atlanta, Georgia 30332, USA, 

Tel. +1 404 894 20000, 

Internet: www.gatech.edu 

Modularisierung fördert schnellere Produktion 

Könnte die Lösung für einen schnelleren Martkeintritt 

für ein Produkt der Verfahrenstechnik in der Modularisierung 

liegen? Ja, sie könnte, erklärte Norbert Kockmann, 

anlässlich der Namur-Hauptsitzung Anfang November 

in Bad Neuenahr. Der Treffpunkt für Anwender 

von Automatisierungstechnik in der Prozessindustrie 

stellte in seinem Vortragsprogramm einige Lösungen für 

die effiziente Prozesstechnik vor. Dazu gehört auch das 

europäische Forschungsprojekt F3 (Fast Flexible Future) 

Factory. Das Projekt modularisiert Anlagen in Containern. 

Invite heißt das Projekt, das von der Bayer Technology 

Services und der TU Dortmund realisiert wurde. 

Bei Evonik ist ein ähnliches Projekt, der Evotrainer, im 

Einsatz. Er entstand aus dem Forschungsprojekt Copiride. 

Dieser 3 x 12 Meter große Container enthält, was für 

die Produktion benötigt wird: Reaktoren, Prozessleittechnik, 

IT-Module, Lagerfläche für die Einsatzstoffe, 

Elemente für konstruktiven Brandschutz, Fluchttüren 

und Auffangwannen nach dem Wasserhaushaltsgesetz. 

Die Verfahrenstechnik gibt hier also eine neue Marschrichtung 

vor; die Automatisierungstechnik muss mit den 

Anforderungen Schritt halten. „Die Automatisierungstechnik 

darf die Entwicklung nicht bremsen, sie soll sie 

unterstützen“, fordert Stephan Bleuel von Sanofi-Aventis. 

Die Branche ist sich sicher: Modularisierung hat Potenzial, 

die Time-to-Market zu verkürzen. 

(ahü) 

TECHNISCHE UNIVERSITÄT DORTMUND, 

Fakultät Bio- und Chemieingenieurwesen, 

Emil-Figge-Strasse 70, D-44227 Dortmund, 

Tel. +49 (0) 231 755 30 30, 

Internet: www.bci.tu-dortmund.de 

Mikrochips sollen Raubkopien verhindern 

Verschiedene Möglichkeiten, Maschinenbauer vor dem 

Kopieren ihrer Ware zu schützen, schlägt das Fraunhofer-Institut 

für Angewandte und Integrierte Sicherheit 

AISEC vor. Um das illegale Kopieren von vornehmlich 

Textilmaschinen, Kompressoren oder Anlagen für Kunststoffverarbeitung 

besser zu kontrollieren, bieten die Wissenschaftler 

zahlreiche Verfahren an. 

Besonders die integrierten Steuerungprogramme der 

Maschinen sind ein beliebtes Angriffsziel für Kopierer. 

Ein ganzer Auftragsmarkt hat sich, laut AISEC, darum 

gebildet. Dienstleister bieten mittlerweile das "Reverse 

Engineering" an. Zunächst analysieren sie den Aufbau 

der Hardware und fertigen Schaltpläne des Originalproduktes 

an. Dann lesen sie die Software aus und rekonstruieren 

daraus die Steuerung und Funktionen der Maschine, 

den Kern des Apparats. Sicherheitskritische 

Ersatzteile, wie bereits in der Luftfahrtindustrie eingesetzt, 

können mit nicht kopierbaren Hologrammen gekennzeichnet 

werden. 

Effektiver ist es dagegen bereits bei der Entwicklung 

der Hardware den Produktschutz einzubeziehen. Auf 

Mikrochips können die Daten der Maschine so verschlüsselt 

hinterlegt werden. AISEC geht davon aus, dass 

eine Prophylaxe dieser Art Maschinenbauer bis zu fünf 

Jahre vor Produktpiraterie schützen kann. (ahü) 

FRAUNHOFER-INSTITUT FÜR ANGEWANDTE UND 

INTEGRIERTE SICHERHEIT AISEC, 

Parkring 4, D-85748 Garching b. München, 

Tel. +49 (0) 89 3229986-128, 

Internet: www.aisec.fraunhofer.de 

14 


12 / 2012

Flinker Modulator: Baustein für effiziente 

Datenübertragung gelangt zur Marktreife 

Wissenschaftlern aus Berlin und Frankfurt/Oder ist 

es gelungen, den bisher kleinsten Hochgeschwindigkeitsmodulator 

der Welt zu entwickeln. Der Modulator 

mit einer Länge von weniger als 10 Mikrometern 

ist für photonisch integrierte Schaltkreise geeignet. 

Modulatoren werden in der Nachrichtentechnik zur 

Übertragung von Informationen eingesetzt. Bei hohen 

Modulationsgeschwindigkeiten von bis zu 25 Gigabaud 

besitzt er eine sehr hohe Temperaturstabilität 

und einen äußerst geringen Energieverbrauch von nur 

200 Femtojoule/Bit. Die Herausforderung bleibt die 

effiziente Zusammenführung der Basiselemente zu 

einem leistungsstarken marktfähigen Produkt. Siliconon-Insulator 

(SOI) Chip stellt sich als technisch besonders 

anspruchsvoll dar. Hier gilt es, eine effiziente 

Kombination aus Laserquelle, elektro-optischem 

Modulator und Treiberelektronik zu entwickeln. Bisher 

konnte für dieses Modul keine optimale Lösung 

aufgezeigt werden, welche gleichzeitig alle Anforderungen 

an die Schaltgeschwindigkeit, Baugröße, 

Zuverlässigkeit und den Energieverbrauch für die 

Implementierung in einen optischen Transceiver, der 

als Schnittstelle zwischen optischer und elektrischer 

Übertragungsstrecke fungiert, erfüllt. (ahü) 

TECHNISCHE UNIVERSITÄT BERLIN, 

Straße des 17. Juni 135, D-10623 Berlin, 

Tel. +49 (0) 30 31 40, Internet: www.tu-berlin.de 

KLEINER ABER OHO: 

Der Silicon-on-Insulator 

(SOI)-Chip ist 26×11 

Quadratmillimeter klein 

und hat über 700 

verschiedene optische 

Bauelemente. 

Foto: TU Berlin 

Roboter Hytaq fliegt oder 

fährt je nach Bedarf 

Ein Automat, der fahren 

und fliegen kann. Forschern 

am Robotics Lab 

des Illinois Institut of 

Technology (IIT) ist es gelungen, 

einen solchen Hybrid 

Terrestrial and Aerial 

Quadrotor, kurz Hytaq, 

zu entwickeln. Der Flugroboter 

besteht aus einem 

QUADROTOR: Umgeben von robotischen Hubschrauber 

mit vier Rotoren, um 

einem runden Schutzkäfig kann 

Hytaq auch fahren. Bild: IIT den herum die Entwickler 

einen Schutzkäfig angelegt 

haben. Dieser ist aus Polykarbonat und Kohlenstofffaser. 

Im Inneren auf einer Achse sitzt der Flugroboter. 

Man nennt ein solches Konstrukt auch Quadrokopter. 

Zum Fahren benutzt der Automat dann den 

runden Käfig. Durch die Abrundung muss nur der 

Rollwiderstand überwunden werden. Die Erfinder hoffen, 

dass es Hytaq gelingt, einfacher an schwierig zu 

erreichende Orte zu gelangen. Außerdem kann die Effizienz 

seiner Fortbewegung angepasst werden. Die 

Batterie von Hytaq reiche zwar nur fünf Minuten, an 

alternativen Energieversorgungsmethoden werde jedoch 

noch gearbeitet. Hytag kann viermal so lange 

Strecken zurücklegen und fast sechs Mal so lang im 

Einsatz sein, weie in reines fliegendes System. (ahü) 

ILLINOIS INSTITUT OF TECHNOLOGY, 

3300 South Federal Street, Chicago, IL 60647, USA 

Internet: www.iit.edu 

Digitale Anlage im Lebenszyklus 

AUSGABE 55 (6) DER ATP EDITION im Juni 2013 greift das Thema der 

Digitalen Anlage im Lebenszyklus auf. Die Digitale Anlage ist der Oberbegriff 

für ein umfassendes Netzwerk von digitalen Modellen, Methoden 

und Werkzeugen die durch ein durchgängiges Datenmanagement 

integriert werden. Ihr Ziel ist die ganzheitliche Planung, Evaluierung 

und laufende Verbesserung aller wesentlichen Strukturen, Prozesse 

und Ressourcen der realen Anlage in Verbindung mit dem Produkt – sie 

ist ein essenzielles Element für die Umsetzung der Vision Industrie 

4.0. Gesucht sind praxisorientierte Beiträge zur Beschreibung, Modellierung, 

Umsetzung, Einführung und Nutzung der Digitalen Anlage bei 

Anlagenplanung, Inbetriebsetzung und Prozessführung. Beiträge, die 

die Nutzung der Digitalen Anlage im Zusammenhang mit CPS darstellen, 

sind ebenfalls willkommen. 

Die atp edition ist die hochwertige Monatspublikation für Fach- und 

Führungskräfte der Automatisierungsbranche. In den Hauptbeiträgen 

werden die Themen mit hohem wissenschaftlichem und technischem 

Anspruch und vergleichsweise abstrakt dargestellt. Im Journalteil 

werden praxisnahe Erfahrungen von Anwendern mit neuen Technologien, 

Prozessen oder Produkten beschrieben. 

Alle Beiträge werden von einem Fachgremium begutachtet. Sollten 

Sie sich selbst aktiv an dem Begutachtungsprozess beteiligen wollen, 

bitten wir um kurze Rückmeldung. Für weitere Rückfragen stehen wir 

Ihnen selbstverständlich gerne zur Verfügung. 

Ihre Redaktion der atp edition: Leon Urbas, Anne Hütter 

CALL FOR 

Aufruf zur Beitragseinreichung 

Thema: Die Digitale Anlage im Lebenszyklus 

Kontakt: urbas@di-verlag.de 

Termin: 28. Januar 2013 


12 / 2012 

15

PRAXIS 

Vernetzte Sicherheitscontroller überwachen die 

komplette Montage von Flugzeugrumpf-Schalen 

Premium Aerotec erreicht mit Lösung von ABB Jokab Safety Performance Level PL e und SIL 3 

DIE SCHUTZUMHAUSUNG QUICK-GUARD 

besteht aus einem Minimum an Komponenten. 

Die Computer-Software SafeCAD erstellt 

automatisch 3D-Zeichnungen sowie Komponentenund 

Schnittlisten. Der Sicherheits-Lichtvorhang 

Focus schützt vor unbefugtem Zutritt. 

Bild: ABB Jokab Safety 

DIE VOLLAUTOMATISIERTE FLÄCHENNIETANLAGE 

NOR ist durch eine Sicherheits-Komplettlösung von 

Jokab Safety rundum geschützt. Bild: Premium Aerotec 

Der Luftfahrtzulieferer Premium Aerotec wählte für 

den Personen-, Maschinen- und Anlagenschutz an 

den Flächennietern und seiner Pulse-Motion-Montagelinie 

eine Sicherheits-Komplettlösung von ABB Jokab 

Safety. Sämtliche Sicherheitsfunktionen an den 

neuen Fertigungslinien in der Schalenmontage im 

niedersächsischen Nordenham werden von zehn miteinander 

vernetzten Sicherheitscontrollern Pluto 

B46 v2 überwacht und gesteuert. Diese sind über sechs 

Protokollumsetzer Gate-P1 mit der übergeordneten 

Profibus-DP-Steuerung vernetzt. Mit Erweiterungsund 

Sicherheitsrelais, Zustimmungsschaltern, Lichtvorhängen, 

Schutzumhausungen sowie Sicherheitsschlössern 

mit Zuhaltung erreicht das Unternehmen 

durchgängig den höchsten Performance Level PL e 

gemäß EN ISO 13849-1 und SIL 3 gemäß EN IEC 61508 

sowie EN IEC 62061. 

5000 RUMPFSCHALEN PRO JAHR 

Jährlich verlassen rund 5000 Schalen das Werk Nordenham, 

die unter anderem auf dem Seeweg zum 

Hauptkunden Airbus nach Hamburg transportiert 

werden. Aus Nordenham erhält der Flugzeughersteller 

Schalen für den A380 und zukünftig die komplette 

Sektion 13/14 der Rumpfstruktur für den A350 XWB. 

Neben der Fertigung von Flugzeugstrukturen für die 

gesamte Airbus-Flotte produziert das Werk Nordenham 

auch Bauteile für andere Luftfahrtkunden sowie 

branchenfremde Unternehmen, wie Komponenten für 

den Triebkopf des chinesischen Hochgeschwindigkeitszuges 

CRH3. 

VOLLAUTOMATISIERTE FLÄCHENNIETANLAGE 

Der Sondermaschinenbauer Brötje-Automation GmbH 

aus Wiefelstede bei Oldenburg ist als Generalunternehmer 

der verantwortliche Lieferant der drei Montagelinien 

für die A350 XWB-Rumpfschalen in Nordenham, 

Stade und Augsburg. Dies beinhaltet neben einem in der 

Flugzeugmontage einzigartigen Förderkonzept auch 

vollautomatisierte Bohr- und Nietmaschinen. 

Sowohl die vollautomatisierte Flächennietanlage in 

Nordenham als auch die Multi-Panel-Assembly-Cell 

(MPAC) in Augsburg sind zur Herstellung von Nietverbindungen 

und zur Montage von Rumpf-Bauteilen für 

den Airbus A 350 bestimmt. Der Bohr- und Nietprozess 

erfordert eine beidseitige und geregelte Krafteinleitung, 

um die Flugzeugschale vor Beschädigungen zu schützen. 

Der eingesetzte Bohr- und Nietendeffektor ist daher zwei- 

16 


12 / 2012

DAS SICHERHEITSSCHLOSS KNOX verhindert, 

dass Menschen in die Nähe gefährlicher Maschinenteile 

gelangen können, bevor die Maschine 

vollständig stillsteht. Bild: ABB Jokab Safety 

DER SICHERHEITSCONTROLLER PLUTO B20 

unterstützt durchgängig den höchsten Performance 

Level PL e und SIL 3. Die Erweiterungsrelais BT51 

bieten zusätzliche Ausgangskontakte, und das 

Gateway Gate P1 ermöglicht die Kommunikation 

mit der übergeordneten Profibus-DP-Steuerung. 

Bild: ABB Jokab Safety 

geteilt. Das sogenannte Oberwerkzeug beherbergt diverse 

einzelne Werkzeuge wie Bohrer, Nieteinsetzer sowie 

Spanabsaugung und kommt ohne Hydraulik aus. Es wird 

über ein Portal in die jeweils gewünschte Position verfahren. 

Das Unterwerkzeug ist steuerungsseitig gekoppelt 

und kann so automatisch in die dazugehörige Gegenhalterposition 

verfahren werden. Eine Vielzahl von 

Achsen erlaubt auch das Bearbeiten von komplexen Bauteilen 

und Strukturen. 

SICHERHEITSZELLE SCHÜTZT MITARBEITER 

Die Pulse Motion Line (PML) für die Schalenproduktion 

ist ein in der Flugzeugmontage weltweit erstmalig eingesetztes 

Montagelinienkonzept. Die Taktung des Bauteils 

erfolgt in vorab festgelegten Abständen, hier alle 7 

Spanten. Die Bauteilträger werden mit einem Transportgestell 

in die PML be- und entladen. Ein durchgängiges 

Transportsystem in der PML sorgt für den Weitertransport 

der Bauteile durch alle Arbeitsbereiche. 

Die Anlage ist aus Sicherheitsgründen mit einem 

Schutzzaun für den Arbeitsbereich der Nietanlage ausgerüstet. 

Die Sicherheitszelle ist mit mehreren Türen 

ausgerüstet. Jede Tür verfügt über eine Türverriegelung 

Knox von Jokab Safety. Der Eintritt in die Sicherheitszelle 

wird erst freigegeben, wenn sich das Positioniersystem 

und die Nietmaschine in einem sicheren Zustand 

befinden. 

Zur Durchführung mehrerer Bohrungen am Testblech 

kann der Bediener den Positionierer eingeschränkt 

verfahren. Zum Schutz des Bedieners in der 

Zelle bewegt sich der Positionierer nur, wenn der Bediener 

eine Zustimmtaste betätigt hält. Die Bewegung 

des Positionierers ist auf „sichere Geschwindigkeit“ 

begrenzt. Wenn der Bediener die Zustimmtaste während 

eines Zyklus loslässt, stoppt der Zyklus an Unterbrechungspunkten 

in der Prozessschrittkette, eine 

Bohrvorschubbewegung wird sofort abgebrochen und 

der Bohrer zurückgezogen. 

Alle diese übergeordneten sicherheitsrelevanten 

Steuerungsprozesse sind durch mehrere miteinander 

vernetzte Sicherheitscontroller des Typs Pluto B46-2 

realisiert. Die von der Sicherheitstechnik geforderte 

Flexibilität ließ sich mit dem freiprogrammierbaren 

Sicherheitscontroller Pluto problemlos verwirklichen. 

Pluto ist ein Controller, der den Entwurf von Sicherheitssystemen 

vereinfacht und die höchste Sicherheitskategorie 

4 nach EN 954-1 beziehungsweise PL e nach 

EN 13849-1 erreicht. 


12 / 2012 

17

PRAXIS 

EINFACHER AUSBAU DANK MODULSYSTEM 

Für das Projekt benötigte man sowohl eine flexible Automatisierungssteuerung 

als auch ein zuverlässiges Sicherheitssystem. 

Die Wahl fiel hier auf die SPS Pluto von 

ABB Jokab Safety, die beide Anforderungen erfüllen 

konnte. Pluto ermöglichte eine leichte und unkomplizierte 

sicherheitstechnische Vernetzung der Fertigungslinie. 

Mithilfe des Pluto-Systems wurde die Berechnung 

des PL stark erleichtert. 

Die modulare Architektur des Systems erlaubt einen 

einfachen Ausbau falls die Kapazität erhöht werden 

muss. Für Brötje-Automation war wichtig, dass die Sicherheitsfunktionen 

von Anfang an in das Anlagenkonzept 

integriert werden konnten. Schließlich ist es nicht 

ganz einfach, ein System im Nachhinein an die zahlreichen 

erforderlichen Sicherheitsfunktionen anzupassen. 

Eine rein Hardware-technische Realisierung mit dem 

damit verbundenen enormen Installationsaufwand und 

möglicherweise einem zusätzlichen Schaltschrank wäre 

zu aufwendig geworden. 

DEZENTRALE AUTOMATISIERUNGSLÖSUNG 

Alle Fäden der dezentral strukturierten Automatisierungslösung 

für das Transportsystem laufen in einem 

zentralen Controller zusammen, der neben den konventionellen 

SPS-Aufgaben die gesamte Sicherheitstechnik 

des Transportsystems auswertet und steuert. Das Ergebnis 

sind mehrere kompakt montierte, dezentrale Schaltschränke, 

die über Profibus DP mit dem zentralen Controller 

verbunden sind. 

Durch den Mischbetrieb der Baugruppen ist es möglich, 

in einer dezentralen Station sowohl Standard- als 

auch sicherheitsrelevante Prozess-Signale zu verarbeiten. 

Der sichere Datenaustausch ist über herkömmliche 

Profibus-Kabel und das Protokoll Profisafe realisiert. 

Dies erspart einen separaten Sicherheitsbus und den damit 

verbundenen Installationsaufwand. 

LICHTVORHANG SORGT FÜR FLEXIBILITÄT 

Die Roboter-Anlage ist aus Sicherheitsgründen mit einer 

Zelleneinhausung für den Arbeitsbereich ausgerüstet. 

Die Sicherheitszelle soll verhindern, dass sich während 

des Automatikbetriebs ein Mitarbeiter im Gefahrenbereich 

des Roboters aufhält. Die Sicherheitszelle wird mit 

mehreren Türen ausgerüstet. Jede Tür hat eine Türsicherung 

Knox von Jokab Safety. Der Eintritt in die Sicherheitszelle 

wird erst freigegeben, wenn der Roboter mit 

dem Endeffektor sicher steht. 

Damit der Bediener oder das Wartungspersonal an den 

Endeffektoren am Ablageplatz arbeiten kann, ist der Bereich 

zwischen Ablageplatz und Sicherheitszelle mit 

einem Jokab-Safety-Lichtvorhang Focus gesichert. Wenn 

mehr als ein Roboter in der Zelle arbeitet, wird mit zusätzlichen 

Lichtvorhängen des Typs Focus die Zelle in 

Arbeitsbereiche aufgeteilt. Durch diese Querteilung der 

Sicherheitszelle wird es möglich, dass sich Bediener oder 

Wartungspersonal in einem Teilbereich der Zelle aufhalten 

können, ohne dass der zweite Roboter seine Arbeit 

stoppen muss. 

PROJEKTÄNDERUNGEN OHNE UMVERDRAHTUNG 

Ausgezahlt hat sich die fehlersichere SPS-Technik bereits 

in der Entwicklungsphase insofern, als im Sondermaschinenbau 

immer wieder Änderungen in der Projektphase 

vorgenommen werden müssen, die sonst einen 

erheblichen Umverdrahtungsaufwand mit sich gebracht 

hätten. Die Sicherheitsfunktionalität der fehlersicheren 

Steuerung Pluto basiert auf vorgefertigten Funktionsbausteinen. 

Diese lassen sich aber auch an individuelle Anforderungen 

anpassen. Zum Austausch nicht sicherheitsrelevanter 

Daten zwischen den Pluto-Steuerungen wird 

das Profibus-Gateway Gate-P1 von ABB Jokab Safety 

eingesetzt. 

Der bei Premium Aerotec mit der Instandhaltungsplanung 

und -steuerung betraute technische Leiter, Peter 

Janßen und sein Mitarbeiter Thomas Karges sowie Brötje-Projektleiter 

Automatisierungstechnik, Rainer Weber, 

schätzen vor allem die hohe Anpassungsfähigkeit des 

Sicherheitscontrollers Pluto sowie die leichte Ausrichtung 

der Unfallschutz-Lichtvorhänge Focus. 

Die drei Automatisierungsspezialisten loben auch den 

übersichtlichen modularen Aufbau und die leichte Programmierbarkeit 

von Pluto mit der kostenlosen Software 

Pluto Manager sowie das durchgängige Erreichen des 

höchsten Performance Levels PL e. 

AUTOR 

ANDREAS STRANGFELD 

ist Leiter Produktmarketing 

Safety bei ABB Stotz- 

Kontakt in Spaichingen. 

ABB Stotz-Kontakt GmbH, 

Max-Planck-Straße 21, D-78549 Spaichingen, 

Tel. +49 (0) 7424 958 65 24, 

E-Mail: andreas.strangfeld@de.abb.com 

18 


12 / 2012

Herausforderung 

Automatisierungstechnik 

Mit dem atp-award werden zwei Autoren der atp edition 

für hervorragende Beiträge ausgezeichnet. Ziel dieser 

Initiative ist es, Wissenschaftler und Praktiker der 

Automatisierungstechnik anzuregen, ihre Ergebnisse 

und Erfahrungen in Veröffentlichungen zu fassen und 

die Wissenstransparenz in der Automatisierungstechnik 

zu fördern. 

Teilnehmen kann jeder Autor der zum Zeitpunkt 

der Veröffentlichung nicht älter als 35 Jahre ist. Nach 

Veröffentlichung eines Beitrags ist der Autor, wenn er 

die Bedingung erfüllt, automatisch im Pool. Die Auswahl 

des Gewinners übernimmt die atp-Fachredaktion. 

Derjenige Autor, der im Autorenteam der jüngste ist, 

erhält stellvertretend für alle Autoren die Auszeichnung. 

Der Preis wird in zwei Kategorien ausgelobt: 

Industrie und Hochschule. Die Kategorien ermittlung 

ergibt sich aus der in dem Beitrag angegebenen Adresse 

des jüngsten Autors. 

Veröffentlichungen – Beitrag zum Wissenspool 

im Fachgebiet Automatisierungstechnik 

Die Entwicklung eines Wissensgebietes erfolgt durch 

einen kooperativen Prozess zwischen wissenschaftlicher 

Grundlagenforschung, Konzept- und Lösungsentwicklung 

und Anwendung in der Praxis. Ein solcher 

Prozess bedarf einer gemeinsamen Informationsplattform. 

Veröffentlichungen sind die essentielle Basis 

eines solchen Informationspools. 

Der atp-award fördert den wissenschaftlichen Austausch 

im dynamischen Feld der Automationstechnik. 

Nachwuchsingenieure sollen gezielt ihre Forschungen 

präsentieren können und so leichter den Zugang zur 

Community erhalten. Der Preis ist mit einer Prämie 

von jeweils 2000 € dotiert. 

Die Auswahl erfolgt in zwei Stufen: 

Voraussetzung für die Teilnahme ist die Veröffentlichung 

des Beitrags in der atp edition. Jeder Aufsatz, 

der als Hauptbeitrag für die atp edition eingereicht 

wird, durchläuft das Peer-Review-Verfahren. Die 

letzte Entscheidung zur Veröffentlichung liegt beim 

Chefredakteur. Wird ein Beitrag veröffentlicht, kommt 

er automatisch in den Pool der atp-award-Bewerber, 

vorausgesetzt einer der Autoren ist zum Zeitpunkt 

der Veröffentlichung nicht älter als 35 Jahre. Ausgezeichnet 

wird der jüngste Autor stellvertretend für alle 

Autoren der Gruppe. Eine Jury aus Vertretern der atp- 

Fachredaktion und des -Beirats ermittelt schließlich 

den Gewinner in den jeweiligen Kategorien Hochschule 

und Industrie. Der Rechtsweg ist ausgeschlossen. 

Beiträge richten Sie bitte an: 

Prof. Dr.-Ing. Leon Urbas 

Chefredakteur 

c/o Technische Universität Dresden 

Institut für Automatisierungstechnik 

Professur für Prozessleittechnik 

01062 Dresden 

Tel. +49 351 463-39614, Fax -39681 

M +49 177 466-5201 

E-Mail: urbas@di-verlag.de 

Beachten Sie die Autorenhinweise der atp edition für 

Hauptbeiträge unter folgendem Link: 

http://www.atp-online.de 

Vom Wettbewerb ausgeschlossen sind Mitarbeiter des Deutschen Industrieverlags. Wird ein Beitrag von mehreren Autoren eingereicht, gelten die Bedingungen für den Erstautor. Der Preis 

als ideeller Wert geht in diesem Fall an die gesamte Autorengruppe, die Dotierung geht jedoch exklusiv an den jüngsten Autor. Grundlage der Teilnahme am Wettbewerb ist die Einsendung 

eines Hauptaufsatz-Manuskriptes an die atp-Chefredaktion. 

www.atp-online.de

PRAXIS 

Punktschweißen von Aluminium-Türen des 

Porsche Panamera prozesssicher automatisiert 

Georg Fischer Automotive steuert das Schweißverfahren DeltaSpot mit der Software Xplorer 

„DER WECHSEL DES 

PROZESSBANDES wird 

erst nach rund 5000 

Punkten erforderlich, 

das heißt, wir schweißen 

ohne Unterbrechung 

rund 300 Porsche- 

Panamera-Türen“, 

erläutert Gießerei- 

Fachmann Alois Edtbauer. 

AUF DEN ZIRKA 3 MM DICKEN RAHMEN der Fahrzeugtüren für 

den Porsche Panamera aus Aluminium-Druckguss ist ein 2 mm 

dickes Versteifungsblech zu fügen, das gleichfalls aus einem 

Aluminium-Werkstoff besteht. 

DIE VORRICHTUNG zum exakten Positionieren der Gussstege 

entwickelten Experten von Georg Fischer in Kooperation mit ABB. 

DIE ANLAGE ZUM 

WIDERSTANDS- 

PUNKTSCHWEISSEN 

mit DeltaSpot läuft 

in Altenmarkt seit dem 

Start der Serienproduktion 

im Jahre 

2008 prozesssicher. 

Bilder: Fronius 

Widerstandspunktschweißen ist das Fügeverfahren 

mit der längsten automatisierungstechnischen Tradition. 

Sind jedoch Aluminiumteile zu punkten, ist dies 

mit dem konventionellen Widerstands-Punktschweißen 

nur sehr eingeschränkt realisierbar. Experten des Automobil-Zulieferers 

Georg Fischer Automotive (GF) haben 

gemeinsam mit denen des Schweißsystempartners Fronius 

eine prozessfähige Automationslösung entwickelt. 

Sie wird am österreichischen Standort Altenmarkt in der 

Fertigung von Rahmen der Türen für den Porsche 

Panamera genutzt. Zum Einsatz kommen die Automatisierungssoftware 

Xplorer und das Widerstands-Punktschweißverfahren 

DeltaSpot. 

Das Gießen von Metall, zum Beispiel Aluminium- und 

Magnesium-Druckgießen, bildet bei Georg Fischer eine 

Kernkompetenz. Alois Edtbauer, der gelernte Werkzeugmacher, 

Gießerei-Fachmann und jetzige Facheinkäufer 

für Gießereiausstattung und -material, beschreibt den 

Aufgabenbereich des Werks mit rund 600 Mitarbeitern: 

„Hier an unserem österreichischen Standort Altenmarkt 

fertigen wir Strukturbauteile wie Federbein-Aufnahmen 

und Türrahmen.“ So ist auf den rund 3 mm dicken Rahmen 

von vier Fahrzeugtüren aus Aluminium-Druckguss 

für den Porsche Panamera ein 2 mm dickes Versteifungsblech 

zu fügen, das gleichfalls aus einem Aluminium- 

Werkstoff besteht. 

VERSCHIEDENE FÜGEVERFAHREN IM VERGLEICH 

Um die fertigungstechnischen Optionen zu erkunden, 

untersuchten die Fachleute mehrere Fügeverfahren auf 

ihre Eignung und ihre Wirtschaftlichkeit – darunter das 

konventionelle Widerstandspunktschweißen, das Rührreibschweißen, 

das Clinchen, das Stanznieten, einen Klebeprozess 

sowie DeltaSpot, ein von Fronius entwickeltes, 

spezielles Widerstands-Punktschweißverfahren. 

Vier verschiedene Fahrzeugtüren eines Satzes sind per 

Punktschweißverbindung mit der Innen-Versteifung zu 

versehen. Die Teile aus Aluminium-Druckguss überzieht 

eine Anti-Oxidationsschicht. Dafür wird in vorgelagerten 

Arbeitsgängen die bestehende Oxidschicht abgebeizt 

20 


12 / 2012

Die Referenzklasse für die 


Erfahren Sie auf höchstem inhaltlichem Niveau, 

was die Automatisierungsbranche bewegt. Alle 

Hauptbeiträge werden im Peer-Review-Verfahren 

begutachtet, um Ihnen maximale inhaltliche 

Qualität zu garantieren. 

Genießen Sie ein einzigartiges Lektüreerlebnis, 

das ausgezeichnete Layout und die exklusive 

Produktausstattung. 

MIT EINEM AUTOMATISIERTEN SYSTEM 

werden im Takt von etwa 100 Sekunden pro 

Fahrzeugtür 16 Punkte von exakt je 5 mm im 

Durchmesser geschweißt. 

und eine dünne Lage Titan-Zirkon (TiZrSiO4) aufgetragen. 

Dies verhindert das Entstehen der natürlichen Aluminiumoxidschicht. 

„Beim fertigen Teil liegt eine Hauptdichtung zwischen 

Tür und Rahmen an der zu fügenden Stelle. Hier muss 

es deshalb möglichst spritzerfrei zugehen. Der wärmebedingte 

Verzug am Werkstück muss in engen Grenzen 

bleiben, und wir müssen ihn durch nachträgliches Richten 

ausgleichen können“, erläutert Ingenieur Wolfgang 

Hintsteiner, Leiter Beschichtung, die Aufgabe. 

PROZESSBAND SICHERT KONSTANTE VERHÄLTNISSE 

Herkömmliches Widerstandspunktschweißen sei für die 

Aufgabe ungeeignet, erläutert Hintsteiner. Es verursache 

zu viele Spritzer und wegen der unkontrollierbaren, 

punktuell starken Wärmeeinbringung im angeschweißten 

Blech entstehe die gefürchtete Kurzwelligkeit, die sich 

nicht mehr korrigieren lasse. Das eigentlich für Aluminium 

und seine Legierungen prädestinierte Rührreibschweißen 

sei ausgeschieden, weil es stark von der Wand- 

Wählen Sie einfach das Bezugsangebot, 

das Ihnen zusagt! 

· Das Heft als gedrucktes, zeitlos-klassisches Fachmagazin 

· Das e-Paper als modernes, digitales Informationsmedium 

für Computer, Tablet oder Smartphone 

· Das Heft + e-Paper als clevere Abo-plus-Kombination 

ideal zum Archivieren 

Alle Bezugsangebote und Direktanforderung 

finden Sie im Online-Shop unter 

www.atp-online.de 


atp edition erscheint in: DIV Deutscher Industrieverlag GmbH, Arnulfstraße 124, 80636 München

PRAXIS 

dicke der Teile abhängig sei. Wegen der Gusstoleranzen 

hätte daher vor jedem Schweißvorgang die Dicke der zu 

verbindenden Teile ermittelt und berücksichtigt werden 

müssen. Die anderen Alternativen schieden aus prozesstechnischen 

Gründen aus und die Wahl fiel auf DeltaSpot. 

Zwischen Elektrode und Werkstück läuft bei diesem 

Verfahren ein Prozessband im Rhythmus der Punktschweißungen. 

Das Aluminium legiert auf das nach jedem 

Schweißpunktieren weiter geförderte Band statt auf die 

fixe Elektrode. Der „gebrauchte“ Abschnitt verlässt jeweils 

den Kontaktbereich. Für jeden Schweißpunkt herrschen 

somit die gleichen Bedingungen. Die Prozessbänder 

schützen damit Elektrode und Werkstück vor Verunreinigungen, 

Auflegieren oder anderen werkstückseitigen 

Einflüssen. Dies stabilisiert den Schweißprozess und erhöht 

die Elektrodenstanddauer. Sie verbessern außerdem 

die Kontaktsituation. Das Prozessband hilft, Oberflächenspritzer 

zu vermeiden und vergrößert das Prozessfenster. 

16 SCHWEISSPUNKTE IN 100 SEKUNDEN 

Nachdem sich DeltaSpot in der Fertigungspraxis seit dem 

Jahr 2008 bewährt, sehen sich Alois Edtbauer und Wolfgang 

Hintsteiner in ihrer Entscheidung bestätigt. „Wir 

haben den Prozess jetzt im Griff. Mit dem Prozessband 

erzeugen wir wiederholgenau einen gleichmäßigen Punkt 

– exakt 5 mm im Durchmesser und 16 Punktverbindungen 

in jedem Werkstück. Wir schweißen im Takt von zirka 100 

Sekunden eine dieser Türen und brauchen die Oberfläche 

hinterher nicht nachzuarbeiten“, führt Hintsteiner aus. 

„Optisch zeigt sich ein sehr sauberer Punkt. Der Wechsel 

des Prozessbandes dauert weniger als 15 Minuten und 

wird erst nach rund 5000 Punkten erforderlich, das heißt 

wir schweißen ohne Unterbrechung rund 300 Porsche- 

Panamera-Türen“, ergänzt Edtbauer. 

Nur einmal pro Band sind auch die Elektroden auszutauschen. 

Unter adäquaten Bedingungen könnten Anwender 

mit dem konventionellen Widerstands-Punktschweißen 

nur 20 Punkte setzen. Das würde praktisch 

eine Elektrodennacharbeit pro Tür bedeuten. 

Die gefügten DeltaSpot-Verbindungen bestehen die 

Zug-Scherprüfung. Eventuell entstehender geringfügiger 

Formverzug ist durch Richten leicht korrigierbar. Alois 

Edtbauer: „Das Verfahren DeltaSpot hat sich in unserer 

Anwendung dank der gelungenen Automatisierungslösung 

auch als kostengünstig erwiesen.“ Die Experten in 

Altenmarkt sehen die Perspektive positiv. „Die Anlage 

läuft prozesssicher“, freut sich Gießereifachmann Edtbauer. 

Und Ingenieur Hintsteiner erklärt: „Für Anwendungsfälle 

wie den unseren mit schweißbarem Guss, 

definierter Oberfläche, Antikorrosionsbeschichtung und 

gegebener Zugänglichkeit ist DeltaSpot erste Wahl.“ 

XPLORER VERKNÜPFT ALLE SCHWEISSSYSTEME 

Ein Schlüssel für das Automatisierungskonzept liegt in 

der Steuerung mit der Software Xplorer. Sie sorgt für den 

einwandfreien Ablauf des gesamten Prozesses inklusive 

des Erstellens der variablen Parameter. Dazu gibt der 

Anwender den Sollwert des Stromes mit einem analogen 

Spannungssignal vor. Die Funktion der Bedienoberfläche 

inklusive Visualisieren von Anlagenstatus und Parametern 

übernimmt der Xplorer. Er erleichtert per grafischer 

Visualisierung das Erstellen der Parameter und den intuitiven 

Umgang mit der Anlage just in time. Der Xplorer 

verknüpft alle Schweißsysteme am Standort, das heißt 

zum Beispiel auch die in Schweißzellen installierten 

Lichtbogenstromquellen. So können die Produktionsexperten 

jederzeit deren Daten, Ergebnisse und Dokumente 

über den Bildschirm verfolgen. 

Die Schweißmanagementsoftware Xplorer steht als 

Freeware allen Nutzern kostenfrei zur Verfügung. Ihre 

Funktionen: Sie vernetzt automatisierte Schweißsysteme 

und erzeugt einen virtuellen Leitstand. Ihre grafische 

Benutzeroberfläche und selbsterklärende Symbole erleichtern 

dem Anwender das übersichtliche Verwalten 

von beliebig vielen Schweißsystemen in seiner Produktion. 

Deren Standort und Status erkennt er auf einen 

Blick. Bewährte Einstellungen (Jobs) kann er einfach von 

einem Schweißsystem auf ein anderes kopieren, zum 

Beispiel in der Darstellung beider Systeme nebeneinander 

auf einem geteilten Bildschirm. 

NUTZER KÖNNEN SICH MOBIL EINLOGGEN 

Den Xplorer kann der User auch per Touchscreen bedienen. 

Mit der mehrplatzfähigen Software können Nutzer 

von verschiedenen PC auf die Daten zugreifen. Der Ort 

für die Datenspeicherung ist frei wählbar, beispielsweise 

ein Serverlaufwerk oder eine Harddisk. Der Xplorer ist 

WLAN-tauglich und steht in 13 Sprachen zur Verfügung. 

Wählen kann der Anwender auch zwischen vier aufeinander 

aufbauenden Xplorer-Funktionspaketen. Jedes 

Paket enthält als Basis den Xplorer sowie die mit den 

entsprechenden Schnittstellen und der aktuellen Firmware 

ausgestatteten Schweißsysteme. Hinzu kommen bei 

Paket 2 der JobExplorer und beim dritten Paket zusätzlich 

die Software zur Dokumentation. Die Funktionen des 

JobExplorer und zur Dokumentation übernimmt beim 

vierten Paket die Fernbedienung RCU 5000i. Unabhängig 

vom Funktionspaket kann der Anwender die Zugriffsrechte 

regeln. Identifiziert sich der Nutzer mit seinem 

Passwort, erhält er die ihm zustehenden Ansichts- und 

Eingriffsoptionen. Jeder Benutzer kann seine Rechte auf 

einen USB-Stick speichern und sich damit bei Bedarf 

mobil einloggen. So erschließt der Xplorer dem Schweißen 

die moderne Automatisierungswelt. 

AUTOREN 

CHRISTOPH PANGERL und MARTIN EIERSEBNER 

sind Produktexperten Widerstandsschweißen bei 

Fronius International. 

Fronius International GmbH, 

Froniusplatz 1, A-4600 Wels, 

E-Mail: eiersebner.martin@fronius.com, 

Tel. +43 7242 241 39 75, 

E-Mail: pangerl.christoph@fronius.com, 

Tel. +43 7242 241 85 17 

22 


12 / 2012

KNOWLEDGE 

for the FUTURE 

Qualified reading 

for automation 

experts 

Process Control Systems Engineering 

Process Control Systems (PCS) are distributed control systems 

(DCS) that are specialized to meet specific requirements of the 

process industries. 

The text book focuses on PCS engineering basics that are common 

to different domains of the process industries. It relates to an 

experimental research plant which serves for the exploration 

of the interaction between process modularization and process 

automation methods. This permits to capture features of highly 

specialized and integrated mono-product plants as well as 

application areas which are dominated by locally standardized 

general-purpose apparatus and multi-product schemes. While 

the text book’s theory is applicable for all PCS of different 

suppliers, the examples refer to Siemens’ control system PCS 7. 

Focusing on a single PCS enables readers to use the book in basic 

lectures on PCS engineering as well as in computer lab courses, 

allowing students to gain hands-on experience. 

Editor: L. Urbas 

1 st edition 2012, 204 pages, content in English * , hardcover 

* 

German language version coming soon 

Order now by fax: +49 201 / 8 20 02 34 or detach and send in a letter 

 

Yes, I place a firm order for the technical book. Please send me 

Company/Institution 

___ copies of Process Control Systems Engineering 

1 st edition 2012 (ISBN: 978-3-8356-3198-4) 

at the price of € 49,80 (plus postage and packing) 

First name and surname of recipient 

Street/P.O. Box, No. 

Reply / Antwort 

Vulkan-Verlag GmbH 

Versandbuchhandlung 

Postfach 10 39 62 

45039 Essen 

GERMANY 

Country, postal code, town 

Phone 

E-Mail 

Line of business 

Fax 

Date, signature 

Please note: According to German law this request may be withdrawn within 14 days after order date in writing to Vulkan Verlag GmbH, Versandbuchhandlung, Postfach 10 39 62, 45039 Essen, Germany. 

In order to accomplish your request and for communication purposes your personal data are being recorded and stored. It is approved that this data may also be used in commercial ways 

by mail, by phone, by fax, by email, none. This approval may be withdrawn at any time. 

PAPCSE2012

PRAXIS 

Energiekonzern ENI setzt erstmals in neuer 

italienischer Raffinerie auf Foundation Fieldbus 

Verteilte Leittechnik, Sicherheitstechnik und Brandschutz sind in einem System zusammengefasst 

Die Eni Slurry Technology (EST) ist ein in Italien entwickeltes 

Verfahren zur Umwandlung von Abfallstoffen 

aus dem Raffinationsprozess in Produkte mit viel 

höherer Qualität sowie in ökologische Materialien. Für 

die erste EST-Anlage in Sannazzaro dè Burgondi wurde 

eine zuverlässige Architektur gewählt, die mehrere Leitstände 

und mehr als 15 000 Signale umfasst. Eni kombiniert 

in dieser Anlage Foundation Fieldbus von Yokogawa 

mit Infrastrukturkomponenten von Pepperl+Fuchs, 

um höchste Verfügbarkeit und günstige Wartungskosten 

zu erreichen. 

Eni, eines der größten integrierten Energieunternehmen, 

ist in den Bereichen Öl und Gas, Exploration und 

Produktion, Gasleitung und Marketing, Energieerzeugung, 

Raffinerie und Vermarktung von Chemikalien und 

Dienstleistungen im Bereich Ölfelder tätig. Die EST-Anlage 

wird von Saipem, einem großen auf Öl und Gas spezialisierten 

Anlagenbauer errichtet. Es ist das bisher 

größte Projekt dieser Art in Italien. Die Bauarbeiten begannen 

im Mai 2011, der Produktionsbeginn ist für Ende 

2012 geplant. 

PROBLEMATISCHE RESTSTOFFE AUFGEWERTET 

Die Anlage in Sannazzaro wird auch für Versuche und 

Forschung bei Eni eingesetzt. Das Verfahren beruht 

auf einer Entdeckung italienischer Wissenschaftler, 

die ein sehr wichtiges Kapitel im Bereich der Öl- und 

Gasverarbeitung schreiben wird. EST ermöglicht die 

Verwertung und Aufwertung von Rohöl mit unüblichen 

Eigenschaften oder sehr schwerem Rohöl, Bitumen 

und Sumpf. 

Erstmalig setzt Eni in einer Raffinerie in Italien 

Foundation Fieldbus-Technologie (FF) ein, um die Feldinstrumentierung 

und Messtechnik mit dem Leitsystem 

(DCS) zu verbinden. Betreiber Eni und Anlagenbauer 

Saipem wählten digitale Übertragungstechnik 

bis zum Feldgerät, weil diese Status-, Alarm und Diagnosefunktion 

anlagenweit ermöglicht. Mit Yokogawa 

wurde ein starker Partner gewählt, der die Prozessdaten 

vollständig in einem System integrieren kann. Hinzu 

kommen die Diagnose für Feldgeräte und die Feldbusphysik 

selbst. 

VOLLE SYSTEMINTEGRATION 

Die verteilte Leittechnik (distributed control system, 

DCS), Sicherheitstechnik (emergency shut down, ESD) 

und der Brandschutz (F&G) sind in einem System zusammengefasst. 

Rund 15 000 E/A-Signale wurden fest verdrahtet. 

5500 Feldbusinstrumente werden über 650 Segmente 

bedient. Trotz der über mehrere Anlagenbereiche 

verteilten Installation sollte eine umfassende Integration 

sichergestellt werden. 

Alessandro Malberti, Produktmanager bei Yokogawa 

Italien, erläutert: „Die Lösung umfasst alle Systeme: DCS, 

ESD und F&G. Sie ermöglichen den direkten Informationsaustausch 

innerhalb der Architektur, wobei nur ein 

redundanter Bus verwendet wird, der alle Systeme miteinander 

verbindet. Die von Yokogawa vorgeschlagene 

Topografie beruht auf der Integration des Distributed- 

Control-System Centum VP mit dem ESD-System ProSafe 

RS und deckt alle Steuerungs- und Sicherheitsfunktionen 

ab“. Das Plant Asset Management wird mit dem 

Modul PRM realisiert. 

Das Gigabit-Kommunikationsnetz Vnet-IP erlaubt 

einen Datenaustausch zwischen Leitsystemen und der 

Bedienerstation. Durch die Integration des Systems 

MIT ZUBEHÖR UND VORVERDRAHTET IM EDELSTAHLGEHÄUSE: 

Die Feldbusverteiler „Segment Protektor“ für die Zone 2 und 

Explosionsschutzart Eigensicherheit „Ex ic“. 

ADVANCED DIAGNOSTIC 

MODULE auf dem 

kompakten Power Hub: 

acht Segmente mit 

Überwachung der 

Feldbusphysik. 

Wartungsteams erhalten 

Meldungen in Klartext 

über die Feldbusinstallation. 

Bilder: Pepperl+Fuchs 

24 


12 / 2012

erhält der Bediener homogene Daten für die Steuerung 

der Anlage. Alle Systeme sind vollständig redundant 

in den folgenden Komponenten aufgebaut: CPU, Stromversorgung, 

E/A- und Kommunikationskarten. Dies 

sorgt dafür, dass die Anlage ausgesprochen zuverlässig 

ist. Malberti ergänzt: „Beide Systeme erlaubten uns 

dank ihrer Modularität die Gestaltung der Foundation 

Fieldbus-Architektur entsprechend den Anforderungen 

der Anlage, wodurch alle Kundenwünsche erfüllt 

wurden.“ 

WARTUNG NUR NACH BEDARF UND PROAKTIV 

Die große Anzahl von über 5000 Messstellen soll intelligent 

instrumentiert werden. Die Feldgeräte übermitteln 

via Foundation Fieldbus H1 (FF) Status- und Wartungsdaten. 

Es ist vollständig in das Gesamtsystem integriert 

und kann alle Konfigurationen der Feldgeräte erfassen, 

die mit dem FF-Segment verbunden sind. 

„Wir fühlen uns verpflichtet, über einen langen Zeitraum 

eine ordnungsgemäße Funktion der FF-Segmente 

zu garantieren, und das hat den Ausschlag für die 

Lösung von Pepperl+Fuchs gegeben“, so der Produktmanager 

von Yokogawa. „Das von Pepperl+Fuchs hergestellte 

Advanced Diagnostic Module (ADM) ermöglicht 

uns eine kontinuierliche Überwachung sogar der 

Installationstechnik integriert im Asset-Management- 

System.“ 

Das ADM erlaubt die Prüfung des Physical Layers, und 

überwacht kontinuierlich Messwerte der Versorgungsspannung 

sowie Erdfehler oder Störpegel im Netzwerk. 

Die Kontrolle all dieser Parameter wird unterstützt 

durch ein Expertensystem, das die hohe Zahl von Messungen 

in Meldungen mit Klartext übersetzt. Verringert 

sich beispielsweise der Signalpegel aller Feldgeräte 

schlagartig, liegt das daran, das ein Terminator häufig 

ungewollt zugeschaltet wurde. Das ADM lässt den Wartungsfachmann 

in diesem Fall nicht mit vielen Meldungen 

über falsche Signalpegel allein. Das Expertensystem 

interpretiert und meldet in verständlichen Worten und 

bietet einen Lösungsvorschlag an: „Termination des 

Netzwerkes überprüfen.“ Durch rechtzeitige Wartung 

kann die volle Funktionsfähigkeit des Feldbus-Segments 

dauerhaft sichergestellt werden. Auf diese Weise werden 

Wartungsarbeiten nicht mehr vorbeugend, sondern wenn 

notwendig und proaktiv durchgeführt. 

SYSTEMINTEGRATION AUCH IM DETAIL 

Die Foundation-Fieldbus-Technologie erlaubt den Einsatz 

von Geräten und Instrumenten von Drittherstellern, 

die die vom FF-Konsortium geforderten Funktionsmerkmale 

besitzen. In der Anlage befinden sich 

Instrumente der Hersteller: Metso, Emerson, Vega, Biffi 

und Auma. 

Bei einem gedachten Gang entlang des Netzwerks gerät 

zunächst die neue Generation des kompakten Power Hub 

für acht Feldbussegmente in den Blick. Über einen Systemstecker 

erfolgt die Verbindung zu den Leittechnikkarten. 

Das spart Kosten bei der Installation und Überprüfung. 

Der Power Hub kann im explosionsgefährdeten 

Bereich „Zone 2“ installiert werden. 

Im Feld befinden sich Edelstahl-Verteilerboxen, in denen 

sich jeweils zwei 8-Kanal-Segment-Protektoren befinden. 

An deren Ausgänge sind Füllstand-, Temperaturund 

Drucktransmitter sowie Aktoren angeschlossen. Der 

Segment-Protektor bietet einen Kurzschlussschutz, sodass 

Arbeiten an Feldgeräten auf den Rest des in Betrieb 

befindlichen Segmentes rückwirkungsfrei bleiben. 

Über feldbusfähige, eigensichere Ventilsteuerbausteine 

werden Druckluftventile angesteuert. Sie erfassen 

neben den Ein- und Ausgangssignalen auch Losbrechund 

Laufzeiten – eine für die bedarfsorientierte Instandhaltung 

unerlässliche Information. 

Signale von Temperatursensoren und Thermoelementen 

finden den Weg in die Leittechnik über das Temperaturinterface 

(TI). Kostengünstig teilen sich jeweils bis 

zu acht Sensoren eine Feldbusadresse. Der Messwert 

liegt digital vor, und die elektrischen Leitungen zu den 

Sensoren werden ebenfalls überwacht. 

Mit leistungsstarker Feldbustechnologie erreicht Eni 

seine Ziele höchster Verfügbarkeit und hält Wartungskosten 

im Griff. Denn Instandhaltungsarbeiten an Feldgeräten 

und Installation werden nur dann durchgeführt, 

wenn es einen Wartungsbedarf gibt. Der Feldbus 

ist der digitale Highway, der die Informationsschätze 

der Anlage hebt und vorausschauenden, reibungslosen 

Betrieb ermöglicht. 

AUTOR 

ANDREAS HENNECKE 

ist Produktmarketingmanager 

im Geschäftsbereich 

Prozessautomation 

bei Pepperl+Fuchs. 

Pepperl+Fuchs GmbH, 

Lilienthalstraße 200, 

D-68307 Mannheim, 

Tel. +49 (0) 621 776 16 01, 

E-Mail: ahennecke@de.pepperl-fuchs.com 


12 / 2012 

25

www.di-verlag.de 

Die neue Adresse für 

das Wissen der Industrie: 

Deutscher 

Industrieverlag 

Ein neues Kapitel beginnt: 

Aus Oldenbourg Industrieverlag wird Deutscher Industrieverlag 

Neue Zeiten erfordern neues Denken. In einer Welt des rasanten Wandels erwarten 

Sie von Ihrem Fachverlag, dass er Sie schneller und umfassender als je zuvor mit allen 

relevanten Informationen versorgt, die Sie für Ihre berufliche Praxis benötigen. 

Wir nehmen diese Herausforderung an: Wir entwickeln uns für Sie zu einem integrierten 

Medienhaus, das neben der Zeitschriften- und Buchproduktion künftig immer stärker 

auch das Wissen des Fachs digital für alle Online-Kanäle auf bereitet. 

Unser neuer Name unterstreicht diesen Wandel. Er verbindet unsere mehr als 150-jährige 

Geschichte nahtlos mit der Zukunft. 

Was sich nicht ändert: Im Mittelpunkt stehen weiterhin Sie und das Praxiswissen 

Ihrer Branche. Ihre Fachkompetenz zu stärken – das ist für uns auch unter dem neuen 

Namen Deutscher Industrieverlag Anspruch und Verpflichtung. 

WIssEn Für DIE 

ZuKunft

HAUPTBEITRAG 

Virtualisierung im Kontext 

eines Prozessleitsystems 

IT-Einfluss auf die Architektur der Prozessautomatisierung 

Durch die Verwendung der Technologie Virtualisierung im Kontext eines Prozessleitsystems 

(PLS) resultiert ein gewisser Nutzen. Demgegenüber stehen Herausforderungen, die, 

wie der Nutzen, in diesem Beitrag beschrieben werden Der Nutzen und die Herausforderungen 

sind unabhängig von einer herstellerspezifischen Lösung eines PLS in virtueller 

Umgebung. Sie wurden im Rahmen der Vorfeldarbeiten zur Virtualisierung von Teilen 

des Siemens-Leitsystems Simatic PCS 7 ermittelt. 

SCHLAGWÖRTER IT / PLS / Virtualisierung 

Virtualization in the context of a Distributed Control System – 

IT influence on the architecture of process automation 

On the one hand, through the use of the IT technology virtualization with regard to distributed 

control systems (DCS) results a certain benefit. On the other hand, different 

challenges have to be taken in account, which are also shown within this paper. The 

benefits and challenges are independent of a provider-specific virtualization-solution for 

DCS. They were identified at the work to virtualize parts of the Siemens DCS – Simatic 

PCS 7. The specific results achieved are also outlined in this review. 

KEYWORDS IT /DCS /virtualization 

28 


12 / 2012

STEFAN RUNDE, MARTIN SCHNEIDER, MARTIN GLASER, STEFFEN THIEME, Siemens AG 

D 

ie Laufzeit von automatisierten technischen 

Systemen in der Prozessindustrie beträgt im 

Gegensatz zur Fertigungsindustrie durchaus 

mehrere Jahrzehnte. Dies ist ein Grund, warum 

in der Prozessindustrie mehr Zeit benötigt 

wird, bis technische Innovationen in den entsprechenden 

Komponenten (zum Beispiel Feldgeräte) und Systemen 

(beispielsweise Prozessleitsystem) Einzug halten. 

Maßgeblicher Treiber für technische Neuerungen ist 

die Notwendigkeit der Kostenreduzierung. Das gilt auch 

für Prozessleitsysteme (PLS). Seitens der Anwender wie 

BASF, Bayer und Merck werden unter anderem geringere 

Investitionskosten gewünscht sowie eine möglichst 

schnelle Inbetriebnahme und ein optimierter Betrieb 

verbunden mit geringeren Kosten. Bei PLS ist die Kernfunktionalität 

Prozessführung und -kontrolle seit ihrer 

Einführung nahezu identisch – verschiedene Aufgaben, 

wie Datenarchivierung, Prozessvisualisierung und 

Alarmmanagement, sind jedoch hinzugekommen oder 

komplexer geworden. 

Daher handelt es sich bei den Neuerungen häufig um 

Optimierungen der bereits existierenden PLS im Produktfolio 

der einzelnen Hersteller. Viele dieser Optimierungen 

gehen auf Technologien aus der IT zurück. Zu 

diesen Technologien zählen beispielsweise Feldbusse, 

Visualisierungen und Rechnersysteme. Bei letzteren stehen 

derzeit die beiden Technologien Virtualisierung und 

Cloud Computing im Fokus. In diesem Beitrag geht es um 

die Technologie Virtualisierung, die eng mit dem Cloud 

Computing verzahnt ist. 

Nachfolgend skizzieren die Autoren die für den Beitrag 

notwendigen Grundlagen der Architektur eines automatisierten 

technischen Systems in der Prozessindustrie, 

danach werden die Grundlagen der Virtualisierung beschrieben. 

Einen Schwerpunkt bildet die Darstellung der 

erzielten Ergebnisse bei der Anwendung eines nichthochverfügbaren 

PLS (nicht-H-PLS) auf Basis von Virtualisierung. 

Während dieser Use-Case bereits in der Praxis 

Einzug gehalten hat, ist die Realisierung eines hochverfügbaren 

PLS (H-PLS) unter Verwendung von Virtualisierung 

untypisch. Die Umsetzung eines H-PLS mit 

Hilfe von Mitteln der Virtualisierung adressiert eine 

nächste PLS-Generation. 

1. ARCHITEKTUR IN DER PROZESSAUTOMATISIERUNG 

In Bild 1 ist die Automatisierungs-Pyramide im Zusammenhang 

mit der Business-Pyramide dargestellt [3]. 

Die Feldebene mit ihren Sensoren und Aktoren bildet 

die Schnittstelle zwischen physikalischem Prozess und 

Automatisierungssystem. Die Aufnahme von Messgrößen 

eines physikalischen Prozesses erfolgt mit Sensoren und 

der Eingriff mittels der Stellgrößen in den physikalischen 

Prozess mit Aktoren. Die Feldgeräte werden beispielsweise 

an Remote-IOs, welche wiederum an Automatisierungsstationen 

(AS) angeschlossen sind, und/oder direkt an die 

AS auf der Steuerungsebene angebunden. In dieser Steuerungsebene 

erfolgt nach Empfang der Messgröße (Absender: 

Sensoren) die Verarbeitung – Steuerung und Regelung 

– durch die AS. Anschließend läuft die Vorgabe der aus 

der Verarbeitung hervorgegangenen Stellgrößen (Adressaten: 

Aktoren). Die einzelnen AS sind eingebettet in ein 

anlagenbezogenes PLS auf der Betriebsführungsebene. Im 

Fokus dieses Beitrags steht die Betriebsführungsebene der 

Automatisierungs-Pyramide mit dem PLS. 

Die für die Ausführung der PLS-Kernfunktionalität 

–Prozessführung und -kontrolle – notwendigen Informationen 

auf dieser Ebene werden durch die prozessnahen 

Komponenten auf der Feld- und Steuerungsebene bereitgestellt. 

Zu diesen Komponenten zählen beispielsweise 

die Sensoren, Aktoren, Remote-IOs, sowie Automatisierungsstationen 

(AS) und Bedien-Stationen (OS) bestehend 

aus der entsprechenden Hard- und Software [13]. 

Weiterhin verdeutlicht Bild 1 die Verbreitung der x86- 

Technologie von der Ebene des Personalmanagements 

(Business-Pyramide) bis in die Betriebsführungsebene 

(Automatisierungs-Pyramide). x86 ist die Abkürzung einer 

Mikroprozessor-Architektur und der damit verbundenen 

Befehlssätze. Ursprünglich entwickelt von Intel, finden die 

Befehlssätze (mit Erweiterungen) beispielsweise Anwendung 

in den Prozessoren AMD Opteron, VIA C7 und Intel 


12 / 2012 

29

HAUPTBEITRAG 

Core i7. Bei genauerer Betrachtung hat die x86-Technologie 

zudem bereits in der Steuerungsebene Einzug gehalten. 

Beispiel: AS ausgeführt als Soft-SPS auf Basis der x86-Technolgie. 

Die bestehenden Virtualisierungslösungen für Clients 

und Server fußen mehrheitlich ebenso auf der x86- 

Technologie und sind im Kontext der Ebenen der Business- 

Pyramide bis hin zur Betriebsführungsebene der Automatisierungs-Pyramide 

bereits Stand der Technik. 

2. GRUNDLAGEN DER VIRTUALISIERUNG 

2.1 Einführung 

Die Technologie Virtualisierung umfasst Methoden, die es 

erlauben, Ressourcen wie CPU-Leistung und Speicherplatz 

effizient zu verwenden und somit Kosten zu sparen. Virtualisierung 

ist heute in der IT etabliert und hat dort ihren 

Nutzen unter Beweis gestellt. Die überwiegende Zahl der 

Rechenzentren von Unternehmen nutzen diese Technologie 

zur Konsolidierung der Ressourcen. Weiterhin ist die 

Virtualisierung ein stark expandierender Markt, wie Gartner 

festhält: „The […] virtualization software market will 

grow at a compound annual rate of 46% from 2008 through 

2013.“ Es ist daher naheliegend, dass Firmen mit großen 

IT-Abteilungen, ausgehend von den IT-Applikationen, die 

Technologie Virtualisierung perspektivisch in ihren Rechenzentren 

dazu einsetzen, ebenfalls Teile der Automatisierungstechnik 

in virtueller Umgebung zu realisieren. 

2.2 Ansätze 

Bei einem konventionellen Rechnersystem (Server, Client) 

bestehend aus Hardware (zum Beispiel Prozessoren, 

Speicher, Netzwerkkomponenten) und Software (Betriebssystem, 

Applikationen) ist das Betriebssystem direkt 

auf der Hardware installiert. Das Betriebssystem 

bildet die Schnittstelle zwischen der Hardware und den 

Applikationen (beispielsweise Tabellenkalkulation). 

Bei der Virtualisierung [1] werden das Betriebssystem 

und alle darauf ablaufenden Applikationen eines Rechners 

von der Hardware entkoppelt und in einer virtuellen 

Maschine (VM) zusammengefasst. Zwischen der Hardware 

und dem Betriebssystem beziehungsweise den Betriebssystemen 

befindet sich ein weiteres, schlankes Minibetriebssystem, 

welches als Hypervisor bezeichnet 

wird. Durch den Hypervisor wird es möglich, mehrere 

VM – zum Beispiel mit unterschiedlichen Betriebssystemen 

wie Microsoft Windows und Linux – parallel auf 

einer Hardware zu betreiben. Ein Rechner mit einer Hardware 

kann somit wie eine Vielzahl von Rechnern agieren. 

Bild 2 zeigt die drei grundsätzlichen Virtualisierungsansätze 

mit Hypervisor Typ 1, Hypervisor Typ 1/Paravirtualization 

und Hypervisor Typ 2 im Vergleich zu 

einem konventionellen System. Der Virtualisierungsansatz 

mit Hypervisor Typ 1 wird auch als Stand Alone 

Approach, Bare host, Bare Metal Hypervisor oder Native 

Host bezeichnet, der Virtualisierungsansatz Hypervisor 

Typ 2 als Host, Hosted Virtualization, Hosted Hypervisor 

oder Host-Guest Approach. 

Beim Virtualisierungsansatz mit Hypervisor Typ 1 

läuft dieser direkt auf der Hardware, weshalb sie auch 

als Hardwarevirtualisierung bezeichnet wird. Der Hypervisor 

ist vollständig unabhängig von weiterer Software 

und hat direkten Zugriff auf die Ressourcen der 

Hardware. Auf dem Hypervisor sind die VM mit verschiedenen 

Betriebssystemen lauffähig und darin wiederum 

die Applikationen, wie es beim Virtualisierungsansatz 

mit Hypervisor Typ 1/Paravirtualization ebenfalls der 

Fall ist. Diese Variante des Virtualisierungsansatzes mit 

Hypervisor Typ 1/Paravirtualization ist jedoch nicht vollständig 

unabhängig von weiterer Software, sondern wird 

mit Hilfe der Parent-Virtual-Machine konfiguriert. Beim 

Virtualisierungsansatz mit Hypervisor Typ 2 läuft dieser 

auf Basis eines Host-Betriebssystems wie Microsoft Windows 

oder Linux. Auf dem Hypervisor wiederum sind 

die verschiedenen Gast-Betriebssysteme lauffähig, und 

basierend darauf, die verschiedenen Applikationen. 

Ein Nachteil der Virtualisierungslösung mit Hypervisor 

Typ 1 ist, dass die Rechner-Hardware für den Hypervisor 

Typ 1 kompatibel und vom Hersteller der Virtualisierungslösung 

zertifiziert sein muss. Beim Ansatz mit Hypervisor 

Typ 2 lässt sich jegliche vom Host-Betriebssystem unterstützte 

Hardware verwenden. Vorteile der Lösungen mit 

Hypervisor Typ 1 und Hypervisor Typ 1/Paravirtualization 

sind jedoch die Effizienz und die Performance aufgrund 

des direkten Zugriffs auf die Hardware im Gegensatz zum 

Ansatz mit Hypervisor Typ 2. 

2.3 Virtualisierungslösungen 

Die Firmen Citrix, Microsoft und VMware sind die derzeit 

bedeutendsten Hersteller von Virtualisierungslösungen. 

Die beiden Produkte XenServer und Hyper-V der 

Firmen Citrix beziehungsweise Microsoft basieren auf 

dem Virtualisierungsansatz Hypervisor Typ 1/Paravirtualisierung. 

Neben den ohnehin notwendigen Lizenzen 

für die Gast-Betriebssysteme ist eine zusätzliche Lizenz 

für das zu installierende Host-Betriebssystem in der 

Parent-Virtual-Machine zu erwerben. Es ist jedoch aus- 

Personalmanagement 

Finanzmanagement 

Materialwirtschaft 

und Controlling 

Produktionsplanung 

und -steuerung 

Produktionsführungsebene 

Betriebsführungsebene 

(SCADA / Leitsystem 

Steuerungsebene 

Feldebene 

Software 

SAP – HR 

SAP – FI 

SAP – CO 

SAP – MM 

SAP – PP 

WinCC PCS 7 

BILD 1: Automatisierungs-Pyramide 

im Gesamtkontext 

Hardware 

x86-basierende Technologien 

30 


12 / 2012

eichend, dass die verwendete Hardware vom Host-Betriebssystem 

unterstützt und zertifiziert sein muss. Microsoft 

stellt explizit Anforderungen an die Hardware, 

wie beispielsweise, dass der verwendete 64-Bit-Prozessor 

Virtualisierungstechnik unterstützen muss. VMware 

unterstützt zudem die 32-Bit-Technik. Von Nachteil ist 

weiterhin, dass die Gast-Betriebssysteme modifiziert 

werden müssen (zum Beispiel Austausch der Treiber). 

Bei dem Produkt ESXi von VMware handelt es sich um 

eine Lösung basierend auf dem Ansatz mit Hypervisor Typ 

1. Damit die verwendete Hardware von diesen Produkten 

unterstützt wird, ist diese von der Firma VMware zu zertifizieren. 

Ein Vorteil dieser Lösungen ist, dass, anders als 

beim Hypervisor Typ 1/Paravirtualization, kein zusätzlicher 

Verwaltungsbedarf (unter anderem Konfiguration, 

Parametrierung) resultierend aus dem Gast-Betriebssystem 

notwendig ist. Die Lösungen von VMware sind etabliert. Sie 

werden heute typischerweise in den Rechenzentren der IT- 

Abteilungen von Unternehmen zur Server-Virtualisierung 

eingesetzt und nehmen nach eigenen Angaben des Unternehmens 

einen Gesamt-Marktanteil von mehr als 80 % ein. 

Aufgrund der etablierten Basis und der weiten Verbreitung 

– auch bei Unternehmen der Prozessindustrie – 

wurde im Rahmen der prototypischen Validierung (Realisierung) 

des Siemens-Leitsystems PCS 7 in einer virtuellen 

Umgebung zunächst die Lösung ESXi der Firma 

VMware gewählt. 

2.4 Nutzen 

Mögliche Motive für den Einsatz von Virtualisierung im 

Kontext der PLT: 

Verringerung der PLS-Investitions- und Betriebskosten 

Eine Herausforderung stellen die unterschiedlichen mittleren 

Lebenszyklen von PC-Hardware dar, auf der die Betriebssystem-Software 

sowie die PLS-Software laufen [5]. 

Die PC-Hardware besitzt im Mittel eine Lebenszeit von 

etwa 8 Jahren, das Betriebssystem von zirka 4 Jahren und 

die Versionen des PLS im Mittel von ungefähr 5 Jahren. Die 

mittleren Lebenszeiten divergieren somit im Vergleich zur 

etwa 20-jährigen Lebenszeit und Betriebsphase von Anlagen 

in der Prozessindustrie [6]. Um die Kompatibilität zwischen 

PC-Hardware und Leittechnik-Komponenten über 

die gesamte Betriebsphase sicherzustellen, werden oft bei 

der Erstellung einer Anlage die entsprechend notwendige 

Anzahl an PC-Hardware und Betriebssystem-Lizenzen für 

die gesamte Betriebsphase beschafft – verbunden mit zusätzlichen 

Investitionskosten. Virtualisierung ermöglicht 

es, die Lebenszyklen voneinander zu entkoppeln und somit 

diese höheren Investitionen obsolet werden zu lassen. 

Virtualisierung kann somit zu einem erhöhten Investitionsschutz 

beitragen [6], vorwiegend für die Unternehmen 

der Prozessindustrie, die eigene IT-Abteilungen mit 

Rechenzentren haben und bereits Virtualisierungs-Technologien 

verwenden. Diese Unternehmen können die 

PLT in die bestehende IT-Infrastruktur integrieren. Es 

sind somit Kosteneinsparungen möglich, zum Beispiel 

durch den Wegfall von ansonsten notwendigem Platzbedarf 

im Produktionsbereich für die Industrie-Server, 

durch Minimierung des Aufwandes für Heizen/Lüften/ 

Kühlen sowie durch zentralisierte Wartung. 

Erhöhung der Effizienz des PLS 

Aufgrund zentraler Recheneinheiten lässt sich die Effizienz 

des PLS steigern – Verbesserung der Skalierbarkeit 

und Verfügbarkeit sowie Steigerung der Produktivität. 

Eine verbesserte Skalierung und Verfügbarkeit wird erreicht, 

da beispielweise die bestehenden Ressourcen (wie 

Prozessoren, Speicher) im Rechenzentrum eines Unternehmens 

gezielt ausgelastet werden. Der Wechsel der 

Hardware und gegebenenfalls die Installation beziehungsweise 

Konfiguration des Betriebssystems aus Sicht 

der Automatisierung entfällt, womit Stillstandszeiten 

reduziert werden. Die Produktivität kann ebenfalls erhöht 

werden, da für das Aufsetzen einer neuen VM bestehende 

Templates verwendet werden können. 

Virtuelle Maschine (VM) 

Applikatiokatiokatiokatiokation 

Appli- 

Appli- 

Appli- 

Appli- 

Applikation 

… 

… 

Applikation 

Applikation 

…… 

Applikation 

… 

Applikatiokation 

Appli- 

Applikation 

…… 

… 

Applikation 

Guest-Betriebssystem 

Guest-Betriebssystem 

… 

… 

Applikation 

Applikation 

Applikatiokation 

Appli- 

Applikation 

Applikation 

Betriebssystem 


… 

Gast-Betriebssystem 


Hypervisor 

Hypervisor 

… 

Applikation 

Hypervisor 

Appli-kation 

Hypervisor 

Host- 

Host- 



Host- 

Host- 





… 

Hypervisor 

Hypervisor 

… 

… 

Hardware 

Hardware 

Hardware 

Hardware 

Hardware 

Hardware 

Hardware 

Hardware 

Konventionelles System 

BILD 2: Virtualisierungsansätze 

Virtualisierungsansatz: 

Hypervisor Typ 1 


Hypervisor Typ 1/ 

Paravirtualization 


Hypervisor Typ 2 


12 / 2012 

31

HAUPTBEITRAG 

Einsatz in bestehenden Anlagen 

Eine Erweiterung und Modernisierung der PA erfordert 

häufig einen nur schwer realisierbaren Ausbau der bestehenden 

Hardware. Daher ist die Hemmschwelle zur 

Erweiterung und Modernisierung von vorhandenen PLS 

hoch. Ausgehend von dem im Beitrag vorgestellten Ansatz, 

das PLS in virtueller Umgebung zu betreiben, wird 

die Hemmschwelle hinsichtlich einer Erweiterung und 

Modernisierung gesenkt. Es ist einfacher möglich, die 

verschiedenen Teile wie Engineering Station(s), Operator 

Station(s) und Maintenance Station(s) im Kontext einer 

VM zu modernisieren und zu erweitern. 

Hochverfügbarkeit auf Basis verbreiteter Technologien 

Sobald ein hochverfügbares PLS notwendig ist, kommen 

heutzutage proprietäre, firmenspezifische Redudanzlösungen 

für die jeweiligen PLS-Server zum Einsatz. In 

IT-Rechenzentren wird Virtualisierung häufig zur Erreichung 

von Hochverfügbarkeit eingestzt. Die Verwendung 

von der in der IT weit verbreiteten Virtualisierung zur 

Realisierung von PLS-Server-Redundanz ermöglicht gegebenenfalls 

die Fokussierung auf weitere zukünftige 

PLS-Herausforderungen (zum Beispiel Security [13]). 

Weiterhin könnte eine solche allgemeine Hochverfügbarkeitslösung 

dazu beitragen, die Investitionskosten bei 

einem zukünftigen PLS für den Anwender zu senken. 

3. TESTSYSTEM 

Die Erprobung von Simatic PCS 7 in virtueller Umgebung 

– als nicht-H-PLS und H-PLS – erfolgte exemplarisch 

im Smart-Automation-Center in Karlsruhe (siehe 

Bild 3). 

Beim Smart-Automation-Center handelt es sich um 

ein automatisiertes technisches System, um neue Technologien 

im Rahmen von Software- und Hardware-Prototypen 

in praxisnaher Umgebung zu erproben. Dieses 

automatisierte technische System besteht aus einem 

kontinuierlichen Teil und einem diskreten Teil für das 

Mischen beziehungsweise Abfüllen von Farbe. Die Basis- 

Ausrüstung des PLS sieht wie folgt aus: 

PLS-Komponenten: Eine Engineering-Station (ES), 

ein redundantes Operator-Station-Serverpaar (OS- 

Server), drei Operator-Station-Clients (OS-Client) 

und eine Maintenance Station (MS) – alle Komponenten 

haben als Basis-Betriebssystem Microsoft 

Windows 7 

Simatic PCS 7: PCS 7 V8.0 

Im folgenden Abschnitt ist Simatic PCS 7 in virtueller 

Umgebung als nicht-H-PLS skizziert – technische Details 

siehe [10]. 

4. SIMATIC PCS 7 IN VIRTUELLER UMGEBUNG 

ALS NICHT-H-PLS 

4.1 Realisierung 

Die Realisierung der virtuellen Umgebung des nicht H- 

Systems erfolgte auf einem Fujitsu Server TX300 S6 (1 

Intel Xeon X5660 mit 6 Kernen à 2,8 GHz, 32 GB RAM). 

Auf dieser Hardware wurde die virtuelle Umgebung bestehend 

aus VMware vSphere V5.0, VMware vSphere 

Client V5.0 und VMware ESXi 5.0 installiert. Server- und 

Client-Funktionalität der PLS-Komponenten sind als VM 

auf Basis von VMware ESXi 5.0 realisiert worden. 

Bild 4 zeigt Komponenten des Leitsystems PCS 7, welche 

mit VMware/ESXi in einer virtuellen Umgebung im Smart- 

Automation-Center realisiert wurden – diskreter Teil 

(inkl. MES) und kontinuierlicher Teil. Detaillierte technische 

Informationen finden sich unter [11], [12], [14], [15]. 

4.2 Ergebnisse 

Die Erprobung eines nicht-H-PLS in virtueller Umgebung 

ergab, dass die Neuinstallation eines solchen PLS und 

die Portierung einer bestehenden Konfiguration in die 

virtuelle Umgebung von VMware ESXi mit einem erhöhten 

Aufwand möglich ist. Dieser Mehraufwand resultierte 

im Wesentlichen aus dem notwendigerweise zu erarbeitenden 

Wissen bezüglich der Virtualisierung. Auf 

Basis der Vorfeldarbeiten wurden weitere ausführliche 

Tests in verschiedenen Anlagen durchgeführt. Die Ergebnisse 

führten dazu, dass Komponenten von Simatic 

PCS 7 für die Virtualisierung mit VMware unter bestimmten 

Bedingungen freigegeben wurden. Weitere 

Details sind in [10], [12] aufgeführt. 

5. SIMATIC PCS 7 IN VIRTUELLER UMGEBUNG ALS H-PLS 

5.1 Realisierung 

Für die Realisierung eines H-PLS in virtueller Umgebung 

gibt es zwei Varianten. 

1 | Kombination bestehender H-Lösungen mit den 

Technologien der Virtualisierung 

2 | Vollständige H-PLS-Lösung unter Verwendung von 

Virtualisierungsmethoden 

Zur Realisierung der Variante 1 reicht es aus, dass industriespezifische 

Hardware eingebunden werden kann – diese 

Variante und der damit verbundene Nutzen und die 

Herausforderungen werden daher im Beitrag nicht weiter 

verfolgt. Im Fokus der Betrachtungen steht die intuitiv 

naheliegende Variante 2. Es wurden unterschiedliche 

Konfigurationen im Kontext der Hochverfügbarkeit und 

Virtualisierung getestet. Die Autoren behandeln ein redundantes 

OS-Serverpaar, welches mit Hilfe der Virtualisierung 

redundant ausgeführt wird. Bild 5 zeigt die Grundlagen 

zu entsprechend benötigten VMware-Produkten. 

Die beiden Funktionen als Bestandteil des Produktes 

VMware vSphere für die PLS-H-Lösung im Kontext einer 

virtuellen Umgebung lauten VMware High Availability 

(VMware HA) und VMware Fault Tolerance (VMware 

FT). Die Funktionen verwenden wiederum VMware- 

Basistechnologien. Zu diesen Technologien zählt unter 

anderem die VMware FT Lockstep Technologie. Diese 

Technologie ist hinsichtlich der hochverfügbaren Lösung 

im Kontext einer virtuellen Umgebung von besonderer 

Bedeutung. Weitere Basistechnologien sind beispielswei- 

32 


12 / 2012

se vSphere vMotion, vSphere Distributed Resource Scheduler 

(DRS) und vSphere Distributed Switch (VDS). 

Bei VMware HA handelt es sich um das Cold-Standby 

– das heißt die sekundäre VM wird gestartet, sobald die 

primäre VM ausfällt. Für diskontinuierliche Batch-Prozesse 

im Kontext der Prozessindustrie kann diese VMware-Technologie 

somit bereits ausreichend sein – unter 

Verwendung entsprechender Werkzeuge, die den Batch- 

Prozess fortsetzen. Für kontinuierliche Prozesse hingegen 

ist dieses Produkt ungenügend. Nach einer ersten Prüfung 

eignet sich dafür das Produkt VMware FT. Es verspricht 

den Hot-Standby und somit den lückenlosen Serverbetrieb. 

Auf Basis der VMware FT Lockstep Technologie 

sowie VMware HA einschließend sieht VMware FT vor, 

dass die sekundäre VM im Standby-Modus läuft und nicht 

erst hochfahren muss nach Ausfall der primären VM. 

Die VMware FT Lockstep Technologie unterscheidet 

zwischen einer primären VM und einer sekundären VM. 

Die primäre VM empfängt beziehungsweise versendet 

Ereignisse an unterlagerte Hard- und Softwarekomponenten. 

Parallel werden alle Ereignisse mit der sekundären 

VM abgeglichen – sowohl primäre als auch sekundäre 

VM führen die gleichen Algorithmen aus und 

die gleichen Eingabe/Ausgabe-Operationen durch. Jedoch 

nehmen im Normalbetrieb lediglich Ausgabe- 

Operationen der primären VM Einfluss auf die unterlagerte 

Hard- und Software. Alle Ausgabe-Operationen 

der sekundären VM werden unterdrückt. Die unterlagerte 

Hard- und Software sieht lediglich eine VM mit 

entsprechender IP- und MAC-Adresse. 

Voraussetzung für VMware HA ist, dass alle ESXi- 

Hosts in einem HA-Cluster gekapselt sind. Die folgenden 

Fälle führen zum Umschalten von der primären VM im 

Master-Host auf die sekundäre VM in einem slave-Host: 

a | Auf ein vom Master-Host gesendetes 1-Hz-(Clock-) 

Signal wird vom Slave-Host nicht geantwortet 

b | Auf Internet Control Message Protocol (ICMP) Signale 

wird vom Slave-Host nicht geantwortet 

c | Auf ein vom gemeinsamen Speicher (Shared Storage) 

gesendetes Clock-Signal wird nicht geantwortet 

Unter Berücksichtigung zu erfüllender Anforderungen 

bezüglich eines H-PLS (zum Beispiel hinsichtlich Speicher, 

Prozessorleistung und Verfügbarkeit) sowie auf 

Basis der PLS-Grundausrüstung wurde die folgende 

Konfiguration umgesetzt: 

BILD 4: Siemens-Leitsystem PCS 7 in virtueller Umgebung 

BILD 5: VMware Server-Redundanzkonzept [9] 

ES OS-Client OS-Client OS-Client MS 

PLS-Komponenten in realer Umgebung 

1x ES, 3x OS-Client, 1x MS 

PLS-Komponenten in virtueller Umgebung 

1x redundanter OS-Server – verteilt auf zwei ESXi- 

Servern 

Die Realisierung des im Fokus stehenden redundanten OS- 

Serverpaares hinsichtlich eines H-PLS auf Basis von VMware 

Lockstep, VMware HA sowie VMware FT zeigt Bild 6. 

Die H-PLS in virtueller Umgebung wird gebildet von 

zwei ESXi-Servern, die sich in einem HP Blade System 

C7000 Enclosure G2 befinden. Die primäre VM läuft auf 

dem ersten ESXi-Server, die sekundäre VM auf dem 

zweiten ESXi-Server. Die Parametrierung der VMs ori- 

ESXI-Server 1 

Primär 

Redundantes OS-Serverpaar 

FT Protokollierung 

Bestätigung 

Virtuelle Maschinen (VM) 

ESXI-Server 2 

Sekundär 

BILD 6: 

Umsetzung eines 

redundanten 

Virtualisierungskonzeptes 


12 / 2012 

33

HAUPTBEITRAG 

entiert sich an dem empfohlenen PC-Hardwareausbau 

für SimaticPCS 7 V8.0. 

Weiterhin wurden in den VM getrennte virtuelle Netzwerkkarten 

für Anlagen- und Terminalbus projektiert. 

Innerhalb eines ESXi-Servers werden diese virtuellen 

Netzwerkkarten in einem virtuellen Switch über Virtual-Machine-Port-Groups 

und VLANs getrennt. Nach außen 

erfolgte die Kommunikation zwischen den beteiligten 

Komponenten über ein VC-Modul (Virtual-Connect- 

Modul) an einem physikalischen Kabel mit einem zugeordneten 

VLAN. 

5.2 Ergebnisse 

Die Tests für PCS 7 V8.0 Update 1 in einer virtuellen 

Betriebsumgebung wurden in der beschriebenen Konfiguration 

erfolgreich beendet. Es wurden keine Probleme 

festgestellt. Ansonsten deckten sich die Erkenntnisse 

bei dieser Erprobung eines H-PLS auf Basis von 

Virtualisierung mit denen bei der Realisierung eines 

nicht-H-PLS. Positiv zu beurteilen ist, dass alle Bedienstationen 

über genau eine geöffnete Remote Desktop- 

Verbindung bedienbar sind. 

REFERENZEN 

[1] Thorns, F.: Das Virtualisierungs-Buch, C & I Computerund 

Literaturverlag, Böblingen, 2008 

[2] Gartner: Virtualization Market in EMEA Driven by Cost 

Considerations, Resource Use and Management 

Benefits, “Dataquest Insight”, 13. Februar 2009 

[3] Abel, D.; Epple, U.; Spohr, G.-U.: Integration von 

Advanced Control in der Prozess-industrie – Rapid 

Control Prototyping, Wiley-VCH, Weinheim, 2008 

[4] Goldberg, R.P.: Architectural Principles for Virtual 

Computer Systems. Harvard University, 1973 

[5] ZVEI Fachverband Automation: Life-Cycle-Management 

für Produkte und Systeme der Automation, 2010 

[6] NE 121: Qualitätssicherung leittechnischer Systeme. 

Namur, 2008 

[7] Keith A. und Ole A.: A Comparison of Software and 

Hardware Techniques for x86 Virtualization. VMware, 2006 

[8] Callow, B. und Turner, R.: Hidden Costs of Virtualization. 

http://www.acronis.com/resources/wp/2.html 

(23.12.2010) 

[9] Waldeck, B.: Netzangriffen keine Chance. In: Computer 

+ Automation 2010(12), S. 54, 2010 

[10] Runde, S., Schneider, M., Glaser, M., Drinjakovic, D.: 

Automatisierungstechnische Architektur in der 

Prozessindustrie mit Leitsystem in virtueller 

Umgebung. In: Tagungsband Automation 2011, S. 

203-208. VDI, 2011 

[11] Siemens AG: SIMATIC PCS 7 OS Software Client ab V7.1 

+ SP2 für den Einsatz in virtuellen Betriebsumgebungen 

freigegeben. http://support.automation.siemens. 

com/WW/llisapi.dll?func=cslib.csinfo&lang=de&objid= 

51401737&caller=nl (09.08.2012) 

[12] Siemens AG: OS Client, BATCH Client und Route 

Control Client mit SIMATIC PCS 7 V8.0+Update 1 für 

virtuelle Betriebsumgebungen freigegeben. http:// 

support.automation.siemens.com/WW/view/ 

de/61052407 [23.11.2012] 

[13] Palmin, A., Runde, S., Kobes, P.: Security in der 

Prozessautomatisierung – Trends und Entwicklungen 

aus dem Fokus der Vorfeldentwicklung. In: Tagungsband 

Automation 2012, S. 177 182. VDI, 2012 

[14] Siemens AG: WinCC/Server-Virtualiserung. 

http://support.automation.siemens.com/WW/view/ 

de/49368181 (24.08.2012) 

[15] Siemens AG: PCS 7 Virtualisierung. 

http://support.automation.siemens.com/WW/view/ 

de/51975791 (24.08.2012) 

6. HERAUSFORDERUNGEN UND NUTZEN 

DER PLS-VIRTUALISIERUNG 

Nachfolgend sind ausgewählte technische und nichttechnische 

Herausforderungen im Kontext PLS und Virtualisierung 

aufgeführt – die erwähnten Punkte sind 

unabhängig von einer spezifischen Virtualisierungslösung 

(zum Beispiel VMware, Citrix, Microsoft) [10]. 

6.1 Technische Herausforderungen 

Einbindung industriespezifischer Hardware 

Die jeweils gewählte Virtualisierungslösung, basierend 

auf Hypervisor Typ 1, Hypervisor Typ 1/Paravirtualization 

oder Hypervisor Typ 2, muss die verwendete Hardware 

unterstützen. Handelt es sich dabei um industriespezifische 

Hardware und nicht um typische Consumer- 

Hardware, so ist diese Unterstützung nicht zwangsläufig 

gegeben. 

Realisierung der Hochverfügbarkeit 

Um die Hochverfügbarkeit des automatisierten technischen 

Systems mit PLS sicherzustellen, wird häufig industriespezifische 

Hardware verwendet. Um dieser Herausforderung 

gerecht zu werden, ist somit zunächst die 

Einbindung industriespezifischer Hardware zu realisieren. 

Weiterhin sind die bisher bestehenden Methoden 

und Modelle im Kontext der Hochverfügbarkeit hinsichtlich 

einer virtuellen Lösung zu realisieren. 

6.2 Nicht-technische Herausforderungen 

Kontrolle des erhöhten IT-Investitionsbedarfs 

Virtualisierung im Kontext der PLT kann nutzbringend 

sein. Wenn jedoch keine geeignete IT-Infrastruktur besteht, 

so sind nicht zu unterschätzende zusätzliche Investitionen 

(Server, Virtualisierungssoftware, zusätzliche 

Supportverträge, IT-Fachleute, und so weiter) notwendig. 

Kontrolle der IT-Betriebskosten 

Die durch Auslagerung in das Rechenzentrum gegebenenfalls 

minimierte Anzahl notwendiger Rechner, auf 

denen die einzelnen Bestandteile des PLS installiert 

sind, ist nicht linear zu den Energieeinsparungen. Ein 

Rechner beziehungsweise Server mit einer Vielzahl an 

VM benötigt mehr Energie als ein vergleichbarer Rechner 

ohne VM. 

34 


12 / 2012

Notwendigkeit von verbesserter Schulung aufgrund 

erhöhter Komplexität 

Zwei Aspekte machen eine verbesserte Ausbildung des 

Personals im Umgang mit dem PLS nötig. Zum einen die 

erhöhte Gesamtkomplexität des Systems, zum anderen 

ist das gegenwärtige Personal im Umfeld der PA normalerweise 

nicht vertraut im Umgang mit der Technologie 

Virtualisierung. Daher ist das notwendige Wissen dem 

Personal im Kontext der PA zu vermitteln. 

Abhängigkeit vom Lieferanten der Virtualisierungssoftware 

Der Einsatz der Virtualisierungs-Technologie bedeutet 

eine zusätzliche Abhängigkeit zum Hersteller einer solchen 

Software. Deshalb sind die Verantwortlichkeiten 

für diese Software und für das Gesamtsystem (zum Beispiel 

Support) festzulegen. 

Das Siemens-Leitsystem Simatic PCS 7 konnte in einer 

exemplarischen Konfiguration erfolgreich in virtueller 

Umgebung realisiert werden – als nicht-hochverfügbares 

und als hochverfügbares Prozessleitsystem. Der häufig 

angeführte Nutzen im Zusammenhang mit Virtualisierung 

konnte jedoch, im Gegensatz zu einer konventionellen 

Lösung ohne Virtualisierung, nicht vollends belegt 

werden. Der mögliche langfristige Nutzen (zum Beispiel 

Minimierung von PLS-Betriebskosten) ist über den Anlagenlebenszyklus 

zu beobachten. Der kurzfristige Nutzen 

ist projektspezifisch. Tendenziell ist ein PLS in virtueller 

Umgebung dann für ein Unternehmen von Vorteil, 

wenn bereits eine starke IT-Infrastruktur besteht – inklusive 

Erfahrungen im Umgang mit dem Thema Virtualisierung. 

Für Unternehmen ohne starke IT-Infrastruktur 

stellt eine solche Lösung eine große Herausforderung dar. 

Es bestehen neben der reinen Herausforderung hinsichtlich 

der Virtualisierungs-Umsetzung auch weitere technische 

und nicht-technische Herausforderungen. Hinsichtlich 

eines zukünftigen, hochverfügbaren PLS auf 

Basis von Virtualisierungstechnologien sind weitere 

Untersuchungen notwendig. Nur so lässt sich eine vollständige 

Vergleichbarkeit mit einem konventionellen 

System herstellen. 

FAZIT 

MANUSKRIPTEINGANG 

18.09.2012 

Im Peer-Review-Verfahren begutachtet 

AUTOREN 

Dr.-Ing. STEFAN RUNDE (geb. 1980) ist in der Vorfeldentwicklung 

des Sektors Industry der Siemens AG seit Oktober 

2010 Projektleiter für das Thema "Future DCS Architecture" 

und seit Oktober 2012 zudem Programm Manager für das 

Themenfeld "PC-based Architecture". Nach der Ausbildung 

zum Energieelektroniker, studierte er Elektro- und Informationstechnik 

an der FH Hannover und promovierte an der 

Helmut-Schmidt-Universität Hamburg. Aktuelle Schwerpunkte 

seiner Arbeit sind die Verbesserung von Engineering 

und Architekturen im Umfeld von SCADA und PLS. 

Siemens AG, I IA ATS 3 1, 

Östliche Rheinbrückenstrasse 50, 

D-76187 Karlsruhe, Tel. +49 (0) 721 595 79 77, 

E-Mail: stefan.runde@siemens.com 

Dipl.-Ing. MARTIN R. SCHNEIDER (geb. 1960) absolvierte ein 

Informatik-Studium an der Hochschule Karlsruhe und ist in 

der Vorfeldentwicklung des Sektors Industry tätig. Er ist 

Teilprojektleiter im Projekt "Future DCS Architectures" 

zuständig für das Thema Integration von IT-Trends wie z.B. 

Virtualisierung oder Cloud Computing in PLS. 

Siemens AG, I IA ATS 3 1 

Östliche Rheinbrückenstrasse 50, D-76187 Karlsruhe, 

Tel. +49 (0) 721 595 61 13, 

E-Mail: martin-rudolf.schneider@siemens.com 

Dipl.-Ing. MARTIN GLASER (geb. 1959) leitete bis September 

2012 im PCS 7 Produktmanagement die Gruppe "Software 

& Innovation" und ist seit Oktober 2012 verantwortlich 

als Projektfamilienleiter "DCS SW-Products". Er studierte 

Elektrotechnik an der TH Karlsruhe und beschäftigt 

sich seit vielen Jahren mit der Entwicklung von PLS, 

insbesondere mit dem Focus auf neue Technologien für die 

Inno vation von PLS. 

Siemens AG, I IA AS PA R&D 1 

Östliche Rheinbrückenstrasse 50, 

D-76187 Karlsruhe, Tel. +49 (0) 721 595 68 90, 

E-Mail: martin.glaser@siemens.com 

Dipl.-Ing. STEFFEN THIEME (geb. 1965) arbeitet als 

technischer Berater für Simatic PCS 7 im Bereich 

"Simatic Systems Support for Process Automation". 

Er studierte Informationstechnik an der TH Ilmenau 

und beschäftigt sich seit vielen Jahren im Rahmen mit 

PLT. Zu seinen aktuellen Aufgaben im Zusammenhang 

mit Simatic PCS 7 gehören unter anderem Simatic 

Batch, Virtualisierung und Industrial Security. 

Siemens AG, I IA AS S SUP PA 2, 

Östliche Rheinbrückenstrasse 50, D-76187 Karlsruhe, 

Tel. +49 (0) 721 595 71 37, 

E-Mail: steffen.thieme@siemens.com 


12 / 2012 

35

HAUPTBEITRAG 

Integriertes Engineering mit 

Automation Service Bus 

Paralleles Engineering mit heterogenen Werkzeugen 

Dieser Beitrag stellt einen neuen herstellerneutralen Ansatz zur Integration von Software- 

Werkzeugen vor, den Automation Service Bus. Es geht darum, wesentliche Lücken bisheriger 

herstellerneutraler Ansätze zu schließen und Vorteile, die sich bisher nur mit herstellerspezifischer 

Integration erreichen ließen, auch für die Integration heterogener Werkzeuge 

zu ermöglichen. 

SCHLAGWÖRTER Paralleles Engineering / Software-Werkzeug-Integration / 

Datenaustausch / Werkzeug unterstützte Arbeitsabläufe / 

Automation Service Bus 

Integrated engineering with the Automation Service Bus – 

Making parallel engineering with heterogeneous tools more efficient 

This contribution introduces a novel vendor-neutral approach for the integration of software 

tools, the Automation Service Bus, in order to close relevant gaps of present vendorneutral 

approaches and enable benefits, which were previously achieved only with vendorspecific 

integration, also for the integration of heterogeneous tools. 

KEYWORDS parallel engineering / software tool integration / data exchange / 

tool-supported workflows / automation service bus 

36 


12 / 2012

STEFAN BIFFL, RICHARD MORDINYI UND THOMAS MOSER, Technische Universität Wien 

Der erste Teil dieses Beitrags in atp-edition 54(5) 

hat den Bedarf an besserer Integration zwischen 

Software-Werkzeugen und deren Datenmodellen 

anhand exemplarischer Anwendungsfälle 

diskutiert. Daraus wurde der Bedarf 

für Mechanismen in Software-Werkzeugen abgeleitet 

und die Stärken und Beschränkungen von drei 

generellen Integrationsansätzen diskutiert: Behelfslösungen 

und herstellerspezifische beziehungsweise herstellerneutrale 

Ansätze. Das Ergebnis: Herstellerspezifische 

Werkzeug-Suiten decken zwar den Großteil der 

vorgestellten Anwendungsfälle ab, schränken allerdings 

typischerweise die Auswahlmöglichkeiten der 

verwendbaren Werkzeuge ein oder geben ein zu verwendendes 

Datenmodell fix vor. Herstellerneutrale Ansätze 

erlauben die freie Auswahl der Werkzeuge und 

Datenmodelle, erfordern aber oft einen erhöhten Grundaufwand 

für die Einbindung der Werkzeuge, da es keine 

offene Integrationsplattform zur Integration von 

Daten und Funktionen aus Software-Werkzeugen zur 

Unterstützung von Abläufen auf Projektebene gibt. Die 

AutomationML-Initiative [1] definiert zum Beispiel ein 

Schema für den Austausch von Topologie-, Geometrieund 

Verhaltensinformationen, stellt aber keine automatisierte 

Austauschmöglichkeit für diese Informationen 

zur Verfügung. 

Im Bereich der Wirtschaftsinformatik wurde der Architekturtrend 

umfangreicher Software-Werkzeug-Suiten 

in den 1990er Jahren etabliert und in den 2000er- 

Jahren durch offene, komponentenorientierte Systeme, 

etwa auf Basis des Enterprise Service Bus [2], abgelöst. 

Ein Beispiel für ein derartiges System ist der Automation 

Service Bus (ASB) Ansatz [3], ein Ergebnis der Forschung 

des von der Logical automation solutions und services 

GmbH betriebenen Christian-Doppler-Forschungslabors 

„Software Engineering Integration für flexible Automatisierungssysteme“ 

(CDL-Flex) an der Technischen Universität 

Wien. 

Der ASB schließt die Lücke zwischen den spezifischen 

Software-Werkzeugen der Fachexperten und den Arbeitsabläufen 

der Projektteilnehmer, die unter Verwendung 

der Daten aus mehreren Software-Werkzeugen effizient 

durchgeführt werden sollen, durch eine systematische 

und nicht-proprietäre Integration auf den Ebenen 

der (1) technischen Systeme und Funktionen, (2) der 

Datenmodelle und (3) der Beschreibung der Arbeitsabläufe. 

Die Integration der lokalen Datenmodelle (das „Engineering 

Babylon“) wird adressiert, in dem genau die 

von den Fachexperten für die Kooperation benutzten 

gemeinsamen Konzepte modelliert, auf die lokalen Repräsentationen 

der Software-Werkzeuge abgebildet und 

so für Maschinen verständlich gemacht werden. In den 

folgenden Abschnitten beschreibt der Beitrag die Kernkomponenten 

des ASB, spezifiziert den Prozess zum 

Entwerfen einer Integrationslösung und diskutiert Vorteile, 

Limitierungen und den benötigten Aufwand. 

1. DER AUTOMATION-SERVICE-BUS-ANSATZ 

Dieser Abschnitt stellt den Automation Service Bus [3] 

vor und beschreibt dessen Hauptkomponenten. Ziel des 

Einsatzes des ASB ist das Bereitstellen einer offenen 

Plattform zur Integration von heterogenen Software- 

Werkzeugen für die Entwicklung von Automatisierungssystemen. 

Im Lebenszyklus der Herstellung und Operation 

von Automatisierungssystemen lassen sich Software- 

Werkzeuge und Systeme als Software-Komponenten [4] 

betrachten, deren Beitrag zum Entwicklungsprozess 

durch eine bessere Kooperation deutlich effektiver und 

effizienter werden kann. 

Basierend auf dem in der Wirtschaftsinformatik erfolgreichen 

Enterprise Service Bus Ansatz [2] werden dafür 

die für das Engineering-Umfeld erforderlichen Verbesserungen 

wie eine herstellerneutrale Kommunikation vorgenommen, 

um das „Engineering-Polynesien“ der Werkzeuginseln 

systematisch zu integrieren (siehe Bild 1). 

Software-Werkzeuge sind mit dem ASB über Konnektoren 

verbunden und stellen an den Schnittstellen Software- 

Services [5] bereit, die den Datenaustausch und den Aufruf 

von Werkzeugfunktionen als Basis für die Automatisierung 

von Arbeitsabläufen im Engineering erlauben. 


12 / 2012 

37

HAUPTBEITRAG 

Bild 1 zeigt eine vereinfachte Sicht auf eine konkrete 

Lösungskonfiguration mit dem ASB, die folgende Elemente 

beinhaltet. (1) Spezifische Werkzeuge für Fachexperten 

aus dem Anlagen-Engineering, etwa zur Planung von 

Rohrleitungs- und Instrumentenfließbildern, Funktionsplänen, 

Elektroplänen, Systemkonfigurationen und SPS- 

Kontrollprogrammen. (2) Den Service Bus mit Konnektoren 

zur technischen Verbindung der Software-Systeme 

miteinander. (3) Die Engineering-Datenbank und die 

Engineering-Knowledge-Base, um gemeinsam verwendete 

Daten auf Projektebene versioniert zu halten und zur 

Übersetzung von gemeinsamen Konzepten auf Projektebene, 

die in den Werkzeugen (in Bezug auf Begriffe oder 

Datenstrukturen) unterschiedlich repräsentiert sind. (4) 

Anwendungen auf Projektebene, die auf die integrierten 

Daten und Funktionen aus den Software-Werkzeugen 

aufbauen, etwa ein Engineering-Cockpit zur besseren 

Projektstatusübersicht oder ein Ticketing System zur Benachrichtigung 

relevanter Projektrollen. (5) Die Konfiguration 

von Arbeitsabläufen, die Software-Werkzeuge verwenden 

und über Regeln gesteuert werden. Nachfolgend 

wird näher auf die Kernkomponenten des ASB in Bild 1 

eingegangen, die Services anbieten, die die angebundenen 

Werkzeuge nicht zur Verfügung stellen. 

Datenintegration werden Dateninstanzen entsprechend 

dem Datenmodell des Werkzeugs an den ASB geschickt 

beziehungsweise vom ASB empfangen. Die entsprechenden 

Konnektoren lesen/schreiben Dateninstanzen in 

Dateien, die über die Werkzeug-spezifischen Datei-Export/Import-Schnittstellen 

verarbeitet werden können. 

Werkzeuge, wie Eplan Electric, Eplan Engineering Center 

der Hardware-Konfigurator OPM, MS Excel oder MS Visio 

gehören zu dieser Kategorie. Bei der Funktionsintegration 

werden das Datenmodell und Werkzeug-spezifische 

Funktionen bei der Anbindung verwendet. Dies 

erfordert eine Kooperation mit dem Werkzeughersteller 

oder Werkzeugpartner, um Werkzeug-spezifische 

Schnittstellen zu implementieren. Der Konnektor tauscht 

also mit dem Werkzeug Informationen über APIs aus, die 

der Werkzeugher-steller bereitstellt. Daraus ergibt sich, 

dass die erzielbare Qualität beziehungsweise Tiefe der 

Anbindung vom Werkzeughersteller abhängt. Aus dem 

Bereich der Automatisierungssysteme wurden die Funktionsplansysteme 

Logicad und Logidoc angebunden, aus 

dem Bereich Software-Engineering-Werkzeuge beispielsweise 

das Ticketing-System Trac zur Sammlung und 

Organisation von Aufgaben, die aus dem Änderungsmanagement 

entstehen [7]. 

1.1 Spezifische Werkzeuge für Fachexperten 

Software-Werkzeuge stellen für Fachexperten Daten und 

Funktionen zur Planung von Anlagen in herstellerspezifischer 

Technologie bereit und bieten typischerweise 

Schnittstellen an, um auf Daten und Funktionen aus den 

Werkzeugen von außen zuzugreifen. Der ASB unterstützt 

die Anbindung von Werkzeugen auf zwei Arten. Bei der 

1.2 Werkzeugdomänen zur Anbindung von Werkzeugen 

Konnektoren verbinden Werkzeuge mit dem ASB und bestehen 

daher aus einer technisch spezifischen Schnittstelle 

zum Werkzeug und einer technisch neutralen 

Schnittstelle, die eine Kommunikation mit allen anderen 

Komponenten am ASB erlaubt. Die neutrale Schnittstelle 

– eine Werkzeugdomäne – entspricht einer Standardisie- 

BILD 1: Grundlegende Elemente 

einer Soft ware-Werkzeugintegration 

mit dem Automation Service Bus. 

BILD 2: Semantische Integration [10] heterogener 

Repräsentationen von Engineering-Wissen. 

38 


12 / 2012

ung von Konnektoren zu Werkzeugtypen, etwa Hardware-Konfiguratoren, 

und ermöglicht einerseits den einfachen 

Austausch von Werkzeugdiensten und erlaubt 

andererseits anwendenden Fachexperten weiterhin die 

gewohnte Verwendung ihrer Werkzeuge (für Details siehe 

[8], [9]). Eine neutrale Schnittstellenbeschreibung gestattet 

eine von Werkzeugen unabhängige Beschreibung von 

Arbeitsabläufen im Projekt und den effizienten Einsatz 

von für das Projekt besonders gut passenden Werkzeugen. 

1.3 Engineering Knowledge Base 

Werkzeugdomänen vermindern die Komplexität der Integration 

von Werkzeuginseln. Allerdings sind Konnektoren 

und auch Werkzeugdomänen nicht in der Lage, semantisch 

heterogene Werkzeuge so an den ASB anzubinden, dass 

die unterschiedlichen Datenmodelle für Computer verständlich 

werden. Ein wesentlicher Beitrag der Integrationslösung 

ist daher die Bereitstellung von Daten, die unterschiedliche 

Projektteilnehmer bearbeiten und verwenden, 

sogenannten gemeinsamen Konzepten (siehe Bild 2 

und Bild 3), in einheitlicher Darstellung auf Projektebene. 

Dieses virtuelle gemeinsame Datenmodell lässt sich dynamisch 

erzeugen oder an neue Projektbedürfnisse anpassten 

und unterscheidet sich dadurch stark von klassischen, 

vor Projektbeginn zu definierenden, und starren statischen 

Datenmodellen. Die Engineering Knowledge Base (EKB) 

[10] repräsentiert das Datenmodell der gemeinsamen Konzepte 

auf Projektebene und die Datenmodelle der unterschiedlichen 

lokalen Repräsentationen in den Software- 

Werkzeugen und erlaubt die notwendigen Transformationen 

zwischen den lokalen Datenmodellen. 

Das „Engineering-Babylon“ entsteht durch unterschiedliche 

lokale Repräsentationen der gemeinsamen 

Konzepte des Projektteams in den beteiligten Softwaresystemen 

und erfordert vermeidbaren Aufwand von 

Fachexperten für wiederkehrende Tätigkeiten, etwa Änderungskaskaden. 

Die EKB adressiert dieses Problem 

durch die Modellierung der von den Fachexperten für 

die Kooperation benutzten gemeinsamen Konzepte, die 

Modellierung der lokalen Repräsentationen der Software-Werkzeuge 

und die Abbildungen der einzelnen 

Konzepte zwischen diesen Modellen (siehe Bild 2) in 

einer expliziten und für Computer verständlichen Form, 

einer Ontologie. Dadurch wird die Übersetzung zwischen 

den unterschiedlichen Darstellungen automatisiert 

und die Fachexperten können Abfragen an die Daten 

auf Basis der gemeinsamen Konzepte stellen. 

Bild 2 zeigt die lokalen Datenmodelle von drei Fachbereichen 

(farbige Elipsen) und deren Überlappungsbereiche 

(in Weiß), die die gemeinsamen Konzepte beinhalten, 

etwa Anforderungen, Geräte, mechatronische 

Objekte oder Signale. Diese Überlappungen erlauben es, 

ein virtuelles gemeinsames Datenmodell zu erstellen, 

das die schematischen und semantischen Informationen 

der einzelnen Konzepte beinhaltet und eine Infrastruktur 

für semiautomatische Transformationen zwischen 

den Konzepten bereitstellt. Die werkzeugunterstützte 

Modellierung der Engineering-Konzepte ermöglicht eine 

automatische Ableitung der benötigten Transformationsanweisungen. 

Ein guter Ansatzpunkt für das Identifizieren 

gemeinsamer Konzepte ist die Analyse der Schnittstellen 

exportierbarer Daten, die Werkzeuge anbieten, 

oder auch von Standards in der Domäne. Sobald die relevanten 

Konzepte identifiziert sind, können diese Konzepte 

aufeinander abgebildet werden (Bild 2) [11]. Dadurch 

lassen sich die Auswirkungen von parallelen 

Änderungen in mehreren Engineering-Plänen automatisch 

analysieren; dies erlaubt den Abgleich von Engineering-Modellen 

aus unterschiedlichen Fachbereichen 

in kürzeren Zyklen mit signifikant geringerem Aufwand 

für die Fachexperten. Das Finden von Risiken und Beheben 

von Fehlern kann früher stattfinden. 

1.4 Engineering Database 

Die Engineering Database (EDB) [12] ist eine Datenbank, 

die zu den im vorigen Unterabschnitt beschriebenen gemeinsamen 

Konzepten die Datenbeiträge aus allen relevanten 

Werkzeugen versioniert speichert und zum Datenaustausch 

sowie für Abfragen zur Verfügung stellt. 

Dadurch wird es möglich, jeglichen Datenzustand zu 

einem bestimmten Zeitpunkt zu reproduzieren und zeitliche 

Analysen über Systemereignisse durchzuführen, 

zum Beispiel die Anzahl der Änderungen pro Benutzer 

im Gesamtprojekt. 

Bild 3 zeigt dazu den grundlegenden Ablauf: Die Verwendung 

des virtuellen Datenmodells (1), welches in der 

EKB explizit in Form einer Ontologie spezifiziert wurde, 

ermöglicht die effiziente und effektive Ableitung und 

Herstellung der zur Laufzeit notwendigen Transformationen 

(2) zwischen den ausgetauschten Werkzeugdaten. 

Die derartig transformierten Daten werden dann in der 

EDB (3) abgelegt. Ein Beispiel für eine derartige Transformation 

ist im unteren Teil von Bild 3 dargestellt. Hier 

wird die Instanz von Cust_Signal namens Cust S1 in eine 

Instanz von FB_Signal namens FB 1 transformiert. Die 

Darstellung des Inhalts der EDB zeigt, dass sich die gemeinsamen 

Elemente beider Konzepte am Anfang des 

Eintrags befinden, während am Ende des Eintrags die 

werkzeugspezifischen Elemente der Werkzeuge Elektroplan 

und Funktionsplan angehängt werden. 

1.5 Anwendungen auf Projektebene 

Auf Basis der versionierten Werkzeugdaten in der EDB 

und der Abfragemöglichkeiten der EKB können auf Projektebene 

neue Auswertungs- und Kommunikationsmöglichkeiten 

bereitgestellt werden. Das Engineering-Cockpit 

[13] ist eine Kollaborationsplattform für Projektmanager 

und Ingenieure und kann, basierend auf der Analyse 

von automatisch erfassten Prozessdaten, etwa dem 

Projektmanager Informationen über den Projektfortschritt 

(siehe Bild 4), absehbare Risiken und Unterlagen 

für Claim Management ohne zusätzlichen Aufwand 

bereitstellen. Die Grundlage für eine Analyse sind die 

abgelegten Modelle in der EKB und die Instanzen in der 

EDB. Abfragen über die Daten aus mehreren Werkzeugen, 

etwa Signale, Planungs- oder Implementierungsstände 

und die Team-Konfiguration im Projekt können kombiniert 

werden, etwa, um zu sehen, welche Personen in 


12 / 2012 

39

HAUPTBEITRAG 

BILD 3: Virtuelles gemeinsames Datenmodell und Transformationen. 

einem Zeitraum welche Änderungen an den Signalen 

eines Engineering-Objekts durchgeführt haben. Ein Ticket-System 

ermöglicht es, die Aufgaben im Team im 

Überblick zu behalten, etwa Änderungsbedarfe aufgrund 

einer Änderungskaskade, die nicht automatisch adressiert 

werden können. Vorkonfigurierte Soll-Werte aus 

den Erfahrungen mit Projekten ähnlicher Größe können 

dem Projektmanager als zusätzliche Vergleichsbasis dienen, 

um über Abweichungen vom Soll-Wert mögliche 

Risiken frühzeitig zu erkennen. 

Bei der Qualitätssicherung im Engineering und der Inbetriebnahme 

einer Anlage müssen Fachexperten zwischen 

gemeinsamen Konzepten, etwa Signalen oder Geräten, 

in Plänen aus unterschiedlichen Bereichen navigieren, 

um die Plausibilität und Konsistenz abzusichern. 

Die Software-Werkzeuge der Fachbereiche vernetzen die 

gemeinsamen Konzepte oft nicht vollständig und effizient, 

sodass die Experten diese in unzureichend vernetzten 

Software-Plänen relativ aufwendig suchen müssen. 

Durch die Verbindung von gemeinsamen Konzepten können 

Anwender effizient zwischen unterschiedlichen Plänen 

und Werkzeugen navigieren und behalten dabei den 

Kontext, zu dem sie Informationen suchen. Das Netz an 

Abbildungen zwischen lokalen und gemeinsamen Konzepten 

in der EKB zeigt konkrete Navigationsmöglichkeiten 

zwischen Ausgangs- und Zielwerkzeug auf. 

1.6 Konfiguration von Arbeitsabläufen 

Ein wesentlicher Nutzen des ASB ist die technologieunabhängige 

Beschreibung von (bestehenden) Engineering- 

Prozessen und deren Automatisierung, um die Fachexperten 

von Tätigkeiten zu entlasten, die Software-Werkzeuge 

übernehmen sollen. Die in den ASB integrierte 

Workflow-Engine unterstützt die automatisierte Ausführung 

von Arbeitsabläufen zwischen Werkzeugen und ist 

daher für das Management von Regeln und Ereignissen 

beziehungsweise für die korrekte Ausführung von Engineering-Workflows 

verantwortlich. Technisch beschreibt 

ein in einer Sprache wie BPMN modellierter und in die 

ASB-Umgebung transformierter Engineering-Workflow 

konfigurierbare Prozessschritte, die die gewünschte Art 

der Integration der einzelnen Werkzeuge im Projekt darstellen. 

Die vom Prozessmanager erarbeiteten und zu 

konfigurierenden Schritte [6] basieren auf den in der EKB 

beschriebenen Datenmodellen (Rollen, Verantwortlichkeiten, 

Gewerken, Signalen, Einschränkungen) und auf 

für die Ausführung relevanten Werkzeugdomänen (inklusive 

deren Datenmodelle und Funktionen) beziehungsweise 

den in der Projektkonfiguration spezifizierten 

konkreten Werkzeuginstanzen. Eine im ASB laufende 

Komponente zur Prozessanalyse sammelt während 

der Ausführung Informationen über die Zustände der 

einzelnen Prozesse, um den wirklichen Ablauf mit dem 

im BPMN beschriebenen Verlauf zu vergleichen und so 

Abweichungen vom Sollzustand zu identifizieren. 

Für den Anwendungsfall von Änderungskaskaden und 

der automatischen Notifizierung von Projektmitarbeitern 

über Änderungen mithilfe eines Ticketing-Systems ist 

das projektspezifische Zusammenspiel aller zuvor erwähnten 

Komponenten zu beschreiben, zum Beispiel: die 

notwendigen Iterationen für eine Überprüfung, die Art 

einer Änderungsanfrage, der Umgang mit parallelen Aktivitäten 

und mit Konflikten [7, 14]. Änderungen in einem 

Werkzeug können je nach Art der Anbindung entweder 

direkt aus dem Werkzeug heraus oder über die Export- 

Schnittstelle des Werkzeugs dem ASB mitgeteilt werden. 

Dies hat zur Folge, dass der aktuelle Datenbestand des 

Werkzeugs in der EDB abgelegt wird. Dieser Vorgang wird 

über einen Engineering-Workflow gesteuert, der durch 

die Versionierung der Daten in der EDB Änderungen im 

Datenbestand erkennt, und auf Basis der Abbildungen 

zwischen Datenmodellen über gemeinsame Konzepte in 

der EKB in der Lage ist, Werkzeuge oder deren Benutzer 

zu identifizieren, die über diese Änderung informiert 

werden sollten. Je nach Konfiguration des Ablaufs werden 

den identifizierten Experten über die Werkzeugdomäne 

Ticketing neue Tickets zugeordnet beziehungsweise die 

Änderungen nach Durchführung der spezifizierten 

40 


12 / 2012

BILD 4: Auswertungen im Engineering-Cockpit – 

etwa die Anzahl der Signale nach Projektphase. 

Transformationsschritte entweder sofort oder nach erfolgter 

Bestätigung durch die Ingenieure zum jeweiligen 

Werkzeug geleitet. Dadurch ist es möglich, den Ablauf 

der Änderungskaskaden einfach und flexibel an die Bedürfnisse 

der Projektteilnehmer anzupassen. 

2. ARBEITSSCHRITTE UND AUFWAND 

Dieser Abschnitt beschreibt die Arbeitsschritte und 

den Aufwand, um mit dem ASB zu einer auf Projektbedürfnisse 

abgestimmte Integrationslösung zu kommen. 

Im ersten Schritt „Datenmodellierung“ erstellen 

die Werkzeugexperten die Datenmodelle für die jeweiligen 

im Projekt verwendeten Werkzeuge einer Werkzeugdomäne 

[15]. In einem weiteren Schritt definieren 

die Experten gemeinsam das dazu passende Datenmodell 

der Werkzeugdomäne. Das Resultat sind in der 

EKB gespeicherte semantische Beschreibungen [16] der 

Modelle und Abbildungen zwischen den Datenmodellen. 

Abschließend werden die Modelle mit qualitätssichernden 

Maßnahmen auf Korrektheit und Gültigkeit 

überprüft [17, 18]. Die in der EKB verwendete Datenmodellierungsmethode 

benutzt Ontologien, wodurch 

sich klare Vorteile ergeben in Bezug auf dynamische 

Erweiterbarkeit der Datenmodelle, explizite semantische 

Beschreibung der Datenmodelle und Unterstützung 

von automatisierten Regel- und Abfragesprachen. 

Herausforderungen in der Verwendung von Ontologien 

ergeben sich aus nicht garantierbaren Laufzeiten von 

Abfragen und aus der mit der Handhabung von Ontologien 

verbundenen Komplexität. 

Im nächsten Schritt „Prozessbeschreibung“ werden 

die Arbeitsprozessbeschreibungen [7] (etwa in der BPMN 

[19]) analysiert und auf die Funktionen abgebildet, die 

die zu verwendenden Werkzeugdomänen bereitstellen. 

Die Architektur des ASB ist darauf ausgelegt, ein flexibles 

Zusammenspiel der vorgestellten Konzepte zu ermöglichen. 

Ein Vorteil ist die iterative Umsetzbarkeit von 

Integrationslösungen, die eine schrittweise Migration 

bestehender Integrationslösungen Richtung ASB mit 

überschaubaren Risiken und Kosten [20, 21] erlaubt. 

Im darauffolgenden Schritt „Prozessumsetzung“ erfolgt 

die konkrete Umsetzung der Integration, indem die 

erfassten Modelle und Arbeitsabläufe dazu verwendet 

werden, um projektspezifische ASB-Artefakte wie Konfigurationsdateien, 

Quellcode und Testszenarien semiautomatisiert 

abzuleiten. In diesem Schritt werden Vorlagen 

für Werkzeugkonnektoren erstellt, die neben der 

konkreten Anbindung an das Zielwerkzeug die Funktionalität 

der Werkzeugdomäne beziehungsweise Gültigkeitsüberprüfungen 

von Dateninstanzen implementieren, 

(b) Schnittstellen und Funktionsaufrufe der Werkzeugdomänen 

angelegt, (c) Transformationsinstruktionen 

zwischen Datenmodellen abgeleitet, um zwischen 

Werkzeugen Daten semantisch korrekt austauschen zu 

können und (d) Testszenarien erstellt, um die Anbindung 

der Werkzeuge an den ASB testen zu können. Die 

ASB-Integrationslösung kann dann auf einem Server, 

etwa in einer Java VM, zur Verwendung im Projekt bereitgestellt 

werden. 

Erfahrungen aus der Anwendung des ASB mit Software-Werkzeugherstellern 

und Fachexperten in der Anlagenplanung 

haben folgenden Aufwand ergeben: ein bis 

zwei Workshop-Tage für die Analyse der Datenmodelle 

für Werkzeugkonnektoren und zu unterstützende Arbeitsabläufe, 

einige Personentage für die Umsetzung 

eines Werkzeugkonnektors als Java beziehungsweise C# 

Klassen anhand des Datenmodells durch Werkzeug- und 

ASB-Experten. Werkzeughersteller können unterschiedliche 

Versionen von Werkzeugkonnektoren anbieten, 

Werkzeugdomänen halten die Auswirkungen von Änderungen 

der Werkzeugspezifika auf ASB-Anwendungen 

möglichst gering. Die Beschreibung der Transformationsmodelle 

ist typischerweise in ein bis zwei Tagen 

möglich, allerdings kann Mehraufwand entstehen, falls 

Daten in der Organisation bisher inkonsistent verwendet 

wurden, was durch die Analyse und den Einsatz der 

automatischen Datenabgleiche oft erstmals auffällt. 

Die Einbindung bekannter Werkzeuge in etablierte 

Standardarbeitsabläufe ist typischerweise in einigen 

Personentagen erzielbar. Wesentlicher Aufwand entsteht 

durch die Abstimmung und Entwicklung organisationsspezifischer 

Arbeitsabläufe, insbesondere gut verständlicher 

Anwenderschnittstellen, die je nach Anforderungen 

und Umfang typischerweise einige Personenwochen 

erfordert. In den ASB-Projekten hat sich eine iterative 

Vorgehensweise in Projektphasen über zwei bis drei Monate 

bewährt, um nützliche und überschaubare Integrationsschritte 

zu setzen. 

Mit Bezug zum Aufwand für die Integration ist es wichtig 

zu unterscheiden, ob es sich um Initialaufwand oder 

um Aufwand für Änderungen der Integrationslösung handelt. 

Einen wichtigen Unterschied zu anderen Integrationsansätzen 

stellt die explizite Verfügbarkeit von Wissen 

über Arbeitsabläufe oder verwendete Software-Werkzeuge 

in Form von Ontologien dar, wodurch eine automatisierte 

und maschinenverständliche Verwendung dieses 

Wissens ermöglicht wird. Der Inititialaufwand anderer 

Integrationsansätze ist daher etwas niedriger, da für die 

ASB-Integration das explizite Wissen über Arbeitsabläufe 

und Software-Werkzeuge zusätzlich modelliert werden 


12 / 2012 

41

HAUPTBEITRAG 

muss. Dieses externalisierte Wissen macht jedoch Änderungen 

der Integrationslösung leichter. Zusätzlich unterstützt 

das Konzept der Werkzeugdomänen effektiv die 

Stabilität von Arbeitsabläufen, auch bei Änderungen an 

Software-Werkzeugen, die lokal in den Konnektoren adressiert 

werden können. Einen weiteren Vorteil bietet der 

ASB im Bereich von qualitätssichernden Maßnahmen. 

Durch die explizite Verfügbarkeit von Wissen über Arbeitsläufe 

und Software-Werkzeuge wird die automatisierte 

Durchführung von qualitätssichernden Maßnahmen 

erleichtert, wodurch die konsistente und plausible 

Datenhaltung verbessert wird; zusätzlich können automatisiert 

Testfälle abgeleitet werden, um die Integrationslösung 

bereits vor der Inbetriebnahme zu testen. 

ZUSAMMENFASSUNG UND AUSBLICK 

Dieser Beitrag hat den Automation Service Bus (ASB) 

vorgestellt, einen offenen herstellerneutralen Ansatz zur 

Integration von Software-Werkzeugen. Die Vision des 

ASB ist die offene Integration von Daten und Funktionen 

aus Software-Werkzeugen, um Abläufe in Engineering- 

Projekten systematisch zu automatisieren. Wesentliche 

Eigenschaften des ASB sind die herstellerneutrale, offene 

Anbindung von Software-Werkzeugen an eine Integrationsplattform. 

Diese Plattform beschreibt die Datenmodelle 

der anzuschließenden Werkzeuge in expliziter 

Form mithilfe von Ontologien, und ermöglicht dadurch 

einerseits die effiziente Konfiguration benötigter Modelltransformationen 

und andererseits die versionierte Speicherung 

von Werkzeugdaten. Gleichzeitig erlaubt der 

ASB die werkzeugunabhängige Definition von Arbeitsabläufen, 

die auch bei Austausch von konkreten Werkzeugversionen 

weitgehend stabil bleiben. 

Der ASB-Ansatz ermöglicht, vorhandene Engineering- 

Prozesse sichtbar und analysierbar zu machen und diese 

Prozesse nach dem Bedarf der Fachexperten zu automatisieren 

oder anzupassen. Der ASB-Ansatz wurde 

anhand realer Projekterfordernisse von Industriepartnern 

aus dem Bereich des industriellen Anlagenbaus 

konzipiert, iterativ verbessert und evaluiert. Die Erstellung 

von Konnektoren für Software-Werkzeuge durch 

die einschlägigen Experten ließ sich je nach Umfang der 

anzubindenden Daten und Funktionen in zwei bis zehn 

Tagen erledigen. Durch die Integration von Daten und 

Funktionen werden neue Funktionen auf Projektebene 

ermöglicht, etwa die Navigation zwischen Sichten auf 

ein mechatronisches Objekt in den unterschiedlichen 

Werkzeugen oder die Datenauswertungen auf Projektebe- 

REFERENZEN 

[1] Drath, R. und Barth, M.: Concept for interoperability between 

independent engineering tools of heterogeneous disciplines. 

In: Proceedings Emerging Technologies & Factory Automation 

(ETFA 2011), S. 1-8, 2011 

[2] Chappell, D.: Enterprise Service Bus - Theory in Practice. 

O’Reilly, 2004 

[3] Biffl, S. und Schatten, A.: A Platform for Service-Oriented 

Integration of Software Engineering Environments. In: 

Proceedings SoMeT 09, S. 75–92, 2009 

[4] Szyperski, C.: Component Software: Beyond Object-Oriented 

Programming. Addison-Wesley, 2002 

[5] Papazoglou, M.P. und Heuvel, W.-J.: Service oriented 

architectures: approaches, technologies and research 

issues. The VLDB Journal 16(3), S. 389 415, 2007 

[6] Sunindyo, W., Moser, T., Winkler, D., Mordinyi, R., Biffl, S.: 

Workflow Validation Framework in Distributed Engineering 

Environments. In: Proceedings 3rd International Workshop 

on Information Systems in Distributed Environment (ISDE'11), 

S. 1 10, 2011 

[7] Winkler, D., Moser, T., Mordinyi, R., Sunindyo, W.D., Biffl, S.: 

Engineering Object Change Management Process Observation 

in Distributed Automation Systems Projects. In: Proceedings 

18th European System & Software Process Improvement 

and Innovation, S. 1-12, 2011 

[8] Biffl, S., Mordinyi, R., Moser, T.: Automated Derivation of 

Configurations for the Integration of Software(+) Engineering 

Environments. In: Proceedings 1st International Workshop on 

Automated Configuration and Tailoring of Applications 

(ACoTA 2010), S. 6 13, 2010 

[9] Mordinyi, R., Moser, T., Biffl, S., Dhungana, D.: Flexible 

Support for Adaptable Software and Systems Engineering 

Processes. In: Proceedings 23rd International Conference on 

Software Engineering and Knowledge Engineering (SEKE 

2011), S. 1 5, 2011 

[10] Moser, T. und Biffl, S.: Semantic Integration of Software and 

Systems Engineering Environments. IEEE Transactions on 

Systems, Man, and Cybernetics, C-42(1), S. 38 50, 2012 

[11] Moser, T., Schimper, K., Mordinyi, R., Anjomshoaa, A.: SAMOA 

- A Semi-Automated Ontology Alignment Method for Systems 

Integration in Safety-Critical Environments. In: Proceedings 

International Conference on Complex, Intelligent and 

Software Intensive Systems, S. 724 729, 2009 

[12] Waltersdorfer, F., Moser, T., Zoitl, A., Biffl, S.: Version 

Management and Conflict Detection Across Heterogeneous 

Engineering Data Models. In: Proceedings 8th IEEE International 

Conference on Industrial Informatics (INDIN 2010), S. 

928 935, 2010 

[13] Moser, T., Mordinyi, R., Winkler, D., Biffl, S.: Engineering 

Project Management Using The Engineering Cockpit. In: 

Proceedings 9th IEEE International Conference on Industrial 

Informatics (INDIN'2011), S. 579 584, 2011 

[14] Mordinyi, R., Moser, T., Winkler, D., Biffl, S.: Navigating 

between Tools in Heterogeneous Automation Systems 

Engineering Landscapes. In: Proceedings 38th Annual 

Conference of the IEEE Industrial Electronics Society (IECON 

2012), S. 6182 6188, 2012 

[15] Moser, T., Mordinyi, R., Mikula, A., Biffl, S.: Making Expert 

Knowledge Explicit to Facilitate Tool Support for Integrating 

42 


12 / 2012

ne über heterogene Datenmodelle aus den verwendeten 

Software-Werkzeugen. 

Der ASB wurde seit 2010 mit Industriepartnern konzipiert 

und entwickelt. Aktuell laufen Evaluierungsprojekte 

mit mehreren Werkzeugpartnern und Anwendern aus dem 

Bereich Anlagenbau, deren Ergebnisse zum Teil bereits in 

realen Projekten eingesetzt werden. Eine Open-Source- 

Variante des ASB, durchläuft den Prozess Richtung Apache-Projekt. 

Gemeinsam mit dem Unternehmenspartner 

Logicals wird der ASB laufend verbessert, um die Konfiguration 

und Verwendung nicht nur für Softwareentwickler 

mit Kenntnis der Modellierungssprachen, sondern 

auch für Anwendungsexperten leicht zugänglich zu machen, 

und damit die Entwicklungszeiten zu verkürzen. 

Die Entwicklung und Anwendung systematischer Ansätze 

zur offenen Integration von Daten (etwa AutomationML 

[22]) und Funktionen (etwa der Automation Service 

Bus) beschleunigen die Innovation von Software- 

Werkzeugen für das Engineering. Sie stärken durch 

Verbesserungen der Effizienz im Engineering die Wettbewerbsfähigkeit 

der europäischen Industrie. 


02.04.2012 


Complex Information Systems in the ATM Domain. In: 

Proceedings International Conference on Complex, Intelligent 

and Software Intensive Systems(CISIS '09), S. 90 97, 2009 

[16] Moser, T., Mordinyi, R., Winkler, D.: Extending Mechatronic 

Objects for Automation Systems Engineering in Heterogeneous 

Engineering Environments. In: Proceedings 17th 

IEEE Conference on Emerging Technologies and Factory 

Automation (ETFA), S. 1-8, 2012 

[17] Biffl, S., Mordinyi, R., Schatten, A: A Model-Driven 

Architecture Approach Using Explicit Stakeholder Quality 

Requirement Models for Building Dependable Information 

Systems. In: Proceedings 5th International Workshop on 

Software Quality, Minneapolis, S. 6, 2007 

[18] Biffl, S., Mordinyi, R., Moser, T., Wahyudin, D.: Ontologysupported 

quality assurance for component-based 

systems configuration. In: Proceedings the 6th international 

Workshop on Software Quality (WoSQ), S. 59 64, 2008 

[19] Allweyer, T.: BPMN 2.0 Introduction to the Standard for 

Business Process Modeling. Books on Demand, 2010 

[20] Biffl, S., Mordinyi, R., Moser, T.: Anforderungsanalyse für 

das integrierte Engineering Mechanismen und Bedarfe 

aus der Praxis, atp edition – Automatisierungstechnische 

Praxis 54(5), S. 28 35, 2012 

[21] Biffl, S., Moser, T., Mordinyi, R.: Automation Service Bus 

löst Software-Problematik, Computer & AUTOMATION 

2012(6), S. 41-44, 2012 

[22] Drath, R.: Datenaustausch in der Anlagenplanung mit 

AutomationML: Integration von CAEX, PLCopen XML und 

COLLADA. Springer, Berlin Heidelberg, 2010 

AUTOREN 

Ao. Univ. Prof. DI Mag. Dr. 

techn. STEFAN BIFFL (geb. 1967) 

ist Leiter des Christian Doppler 

Forschungslabors „Software 

Engineering Integration für 

flexible Automatisierungssysteme“ 

(CDL-Flex) an der Fakultät 

für Informatik der Technischen 

Universität Wien. Seine Forschungsinteressen 

liegen im Bereich der Produktund 

Prozessverbesserung für Software-intensive 

Systeme sowie der empirischen Evaluierung im 

industriellen Umfeld. 

Technische Universität Wien, 

Favoritenstr. 9-11/188, A-1040, Wien, 

Tel. +43 (0) 1 58 80 11 88 10, 

E-Mail: stefan.biffl@tuwien.ac.at 

DI Mag. Dr. techn. RICHARD 

MORDINYI (geb. 1979) ist Postdoc 

im Christian Doppler Forschungslabor 

„Software Engineering 

Integration für flexible Automatisierungssysteme“ 

(CDL-Flex) 

an der Fakultät für Informatik 

der Technischen Universität 

Wien. Seine Forschungsinteressen 

liegen im Bereich der Modell-getriebenen 

Konfiguration von Integrationsplattformen, Agiler 

Softwarearchitekturen und sicherer Koordinationsstrategien 

in komplexen verteilten Systemen. 


Favoritenstr. 9-11/188, A-1040, Wien, 

Tel. +43 (0) 1 588 01 18 80 51, 

E-Mail: richard.mordinyi@tuwien.ac.at 

Mag. Dr. rer. soc. oec. THOMAS 

MOSER (geb. 1981) ist Postdoc 

im Christian Doppler Forschungslabor 

„Software 

Engineering Integration für 

flexible Automatisierungssysteme“ 

(CDL-Flex) an der Fakultät 

für Informatik der Technischen 

Universität Wien. Seine Forschungsinteressen 

liegen im Bereich der Datenmodellierung 

und Datenintegration für Softwareintensive 

Systeme sowie im Bereich Semantic Web. 

Institut für Softwaretechnik und interaktive Systeme, 


Favoritenstr. 9-11/188, A-1040 Wien, 

Tel. +43 (0) 1 588 01 18 80 51, 

E-Mail: thomas.moser@tuwien.ac.at 


12 / 2012 

43

HAUPTBEITRAG 

Feldgeräte und semantische 

Informationsmodelle 

Plug-and-play-Integration und dynamische Orchestrierung 

Programmierung und Rekonfiguration von Anlagensteuerungen sind mit sehr vielen manuellen 

Tätigkeiten verbunden und daher zeitaufwendig und fehleranfällig. Konkrete 

semantische Informationsmodelle und Middlewareparadigmen schaffen Abhilfe. Sie sind 

daher die Basis für automatisierte Vorgänge wie beispielsweise bei der Feldgeräteintegration 

oder der dynamischen Anpassung von Produktionsprozessen zur Laufzeit. Dieser 

Beitrag erläutert Arten der Wissensrepräsentation, diskutiert existierende Wissensquellen 

zum Aufbau von konkreten Informationsmodellen und weist Nutzenpotenziale auf. 

SCHLAGWÖRTER Feldgeräteprofil / Plug-and-play / Dynamische Orchestrierung / 

Informationsmodell 

Semantic information models for field device control – 

Plug-and-play integration and dynamic orchestration 

Programming and reconfiguration of control systems are combined with many manual 

operations and therefore timeconsuming and error prone. Specific semantic information 

models and middleware paradigms remedy and are the basis for automated procedures 

at field device integration or the dynamic adaption of production processes at runtime. 

This treatise explains different kinds of knowledge representation, discusses existing 

knowledge sources for the setup of specific information models and presents potential 

benefits. 

KEYWORDS field device profile / plug&play / dynamic orchestration / information model 

44 


12 / 2012

STEFAN HODEK, MATTHIAS LOSKYLL, JOCHEN SCHLICK, 

Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) 

Heutige Produktionsanlagen bestehen aus einer 

Vielzahl unterschiedlicher Feldgeräte. Die Intelligenz 

der Feldgeräte erlaubt dezentrale und 

verteilte Steuerungskonzepte, was eine Interaktion 

zwischen Feldgeräten und Steuerungen 

über industrielle Kommunikationssysteme voraussetzt. 

Kernproblem bei der Realisierung ist die Integration der 

unterschiedlichen Feldgeräte zu einem Gesamtsystem. 

Zentraler Aspekt: die Feldgeräteansteuerung durch verschiedene 

Systeme. Beispiele für solche Systeme sind 

SPSen, Qualitätsleitrechner, Betriebsdatenerfassung, 

Auftragsverwaltung oder Liniensteuerung. Die Ansteuerung 

von Feldgeräten setzt bei der Systemintegration 

detaillierte Kenntnisse des Ingenieurs über die aktivierbaren 

Funktionalitäten voraus. Diese Kenntnisse bilden 

die Basis für das Programmieren von Steuerungen sowie 

für den elektronischen Datenaustausch und damit für 

die horizontale und vertikale Integration. 

Die Aktivierung dieser Funktionen erfolgt meist 

durch Steuer- und Statuswörter, die mithilfe von industriellen 

Kommunikationssystemen übertragen werden. 

Die Bedeutung der Wörter ist in der Dokumentation in 

Fließtext und Tabellen beschrieben und wird durch den 

Systementwickler nachgeschlagen und in Form von 

Programmcodes in die Steuerung implementiert. Die 

zu übertragenden Nutzdaten müssen daher manuell 

und explizit eingerichtet werden, was zu einem hohen 

Arbeitsaufwand führt. Die Qualität der Dokumentation 

und die Erfahrung des Ingenieurs sind maßgebend für 

den zeitlichen Arbeitsaufwand bei der Feldgeräteintegration. 

Die Integrationsphase ist damit schwer abzuschätzen 

und eines der wesentlichen Hemmnisse für 

wandelbare Fabriken. 

Die Plug-and-play-Feldgeräteintegration intendiert 

die automatische Erkennung, Konfiguration und Integration 

von Feldgeräten in die Steuerungsprogramme 

von Automatisierungssystemen während der Betriebsphase 

[1]. Neu angeschlossene Peripheriegeräte und 

deren Basisfunktionalitäten lassen sich ohne manuelle 

Arbeitsschritte nach dem elektromechanischen Einbringen 

sofort nutzen. Der Integrationsaufwand wird 

folglich auf nahezu Null reduziert. Die dynamische 

Orchestrierung [2] bildet eine konzeptionelle Weiterentwicklung 

des Plug-and-play-Gedankens und geht 

davon aus, dass abstrakt beschriebene Programmabläufe 

erst unmittelbar vor ihrer Ausführung, das heißt 

in der Lebenszyklusphase des produktiven Betriebs, 

auf die in der Anlage verfügbaren Geräte abgebildet 

werden. Der zur Fertigung eines bestimmten Produkts 

beziehungsweise einer Produktvariante benötigte konkrete 

(ausführbare) Prozessablauf wird also ad hoc gebildet, 

beispielweise in dem Moment, in dem ein Rohprodukt 

in die Anlage eingebracht wird. Damit ein 

solches Plug-and-play und eine dynamische Orchestrierung 

realisierbar sind, muss der Datenaustausch auf 

einer semantisch beschriebenen Ebene beruhen [3]. 

Grundvoraussetzung ist es, ein explizites semantisches 

Informationsmodell zur Beschreibung der Datensemantik 

zu verwenden. 

In diesem Beitrag werden drei Aspekte zur Charakterisierung 

von Informationsmodellen unterschieden – 

Grundkonzepte der Modellierung, Arten der Wissensrepräsentation 

und konkrete Instanzen von Informationsmodellen 

(siehe Bild 1). Modellierungsprinzipien oder 

Grundkonzepte sind Hierarchie, Aggregation, Variablen, 

Funktionen, Referenzierung, Klassen, Methoden, Vererbung 

und Datentypen [4]. Da der Zusammenhang zwischen 

Informationsmodellen und Modellierungsprinzipien 

mit Bezug zu existierenden Standards bereits in der 

genannten Veröffentlichung untersucht wurde, werden 

diese hier nicht weiter behandelt. Abschnitt 1 erläutert 

stattdessen verschiedene Arten der Wissensrepräsentation, 

welche unterschiedliche Grundkonzepte der Modellierung 

benutzen, und legt damit einen Grundstein 

zur Bewertung existierender Standards und zur Weiterentwicklung 

von Programmierweisen bei Automatisierungssystemen. 

Weiterhin liefern die Autoren einen Überblick und 

eine Bewertung bestehender Standards zur Beschreibung 

von Feldgerätefunktionalitäten (Abschnitt 2). Ziel 

ist es, die Erstellung von Instanzen bei der Modellierung 

von Automatisierungssystemen durch Wiederver- 


12 / 2012 

45

HAUPTBEITRAG 

GLOSSAR 

wendung exsistierender Standards zu erleichtern. Einsatzmöglichkeiten 

und Mehrwerte solcher Instanzen 

(explizite semantische Informationsmodelle) werden 

anhand der Plug-and-play-Feldgeräteintegration und 

der dynamischen Orchestrierung beschrieben (Abschnitt 

3). Erst diese einheitliche Abbildung des Datenund 

Informationsraums in Kombination mit einer Abstraktion 

der Kommunikation in Form einer Middleware 

[5] ermöglicht die postulierte Reduzierung des 

Engineeringaufwands, wie es die zwei genannten Anwendungen 

darstellen. 

1. ARTEN DER EXPLIZITEN WISSENSREPRÄSENTATION 

Konkrete semantische Informationsmodelle beschreiben 

explizites Wissen, wie beispielsweise konkrete Feldgerätefunktionalitäten, 

und werden mittels einer ausgewählten 

Art der expliziten Wissensrepräsentation modelliert. 

Semantische Informationsmodelle machen es 

möglich, Daten formal zu beschreiben und somit eine 

semantische Verarbeitung dieser Daten durch Maschinen 

zu gewährleisten, das heißt die Interpretation elektronisch 

gespeicherter Informationen hinsichtlich ihrer 

Inhalte und Bedeutung, zu gewährleisten. Der Bereich 

der expliziten Wissensrepräsentation umfasst die Modellierung 

des Wissens und die Definition formaler Logiken, 

welche Regeln bereitstellen, um Schlüsse über die 

modellierte Wissensbasis ziehen zu können. Die explizite 

Definition der Semantik komplexer Wissenszusammenhänge 

ermöglicht die eindeutige Interpretation der 

Bedeutung von Information durch Maschinen. Hierdurch 

lassen sich Inkonsistenzen und Widersprüche 

automatisiert erkennen. Des Weiteren bilden semantische 

Technologien die Grundlage für einen strukturierten 

Informationsaustausch zwischen heterogenen Systemen 

(semantische Interoperabilität). Der entscheidende 

Mehrwert semantischer Technologien besteht in der 

Möglichkeit, automatisiert Schlussfolgerungen (logische 

Konsequenzen) ziehen und aus explizit modelliertem 

Wissen neues implizites Wissen ableiten zu können. 

Es existieren verschiedene Konzepte zur expliziten 

Wissensrepräsentation, die sich in ihrer Ausdrucksstärke 

und semantischen Mächtigkeit unterscheiden [6], siehe 

Infokasten. 

Glossar: eine einfache Auflistung von Begriffen und deren Erklärung. 

Taxonomie: eine hierarchische, strukturierte Auflistung von Begriffen ohne 

komplexe Beziehungen zwischen diesen. 

Thesaurus: ähnlich der Taxonomie, erweitert um Relationen, die Ähnlichkeiten 

und Synonyme beschreiben. 

Topic Map: erweitert Thesauri um objektorientierte Prinzipien (Unterteilung 

in Klassen und Instanzen) und beliebige Relationstypen (zum Beispiel: 

istTeilVon oder nutztInterface). 

Ontologie: erweitert zuvor genannte Repräsentationsarten um logische 

Regeln, um ein komplexes Wissensnetzwerk zu bilden und automatisches 

Reasoning zu ermöglichen. 

Die semantisch reichhaltigste Form der expliziten Wissensrepräsentation 

stellen Ontologien dar. Als Ontologie 

wird eine explizite formale Spezifikation einer gemeinsamen 

Konzeptualisierung bezeichnet [7]. Das bedeutet, 

dass Ontologien einen bestimmten Wissensbereich mithilfe 

einer standardisierten Terminologie sowie Beziehungen 

und Ableitungsregeln zwischen den dort definierten 

Begriffen beschreiben. 

Im Laufe der letzten Jahre wurden diverse standardisierte 

Beschreibungssprachen zur Abbildung semantischer 

Informationsmodelle entwickelt. Dabei hat sich die 

Web Ontology Language (OWL) als die durch das W3C 

empfohlene Ontologie-Beschreibungssprache durchgesetzt. 

OWL basiert auf RDF (Resource Description Framework) 

und auf einer Beschreibungslogik, die eine Untermenge 

der Prädikatenlogik erster Stufe darstellt. Jedes in 

OWL modellierte Objekt (Klasse, Instanz, Relation) wird 

mittels eines Uniform Resource Identifiers der Ontologie 

und des entsprechenden Objektnamens identifiziert. Ein 

großer Vorteil von OWL ist die Möglichkeit, mithilfe von 

Reasoning-Systemen Schlussfolgerungen auf Basis der 

Ontologie ziehen zu können. Diese erlauben beispielsweise 

die automatische Prüfung der Systeminteroperabilität 

sowie den Abgleich zwischen benötigten und angebotenen 

Feldgerätefunktionalitäten (Abschnitt 3). 

2. BESCHREIBUNG VON GERÄTEN UND FUNKTIONEN 

2.1 Typisierung von Standards 

Spezifische Informationen über die Automatisierungstechnik 

sind in unterschiedlichsten Standards hinterlegt. Beispiele 

dafür: Prozessbeschreibungen, Produktbeschreibungen, 

Klassifizierungssysteme, Merkmalleisten, Kommunikationsprotokolle, 

Gerätebeschreibungen und Feldgeräteprofile 

(siehe Bild 2). Im Folgenden werden diese 

erläutert und hinsichtlich ihres Informationsgehaltes über 

Feldgerätefunktionalitäten zur Wiederverwendung beim 

Erstellen von Modellinstanzen argumentativ bewertet. 

Die Prozessbeschreibungen in der VDI 2411 (Förderwesen) 

oder VDI 2860 (Handhabungstechnik) definieren Elementarfunktionen 

und Prozessschritte. Zur Realisierung 

dieser Elementarfunktionen ist oft ein Zusammenspiel 

mehrerer Feldgeräte notwendig. Diese Art von Standards 

eignet sich daher zur Beschreibung der Fähigkeiten komplexer 

mechatronischer Einheiten. Basisfunktionalitäten 

einzelner Feldgeräte lassen sich damit nicht erklären. 

STEP (STandard for the Exchange of Product model 

data, ISO-Norm 10303) ist ein Standard zur Beschreibung 

von Produktdaten, der neben den physischen auch funktionale 

Aspekte eines Produktes erläutert. Sogenannte 

Anwendungsprotokolle (Application Protocols) geben 

die oberste Gliederung vor und decken unterschiedliche 

Industriezweige ab. Der Fokus von STEP liegt auf der 

Beschreibung von Dimensionen, mechanischen Eigenschaften, 

elektrischen Anschlüssen und Strukturen. 

Über Kommunikationsnetzwerke aufrufbare Funktionen 

sind darin nicht für einzelne Feldgeräteklassen in ausreichendem 

Maße beschrieben. 

Klassifizierungssysteme, wie ecl@ss und Unspsc für 

Produkte oder ETIM und IEC 61360-4 für elektrische 

46 


12 / 2012

Grundkonzepte der Modellierung 

Prozessbeschreibungen 

• Begriffe im Förderwesen (VDI 2411) und Handhabungstechnik (VDI 2860) 

Produktbeschreibungen 

• STEP (ISO 10303) 

Arten der Wissensrepräsentation 

Klassifizierungssysteme 

• eCl@ss, UNSPSC, ETIM, ICS, IEC 61360-4 

Merkmalleisten 

• Prolist (NE 100), Elektrische Komponenten (IEC 61360-4) 

Konkrete Instanzen von Informationsmodellen 

Kommunikationsprotokolle 

• Industrielle Kommunikationsnetze (DIN IEC61784-1), Manufacturing Message 

Specification (ISO 9506), Feldbusanwendungsprofile (DIN IEC 61158-500 u.600) 

Go 

6000 

3000 

10 

FB_MoveAbsolute 

Execute Done 

Position Active 

Velocity ErrorID 

Acceleration 

Finish 

Gerätebeschreibungssprachen 

• GSD, EDD, FDT/DTM, FDI, EDS, FDCML, XIF 

Feldgeräteprofile 

• Siehe Bild 3 

BILD 1: Aspekte zur Charakterisierung 

von Infomationsmodellen 

BILD 2: Übersicht zu Typen von Standards 

mit Beispielen 

Produkte, sind planmäßige Sammlungen von abstrakten 

Typen oder Kategorien, die zur Abgrenzung und Ordnung 

verwendet werden. Objekte werden anhand von 

Merkmalen einzelnen Kategorien zugeordnet und dadurch 

hierarchisiert. Zu den Typen gehörende Funktionen 

oder Methoden sind nicht standardisiert. Bei den in 

dieser Abhandlung dargestellten Anwendungen (siehe 

Abschnitt 3) unterstützen sie daher lediglich die Einteilung 

von Feldgeräten im Vorfeld der Modellierung, jedoch 

nicht den Aufbau aufrufbarer Schnittstellen. 

Merkmalleisten weisen eine große Ähnlichkeit zu 

Klassifizierungssystemen auf, jedoch steht bei ihnen 

nicht die Klassifizierung von Produktspektren, sondern 

die Standardisierung von Produktmerkmalen im Vordergrund. 

Prolist (Namur-Empfehlung NE 100) stellt eine 

solche Merkmalleiste für Produkte und Systeme aus dem 

Bereich der Prozessleittechnik (Elektro- und MSR-Technik) 

dar. Die Merkmale umfassen keine Beschreibung 

der aufrufbaren Feldgerätefunktionen. 

Kommunikationsprotokolle, auch Kommunikationsprofile 

oder Feldbusprofile genannt, sind Vereinbarungen, 

nach denen die Datenübertragung zwischen zwei 

oder mehreren Parteien abläuft. Diese beschreiben nicht 

die anwendungsbezogenen Fähigkeiten der Kommunikationspartner, 

sondern deren Fähigkeiten zur Kommunikation. 

Beispiele sind DIN IEC 61158-500&600 (Feldbusanwendungsprofile), 

DIN IEC 61784-1 (Industrielle 

Kommunikationsnetze – Feldbusprofile) oder ISO 9506 

(Manufacturing Message Specification). 

Gerätebeschreibungen (beispielsweise GSD, EDD, EDS, 

FDCML, XIF) und Integrationskonzepte (FDT/DTM, FDI) 

machen Informationen und Funktionen von Feldgeräten 

zugänglich und erlauben somit das Bedienen, Ansteuern 

und Parametrieren von Feldgeräten über ein Kommunikationssystem. 

Feldgeräteparameter und -funktionen 

sind zwar in einer formalen Sprache beschrieben, jedoch 

herstellerindividuell festgelegt. Anwendungsbezogene 

Semantik ist daher nicht standardisiert. 

Zusammenfassung: Die Typisierung und Bewertung 

unterschiedlichster Standards hinsichtlich ihrer Eignung 

als Wissensquellen zum Aufbau von semantischen 

Informationsmodellen für die Plug-and-play-Feldgeräteintegration 

und die dynamische Orchestrierung hat 

ergeben, dass bestehende Richtlinien (beispielsweise 

die VDI 2411 und VDI 2860) Elementarfunktionen von 

komplexen mechatronischen Einheiten vorgeben können. 

Die Fähigkeiten einzelner Feldgeräte sind zwar 

computerlesbar in Gerätebeschreibungssprachen enthalten, 

jedoch ist die Semantik der Feldgerätefunktionen 

nicht geräteklassenübergreifend standardisiert. Klassifizierungssysteme 

und Merkmalleisten stellen dagegen 

eine wichtige Grundlage zur Einordnung und Abgrenzung 

im Vorfeld der Modellierung dar. Kommunikationsprotokolle 

und Produktbeschreibungen liefern den 

für die hier definierte Zielsetzung geringsten wiederverwendbaren 

Informationsgehalt. 

2.2 Feldgeräteprofile als Basis für Instanzen 

Aufgrund der fehlenden Anwendungssemantik eignen 

sich die zuvor genannten Standards nur eingeschränkt 

für den Aufbau konkreter semantischer Informationsmodelle 

zur Beschreibung der Feldgeräteansteuerung. 

Eine weiterführende Analyse hat ergeben, dass die benötigte 

Information primär in Feldgeräteprofilen enthal- 


12 / 2012 

47

HAUPTBEITRAG 

ten ist. Beispiele für Feldgeräteprofile und deren zugehörige 

Anwendungsgebiete zeigt Tabelle 1. 

Zu unterscheiden sind Sammlungen von Feldgeräteprofilen 

(beispielsweise CiA device profile, CIP oder spezielle 

Applikationsprofile der PNO), die für spezielle 

Kommunikationssysteme definiert sind und solche für 

einzelne Gerätetypen. Zur Verdeutlichung des in Feldgeräteprofilen 

enthaltenen Wissens werden einige Antriebsprofile 

nachfolgend vorgestellt: 

Das CiA 402 drives and motion control device profile 

beschreibt auf 274 Seiten allgemeine Definitionen, Betriebszustände, 

Anwendungsdaten, Operation Modes zur 

Abbildung verschiedener Betriebsarten sowie anwendungsunabhängige 

Parameter (Metadaten) wie Motortyp, 

Katalognummer, Hersteller und Fehlercodes. 

Das CIP Volume 1 enthält auf zwölf der insgesamt 1494 

Seiten ein Profil für AC- und DC-Antriebe, welches optionale 

und vorgeschriebene Objekte von Antrieben vorgibt, 

zugehörige Parameter festlegt und auf Wertebereiche 

referenziert. 

Das Profidrive-Profil der PNO (Zeile drei in Tabelle 1) 

definiert auf 287 Seiten Betriebsmodi, Gerätezustände, 

Datentypen, funktionale Objekte, Anwendungsszenarien, 

Kommunikationsbeziehungen, Kommunikationsdienste 

sowie Abbildungsvorschriften der Kommunikationssysteme 

Profibus und Profinet. 

PLCopen Motion Control definiert auf 141 Seiten Funktionsblöcke 

für die Antriebssteuerung. Ein Zustandsdiagramm 

erklärt, in welchem Zustand welche Funktionen 

möglich sind. 

Zusammenfassende Bewertung: Kerninhalt von Feldgeräteprofilen 

ist die Definition von Parametern, Funktionen 

und Verhalten von Feldgeräteklassen. Dabei sind jedoch 

erhebliche Unterschiede in Bezug auf die zugrunde liegenden 

Modellierungskonzepte, die Art der Wissensrepräsentation 

sowie den Grad und Umfang der standardisierten 

Inhalte die Regel. Die Art der Wissensrepräsentation bei 

Feldgeräteprofilen folgt meist dem Steuer-/Statuswort-Paradigma, 

das heißt, unterschiedliche Funktionen werden 

auf Bitstreams abgebildet. Ein direktes und intuitives Ablesen 

von Funktionen oder Parametern aus dem Profil wird 

dadurch erschwert. Zur Reduzierung des Engineeringaufwands 

ist die Anhebung der Abstraktionsebene auf eine 

funktionsorientierte, taxonomieähnliche Wissensrepräsentation 

notwendig. Durch Abbildung der Beziehungen zwischen 

den einzelnen Funktionen und Parametern, beispielsweise 

mithilfe von Ontologien, kann darüber hinaus 

die Semantik der Daten dem Computer verständlich gemacht 

werden, was somit neue Wege des computergestützten 

Engineerings eröffnet. Trotz ihrer Unterschiede enthalten 

Feldgeräteprofile einen hohen Anteil anwendungsbezogener 

Semantik, wodurch die Basis für Anwendungsfälle 

wie die Plug-and-play-Feldgeräteintegration oder die 

dynamische Prozessorchestrierung vorhanden ist. 

2.3 Ontologiebasierte Informationsmodelle 

Neben der Möglichkeit, bestehende Standards zur Erstellung 

konkreter Instanzen von semantischen Informationsmodellen 

zu nutzen, bietet sich die Wiederverwendung 

existierender Ontologien an. Trotz des steigenden Interesses 

an der semantischen Modellierung im Bereich der Automatisierungstechnik, 

siehe [8] und [9], existieren nur 

wenige wiederverwendbare und frei verfügbare Ontologien. 

Dieses Defizit ist insbesondere auf die aufwendige und 

komplexe Modellierung von Ontologien zurückzuführen. 

Neben der fehlenden Unterstützung durch intuitive Modellierungswerkzeuge, 

die auch von Nicht-Experten genutzt 

werden können, mangelt es insbesondere an Möglichkeiten 

zur effizienten Wissensakquisition. Diese umfasst 

die Identifizierung geeigneter Wissensquellen sowie 

die Extraktion des enthaltenen Wissens als Grundlage zur 

Erstellung semantischer Informationsmodelle. Der in diesem 

Beitrag verfolgte Lösungsansatz besteht in der Nutzung 

existierender Standards (Abschnitt 2.1), um einerseits 

den Wissensakquisitionsprozess effizienter zu gestalten 

und andererseits eine breite Akzeptanz der erstellten 

Informationsmodelle zu erreichen. 

Bei der Untersuchung existierender wiederverwendbarer 

Ontologien wird deutlich, dass es sich dabei meist 

um Ontologien handelt, die domänenunabhängiges Allgemeinwissen 

definieren (zum Beispiel Sumo, Cyc). Mit 

Mason, Adacor und Avilus existieren jedoch auch produktionsspezifische 

Ontologien, die grundlegende Terminologien 

und Begriffszusammenhänge darstellen, 

beispielsweise über Produkte, Produktionsmittel und 

Funktionen. Diese Ontologien bilden durch die Festlegung 

einer anwendungsübergreifenden Terminologie 

eine wichtige Grundlage, um eine semantische Interoperabilität 

zwischen heterogenen Systemen zu gewährleisten. 

Es mangelt jedoch weiterhin an konkreten, formal 

definierten Domänenontologien zur Abbildung 

verschiedener Terminologien von Feldgerätefunktionalitäten 

wie sie sich beispielsweise aus Feldgeräteprofilen 

und Richtlinien extrahieren lassen. 

3. ANWENDUNGSFÄLLE 

3.1 Plug-and-play-Feldgeräteintegration 

Die Inbetriebnahme und Integration von Feldgeräten 

lässt sich in den mechanischen Einbau inklusive Verkabelung 

(I), die Einzelinbetriebnahme der Feldgeräte (II), 

die Konfiguration der Kommunikationsverbindung (III), 

die Programmierung der SPS (IV) und den Test des Gesamtprogramms 

(V) gliedern. Durch die Plug-and-play- 

Feldgeräteintegration lassen sich die Schritte II und III 

sowie große Teile des Schrittes IV automatisieren. Dazu 

sind abstrakte Programmierschnittstellen, selbstkonfigurierende 

Kommunikationssysteme sowie laufzeitadaptierbare 

SPS-Programme nötig. Abstrakte Programmierschnittstellen 

stellen aufrufbare Funktionen für 

einzelne Feldgeräteklassen zur Verfügung. Dadurch 

muss das später zu verwendende Feldgerät zum Zeitpunkt 

der Programmentwicklung nicht bekannt sein. 

Ein Gerätetausch zur Betriebszeit erfordert darüber hinaus 

eine um spezielle Softwaremodule erweiterte SPS. 

Neben einem Gerätemanager, der unter anderem die 

Konfigurationssätze aller benötigten Feldgeräte vorhält, 

muss das den Produktionsprozess beschreibende SPS- 

Programm auf Basis abstrakt definierter Programmierschnittstellen 

erstellt sein. Letztere sind ein Beispiel für 

48 


12 / 2012

konkrete semantische Informationsmodelle. Bei bekannter 

Geräteposition kann eine SPS dadurch einen 

Abgleich zwischen der weggefallenen und der neu hinzugefügten 

Gerätefunktionalität vornehmen und so ein 

Ersatzgerät automatisch einbinden. Weitere Details eines 

ersten Konzeptdemonstrators können [1] entnommen 

werden. Dieser ist Teil der Versuchsanlage der 

Technologie-Initiative Smartfactory kl e.V. (Bild 3). 

3.2 Dynamische Orchestrierung von Produktionsprozessen 

Der Ansatz der dynamischen Orchestrierung baut auf 

Ideen zur digitalen Veredelung von Anlagenkomponenten 

auf, bei der die mechatronischen Funktionalitäten 

von Feldgeräten einer Anlage, beispielsweise dem Paradigma 

der Serviceorientierung folgend, zusammen 

mit der ausführenden Hardware gekapselt werden. Eine 

Implementierung dieses Ansatzes erfolgt oft mithilfe 

von Webservices, also über Internetprotokolle aufrufbare, 

abgeschlossene Anwendungen, deren Schnittstellen 

mit standardisierten Beschreibungssprachen definiert 

werden. Die somit durch Webservices bereitgestellten 

Funktionalitäten von Feldgeräten lassen sich 

zu höherwertigen Prozessen kombinieren und zur Anlagensteuerung 

nutzen. 

Eine dynamische Orchestrierung ist auf Basis heutiger 

Standardtechnologien (zum Beispiel WSDL, BPEL) jedoch 

kaum möglich, da diese auf syntaktischer Ebene arbeiten. 

Die Bedeutung der hinter einer Webservice-Definition 

Name Anwendungsgebiet Ersteller Implementierung 

CiA device profile 

Diverse Geräte der 


CAN in Automation 

CAN, Canopen, 

Ethercat, Powerlink 

Common Industrial 

Protocol 



Open DeviceNet Vendor 

Association (ODVA) 

Componet, Controlnet, 

Devicenet, Ethernet/IP 

Spezifische 

Applikationsprofile 



Profibus Profinet Nutzerorganisation 

(PNO) 

Profibus, Profinet 

Controller-to- 

Controller Profile 

DIN EN 61800-7-1/-20x/ 

-30x: Antriebsprofile 

Antriebe Sercos international e.V. Ethercat, Sercos 

Antriebe 

Deutsches Institut für Normung 

CiA, CIP, Profidrive, 

Sercos 

DriveCom Profile Antriebe DriveCom User Group e.V. Interbus 

PLCopen Motion Control 

Function Blocks 

Antriebe PLCopen organization in SPSen 

OPC UA ADI (Analyzer 

Device Interface) 

Mess- & Analysegeräte der 

Verfahrenstechnik 

OPC Foundation 

OPC UA 

PackML: Packaging 

Machine Language V3.0 

Verpackungsmaschinen 

Organization for Machine Automation 

and Control (OMAC) 

continuous flow process 

colored soap production 

discret handling process 

bottling, handling, labeling, QC, packaging... 

TABELLE 1: Auswahl von 

Feldgeräteprofilen in der 


BILD 3: 

Die Versuchsanlage 

Smart Factory 

Kaiserslautern 


12 / 2012 

49

HAUPTBEITRAG 

BILD 4: 

Ausschnitt einer Ontologie 

zur Beschreibung von 

Feldgerätefunktionalitäten 

liegenden Funktionalität wird durch Maschinen also 

nicht verstanden. Durch die semantische Annotation von 

Webservices kann die zur Verfügung gestellte Funktionalität 

in einer maschinenverständlichen Art und Weise 

beschrieben werden, wodurch beispielsweise Webservices 

mit gleicher oder ähnlicher syntaktischer Beschreibung 

hinsichtlich der Semantik ihrer Schnittstellen- und 

Funktionsbeschreibungen unterschieden werden können. 

Des Weiteren wird es möglich, mittels Reasoning- 

Prozessen, basierend auf der semantischen Beschreibung, 

einen automatischen Abgleich und eine entsprechende 

Selektion geeigneter Funktionalitäten umzusetzen. 

Grundgedanke des realisierten Anwendungsfalls ist 

die Orchestrierung von Produktionsprozessen ausgehend 

von einer abstrakten Prozess- und Produktbeschreibung 

abhängig vom konkreten Aufbau der Produktionsanlage 

und der von den Feldgeräten angebotenen Funktionalitäten. 

Zudem können Produktionsprozesse dynamisch sogar 

zur Laufzeit an vorkommende Ereignisse (zum Beispiel 

Ausfall eines Feldgeräts) angepasst werden, indem 

ähnliche Funktionalitäten anderer Feldgeräte gefunden 

und in den Prozess eingebunden werden. 

Der beschriebene Anwendungsfall einer dynamischen 

Orchestrierung entstand im Rahmen der Smart Factory 

Kaiserslautern. Dazu wurden verschiedene Feldgeräte der 

Anlage mit Mikrokontrollern ausgestattet, über die die 

Funktionalitäten der Feldgeräte als Webservices im Netzwerk 

der Anlage angeboten und durch ein Orchestrierungsprogramm 

von einem zentralen PC aufgerufen werden 

[10]. Das Orchestrierungsprogramm ermittelt, ausgehend 

von der abstrakten Prozessbeschreibung des zu 

fertigenden Produkts, welche Webservices in der vorliegenden 

Anlage aktuell verfügbar sind und wie diese orchestriert 

werden müssen, um den gewünschten Prozess 

zu realisieren. Dabei findet ein semantischer Abgleich der 

benötigten und vorhandenen Funktionalitäten statt. Die 

semantische Beschreibung der Webservices erfolgt durch 

Annotation mit den Konzepten verschiedener OWL-Ontologien, 

die beispielsweise Feldgerätefunktionalitäten, 

Geräteklassen sowie Anlagenstrukturen beinhalten. 

Bild 4 zeigt einen Ausschnitt einer Ontologie zur semantischen 

Beschreibung von Feldgerätefunktionalitäten. 

Neben den zur Annotation genutzten Instanzen von Funktionalitäten 

(zum Beispiel Write, Hold) werden aktuell im 

System vorhandene Webservices durch Instanzen repräsentiert 

(zum Beispiel Camera_Keyence_CA900011). 

REFERENZEN 

[1] Hodek, S. und Schlick, S.: Plug&Play Feldgeräteintegration 

– Methoden, Softwarekonzepte und technische Realisierungsformen 

für eine ad hoc Feldgeräteintegration. In: 

Tagungsband Automation, S. 63-66, VDI, 2012 

[2] Loskyll, M., Heck, I., Schlick, J., Schwarz, M.: Contextbased 

Orchestration for Control of Resource-efficient 

Manufacturing Processes. Future Internet 4(3), 737-761, 

2012 

[3] Zühlke, D.: SmartFactory – Towards a factory-of-things, 

IFAC journal Annual reviews in control 34(1), 129 138, 2010 

[4] Mahnke, W., Gössling, A., Urbas, L.: Informationsmodellierung 

für Middleware in der Automatisierung. In: Tagungsband 

Automation, S. 119-124, VDI, 2011 

[5] VDI/VDE 2657: Middleware in der Automatisierungstechnik, 

Dezember 2010 

[6] Blumauer, A. und Pellegrini, T.: Semantic Web und 

semantische Technologien: Zentrale Begriffe und 

Unterscheidungen. In: T. Pellegrini und A. Blumauer (Hrsg.) 

50 


12 / 2012

FAZIT 

Die Realisierung eines Plug-and-play erfordert die Existenz 

einer Schnittstelle, die es zur Betriebszeit erlaubt, den Funktionsaufruf 

im SPS-Programm einer zur Entwurfszeit unbekannten 

Feldgerätefunktionalität zuzuordnen. Ein semantisches 

Informationsmodell, welches die Funktionalitäten 

der Feldgeräte beschreibt, gewährleistet die Interoperabilität 

dieser Schnittstelle. Die dynamische Orchestrierung basiert 

auf dem semantischen Vergleich von Eigenschaften von 

Feldgerätefunktionalitäten zur Laufzeit. Kern dieses Beitrags 

ist die Untersuchung existierender Standards zur Wissensextraktion 

bei der Instanziierung dieser semantischen Informationsmodelle. 

Das Ergebnis: Vor allem Feldgeräteprofile 

stellen eine grundlegende Wissensquelle dar, da hier 

bereits herstellerübergreifend einzelne Funktionalitäten von 

Feldgeräteklassen genormt sind. Diese Vereinheitlichung 

basiert jedoch meist auf Bit/Byte-Ebene und einer Prosa- 

Beschreibung der Funktionalität, was eine manuelle Formalisierung 

notwendig macht. Spezifische semantische Informationsmodelle 

und Middleware-Paradigmen sind damit 

Grundlage dafür, den Integrationsaufwand erheblich zu 

reduzieren und somit den Weg zur flexiblen und wandelbaren 

Fabrik zu ebnen. 


01.07.2012 

DANKSAGUNG 


Die hier beschriebenen Arbeiten wurden teilweise mit 

Mitteln des Bundesministeriums für Bildung und 

Forschung unter dem Förderkennzeichen 01IA11001 

(Projekt RES-COM) gefördert. Die Verantwortung für 

den Inhalt dieser Veröffentlichung liegt bei den Autoren 

AUTOREN 

Dipl-Ing. STEFAN HODEK 

(geb. 1981) studierte 

Elektrotechnik an der TU 

Kaiserslautern. Seit 2008 ist 

er Researcher am DFKI und 

Mitglied im VDI Fachausschuss 

für Middleware. 

Seine Forschungstätigkeiten 

liegen im Bereich von 

Steuerungs- und Kommunikationssystemen im 

Allgemeinen und in der Feldgeräteintegration 

im Speziellen. 

Deutsches Forschungszentrum 

für Künstliche Intelligenz, 

Trippstadter Str. 122, D-67663 Kaiserslautern, 

Tel. +49 (0) 631 205 75 34 07, 

E-Mail: stefan.hodek@dfki.de 

M.Sc. MATTHIAS LOSKYLL 

(geb. 1984) studierte Informatik 

an der Universität des 

Saarlandes. Seit 2009 ist er 

als Researcher am DFKI im 

Forschungsbereich „Innovative 

Fabriksysteme“ tätig. 

Seine Forschungsaktivitäten 

beschäftigen sich hauptsächlich 

mit der Anwendung semantischer Technologien 

in der Automatisierungstechnik. 




Tel. +49 (0) 631 205 75 52 85, 

E-Mail: matthias.loskyll@dfki.de. 

Semantic Web. Wege zur Wissensgesellschaft, 

S. 9-25. Springer, 2006 

[7] Gruber, T.: A Translation Approach to Portable Ontology 

Specifications. Knowledge Acquisition 5(2), 199-220, 1993 

[8] Wollschlaeger, M., Runde, S., Brauen, A., Mühlhause, M., 

Drumm, O., Thomalla, C., Sabov, A., Lindemann, L.: 

Semantische Integration im Lebenszyklus der Automation. 

In: Tagungsband Automation, S. 169-170. VDI, 2009 

[9] Runde, S., Dibowski, H., Fay, A., Kabitzsch, K.: A semantic 

requirement ontology for the engineering of building 

automation systems by means of OWL. In: Proceedings 

14th IEEE International Conference on Emerging Technologies 

and Factory Automation (ETFA’09), S. 1-8, 2009 

[10] Loskyll, M., Schlick, S., Hodek, S., Ollinger, L., Gerber, T., 

Pîrvu, B.: Semantic Service Discovery and Orchestration 

for Manufacturing Processes. In: Proceedings 16th IEEE 

International Conference on Emerging Technologies and 

Factory Automation (ETFA’11), S. 1-8, 2011 

Dr.-Ing. JOCHEN SCHLICK 

(geb. 1974) promovierte 

2005 an der TU Kaiserslautern 

im Bereich von kognitiven 

Mikromontagesystemen. 

Nach einer mehrjährigen 

Tätigkeit in der strategischen 

Produktionsoptimierung 

bei Bosch kehrte er 

2009 als stellvertretender Forschungsbereichsleiter 

für innovative Fabriksysteme in die 

Forschung zurück. 




Tel. +49 (0) 631 205 75 34 05, 

E-Mail: jochen.schlick@dfki.de 


12 / 2012 

51

HAUPTBEITRAG 

Automatisierung mit FASA 

Eine Architektur für flexible, verteilte Systeme 

Multicore-Prozessoren werden vermehrt in der Automatisierungstechnik eingesetzt. Dies 

erzeugt neue Herausforderungen für die Softwareentwicklung: Einerseits soll die vorhandene 

Hardware optimal ausgenutzt, andererseits müssen strenge Echtzeitanforderungen 

auch von paralleler Software erfüllt werden, und die Systeme sollen flexibel bleiben, um 

zeitnah auf Änderungen der Systemanforderungen reagieren zu können. Der Beitrag befasst 

sich mit Fasa (Future Automation System Architecture), einer komponentenbasierten 

Architektur und Ausführungsumgebung für modulare, verteilte und dynamische Automatisierungssysteme 

mit Multicore-Prozessoren. Die Architektur vereinfacht die deterministische 

verteilte Ausführung von Applikationen. Fasa bietet Features wie softwarebasierte 

Fehlertoleranz und Softwareupdates zur Laufzeit als einfach zu nutzende Dienste 

für den Anwendungsentwickler. 

SCHLAGWÖRTER Verteilte Systeme / Multicore / Modularität / Fehlertoleranz 

Flexible distributed automation systems with FASA – 

A software architecture for parallel real-time systems 

The advent of multicore CPUs in automation raises some challenges for software engineering. 

On the one hand, existing hardware should be optimally used. On the other hand, 

strict real-time requirements must be satisfied by parallel software. At the same time, 

systems should remain flexible to be able to react quickly to changing system requirements. 

Fasa is a component-based architecture and execution environment for modular, dynamic 

automation systems with multicore CPUs and distributed execution. Fasa simplifies the 

deterministic distributed execution of applications and offers novel features such as 

software-based fault tolerance and software updates during runtime as transparent and 

easy-to-use services for application developers. 

KEYWORDS distributed systems / multicore / modularity / fault tolerance 

52 


12 / 2012

MICHAEL WAHLER, THOMAS GAMER, MANUEL ORIOL, ATUL KUMAR, MARTIN NAEDELE, 

ABB Corporate Research, Industrial Software Systems 

Die Zeit des Free Lunch [3] ist leider vorbei, in 

der regelmäßig immer schnellere Prozessoren 

entwickelt wurden, auf denen herkömmliche 

sequenzielle Software immer schneller lief. 

Performancegewinne werden in Zukunft nur 

mit einer größeren Anzahl von CPU-Cores erzielt. Sequenzielle 

Software aber läuft auf mehreren Cores nicht 

schneller. Von Multicore-Prozessoren kann nur profitieren, 

wer Software parallelisiert. Das ist jedoch nicht 

einfach, da parallele Software die Synchronisierung von 

parallelen Threads erfordert, was in der Praxis zu fehlerhaften 

Abläufen (race conditions) oder zum Stillstand 

des Systems (deadlocks) führen kann. Als wäre das nicht 

genug, müssen Softwareentwickler die immer komplexeren 

CPU-Architekturen berücksichtigen, in denen es 

mehrere Cache-Levels gibt und manche Caches von mehreren 

Cores gemeinsam benutzt werden. 

Diese Probleme werden mit der zukünftigen Hardwareentwicklung 

sogar noch zunehmen. Während es 

relativ einfach ist, die eigene Software an Dual-Core- 

Prozessoren anzupassen, ist es ungleich schwieriger, 

Software für 16, 48 oder 100 Cores zu skalieren. Daher 

muss schon während der Entwicklung einer Ausführungsumgebung 

und deren Softwarearchitektur darauf 

geachtet werden, dass potenziell eine große Anzahl an 

Ausführungsressourcen (CPUs in einem Multi-CPU- 

System oder Cores in einer Multicore-CPU) zur Verfügung 

steht. 

In diesem Beitrag stellen die Autoren Fasa (Future 

Automation System Architecture) vor, eine Softwarearchitektur 

und Ausführungsumgebung für zukünftige 

Automatisierungssysteme mit Multicore-Prozessoren 

und verteilter Ausführung. Fasa kombiniert 

eine flexible Erstellung und Verteilung von Anwendungen 

mit streng statischer, deterministischer Ausführung. 

Dabei bietet Fasa dem Anwendungsentwickler 

vollständige Transparenz bezüglich des Ausführungsortes: 

Je nach Systemkonfiguration lässt sich die gleiche 

Anwendung auf einem CPU-Core, auf mehreren Cores 

der gleichen CPU, oder auf mehreren CPUs verteilt über 

mehrere Rechnerknoten (Controller) ausführen. Hierfür 

wird beim Deployment ein Schedule errechnet, der die 

zeitlichen Anforderungen der Anwendungen, Abhängigkeiten 

zwischen Komponenten und Latenzen der 

Kommunikationsmechanismen berücksichtigt. Darüber 

hinaus bietet Fasa neuartige Features wie softwarebasierte 

Fehlertoleranz und unterbrechungsfreie 

Softwareupdates zur Laufzeit, die für den Anwendungsentwickler 

transparent sind. 

Bild 1 zeigt die grundlegende Architektur von Fasa. 

Auf Hardwareseite gibt es eine beliebige Anzahl von 

Prozessoren, die über einen Echtzeit-Bus kommunizieren 

können. Das Fasa-Runtime-Framework bietet eine 

Abstraktion der Hardware und eine Ausführungsumgebung 

für Applikationen. Applikationen werden, wie 

im Bild gezeigt, transparent in dieser Ausführungsumgebung 

ausgeführt. 

1. GRUNDKONZEPTE VON FASA 

Fasa stellt einige Basiskonzepte und -mechanismen zur 

Verfügung, die die Grundlage für komplexere Mechanismen 

bilden, beispielsweise Softwareupdates oder softwarebasierte 

Fehlertoleranz. 

1.1 Komponenten, Blöcke und lineare statische Schedules 

Fasa ist ein Framework für die Entwicklung und Ausführung 

zyklischer Kontrollanwendungen. Fasa unterstützt 

eine komponentenbasierte Definition der Kontrollanwendungen; 

durch die erreichte Modularität 

bietet Fasa eine erhöhte Flexibilität und Anpassbarkeit. 

Komponenten bestehen aus einem oder mehreren Blöcken, 

die die elementaren Ausführungsbausteine darstellen. 

Jeder Block realisiert genau einen Aspekt der 

Funktionalität seiner Komponente, das heißt, Blöcke 

implementieren in sich abgeschlossene Funktionalitäten. 

Blöcke in Fasa dürfen daher nicht blockieren und 

müssen immer terminieren [2]. Eine Komponente hat 

einen Zustand, auf den die in ihr enthaltenen Blöcke 


12 / 2012 

53

HAUPTBEITRAG 

zugreifen können. Zudem kann eine Komponente Parameter 

definieren, welche während der Laufzeit durch 

eine definierte Schnittstelle von außen verändert werden 

können. Alle Blöcke derselben Komponente haben 

gemeinsamen Zugriff auf den Zustand und die Parameter 

der Komponente. Zustandsdaten in unterschiedlichen 

Komponenten sind jedoch streng voneinander 

getrennt. Da die Blöcke selbst zustandslos sind (nur die 

sie umgebende Komponente hat einen Zustand), lassen 

sich diese sehr einfach während der Laufzeit austauschen. 

Der Kontext der Blöcke bleibt durch die Zustandshaltung 

in den Komponenten jedoch erhalten. In 

Bezug auf das Deployment einer Anwendung stellen 

Komponenten die kleinste Einheit in Fasa dar, das 

heißt, eine Komponente kann nicht verteilt ausgeführt 

werden. Das bedeutet, dass Blöcke derselben Komponente 

nicht auf unterschiedlichen Ressourcen ausgeführt 

werden können. Die verschiedenen Komponenten 

einer Anwendung können hingegen auf unterschiedlichen 

Ressourcen zur Ausführung gebracht werden. 

Blöcke können über Ports mit anderen Blöcken Daten 

austauschen. Dazu werden die Ports über Kanäle verbunden. 

Kanäle in Fasa sind unidirektional und 1-zu-1. Das 

bedeutet, dass höchstens ein Block auf einen gegebenen 

Kanal schreiben kann und höchstens ein Block davon 

lesen kann. Durch diese Elemente kann jede Anwendung 

in Fasa als gerichteter Graph dargestellt werden, in welchem 

Knoten die Blöcke repräsentieren und Kanten die 

Kanäle. 

Kanäle sind lediglich für den Datentransport verantwortlich. 

Sie übermitteln Daten ohne jegliche Prüfung, 

jedoch muss jedes Paar von Out-Port und In-Port, die 

miteinander verbunden sind, denselben Datentyp haben. 

Die Prüfung der Daten auf Plausibilität und Aktualität 

ist die Aufgabe des jeweiligen Blocks. Blöcke können 

über das Framework zur Laufzeit feststellen, welche ihrer 

Ports über einen Kanal verbunden sind. Bei miteinander 

verbundenen Blöcken stellt das Framework sicher, 

dass ein übertragenes Datenelement an den In-Port des 

Zielblocks geschrieben worden ist, bevor es mit der Ausführung 

des Zielblocks beginnt. 

Bild 2 zeigt eine Beispielanwendung in Fasa. Die Anwendung 

ist ein kaskadierter PID-Controller und besteht 

aus sechs Komponenten (dargestellt durch grüne Rechtecke), 

die mit ihrer ID (zum Beispiel I1, P1) und dem jeweiligen 

Komponententyp (zum Beispiel Feldbus In, PID 

Controller) beschriftet sind. Mit Ausnahme der Komponente 

I1 vom Typ Feldbus In, welche zwei Blöcke (dargestellt 

durch blaue Rechtecke) bereitstellt, haben alle 

Komponenten nur jeweils einen Block. Kanäle sind 

durch Pfeile verdeutlicht und mit ihrem Datentyp beschriftet. 

In-Ports sind links von ihrem zugehörigen 

Block als kleine Quadrate erkenntlich. Out-Ports sind 

rechts von ihrem Block durch kleine Quadrate am Beginn 

der gerichteten Verbindung dargestellt. 

Eine weitere Besonderheit von Fasa ist, dass die Firmware 

selbst modular aufgebaut ist. Ähnlich wie im 

Microkernel-Konzept von Betriebssystemen gibt es einen 

kleinen Kern, der für die Ausführung von Komponenten 

zuständig ist. Die meisten Systemfunktionalitäten 

(zum Beispiel Netzwerkkommunikation) sind als 

Komponenten realisiert. Dadurch genießen diese Systemfunktionalitäten 

die gleichen Vorteile wie normale 

Applikationen, zum Beispiel dynamische Softwareupdates. 

Anwendungen in Fasa werden zyklisch ausgeführt. 

Hierfür kann entweder für die gesamte Anwendung oder 

für jeden einzelnen Block eine Ausführungsfrequenz 

(Periodizität) definiert werden. 

Fasa unterstützt die lineare Ausführung von Anwendungen 

mit einem statischen Schedule. Das bedeutet, 

dass zur Zeit des Deployments eine lineare Ordnung 

über alle Blöcke, die in den Komponenten einer Anwendung 

definiert sind, berechnet wird. Grundlage für diese 

Ordnung ist die Abhängigkeit zwischen den Blöcken, 

die sich durch den über die Kanäle definierten Datenfluss 

ergibt. Das heißt, dass ein Block A, der ein Datenelement 

an einen anderen Block B sendet, auch vor diesem 

ausgeführt werden muss. Diese lineare Ordnung ist 

die Grundlage für die Abarbeitungssequenz der Blöcke 

in jedem Zyklus. Dabei wird die Ausführung eines einzelnen 

Blocks nie unterbrochen. Auf einem Fasa-System 

können mehrere unterschiedliche Schedules hinterlegt 

sein, die jeweils in einer Konfiguration abgelegt sind. Zu 

jedem Zeitpunkt ist genau eine Konfiguration aktiv. 

Zu jeder Anwendung können mehrere oder auch keine 

Linearisierung existieren. Sollte keine Linearisierung 

möglich sein, muss der Anwendungsumfang reduziert 

werden. Bild 3 zeigt eine Linearisierung der Beispielanwendung 

aus Bild 2. 

Rückkopplungen sind ein häufig eingesetztes Gestaltungselement 

in der Automatisierungstechnik, da sie es 

erlauben, die Ausgangswerte eines Prozesses als Eingangswerte 

für die nächste Iteration des Prozesses zu 

verwenden. Die einfachste Art der Rückkopplung ist in 

Bild 4 (a) durch einen Kanal dargestellt, der einen Out- 

Port eines Blocks mit einem In-Port verbindet. Um eine 

semantisch korrekte lineare Ordnung zwischen den Blöcken 

zu erreichen, werden Rückkopplungen in Fasa realisiert, 

wie in Bild 4 (b) gezeigt: Statt eines Kanals wird 

das für die Rückkopplung benötigte Datenelement von 

einem Hilfsblock (Mem) im Zustand der Komponente 

abgelegt. Bei der Ausführung liest Block 1 jenes Datenelement 

dann aus dem Zustand, anstatt es von seinem 

In-Port zu lesen wie in Bild 4 (a). Auch kompliziertere 

Rückkopplungsmechanismen lassen sich durch eine solche 

Konstruktion realisieren. 

Mit zunehmender Anzahl von Komponenten und Abhängigkeiten 

zwischen Komponenten wird es schwieriger, 

korrekte Linearisierungen zu berechnen. In verteilten 

Systemen (mit Multicore-Prozessoren und/oder mehreren 

Rechnerknoten) müssen zudem auch mehrere 

Ausführungsressourcen synchronisiert werden, die 

parallel jeweils einen linearen Schedule ausführen. 

Hierbei müssen auch unterschiedliche Latenzen betrachtet 

werden, da die Kommunikation zwischen zwei CPU- 

Cores im Allgemeinen schneller abläuft als zwischen 

zwei Hosts in einem verteilten Automatisierungssystem. 

Ebenfalls muss berücksichtigt werden, dass manche 

Komponenten nur auf bestimmten Ausführungsressourcen 

laufen können, wenn zum Beispiel ein spezieller I/O 

benötigt wird. Im nächsten Abschnitt wird beschrieben, 

54 


12 / 2012

wie sich die Scheduleberechnung automatisieren lässt 

und damit auch Anwendungen transparent auf einem 

verteilten System ausgeführt werden können. 

1.2 Verteilte Ausführung und globaler Schedule 

Ausführungsressourcen werden in Fasa Hosts genannt. 

Jeder Host führt eine Instanz des Fasa-Kernels aus. Ein 

solcher Host ist entweder ein Single-Core-Computer oder 

ein einzelner Core in einem Multicore-Computer. In beiden 

Fällen wird ein Echtzeitbetriebssystem vorausgesetzt. 

In einem komplexen System mit mehreren Hosts 

und einer Vielzahl von Anwendungen können Komponenten 

derselben Anwendungen auf mehrere Hosts verteilt 

oder Komponenten unterschiedlicher Anwendungen 

auf dem gleichen Host geladen werden. Hierbei wird 

vorausgesetzt, dass alle Hosts zeitsynchronisiert werden, 

zum Beispiel nach dem Precision-Time-Protocol (IEEE 

1588, [5]), welches mit Fokus auf lokale Netze und geringem 

Aufwand bezüglich Bandbreite und Rechenzeit entwickelt 

wurde. 

Um eine verteilte Ausführung zu erreichen, muss 

beim Deployment ein System-Schedule berechnet werden. 

Der System-Schedule bestimmt, welcher Block zu 

welcher Zeit (Offset) im Zyklus auf welchem Host ausgeführt 

wird. Bild 5 zeigt einen solchen Schedule für 

die Beispielanwendung aus Bild 2 für ein System mit 

zwei Hosts. 

Bei der Berechnung des System-Schedules ist eine 

Vielzahl von Parametern zu berücksichtigen: Die 

partielle Ordnung der Blöcke, die maximale Laufzeit 

jedes Blocks (worst-case execution time, WCET) auf 

den verschiedenen Hosts, die Frequenz der einzelnen 

Blöcke, und die Zyklenlängen auf den jeweiligen 

Hosts. Darüber hinaus hängt die Zeit, die benötigt 

wird, um ein Datenelement von einem Block A an 

einen Block B zu schicken, von der relativen Position 

von A und B ab. Blöcke auf verschiedenen Hosts 

kommunizieren über IPC-Mechanismen, falls die 

Hosts auf verschiedenen Cores derselben CPU laufen, 

oder über Netzwerk-Proxies, falls die Hosts auf verschiedenen 

Systemen laufen. Schließlich soll es am 

Ende jedes Zyklus noch eine Schlupfzeit (slack time) 

FASA Runtime Framework 

CPU Core 

CPU Core 

Controller 

Anwendungen 

CPU Core 

CPU Core 

... 

CPU Core 

CPU Core 

Echtzeit-Bus 

BILD 1: Die Architektur 

von Fasa im Überblick 

CPU Core 

Controller 

CPU Core 

I1: 

Feldbus In 

Temp 

Druck 

I2: 

Ethernet 

Track 

float 

float 

bool 

P1: 

PID 

Controller 

PidCC 

M1: 

Mathematik 

Bibliothek 

Offset 

float 

float 

P2: 

PID 

Controller 

PidCC 

float 

O1: 

Feldbus Out 

Ventil 

BILD 2: Eine Beispielanwendung 

in Fasa 

I1:Temp P1:PidCC I2:Track I1:Druck M1:Offset P2:PidCC O1:Ventil 

t 0 t 1 

BILD 3: Schedule für die Beispielanwendung 

C1: T1 

C1: T1 

Zustand 

Block 1 Block 1 Mem 

I1:Temp I1:Druck P1:PidCC 

t 0 t 1 

I2:Track 

M1:Offset P2:PidCC O1:Ventil 

(a) 

(b) 

BILD 4: Beispiel für die Realisierung 

von Rückkopplungen in Fasa 

t 0 t 1 

BILD 5: System-Schedule der Beispielanwendung auf zwei Hosts 


12 / 2012 

55

HAUPTBEITRAG 

geben, die es dem Betriebssystem erlaubt, andere Threads 

auszuführen. 

Für das Deployment von Fasa-Applikationen muss also 

zunächst ein verteiltes Scheduling-Problem gelöst werden. 

Dies wird offline durchgeführt, das heißt, bevor das 

System startet, und resultiert in jeweils einem statischen, 

linearen Schedule für jeden Fasa-Host. Ein solches Scheduling-Problem 

besteht aus zwei Teilen: eine Zuweisung 

jeder Komponente auf einen Host und die Berechnung 

eines Zeitintervalls für die Ausführung eines jeden 

Blocks. Die Zuweisung muss hierbei den Speicherbedarf 

der Komponenten und den verfügbaren Speicher auf jedem 

Host berücksichtigen. Die Zeitintervalle dürfen sich 

für Blöcke, die auf dem gleichen Host ausgeführt werden, 

nicht überlappen. 

Die Länge eines Zeitintervalls entspricht für die Lösung 

des Scheduling-Problems der WCET des jeweiligen 

Blocks. Es wird dabei angenommen, dass Blöcke bei jeder 

Ausführung ihre WCET in Anspruch nehmen. Da diese 

Annahme in der Praxis selten zutrifft, führt sie zu einer 

suboptimalen Ausnutzung der verfügbaren Rechenzeit. 

Dadurch, dass der Dispatcher jeden Block zu der durch 

die WCET bestimmten Zeit startet, wird jedoch der Jitter 

zwischen Zyklen minimiert, da die Abstände zwischen 

zwei Ausführungen eines jeden Blocks konstant sind. 

Das verteilte Scheduling-Problem in Fasa ähnelt typischen 

Job-Shop-Problemen, was dieses NP-schwer 

macht. Damit ist es praktisch unmöglich, ein solches 

Problem selbst für mittelgroße Systeme zu lösen [1]. Um 

Fasa skalierbar zu machen, ist eine automatisierte Lösung 

notwendig. Fasa benutzt einen Constraint-Programming-basierten 

Ansatz, um System-Schedules automatisiert 

zu berechnen [6]. 

1.3 Abstrahierung der Plattform 

Um die Wiederverwendbarkeit des Frameworks sowie 

der Anwendungen, Komponenten und Blöcke zu gewährleisten, 

bietet Fasa eine Schicht, um eine Abstraktion 

von der Hardware und vom verwendeten Betriebssystem 

zu gewährleisten. Hierfür müssen nur für wenige plattformspezifische 

Mechanismen Abstraktionen angeboten 

werden: 

Anwendungen 

FASA Kernel 

P1: 

PID 

Controller 

Speicher 

P1‘: 

PID 

Controller 

Plattformabstraktion 

PidCC 

PidCC 


v1 

v2 

BILD 6: Plattformabstrahierung 

... PidCC ... ... PidCC ... 

Schedule 1 Schedule 2 

BILD 7: Softwareupdate zwischen zwei Versionen von PID-Controller 

Host 1 

Host 2 

Host 3 

I1:Temp 

Mu 

Se 1 Se 2 

Se 4 

P1:PidCC 

Re 3 Re 4 

Voter 

Re 2 

P1‘:PidCC 

Re 1 

P1‘:PidCC Se 3 

BILD 8: 

System-Schedule 

des kritischen 

Pfads der 

redundanten 

Beispielanwendung 

auf drei Hosts 

t 0 

56 


12 / 2012

Timer erlauben es dem Framework, die Echtzeitanforderungen 

umzusetzen. Beispiel: zyklischer Start 

der Schedule-Ausführung. 

Datenübertragung (beispielsweise Message Queues 

oder Shared Memory) wird für die Implementierung 

von Kanälen benötigt. 

Synchronisierung (zum Beispiel Mutex oder Semaphoren) 

werden zur Benachrichtigung innerhalb des 

Frameworks verwendet. 

Threads werden vom Framework benutzt, um Applikationen 

mit höchster Priorität und Verwaltungsaufgaben 

mit niedriger Priorität auszuführen. 

In unserer Referenzimplementierung [2] wird die Plattformabstraktion 

durch eine Reihe von Wrapperklassen 

und Klassentemplates in C++ realisiert. Als Beispiel kapselt 

eine Klasse Thread den Zugriff auf die Threadbibliotheken 

des Betriebssystems, in unserer Implementierung 

auf die pthread-Bibliothek des POSIX-Standards. 

Diese Aufteilung ist in Bild 6 visualisiert. 

2. ERWEITERTE FEATURES VON FASA 

Aufbauend auf den bereits vorgestellten Grundkonzepten 

bietet Fasa eine Reihe von erweiterten Features, die 

die Performanz, Verfügbarkeit und Skalierbarkeit von 

Automatisierungssystemen verbessern. Da diese für den 

Anwendungsentwickler transparent sind, lassen sie sich 

einfach und kostengünstig nutzen beziehungsweise in 

die Anwendung integrieren. 

2.1 Softwareupdates zur Laufzeit 

Die komponentenbasierte Architektur von Fasa erlaubt 

es nicht nur, zur Entwurfszeit eine Komponente durch 

eine andere zu ersetzen, sondern auch zur Laufzeit. Im 

Gegensatz zu existierenden Lösungen ist es in Fasa 

möglich, die Applikationen (also die Verknüpfung von 

Komponenten) zu verändern, und Teile der Firmware 

auszutauschen. Durch die Microkernel-inspirierte Architektur 

von Fasa (Systemkomponenten wie zum Beispiel 

der Netzwerktransport werden genau wie Applikationskomponenten 

behandelt) und durch Verwendung 

von dynamischem Links kann so ein Großteil der 

Firmware ausgewechselt werden. Das ist auch im laufenden 

Betrieb ohne Beeinträchtigung des Systems 

möglich [4]. 

Es gibt mehrere Gründe, weshalb solch dynamische 

Softwareupdates notwendig sind. Zum einen kann selbst 

durch intensives Testen nicht ausgeschlossen werden, 

dass ein Bug im System verblieben ist. Durch dynamische 

Updates können entdeckte Bugs im laufenden Betrieb 

behoben werden. Ein weiterer Grund sind Security- 

Patches, da sich über die Lebensdauer eines Systems die 

Angriffsfläche eines Systems verändert. Ein Beispiel ist 

der Hashing-Algorithmus MD5, der lange Zeit als sicher 

galt, später aber durch zunehmende Rechenleistung und 

verbesserte Angriffsvarianten gebrochen wurde [9]. 

Schließlich können Softwareupdates zur Laufzeit dazu 

dienen, im Rahmen eines Servicevertrags die installierte 

Software auf dem neuesten Stand zu halten oder zusätzliche 

Software zu installieren. 

Bei dynamischen Updates für kritische Systeme ist es 

besonders wichtig, dass die Applikationen, die auf dem 

zu aktualisierenden System laufen, nicht gestört werden. 

Fasa ermöglicht es, Komponenten zur Laufzeit zu ersetzen, 

ohne das System anzuhalten oder auch nur einen 

Zyklus zu verpassen. Dies wird realisiert durch die Aufteilung 

des Updates in zwei Phasen: Vorbereitung und 

Umschaltung. 

In der Vorbereitungsphase wird der Code der neuen 

Komponenten zuerst auf das System kopiert (zum Beispiel 

mit dem SSH-basierten Secure Copy) und die gewünschten 

Komponenteninstanzen werden initialisiert. 

Gleichzeitig wird eine neue Konfiguration mit einem 

aktualisierten Schedule übertragen, der aber noch nicht 

aktiv ist. All diese Aktivitäten sind nicht zeitkritisch 

und werden als Thread parallel zu den Applikationen 

ausgeführt. In unserer Referenzimplementierung werden 

die auszuführenden Blöcke in jedem Zyklus in einem 

Thread mit höchster Priorität ausgeführt. Zwischen dem 

Ende des letzten Blocks und dem Beginn des nächsten 

Zyklus – also in der Schlupfzeit – blockiert dieser Thread. 

So kann das Betriebssystem Threads mit niedrigerer 

Priorität ausführen und zum Beispiel neue Komponenten 

laden. 

Bild 7 zeigt ein Beispiel für ein dynamisches Softwareupdate. 

Dabei wird eine Instanz der Komponente 

PID Controller in Version 1 (v1) durch eine neuere Version 

(v2) ersetzt. Das System führt vor dem Update den 

Schedule von Konfiguration 1 aus. Beim Softwareupdate 

wird zuerst in der Vorbereitungsphase eine Instanz P1‘ 

der neuen Komponentenversion instanziiert und initialisiert. 

Dann wird eine neue Konfiguration 2 erzeugt, 

deren Schedule statt dem PidCC-Block von P1 denjenigen 

von P1‘ aufruft. Sobald P1‘ initialisiert ist und Konfiguration 

2 erzeugt wurde, kann mittels API-Aufruf vom 

alten auf den neuen Schedule umgeschaltet werden. 

Sobald diese Vorbereitungsphase beendet ist, signalisiert 

das System, dass es bereit zum Umschalten ist. Das 

Umschalten erfolgt quasi-atomar zu Beginn eines neuen 

Zyklus durch das Umsetzen eines einzigen Zeigers. So 

wird verhindert, dass Teile des alten Schedules und Teile 

des neuen Schedules im selben Zyklus ausgeführt 

werden. Falls die Schedules von mehreren Hosts gleichzeitig 

geändert werden müssen, zum Beispiel wenn ein 

Update eine verteilt ausgeführte Anwendung betrifft, 

lassen sich die Updates durch Angabe eines gemeinsamen 

Zeitpunkts zum Umschalten synchronisieren. 

Nach dem Umschalten auf den neuen Schedule bleibt 

der alte Schedule zunächst im Speicher erhalten, ebenso 

wie eventuell nicht mehr benötigte Komponenten. Dies 

ist notwendig, um ein Rollback zu ermöglichen, falls das 

System nach dem Update nicht wie erwartet funktioniert. 

Falls das System korrekt funktioniert, können 

nicht mehr benötigte Komponenten und Schedules aus 

dem Speicher gelöscht werden. 

Einen Sonderfall beim dynamischen Update bilden 

zustandsbehaftete Komponenten. Hier muss der Zustand 

der alten Komponente zur neuen Komponente transfe- 


12 / 2012 

57

HAUPTBEITRAG 

riert werden. Die Schwierigkeit ist einerseits, dass sich 

die Struktur des Zustands ändern kann, zum Beispiel 

können sich Messwerte von km/h in m/s ändern. Andererseits 

kann es vor allem passieren, dass der Zustand 

von einzelnen Komponenten so umfangreich ist, dass er 

sich nicht innerhalb eines Zyklus übertragen lässt. Falls 

mehrere Zyklen zur Übertragung notwendig sind, kommt 

es vor, dass sich ein Teil des Zustands der Quellkomponente, 

der bereits zur Zielkomponente übertragen wurde, 

wieder ändert. Hierfür bietet Fasa einen Mechanismus 

zur Zustandsübertragung, der in [4] ausführlich erklärt 

ist. Im bereits genannten Beispiel des Updates der Komponente 

PID Controller von Version 1 auf Version 2 wird 

die Zustandsübertragung in der Vorbereitungsphase 

nach dem Initialisieren der Instanz P1‘ ausgeführt. Das 

System schaltet erst auf den neuen Schedule um, nachdem 

der Zustand von P1 vollständig auf P1‘ übertragen 

wurde. 

2.2 Softwarebasierte Fehlertoleranz und Safety 

Mithilfe der softwarebasierten Fehlertoleranz lässt sich 

eine hohe Verfügbarkeit für die mit Fasa ausgeführten 

Anwendungen erreichen. Dieses erweiterte Feature zeigt 

auch, dass Fasa aufgrund seiner Modularität und Flexibilität 

in der Lage ist, derartige erweiterte Features aufgrund 

der einfachen Wiederverwendbarkeit von Komponenten 

und der flexiblen Ausführungsumgebung 

schnell und vor allem transparent für den Anwendungsentwickler 

umzusetzen. Transparenz bedeutet in diesem 

Kontext, dass Fehlertoleranz beziehungsweise Redundanz 

in Fasa als Service für den Anwender angeboten 

wird. Dieser muss lediglich auswählen, dass er 

diesen Dienst nutzen möchte und einige grundlegende 

Parameter konfigurieren, zum Beispiel welches Redundanzmuster 

verwendet werden soll, welche Art von 

Fehler toleriert werden soll oder wie viele Fehler toleriert 

werden sollen. Die Berechung des Deployments, 

eines dazu passenden Schedules sowie die eigentliche 

Integration zusätzlich benötigter Komponenten in die 

Applikation übernimmt Fasa – der Anwendungsentwickler 

muss diese also weder selbst implementieren 

noch in seine Applikation integrieren. Darüber hinaus 

ermöglicht Fasa erfahrenen Anwendern, direkt Einfluss 

auf Detailebene zu nehmen, das heißt, beispielsweise 

das Deployment zu beeinflussen oder zu nutzende Algorithmen 

auszuwählen. 

Eine erste Design-Entscheidung, die im Kontext von 

Fehlertoleranz in Fasa getroffen werden musste, war 

die Frage nach der Granularität der Redundanz. Da 

Fasa ein komponentenbasiertes System ist, ließe sich 

Redundanz auf allen Ebenen anbieten. Redundanz auf 

Block-Ebene erbringt jedoch nur einen geringen Mehrwert, 

da Fehlertoleranz in diesem Fall auf einzelne 

Blöcke auf demselben Host – und damit auf den vergleichsweise 

unwahrscheinlichen Fall eines auf den 

Block begrenzten Fehlers – eingeschränkt wäre. Fehlertoleranz 

in Fasa ist daher auf Ebene der Komponenten 

angesiedelt. Dies hat mehrere Vorteile: Da Komponenten 

einen Zustand haben können, schließt Fehlertoleranz 

auf Komponenten-Ebene neben der Verfügbarkeit 

der Komponente auch deren Zustand mit ein. 

Außerdem ist eine feingranulare Abstufung für Verfügbarkeit 

möglich, das heißt, nur kritische Teile einer 

Anwendung müssen redundant ausgelegt werden, und 

somit können möglicherweise Ressourcen im Vergleich 

zur heute gebräuchlichen Anwendungsredundanz eingespart 

werden. Zudem können redundante Komponenten 

auf verschiedenen Cores oder Hosts ausgeführt 

werden. Somit werden deutlich mehr Fehlerszenarien, 

beispielsweise auch der Ausfall eines Controllers oder 

einer Netzwerkverbindung, abgedeckt als dies bei der 

Block-Redundanz der Fall wäre. Auch die Fehlertoleranz 

auf Applikations-Ebene kann realisiert werden, 

da dies lediglich eine Erweiterung der Komponenten- 

Redundanz darstellt. 

Die im Folgenden beschriebene beispielhafte Umsetzung 

des Redundanzmusters M-out-of-N [8] (die Komponente 

wird N-fach redundant ausgeführt; mindestens M 

dieser Instanzen müssen übereinstimmen, was mittels 

eines Voters überprüft wird) dient dem besseren Verständnis 

der Zusammenhänge. Stellt beispielsweise die 

Komponente P1 aus Bild 2 die kritische Komponente der 

Anwendung dar, und wurde das Redundanzmuster M- 

out-of-N angefordert, sowie ein Fehlermodell beschrieben, 

welches den Ausfall eines Hosts beziehungsweise 

Links abdecken soll und annimmt, dass keine externen 

Mechanismen zur Fehlererkennung zur Verfügung stehen, 

könnte Fasa das in Bild 8 dargestellte Deployment 

und einen dazu passenden Schedule berechnen. Hierbei 

ist zu sehen, dass Fasa zum Erreichen der Fehlertoleranz 

ein 2-out-of-3 Muster gewählt hat, sowie die zusätzlich 

benötigten Komponenten zur Umsetzung – einen Multiplier 

(Mu) für den Sensor-Input, einen Voter (Vo), mehrere 

Netzwerk-Proxies (Sender Se und Empfänger Re) 

und die redundanten Komponenten (P1‘) – automatisch 

hinzugefügt und im Schedule berücksichtigt hat. Dass 

im gezeigten Setup lediglich ein Voter genutzt wird, ist 

ebenfalls eine Vereinfachung. Um den Single-Point-of- 

Failure zu vermeiden, könnte auch der Voter repliziert 

werden. Alternativ lässt sich auch die Flexibilität und 

Anpassbarkeit von Fasa nutzen, um im Fehlerfall durch 

eine schnelle, bereits im Hintergrund vorgehaltene neue 

Konfiguration auf einen Standby-Voter umzuschalten. 

Idealerweise sollte auch die Sensorik redundant ausgelegt 

werden. Ist dies nicht möglich, kann die Verteilung 

der Input-Werte mithilfe der von Fasa angebotenen Multiplier-Komponente 

erfolgen, welche zur Vermeidung 

eines Single-Point-of-Failure dann auch redundant ausgelegt 

werden sollte. 

Mithilfe der erläuterten Fehlertoleranz können verschiedene 

Anwendungsfälle abgedeckt werden; unter 

anderem sind dies das Hinzufügen von Redundanz, der 

Austausch des verwendeten Voting-Algorithmus, der 

Austausch des verwendeten Redundanzmusters, das 

Wiederherstellen der Fehlertoleranz nach einem Fehler 

und natürlich die eigentliche Maskierung eines Fehlers 

zur Sicherstellung der Verfügbarkeit einer Applikation. 

Alle diese Anwendungsfälle werden während der Ausführung 

einer Applikation unterstützt, ohne die eigentliche 

Funktion der Applikation zu stören und ohne dass 

58 


12 / 2012

die Anwendung in spezieller Weise dafür vorbereitet 

werden muss. Der für die Anwendung von Fehlertoleranz 

in Kauf zu nehmende Overhead ist am Beispiel von 

M-out-of-N eine zusätzliche Verzögerung bei der Ausführung 

der Applikation durch die Ausführung des Voters 

sowie die eventuell benötigte Wartezeit auf die N 

Inputs für das Voting. 

Fehlertoleranz ist nicht auf das Redundanzmuster M- 

out-of-N beschränkt, sondern lässt auch andere Redundanzmuster 

zu. Umgesetzt wurden beispielsweise auch 

die Muster Hot Standby und Warm Standby. Auch hier 

werden verschiedene Basisdienste von Fasa in Anspruch 

genommen. Außerdem werden zusätzliche erweiterte 

Features benötigt, die dem Benutzer von Fasa aber ebenfalls 

als Service zur Verfügung gestellt und transparent 

angewendet werden. Beispielsweise wird beim Redundanzmuster 

Warm Standby zur Replikation des Zustands 

zwischen der Primary- und der Secondary-Komponente 

die Funktionalität der Zustandssynchronisierung benötigt. 

Auch das erweiterte Feature des Exception Handling, 

das heißt, die Benachrichtigung nachfolgender 

Blöcke und Komponenten über intern erkannte Fehler, 

lässt sich in die Fehlertoleranz integrieren. 

Auch wenn der Fokus des erweiterten Features Fehlertoleranz 

bisher auf der hohen Verfügbarkeit der Applikation 

lag, ist die Anwendung desselben Features ebenso 

zur Erfüllung von Safety-Anforderungen nutzbar. Hier 

sind weitere Randbedingungen zu beachten, zum Beispiel 

eine den Zertifizierungsrichtlinien entsprechende 

Dokumentation der Entwicklung oder die Berechnung 

der Fehlerwahrscheinlichkeiten. Dies war bisher nicht 

im Fokus der Entwicklung. 

3. VERWANDTE TECHNOLOGIEN UND SYSTEME 

Das Konzept der Blöcke in Fasa ist mit den Funktionsblöcken 

aus den Standards IEC 61131 und IEC 61499 

[10] verwandt. Allerdings gibt es keine 1-zu-1-Beziehung: 

So existieren beispielsweise in Fasa keine Execution 

Control Charts wie in IEC 61499, und die in Fasa 

mögliche Organisation von Blöcken in Komponenten 

ist zwar verwandt mit zusammengesetzten Funktionsblöcken 

(Composite Control Blocks), entspricht ihnen 

aber semantisch nicht vollständig. Der Fokus von Fasa 

liegt auf der transparenten Verteilung von Anwendungen 

und erweiterten Features wie Fehlertoleranz. Daher 

kann Fasa als eine Art Assemblersprache für Hochsprachen 

wie IEC 61499 gesehen werden: In einem unserer 

Arbeitspakete wird zur Zeit untersucht, wie geeignete 

REFERENZEN 

[1] Lombardi, M. und Milano, M.: Optimal Methods for Resource 

Allocation and Scheduling: a Cross-disciplinary Survey. Constraints 

17(1), S. 51-85, 2012 

[2] Richter, S., Wahler, M., Kumar, A.: A Framework for Component- 

Based Real-Time Control Applications. In: Proceedings 13 th Real-Time 

Linux Workshop, S. 107-115, 2011 

[3] Sutter, H.: A fundamental turn toward concurrency in software. 

Dr. Dobb’s Journal 2005(30), S. 202-210, 2005. 

(http://www.drdobbs.com/architecture-and-design/184405990) 

[4] Wahler, M., Richter, S., Kumar, S., Oriol, M:. Non-disruptive Largescale 

Component Updates for Real-Time Controllers. In: 3rd 

Workshop on Hot Topics in Software Upgrades (HotSWUp 2011), 

Proceedings IEEE 27 th International Conference on Data Engineering 

Workshops (ICDEW), S. 174-178, 2011 

[5] IEEE 1588: Standard for a Precision Clock Synchronization Protocol 

for Networked Measurement and Control Systems. 2002 

[6] Oriol, M., Wahler, M., Steiger, R., Stoeter, S., Vardar, E., Koziolek, H., 

Kumar, A.: FASA: A Scalable Software Framework for Distributed Control 

Systems. In: Proceedings 3rd International ACM Sigsoft Symposium on 

Architecting Critical Systems (ISARCS 2012), S. 51-60, 2012 

[7] Garcia, C., Prett, D. M., Morari, M.: Model predictive control: Theory 

and practice – A survey. Automatica 25(3), S. 335–348, 1989 

[8] Avizienis, A. A.: The N-Version Approach to Fault-Tolerant Software. 

IEEE Transactions on Software Engineering SE–11(12), S. 1491-1501, 1985 

[9] Stevens, M., Lenstra, A., de Weger, B.: Chosen-prefix collisions for 

MD5 and applications. Applied Cryptography 2(4), S. 322-359, 2012 

[10] Vyatkin, V.: IEC 61499 Function Blocks for Embedded and Distributed 

Control Systems Design. ISA, 2007 

[11] Fieldbus Foundation. http://www.fieldbus.org 

[12] Kopetz, H., Merker, W.: The Architecture of MARS. In: Proceedings 25 th 

International Symposium on Fault-Tolerant Computing, S. 50-55, 1995 

[13] Schneider, S.A., Chen, V.W., Pardo-Castellote, G.: The ControlShell 

component-based real-time programming system. In: Proceedings 

IEEE International Conference on Robotics and Automation, 

S. 2381-2388, 1995 

[14] Xu Ke, Sierszecki, K., Angelov, C.: COMDES-II: A Component-Based 

Framework for Generative Development of Distributed Real-Time 

Control Systems. In: Proceedings 13 th IEEE International Conference 

on Embedded and Real-Time Computing Systems and Applications 

(RTCSA), S. 198-208, 2007 

[15] Ando, N., Suehiro, T., Kitagaki, K, Kotoku, T., Woo-Keun Yoon: 

RT-Middleware: Distributed Component Middleware for RT (Robot 

Technology). In: Proceedings IEEE/RSJ International Conference on 

Intelligent Robots and Systems (IROS), S. 3933-3938, 2005 

[16] Yau, S.S. und Bing Xia: An approach to distributed component-based 

real-time application software development. In: Proceedings 1st 

International Symposium on Object-Oriented Real-time Distributed 

Computing (ISORC), S. 275-283, 1998 

[17] Hill, J.H.: Towards Heterogeneous Composition of Distributed 

Real-Time and Embedded (DRE) Systems Using the CORBA Component 

Model. In: Proceedings 37 th EUROMICRO Conference on Software 

Engineering and Advanced Applications (SEAA), S. 73-80, 2011 

[18] Uppaal PORT. http://www.uppaal.org/port 

[19] SAVE IDE: http://sourceforge.net/projects/save-ide/ 

[20] Kindel, O. und Friedrich, M.: Softwareentwicklung mit AUTOSAR: 

Grundlagen, Engineering, Management in der Praxis. dpunkt Verlag, 2009 


12 / 2012 

59

HAUPTBEITRAG 

AUTOREN 

Dr. MICHAEL WAHLER (geb. 1978) leitet die Gruppe 

Software Systems am ABB Forschungszentrum in Baden- 

Dättwil und ist aktiver Forscher. Der Schwerpunkt seiner 

Arbeit liegt auf der Architektur und dem Engineering von 

nachhaltiger Software für Automatisierungssysteme. 

ABB Schweiz AG Corporate Research, 

Industrial Software Systems, 

Segelhofstr. 1K, CH-5405 Baden-Dättwil, 

Tel. +41 (0) 58 58 6 81 67, E-Mail: michael.wahler@ch.abb.com 

Dr. THOMAS GAMER (geb. 1979) ist Scientist am ABB 

Forschungszentrum in Ladenburg. Der Schwerpunkt 

seiner Arbeit liegt auf Softwarearchitekturen und Softwareengineering 

für zukünftige Automatisierungssysteme, 

Fehlertoleranz und Gebäudeautomation. 

ABB AG Corporate Research Center Germany, 


Wallstadter Str. 59, D-68526 Ladenburg, 

Tel. +49 (0) 6203 71 60 24, E-Mail: thomas.gamer@de.abb.com 

Dr. MANUEL ORIOL (geb. 1975) ist Principal Scientist am 

ABB Forschungszentrum in Baden-Dättwil. Der Schwerpunkt 

seiner Arbeit liegt auf dynamischen Softwareupdates, 

Middleware, Softwaretests und Echtzeitsystemen. 




Tel. +41 (0) 58 58 6 70 38, E-Mail: manuel.oriol@ch.abb.com 

Dr. ATUL KUMAR (geb. 1974) ist Principal Scientist am ABB 

Forschungzentrum Indien in Bangalore. Seine Forschungsinteressen 

beziehen sich auf die Bereiche verteilte Systeme, 

Softwareengineering, und Internettechnologien. Der 

Schwerpunkt seiner Arbeit liegt auf Softwarearchitektur 

für die zukünftige Generation von industriellen Automatisierungssystemen. 

ABB Corporate Research Center Bangalore, 


Whitefield Road, Mahadevpura PO, Bangalore 560048 INDIA, 

Tel. +91 80 67 57 99 50, E-Mail: atulkumar.d@in.abb.com 

Dr. MARTIN NAEDELE (geb. 1972) ist der R&D-Programm- 

Manager für Industrial Software Systems in ABB 

Corporate Research. 




Tel. +41 (0) 58 58 6 83 39, E-Mail: martin.naedele@ch.abb.com 

Untermengen von IEC 61499 auf die Konzepte von Fasa 

abgebildet werden können. 

Im Gegensatz zum Foundation Fieldbus (IEC 61804-2, 

[11]) liegt die Ausrichtung von Fasa auf der Plattformabstraktion, 

Flexibilität, und dem Bereitstellen von erweiterten 

Features, die für den Benutzer transparent sind, 

wie zum Beispiel Fehlertoleranz. Es wäre denkbar, Fasa 

mit Foundation Fieldbus zu kombinieren: Fasa ließe sich 

auf einer höheren Abstraktionsebene zum Erstellen von 

fehlertoleranten, verteilten Anwendungen nutzen und 

ein Foundation-Fieldbus-System als deren Ausführungsumgebung. 

Ein Teil von Fasa ist von Komponenten-Frameworks 

inspiriert, die in den letzten 20 Jahren für Echtzeit-Kontrollsysteme 

entwickelt wurden, wie Mars [12], ControlShell 

[13], Comdes-II [14], RT-middleware [15], Corba [16] 

[17], Uppaal Port [18], und die Automotive Open System 

Architecture (Autosar) [20]. Das Ziel dieser Systeme ist, 

die Flexibilität der komponentenbasierten Softwareentwicklung 

mit den Anforderungen von Echtzeitanwendungen 

zu verbinden. In einigen Fällen bieten diese 

Systeme auch Entwicklungsumgebungen (IDEs). So kann 

Uppaal Port mit der Save IDE [19] als Eclipse-Plugin benutzt 

werden. 

Während all diese Komponentenplattformen den Programmierern 

Komponenten und Kanäle als die hauptsächlichen 

Designelemente anbieten, liegt der entscheidende 

Unterschied zwischen diesen Systemen und Fasa 

in den angebotenen erweiterten Features. Nach dem 

Wissen der Autoren ist Fasa die einzige Plattform, die 

Features wie dynamische Softwareupdates, transparente 

Unterstützung von Multicore-CPUs und verteilter Ausführung 

sowie transparente Fehlertoleranz im Kontext 

von Echtzeitsystemen bietet. 

FAZIT 

Die aufkommende Parallelisierung von Prozessoren in 

der Automatisierungstechnik stellt Softwareentwickler 

vor Herausforderungen, bietet aber auch neue Möglichkeiten. 

Der Schlüssel zum Bewältigen der Herausforderungen 

und zum Ausnutzen der Möglichkeiten paralleler 

Systeme liegt in der Softwarearchitektur. Fasa ist ein 

Beispiel für eine Architektur, die es erlaubt, Anwendungen 

flexibel verteilt auf mehreren Ressourcen (zum Beispiel 

CPU-Cores) auszuführen und dabei dem Anwendungsentwickler 

vollständige Ausführungstransparenz 

zu bieten. Basierend auf einigen Basiskonzepten, wie 

Modularität durch Komponenten und deterministische 

Ausführung durch statische Schedules, ermöglicht Fasa 

fortgeschrittene Features wie werkzeuggestützte Berechnung 

komplexer, verteilter Schedules, softwarebasierte 

Fehlertoleranz oder unterbrechungsfreie Softwareupdates 

zur Laufzeit. Dadurch erzielt Fasa ein hohes Maß 

an Flexibilität mit zuverlässiger deterministischer Ausführung 

von Anwendungen. 


26.07.2012 


60 


12 / 2012

HAUPTBEITRAG 

Effizienz durch ergonomische 

Benutzungsschnittstelle 

Industrielle Mensch-Prozess-Kommunikation gestalten 

Wie sich die industrielle Mensch-Prozess-Kommunikation für die operative Prozessführung 

gestalten lässt, wird in diesem Beitrag anhand eines Konzepts vorgestellt. Hintergrund 

ist die stetig steigende Komplexität der zu überwachenden Produktionsprozesse 

und der Arbeitsumgebung in Warten aus der Sicht der Anlagenfahrer. Moderne Anlagenleitstände 

und Bedienkonzepte können den Anlagenfahrer über eine leistungsfähige Benutzungsschnittstelle 

bei der Ausübung seiner Aufgaben unterstützen und entlasten. 

SCHLAGWÖRTER Mensch-Maschine-Schnittstelle / Benutzungsschnittstelle / Mensch- 

Prozess-Kommunikation / benutzerzentriertes Visualisierungskonzept / 

Leitstandskonzept / Ergonomie 

Efficient Plant Operation using ergonomic User Interface – 

User-centric design of industrial human-machine-communication 

This article presents an operator control concept for designing industrial human-machine-interface 

of operational process control. The background of this concept is the constantly 

increasing complexity of the processes to be monitored and the working environment 

in control rooms from the operator’s perspective. The use of modern plant control 

centers and operator control concepts can support and unburden operators in the execution 

of their tasks by means of a powerful human-machine-interface. 

KEYWORDS human-machine-interface / human-machine-communication / user-centered 

concept of visualization / supervisory control / ergonomics 

62 


12 / 2012

LUTZ GLATHE, SVEN KEMPF, Siemens 

D 

ie primäre Aufgabe des Anlagenfahrers ist die 

operative Prozessführung auf der Basis von Prozess- 

und Anlageninformationen der verfahrenstechnischen 

Produktion und deren Logistik- und 

Hilfsprozessen [1]. Die operative Prozessführung 

hat zum Ziel, den bestimmungsgemäßen, sicheren Betrieb 

der Produktionsanlage einzuhalten, die Verfügbarkeit der 

Produktion trotz einzelner Störungen zu maximieren und 

die Produktqualität trotz schwankender Qualität der eingesetzten 

Rohstoffe und Störungen in der Anlage sowie unterschiedlichem 

Durchsatz zu gewährleisten [2]. Schließlich 

soll der Prozessablauf im Sinne von Kosten, Qualität und 

Sicherheit optimiert werden. Insbesondere der hohe Kostendruck 

erweitert die primäre Aufgabenstellung des Anlagenfahrers 

zum Beispiel durch dispositive Aufgaben, erweiterte 

Qualitätssicherung und bedarfsgerechtes Betreiben der 

Anlage nach Key-Performance-Indikatoren, wie maximalem 

Durchsatz oder optimalem Energieeinsatz. Diese erweiterten 

Aufgaben sind traditionell im Bereich der Anlagen- und Betriebsleitebene 

angesiedelt. Die dafür notwendigen Informationen 

werden dem Anlagenfahrer in zentralen Leitstrukturen, 

hauptsächlich über die Anzeige- und Bedienkomponenten 

des Prozessleitsystems in der Messwarte präsentiert. 

Darüber hinaus müssen dem Anlagenfahrer zur Ausübung 

seiner zusätzlichen Aufgaben ergänzende Informationen aus 

einer heterogenen Systemwelt, zum Beispiel Process Information 

and Management System (PIMS), Enterprise Resource 

Planning System (ERP), Laboratory and Information Management 

System (LIMS), zur Verfügung gestellt und aufgabenbezogen 

präsentiert werden. 

Diese gewachsene heterogene Automatisierungslandschaft 

erzeugt eine stetig ansteigende Komplexität der 

Arbeitsumgebung von Leitwartenmitarbeitern. Zusätzlich 

führt der zunehmende Automatisierungsgrad von 

heutigen industriellen Produktionsprozessen zur Einsparung 

an Leitwartenpersonal und parallel zu einer starken 

Zunahme der pro Anlagenfahrer zu überwachenden Prozessinformationen, 

beispielsweise durch die Zusammenlegung 

von Leitwarten in Produktionsclustern. Abweichungen 

von Prozesswerten müssen auch dann schnell 

und zuverlässig erkannt werden, wenn hoch automatisierte 

Prozesse lange Zeit störungsfrei laufen; das erfordert 

vom Anlagenfahrer ständig hohe Konzentration. 

Diese steigende Komplexität der Produktionsprozesse 

und der Arbeitsumgebung in Warten erschwert es dem 

Anlagenfahrer, ein ganzheitliches mentales Modell der zu 

überwachenden Anlage und Prozesse zu bilden. Dabei ist 

gerade die Generierung eines mentalen Modells enorm 

wichtig. „Laut der statistischen Berichte der ICAO oder der 

Versicherungsgesellschaften wie Lloyd werden über 70 

Prozent aller registrierten Unfälle, Katastrophen und Havarien 

durch den menschlichen Faktor verursacht.“ [15] 

Jedoch ist die primäre Ursache für das menschliche Versagen 

oft nicht die Fehlbedienung beziehungsweise fehlerhafte 

Reaktion des Anlagenfahrers, sondern eine unzureichende 

technische Gestaltung der Bediensicherheit 

unter Berücksichtigung des menschlichen Faktors. Der 

menschliche Faktor ist auch aus Sicht des demografischen 

Wandels und der damit einhergehenden zunehmenden 

Zahl älterer Mitarbeiter in industriellen Bereichen bei der 

Gestaltung von Mensch-Maschine-Schnittstellen (Human- 

Machine-Interface, abgekürzt HMI) zu berücksichtigen. 

Eine Lösung bietet der Einsatz nutzer- und aufgabenorientierter 

Konzepte. Diese zielen darauf ab, Arbeitssysteme 

ganzheitlich zu gestalten, das heißt den Einsatz von 

Technik, Organisation und Qualifikation der Nutzer gemeinsam 

zu optimieren. Anstatt die Anpassung des Menschen 

an die Technik zu fordern, muss sich die Technik 

an den Menschen anpassen [3]. Bereits in der frühen Planungsphase 

von verfahrenstechnischen Anlagen sind 

diese Aspekte der ergonomischen Prozessvisualisierung 

beim Design und der konzeptionellen Festlegung von 

Anlagenleitständen und Bedienkonzepten ausreichend 

zu berücksichtigen. Diese ergonomische Benutzungsschnittstelle, 

leistet dazu einen wesentlichen Beitrag. 

Der Beitrag stellt zunächst den Status quo der Prozessvisualisierung 

in der Prozessindustrie vor, wie er den 

Anforderungen an die Arbeitsbelastung der Anlagenfahrer 

und den zugehörigen Standards und Regelwerken 

entspricht. Weiterhin wird auf konzeptionelle Ansätze 

der Gestaltung von Leitplätzen sowie deren Elemente 

und Strukturen eingegangen. Besonders hervorgehoben 


12 / 2012 

63

HAUPTBEITRAG 

wird die Implementierung von innovativen Visualisierungskonzepten 

in Prozessleitsystem-(PLS)-Projekten. 

Zur Illustration des diskutierten Konzepts wird eine 

Implementierung einer Destillationskolonne mithilfe des 

Prozessleitsystems Simatic PCS 7 vorgestellt. 

1. STATUS QUO DER PROZESSVISUALISIERUNG 

Das Anzeige- und Bedienkonzept für Anlagenfahrer hat 

sich in den vergangenen Jahren deutlich verändert. Früher 

wurden Anlagen mithilfe einer großflächigen Mosaiktafel 

zur zeitgleichen Anzeige aller Instrumente in der 

zentralen Messwarte bedient und beobachtet. Heute sitzt 

der Anlagenfahrer an einem PC-Bedienplatz mit bis zu 

vier Bildschirmen. Die Übersichtlichkeit in der Darstellung 

des Anlagenstatus und Prozesszustandes ist im Vergleich 

zur Mosaiktafel flächenbedingt eingeschränkt, 

allerdings sind viele zusätzliche Informationen verfügbar, 

zum Beispiel über Diagnosefunktionen. Um trotz 

begrenzter Bildfläche (vier Bildschirme) aussagekräftige 

Grafikbilder darzustellen und die Orientierung sowie 

Bildanwahl zu ermöglichen, wird die Gesamteinheit an 

Informationen einer verfahrenstechnischen Anlage hierarchisch 

in verfahrens- und leittechnische Darstellungen 

gegliedert, wobei die Übergänge fließend sind. Entsprechend 

ihrer Lage in der Hierarchie unterscheidet die 

VDI 3699-3 [6] Grafikbilder für die Ebenen Anlage, Bereich, 

Teilanlage und Anlagenteile (siehe Bild 1). 

In der Praxis überwiegen an der Instrumentierung ausgerichtete 

Level-3-Grafikbilder auf der Ebene Teilanlage, 

die auf der Basis von Rohrleitungs- und Instrumentenfließbildern 

entstanden sind. Der Anlagenfahrer benötigt 

jedoch zusätzliche informationsorientierte Übersichtsund 

Gruppendarstellungen, die seiner Prozessführungsaufgabe 

angemessen sind; was gleichzeitig benötigt wird, 

ist auch gleichzeitig anzuzeigen. Anderenfalls sind zusätzliche, 

zeitaufwendige Anwahlbedienungen sowie 

Belastungen des Kurzzeitgedächtnisses durch Merken 

notwendig. Des Weiteren werden Prozesswerte numerisch 

angezeigt, wodurch eine Bewertung, ob sich der Prozesswert 

im Zielbereich bewegt, individuell durch den Anlagenfahrer 

erfolgen muss. Ein weiterer Schwerpunkt liegt 

im Bereich von Grafikeffekten, wie dreidimensionale 

Darstellungen oder der zusätzlichen Anzeige von Gerätestatusinformationen, 

die allerdings für die primäre Aufgabe 

des Anlagenfahrers keinen Vorteil liefern. Heutige 

Visualisierungssysteme und -verfahren erzielen nur in 

Teilbereichen gute Ergebnisse; beispielsweise können einzelne 

Teilanlagen oder Teilprozesse durch Grafikbilder 

entsprechend übersichtlich abgebildet werden. Die eingesetzten 

Systemlösungen sind gekennzeichnet durch: 

Heterogene Systemwelt unterschiedlicher Geräte 

und Softwareprodukte mit inhomogenen Bedienoberflächen 

(PIMS, ERP, LIMS, Asset-Management-Systeme) 

Mehrere Ein- und Ausgabegeräte pro Rechner am 

Operator-Arbeitsplatz 

Standard-Konfiguration von Operator-Arbeitsplätzen 

(beispielsweise grundsätzlich vier Bildschirme pro 

Client) 

Kostengetriebene Arbeitsplatzgestaltung 

Diese Verfahren zur Darstellung von Prozesswerten zeigen 

jedoch Schwächen hinsichtlich: 

Darstellung des Gesamtzustandes des Prozesses beziehungsweise 

der Anlage „Big Picture“ 

Informationsaufnahme des Bedieners durch den 

überwiegenden Einsatz von alphanumerischen Anzeigen 

anstatt von Analogdarstellungen mit Mustererkennung 

Aufmerksamkeitssteuerung des Anlagenfahrers infolge 

der Form- und Farbkodierungen 

Aufgaben- und tätigkeitsbezogener Visualisierung 

Darstellung von Informationen 

Des Weiteren wird die Konzept- und Designphase von 

konzeptionellen Schwächen begleitet: 

Prozessbilder werden auf der Basis eingekreister 

Rohrleitungs- und Instrumentenfließbilder mit einem 

anderen Darstellungszweck erstellt 

Gerade in Neuanlagen kann das Bedienpersonal 

nicht frühzeitig in den Designprozess eingebunden 

werden 

Fehlender geräteübergreifender Standard der Prozessvisualisierung 

Fehlendes Prozess-Know-how im Design-Prozess 

Prozesswissen erfahrener Anlagenfahrer wird unzureichend 

in das Design der Prozessvisualisierung 

übernommen 

2. ERGONOMISCHE PROZESSVISUALISIERUNG 

Nachfolgend wird das Konzept einer ergonomischen Benutzungsschnittstelle 

zur industriellen Prozessführung 

nach EEMUA 201 [10] vorgestellt (siehe Bild 2). 

Dieses Konzept vereint bekannte Elemente und Strukturen 

von Bedieneinheiten, wie Bedienoberflächen und 

deren Bedienverfahren, die Gestaltung von Leitplätzen 

und Messwarten und organisatorische Maßnahmen in einem 

ganzheitlichen Lösungsansatz. Ausgangspunkt aller 

Betrachtungen ist die detaillierte Analyse der Anlagenfahrer-Tätigkeiten 

Überwachen, Eingreifen und Diagnose 

(siehe Bild 3) hinsichtlich der Prozessführung und zusätzlicher 

Aufgaben im Umfeld der Messwarte, siehe Beispiele 

in Tabelle 1. Diese Analyse der Anlagenfahrer-Tätigkeiten 

wird projektbezogen unter Einbeziehung der Bedienmannschaft 

für jede Anlage spezifisch durchgeführt. 

Aus der Priorisierung der Anforderungen an die Prozessvisualisierung 

(Tabelle 1) lassen sich folgende Themen 

zu deren Verbesserung ableiten: 

Maßnahmen in der Konzept- und Designphase: 

Konzept der Prozessvisualisierung im Design Guide 

der Prozessvisualisierung spezifizieren 

Bedienpersonal frühzeitig in den Designprozess einbinden, 

in der Regel nach Freigabe des Design Guides 

der Prozessvisualisierung. Falls nicht möglich, sind 

die übergeordneten, abstrakten Gruppendarstellungen 

nachträglich in der Optimierungsphase zu erstellen 

Experten mit Prozess-Know-how (zum Beispiel erfahrene 

Anlagenfahrer) einbinden und deren Wissen 

(beispielsweise Referenzwerte für Prozessparameter) 

in die Prozessbilddarstellungen übernehmen 

64 


12 / 2012

Bild 1 

Verfahrenstechnik 

Anlage 

Bereich 

Teilanlage 

Anlagenteil 

Level 4 

L1-Übersichtsgrafik 

Hierarchie L. 1 

Level 3 

L2-Übersichtsgrafik 

Level 2 

L3-Detailgrafik 

L4-Detailgrafik 

BILD 1: Hierarchieebenen von Grafikbildern 

nach VDI 3699-3 [6] 

Bild 3 

Leittechnik 

Anlage 

Bereich 

Gruppe 

Kreis 

Aufgabe 

Tätigkeit 

Prozessführung 

Eingreifen Überwachen Diagnose 

Handlungsfolge 

Operator-Rundgang 

Absuchen 

Entdecken 

Entdecken 

Suchen 

Erkennen 

Zählen Vergleichen 

Interpretieren 

Entscheiden 

Routine-Überwachung 

durch System 

Signalort 

Was ist es? 

Wo? 

Was bedeutet es? 

Gegenmaßnahmen 

Messwarte 

Suchen 

Stellteil 

Bild 2 

Ausführen 

Betätigen Stellteil 

Überprüfen 

Gewünschte Wirkung 

Ergonomische Benutzungsschnittstelle 

Bedien- und 

Beobachtungssystem 

Bedienoberfläche 

Operator 

Leitplatz 

(Operator- 

Arbeitsplatz) 

Console 

Messwarte Organisation / 

VT-Anlage 

BILD 3: Tätigkeiten und Handlungen des Anlagenfahrers 

in der Prozessführungsaufgabe nach VDI/VDE 3699 [5] 

Design Implementierung Betrieb 

BILD 2: Konzept einer ergonomischen 

Benutzungsschnittstelle zur industriellen 

Prozessführung nach EEMUA 201 [10] 

No. Aufgabe Tätigkeit Handlung Anforderung an die Prozessvisualisierung 

1 Prozess führung Überwachen einer 

automatisierten Anlage 





4 Materialdisposition 

5 Dokumentation 

der Prozessführung 

6 Erweiterte 

Qualitätssicherung 

Einsatzstoffe 

disponieren 

Schichtbuch führen 

Überwachen der 

qualitätsrelevanten 

Prozessparameter 

Beobachten von 

wesentlichen 

Fahrparametern 

(verfahrens technische 

KPIs) 

Erkennen/Wahrnehmen 

von Störungen 

Suchen/Identifizieren 

der Störungsursache 

Eingabe von 

Rezeptparametern 

Relevante Prozesswerte 

in Schichtbuch 

eintragen 

Beobachten von 

Qualitäts– KPIs 

– Level-2-Übersichtsdarstellungen mit wesentlichen Fahrparametern 

der zu überwachenden Anlage 

– Anzeige der zulässigen Toleranzen 

– Anzeige von Grenzwertverletzungen 

– Anzeige von Alarmen und deren Prioritäten 

– Analoganzeigen zur „Muster-Unterstützung“ 

– Trendanzeigen zur Situationseinschätzung und Entscheidung 

über Fahrstrategie 

– Aufmerksamkeitssteuerung durch Farbschema mit speziellen 

Alarmfarben 

– Vermeidung einer kognitiven Überforderung 

– Sprungfunktion von Alarmseite zur Messstelle im Prozessbild 

TABELLE 1: Anforderungen an die Prozessvisualisierung aufgrund der Aufgaben von Anlagenfahrern 

– Einheitliche und geräteneutrale Präsentation der Bedienmasken 

– Verwendung der gleichen Ein- und Ausgabegeräte wie zur 

Prozessführung 

– Präsentation aller relevanten Prozesswerte in einer Darstellung 

(Protokoll) 

– Visualisierung von Qualitäts-KPIs in Übersichtsdarstellungen 

der Prozessführung 

– Geräteunabhängige homogene Präsentation der Qualitäts-KPIs 


12 / 2012 

65

HAUPTBEITRAG 

Bild 4 

BILD 4: Serviceschritte zur 

Implementierung von 

ergonomischen 

Visualisierungskonzepten 

in PLS-Projekten 

PLS HMI 

Evaluierung 

Konzept 

Operator 

Workshop 

PLS-Projekt 

Analyse 

Design 

BILD 5: Level-2-Übersichtsdarstellung 

für die 

Destillationskolonne 

TABELLE 2: Anforderungen an 

die Prozessvisualisierung einer 

Destillationskolonne (Auszug) 

No. Aufgabe Tätigkeit Handlung Anforderung an die Prozessvisualisierung 

1 Prozessführung 






Eingreifen 

Überwachen 

Überwachen 

Diagnose 

Eingreifen 

Überwachen 

An- und Abfahren der 

Destillations kolonne 

Kontinuierliche 

Überwachung der 

Qualität 

Überwachen 

der Prozessund 

Anlagenverfügbarkeit 

Reagieren auf 

Prozess abweichungen 

Schnelles und 

sicheres Reagieren in 

kritischen Situationen 

Kontinuierliche 

Überwachung 

der Kolonne im 

Kontext weiterer 

Teilanlagen 

– Detaildarstellung aller Prozessgrößen in Anlagen-topologisch strukturierten 

Level-3-Prozessgrafiken 

– Bedienbarkeit der Prozessparameter 

– Bediendarstellungen für das An- und Abfahren, beispielsweise Ablaufsteuerungen 

– Anzahl der Bildschirme ist der Bedienaufgabe angemessen 

– Übersichtsdarstellungen aller qualitätsrelevanter Fahrparameter der Kolonne in 

aufgabenangemessenen Level-2-Prozessgrafiken 

– Anzeige der zulässigen Toleranzen 

– Analoganzeigen zur Muster-Unterstützung 

– Trendanzeigen zur Situationseinschätzung und Entscheidung über Fahrstrategie 

– Übersichtsdarstellungen mit wesentlichen Fahrparametern der Kolonne in 

aufgabenangemessenen Level-2-Prozessgrafiken 

– Anzeige von Grenzwertverletzungen 

– Anzeige von Alarmen und deren Priorität 

– Trendanzeigen zur Situationseinschätzung und Entscheidung über Fahrstrategie 

– Aufmerksamkeitssteuerung durch Farbschema mit speziellen Alarmfarben 

– Vermeidung einer kognitiven Überforderung 

– Sprungfunktion von Alarmseite beziehungsweise Übersichtsdarstellung zur Messstelle 

im Detail-Prozessbild 

– Detaildarstellung aller Prozessgrößen in Anlagen-topologisch strukturierten 

Level-3– Prozessgrafiken 

– Bedienbarkeit der Prozessparameter 

– Anzahl der Bildschirme ist der Gleichzeitigkeit der Bedienaufgabe angemessen 

– Komprimierte Übersichtsdarstellungen wesentlicher Fahrparameter der Kolonne 

in aufgabenangemessenen Level-1-Prozessgrafiken 

– Komprimierte Übersichtsdarstellung wesentlicher Fahrparameter anderer 

Teilanlagen 

– Anzeige von Anlagen-KPIs 

– Navigation in Bildhierarchie durch Sprungfunktionen 

66 


12 / 2012

Systemlösungen: 

Multifunktionaler integrierter Operator-Arbeitsplatz 

mit homogener Bedienoberfläche, Bedienung mit 

gleichen Ein-Ausgabegeräten 

Applikationen aller Einzelgeräte nach einem systemweiten 

Design Guide der Prozessvisualisierung 

Konfiguration des Operatorarbeitsplatzes als Teil der 

Leitplatzorganisation 

Ergonomische Gestaltung des Operatorarbeitsplatzes 

Gestaltung der Warte nach ergonomischen Kriterien 

und Anforderungen an Arbeitsstätten 

Verfahren zur Darstellung von Prozesswerten: 

Zusätzlicher Einsatz von abstrakten Bedienverfahren, 

bei denen die Prozesstopologie eine untergeordnete 

Rolle spielt, zum Beispiel prozessbezogene 

und aufgabenangemessene Übersichts- und Gruppendarstellungen 

auf dem Level-1/2 mit wesentlichen 

Fahrparametern der zu überwachenden Anlage, 

in einer Anordnung von Hybridanzeigen mit 

Zielbereich- und Grenzwertvisualisierung, die die 

Mustererkennung unterstützt. Die darzustellenden 

Fahrparameter werden in Interaktion mit dem Bedienpersonal 

anhand von Kriterien ausgewählt. 

Aufgrund der Gebrauchstauglichkeit dieser Übersichtsdarstellungen 

für den Operator erfolgen daraus 

erfahrungsgemäß etwa 80 % der Bedienung und 

Beobachtung im Normalbetrieb der Anlage. 

Teilweiser Ersatz alphanumerischer Anzeigen durch 

Analog- und Hybridanzeigen sowie Kurvendarstellungen 

Reduktion der Komplexität von Prozessfließbildern 

durch aufgaben- und prozesszustandsorientierte 

Auswahl der darzustellenden Prozesswerte (dezidierte 

Darstellungen für das An- und Abfahren, den 

Normalbetrieb, Lastwechsel und Diagnose) 

Einsatz eines Farbschemas inklusive Alarmfarben 

Prozessbilddarstellungen als Bestandteil der Leitplatzorganisation 

Darstellung von Informationen statt Daten, beispielsweise 

neuartige Darstellungsobjekte für Temperaturverteilungen, 

Trenddarstellungen zur Situationseinschätzung 

und Entscheidungsfindung 

über Fahrstrategien oder Kiviat-Diagramme zur 

komprimierten Darstellung von drei bis zehn Prozesswerten 

zwecks Evaluierung für zuvor festgelegte 

Kriterien 

Das Konzept basiert auf den in der VDI/VDE 3699 „Prozessführung 

mit Bildschirmen“ [4-9] genannten Regeln 

und Empfehlungen für die Gestaltung von Darstellungen 

bei Verwendung von Bildschirmsystemen zur Prozessführung. 

Die dort getroffenen Empfehlungen werden im 

vorliegenden Konzept weitergeführt und in den Kontext 

einer ergonomischen Prozessvisualisierung gestellt. 

3. IMPLEMENTIERUNG IN PLS-PROJEKTEN 

In diesem Abschnitt wird die Implementierung des Konzepts 

in PLS-Projekten beschrieben (siehe Bild 4). Übliche 

PLS-Projekte sind Automatisierungslösungen für 

Neuanlagen, Migrationen von Altsystemen, Optimierungsprojekte 

oder die Kombination aus Migrationsund 

Optimierungsprojekt. Voraussetzungen für eine 

umfassende Implementierung sind eine existierende 

beziehungsweise bekannte Basisautomatisierung (HMI 

zur Evaluierung) und Betriebserfahrungen zur Analyse 

der Operator-Aufgaben. Teilimplementierungen, insbesondere 

der Messwarten-, Leitstands-, Farb-, Darstellungs- 

und Alarmmanagement-Konzepte sind auch für 

Neuanlagenprojekte notwendig. 

Wie in Bild 4 dargestellt, werden die Implementierungsphasen 

Evaluierung, Konzept, Operator Workshop, 

Analyse und Design durch einen Service mit umfangreichen 

prozesstechnischen Kenntnissen erbracht. Die 

HMI-Projektierung erfolgt dann im PLS-Projekt. Der Gestaltungsprozess 

orientiert sich an den Grundsätzen der 

menschzentrierten Gestaltung nach DIN EN ISO 9241- 

210 [16] und ist auf die industrielle Praxis der Prozessvisualisierung 

ausgerichtet. 

Das Visualisierungskonzept sollte gezielt auf die Arbeitsabläufe 

der Nutzer abgestimmt sein (siehe Abschnitt 

2). Daher ist zu empfehlen, die Anlagenfahrer 

aktiv in den Entwicklungsprozess einzubeziehen. Nur 

so lassen sich deren oftmals über viele Jahre angesammelte 

Erfahrung und das damit verbundene kostbare 

Know-how in das Design des Leitstandes einbeziehen 

und damit sichern. 

Evaluierung 

Ein leistungsfähiges Bedien- und Beobachtungskonzept 

muss auf den neuesten wissenschaftlichen Erkenntnissen 

hinsichtlich Ergonomie und Usability 

beruhen. Dazu wird der vorhandene Leitstand im Zuge 

eines Evaluierungsprozesses, zum Beispiel nach Kriterien 

der EN ISO 11064-5 [14] bewertet: 

System-Befugnis 

Informationsanforderungen 

Effiziente Mensch-System-Schnittstelle 

Benutzerorientierte Gestaltung 

Erzeugen von Aufmerksamkeit 

Anwendung ergonomischer Grundsätze und so weiter 

Konzept 

Das im Evaluierungsprozess gefundene Potenzial 

wird in der Konzeptphase bewertet und ein Maßnahmenkatalog 

zur Optimierung des Leitstandes erarbeitet. 

Der Umfang dieser Maßnahmen wird in einem 

Design Guide verabschiedet und beschreibt folgende 

Inhalte: 

Umfang der HMI-Maßnahmen 

Bildinhalte/-Aussehen/-Navigation 

Darstellungsstandards 

Design der Bedienkonsolen und Leitstände 

Leitwartendesign 

Beschreibung des HMI-Design-Prozesses 

Operator Workshop 

Der verabschiedete Maßnahmenkatalog wird in einem Operator 

Workshop erklärt und den Nutzern vertraut gemacht. 

Dabei geht es unter anderem um das verwendete Farbkonzept, 

die neuartigen informationsorientierten Anzeigen 

sowie die aufgaben- und topologieorientierte Darstellung 

der Ebene von Prozessgruppen (Level-2-Grafikbilder). 


12 / 2012 

67

HAUPTBEITRAG 

Analyse 

In der Analysephase werden die vorhandenen Prozessbilder 

mit allen Beteiligten – idealerweise in der Messwarte 

am Livesystem – durchgesprochen, um zu erkennen, 

inwiefern sie die tatsächlichen Prozesse repräsentieren 

und die erforderlichen Bedienabläufe unterstützen. 

Design 

Aus den in der Analyse gewonnenen Erkenntnissen 

werden übergeordnete Prozessgruppendarstellungen 

erstellt und die jeweils am besten geeigneten Darstellungsformen 

– digital, analog und/oder Kurvendarstellung 

– bestimmt. Im Ergebnis entstehen die Level- 

2-Prozessbilder, über die künftig 80 Prozent aller Bedienvorgänge 

vorgenommen werden sollen. In einer 

anschließenden Optimierungsphase haben die Anlagenfahrer 

Gelegenheit, diese neuartigen Level-2-Prozessbilder 

aus Anwendersicht zu beurteilen und ergänzende 

Verbesserungsvorschläge einzubringen. 

Implementierung in PLS-Projekt 

Nach der Genehmigung durch den Betreiber werden 

die Bildentwürfe im Rahmen des PLS-Projektes in die 

Visualisierungssoftware umgesetzt. 

Eine parallele Bearbeitung des Service und des PLS- 

Projektes (siehe Bild 4) ist möglich und bietet folgende 

Vorteile: 

PLS-Projekte, wie Migrationsprojekte, sind in der Regel 

kosten-, termin- und risikogetrieben und lassen 

kaum Spielraum für funktionale Erweiterungen 

System-Upgrades sind ideale Zeitpunkte für funktionale 

Optimierungen und Erweiterungen, weil sich 

die Anlagenbediener auf neue Systemmerkmale einstellen 

müssen 

Optimierungsprojekte können weitestgehend mit der 

Bedienmannschaft als Ansprechpartner durchgeführt 

werden; die knappen Ressourcen, insbesondere 

auf der Betreiberseite werden damit berücksichtigt 

Für die Bearbeitung von PLS-Projekten und HMI- 

Optimierungsprojekten sind unterschiedliche Kompetenzen 

erforderlich. Während für PLS-Projekte 

eher System- und Automatisierungskenntnisse erforderlich 

sind, werden für die ergonomische Gestaltung 

des HMI sowohl umfangreiche verfahrenstechnische 

Kenntnisse als auch Kenntnisse im Usability 

Engineering benötigt 

In vielen Fällen werden im Zuge von Migrationen 

auch Messwarten zusammengelegt; die damit einhergehende 

höhere Arbeitslast muss durch ein leistungsfähigeres 

HMI-Design kompensiert werden 

4. IMPLEMENTIERUNG EINER DESTILLATIONSKOLONNE 

Das in den vorigen Abschnitten beschriebene Konzept 

wird nachfolgend am Beispiel einer Zweistoff-Destillationskolonne 

erläutert. Die Destillation, genauer als Rektifikation 

bezeichnet, ist ein in der chemischen und petrochemischen 

Industrie häufig angewandtes Verfahren 

zur thermischen Trennung von Mehrstoffgemischen. Die 

Anforderungen an die Destillation steigen ständig im 

Hinblick auf Reinheit und Wirtschaftlichkeit. 

Im ersten Schritt wurde die Aufgabenanalyse unter 

Einbeziehung der Bedienmannschaft durchgeführt. Wesentliche 

Aufgaben des Anlagenfahrers einer Destillationskolonne 

sind in der Tabelle 2 aufgeführt (Auszug). 

Diese Aufgaben werden im Anzeige- und Bedienkonzept 

berücksichtigt, um eine optimale Arbeitsumgebung 

für den Operator zu gewährleisten. 

Für das An- und Abfahren der Destillationskolonne 

(Aufgabe 1 der Tabelle 2) werden die üblichen Level- 

3-Detaildarstellungen verwendet, diese sind nicht Gegenstand 

der Betrachtung in diesem Beispiel. 

Für die Überwachung der relevanten prozesstechnischen 

Kenngrößen (Aufgaben 2/3 der Tabelle 2) wird eine 

gemeinsame Level-2-Übersichtsdarstellung gewählt (siehe 

Bild 4). 

Diese beinhaltet die wichtigsten Prozesswerte und Regelungen 

der Destillationskolonne. Diese Darstellung hat 

den Vorteil, dass viele Daten zu einer komprimierten Informationsdarstellung 

zusammengefasst werden können. 

Die Aufgabe 2 der Tabelle 2 „Kontinuierliche Überwachung 

der Prozessqualität“ wird einerseits durch die 

Darstellung des Temperaturprofils und andererseits 

durch die Kurvendarstellung des Model Predictive Controller 

(MPC, Modell-prädiktiver Regler) im Level-2-Bedienbild 

wirksam unterstützt. Wegen des Zusammenhangs 

zwischen Temperaturen (hier TI 3113 und TI 

3111) und Konzentrationen im Phasengleichgewicht 

(von Dampf und Flüssigkeit) wird durch eine Temperaturregelung 

indirekt eine Konzentrationsregelung, das 

heißt die Qualitätsregelung für den Prozess der Stofftrennung 

bei der Destillation erreicht. Der entscheidende 

wirtschaftliche Nutzen ergibt sich durch die bedarfsgerechte 

Fahrweise der Kolonne, indem die Sollwerte 

für die Qualitätsregelung zielgerichtet modifiziert 

werden können. Es wird also nicht die bestmögliche 

Qualität produziert, sondern die am wirtschaftlichsten 

herstellbare zulässige Qualität. In anderen Anlagenkonstellationen 

kann es andere Optimierungsziele geben. 

Beispielsweise kann der Durchsatz maximiert werden, 

indem bei laufender Qualitätsregelung der Zulauf 

schrittweise erhöht wird, bis die Heizdampfmenge sich 

in der Nähe der Obergrenze einpendelt. 

Die Beurteilung des Prozesszustands – hier der Prozessqualität 

– anhand der Temperaturen als Analogwertanzeigen 

kann nur aus Erfahrung getätigt werden. Visualisiert 

man die Temperaturen stattdessen als Temperaturverlauf 

des optimalen Arbeitsbereichs, kann die Beurteilung 

direkt aus dem Bild abgelesen werden (siehe 

Bild 5: Die untere Temperatur TI 3111 weicht um vier 

Kelvin vom Arbeitspunkt ab). 

Ähnlich verhält es sich mit der Beurteilung des Prozessverlaufs. 

Die Kurvendarstellung von Soll-, Ist- und 

Stellwerten des MPC untertützt die Situationseinschätzung 

und die Wahl der geeigneten Fahrstrategie. 

Weitere wichtige Kenngrößen, die in der Level-2-Übersichtsdarstellung 

der Kolonne dargestellt werden, sind 

der Energieverbrauch der Anlage, der Ausstoß, die Betriebszeit, 

die Rücklaufparameter, der Kopfdruck, der 

Zulauf und deren Temperatur sowie der Dampfstrom. 

Das Gros dieser Kenngrößen wird in Form von informationsorientierten 

Hybridanzeigen im Prozessbild repräsentiert. 

Diese visualisieren den Gutbereich und Grenzwerte 

für den Prozesswert (siehe Bild 6). Eine Beurtei- 

68 


12 / 2012

lung anhand eines Analogwertes könnte ansonsten nur 

mit Erfahrung gemacht werden. 

Auch das Farbschema, mit der restriktiven Verwendung 

der gesättigten Farben Rot und Gelb für die Visualisierung 

von Grenzwerten, erfüllt die Anforderungen 

an die Prozessvisualisierung hinsichtlich Aufmerksamkeitssteuerung 

der Anlagenfahrer. Für die Überwachung 

der relevanten prozesstechnischen Kenngrößen der Gesamtanlage 

(Aufgaben 6 der Tabelle 2) wird eine gemeinsame 

Level-1-Übersichtsdarstellung mit einer komprimierten 

Darstellung der wesentlichen Fahrparameter 

gewählt (siehe Bild 7). So werden die Kenngrößen der 

Reaktoren mit Kiviat-Diagrammen visualisiert. 

Die Optimierung eines HMI hin zu einer ergonomischen 

Benutzungsschnittstelle erzielt messbaren Nutzen (siehe 

Bild 8). Einheitliche Produktqualität, höhere Verfügbarkeit, 

weniger Ausschuss oder schnellere Anfahr- und 

Produktwechselzeiten können messbar schichtübergreifend 

verbessert und gemessen werden. Weiterhin werden 

Fehlbedienungen der Anlagenfahrer durch rasches Erkennen 

von Abweichungen vermieden und zielgerichtetes 

Reagieren ermöglicht. Die Komplexität wird durch 

einheitliche und vereinfachte Benutzungsschnittstellen, 

effektives Alarmmanagement und einheitliche Datenschnittstellen 

reduziert. Die aktive Einbeziehung der 

Anlagenfahrer in die Gestaltung des Bedienkonzepts 

trägt zur hohen Akzeptanz und zur kontinuierlichen 

Verbesserung des Gesamtprozesses bei und steigert die 

Operational Excellence. 

Bild 6 

5. ERWARTETER NUTZEN 


Mit dem vorgeschlagenen ergonomischen Visualisierungskonzept 

soll ein ganzheitlicher Lösungsansatz gefunden 

werden, um der steigenden Komplexität der zu 

Bild 8 

Warnung oben 

Alarm oben 

Produktivität 

und 

Wirtschaftlichkeit 

Produktivität, typisch 5-12% 

Quelle: ASM Consortium 2009 [13] 

Gutbereich 

Prozesswert 

unterhalb des 

Gutbereichs 

Prozesswert mit 

Einheit 

Zustand 

Simulation 

Prozesswert im 

Zustand Warnung 

Warnung oben 

Prozesswert im Zustand 

Alarm 

Alarm oben 

Qualität 

Operabilität 

und 

Verfügbarkeit 

Reproduzierbarkeit der 

Anlagenfahrweise durch Design 

Schwankungsbreite von Qualitäts- 

Parametern 

Toleranz geg. Rohstoffschwankungen 

Störungsempfindlichkeit 

HMI-Komplexität 

BILD 6: Neuartige Hybridanzeigen ermöglichen die Anzeige von 

Gutbereich und Grenzwerten 

Qualität der Prozessführung 

Arbeitslast des Bedienpersonals 

Beherrschung des Bedienerwechsels 

Bedienbarkeit 

Aufmerksamkeitssteuerung durch 

Farbkonzept 

Bediensicherheit 

Trainingszeiten 

Umweltschutz 

Gefahr / Risiko durch Fehlbedienung 

BILD 8: Nutzen von Konzepten ergonomischer 

Benutzungsschnittstellen 

BILD 7: Level-1-Übersichtsdarstellung für die Gesamtanlage 


12 / 2012 

69

HAUPTBEITRAG 

überwachenden Prozesse und der Arbeitsumgebung in 

Warten aus der Sicht der Anlagenfahrer wirksam zu begegnen 

[11]. Aspekte, wie der sichere Betrieb der Produktionsanlagen 

durch die Vermeidung von Bedienfehlern, 

die erweiterte Aufgabenstellung der Operatoren, der 

Verlust an Betriebs-Know-how durch Mitarbeiterfluktation 

und nicht zuletzt die erhöhte Arbeitslast durch Zusammenlegen 

von Messwarten, rechtfertigen die Investitionen 

in moderne Benutzungsschnittstellen beziehungsweise 

erfordern die Umgestaltung traditioneller 

Bedienkonzepte. Die Erhöhung der Bediensicherheit von 

Prozessanlagen durch eine sichere Ausführung der Bedienkonzeption 

wird darüber hinaus durch eine Reihe 

von Vorschriften und Richtlinien gefordert. Erste Erfahrungen 

bedeutender Anwender sprechen für den Einsatz 

dieses Konzeptes [12]. 

Zukünftige Weiterentwicklungen des Konzeptes im 

Rahmen nachhaltiger Visualisierungslösungen für mehr 

Effizienz und Rentabilität berücksichtigen unter anderem 

folgende Anforderungen: 

Effiziente Implementierungskonzepte 

Die Benutzungsschnittstelle im demografischen 

Wandel 

Adaption von Benutzungsschnittstellen, das heißt 

Anpassung an die zur Laufzeit vorherrschenden 

Randbedingungen, zum Beispiel Benutzerrolle oder 

Anlagenzustand. 


20.07.2012 


REFERENZEN 

AUTOREN 

[1] NA 120: Operator-Arbeitsplatz aus Sicht der Mensch- 

Prozess-Kommunikation. Namur, 2008 

[2] Charwat, H.J.: Lexikon der Mensch-Maschine 

Kommunikation. Oldenbourg Industrieverlag, 

München 1994 

[3] Wickens, C.D. und Holland, J.G. (2000). Engineering 

psychology and human performance. Prentice Hall, 

New Jersey, 2000. 

[4] VDI/VDE 3699-1: Prozessführung mit Bildschirmen, 

Blatt 1 Begriffe. Beuth, 2005 


Blatt 2 Grundlagen. Beuth, 2005 


Blatt 3 Fließbilder. Beuth, 1999 


Blatt 4 Kurven. Beuth, 1997 


Blatt 5 Meldungen. Beuth, 1998 


Blatt 6 Bedienverfahren und Bediengeräte. Beuth, 2002 

[10] EEMUA 201: Process Plant Control Desk utilising 

Human-Computer-Interfaces - A Guide to Design, 

Operational and Human-Computer Interface Issues“. 2002 

[11] Kempf, S. und Glathe, L.: Moderne Anlagenleitstände 

und Bedienkonzepte. In: Tagungsband Automation 

2011, S.173–176. VDI, 2011 

[12] Glathe, L.: Innovatives Bedienkonzept. process news 

2012(2), 22 23, 2012 

[13] Abnormal Situation Management Consortium. Benefits 

- http://mycontrolroom.com/site/content/view/16/29/ 

[14] EN ISO 11064-5: Ergonomische Gestaltung von Leitzentralen 

– Teil 5: Anzeigen und Stellteile. 2008 

[15] Galabov, V.: Bediendiagnose - eine Beitrag zur 

Steigerung der Mensch-Maschine-Systemverfügbarkeit. 

atp - Automatisierungstechnische Praxis atp 

42(6), 58 63, 2000 

[16] DIN EN ISO 9241-210: Ergonomie der Mensch-System- 

Interaktion - Teil 210: Prozess zur Gestaltung 

gebrauchstauglicher interaktiver Systeme. 2011 

Dipl.-Ing. LUTZ GLATHE 

(geb. 1962) beschäftigt sich 

seit 1990 bei der Siemens AG 

(und Vorgängerunternehmen) 

in Frankfurt am Main mit 

Automatisierungslösungen 

und Konzepten. Derzeit ist er 

Projektleiter für das HMI- 

Consulting und war maßgeblich 

an der Entwicklung des Konzeptes beteiligt. 

Er ist Mitglied im FA 5.32 „Nutzergerechte 

Gestaltung von Prozessleitsystemen (3699)“ des 

VDI/VDE-GMA und Gast im Namur-Arbeitskreis 

2.9 „Mensch-Prozess-Kommunikation“. 

Siemens AG, 

Industriepark Höchst, Geb. B598, 

D-65926 Frankfurt am Main, 

Tel. +49 (0) 69 79 78 46 12, 

E-Mail: lutz.glathe@siemens.com 

Dipl.-Ing. SVEN KEMPF 

(geb. 1972) beschäftigt sich 

seit 2000 bei der Siemens 

AG in Karlsruhe mit dem 

Schwerpunkt Leittechnik. 

Er arbeitet seit 2004 im 

technischen Vertrieb als 

Manager für technologische 

Konzepte. Seine 

Schwerpunkte sind Verfügbarkeitsthemen, 

IT-Security und die Optimierung der verfahrenstechnischen 

Prozessführung. 

Siemens AG, 

G. Braun Str. 18, D-76187 Karlsruhe, 

Tel. +49 (0) 721 595 60 42, 

E-Mail: sven.kempf@siemens.com 

70 


12 / 2012

Die Referenzklasse für die 


Erfahren Sie auf höchstem inhaltlichen Niveau, was die 

Automatisierungsbranche bewegt. Alle Hauptbeiträge 

werden in einem Peer-Review-Verfahren begutachtet, 

um Ihnen maximale inhaltliche Qualität zu garantieren. 

Sichern Sie sich jetzt dieses erstklassige Lektüreerlebnis. 

Als exklusiv ausgestattetes Heft sowie als praktisches 

e-Paper – ideal für unterwegs, auf mobilen Endgeräten 

oder zum Archivieren. 

Gratis für Sie: Der Tagungsband AALE 2012 als e-Paper 

Das Kompendium bietet eine Zusammenstellung der Fachreferate des 9. Fachkolloquiums 

für angewandte Automatisierungstechnik in Lehre und Entwicklung an Fachhochschulen. 

Die Veranstaltung versteht sich als Forum für Fachleute der Automatisierungstechnik aus 

Hochschulen und Wirtschaft. Sie wird von der Fakultät Mechatronik und Elektrotechnik der 

Hochschule Esslingen mit Unterstützung des VFAALE und dem Kompetenzzentrum 

Mechatronik BW e.V. organisiert und ausgerichtet. 

1. Aufl age 2012, 399 Seiten, Broschur 

atp edition erscheint in : DIV Deutscher Industrieverlag GmbH, Arnulfstraße 124, 80636 München 


Vorteilsanforderung per Fax: +49 (0) 931 / 4170 - 492 oder im Fensterumschlag einsenden 

Ja, ich möchte atp edition im Abo-plus-Paket lesen. 

Bitte schicken Sie mir die Fachpublikation für zunächst ein Jahr (12 Ausgaben) als gedrucktes Heft 

+ digital als e-Paper (PDF-Datei als Einzellizenz) für € 638,40 (Deutschland) / € 643,40 (Ausland). 

Als Dankeschön erhalte ich den Tagungsband AALE 2012 gratis als e-Book. 

Nur wenn ich nicht bis von 8 Wochen vor Bezugsjahresende kündige, verlängert sich der Bezug um 

ein Jahr. 

Die sichere, pünktliche und bequeme Bezahlung per Bankabbuchung wird mit einer Gutschrift von 

€ 20,- auf die erste Jahresrechung belohnt. 

Firma/Institution 

Vorname/Name des Empfängers 

Straße/Postfach, Nr. 

Land, PLZ, Ort 

Telefon 

Telefax 

Antwort 

Leserservice atp 

Postfach 91 61 

97091 Würzburg 

E-Mail 

Branche/Wirtschaftszweig 

Bevorzugte Zahlungsweise □ Bankabbuchung □ Rechnung 

Bank, Ort 

Bankleitzahl 

✘ 

Kontonummer 

Widerrufsrecht: Sie können Ihre Vertragserklärung innerhalb von 14 Tagen ohne Angabe von Gründen in Textform (Brief, Fax, E-Mail) oder durch 

Rücksendung der Sache widerrufen. Die Frist beginnt nach Erhalt dieser Belehrung in Textform. Zur Wahrung der Widerrufsfrist genügt die rechtzeitige 

Datum, Unterschrift 

PAATPE0312 

Absendung des Widerrufs oder der Sache an den Leserservice atp, Franz-Horn-Str. 2, 97082 Würzburg. 

Nutzung personenbezogener Daten: Für die Auftragsabwicklung und zur Pfl ege der laufenden Kommunikation werden personenbezogene Daten erfasst, gespeichert und verarbeitet. Mit dieser Anforderung er kläre ich mich damit einverstanden, dass ich von 

DIV Deutscher Industrieverlag oder vom Vulkan-Verlag □ per Post, □ per Telefon, □ per Telefax, □ per E-Mail, □ nicht über interessante, fachspezifi sche Medien- und Informationsangebote informiert und beworben werde. Diese Erklärung kann ich mit Wirkung für 

die Zukunft jederzeit widerrufen.

HAUPTBEITRAG 

Semantikvielfalt mit 

AutomationML beherrschen 

Vorgehensmodell für die Standardisierung von Datenmodellen 

Mit der Einführung eines Konzeptes zur Beherrschung heterogener Datenmodelle im 

Austausch von Engineering-Daten hat AutomationML in 2011 und 2012 einen erheblichen 

Fortschritt erzielt. Dieser Beitrag beschreibt, warum ein gemeinsames und neutrales 

Standard-Datenmodell im Engineering bisher nicht gelungen ist und wie AutomationML 

den Umgang mit Semantikvielfalt ermöglicht. Daraus entwickeln die Autoren ein evolutionäres 

Standardisierungs-Reifegradmodell. Das Konzept ist reif für die industrielle 

Einführung und bietet Vorteile für Industrie, Gremien und Akademia. 

SCHLAGWÖRTER AutomationML / Datenaustausch / CAEX / Reifegradmodell 

Handling semantic heterogeneity with AutomationML – 

An approach for the standardization of data models 

In 2011, the AutomationML consortium has achieved significant technical progress – the 

introduction of a concept that masters different semantics in the data exchange process 

of a heterogeneous engineering tool landscape. This contribution gives an overview about 

the current technical developement state of the data exchange format AutomationML. 

KEYWORDS AutomationML / data exchange / CAEX / COLLADA / PLCopen XML 

72 


12 / 2012

RAINER DRATH, MIKE BARTH, ABB Forschungszentrum 

Für Ingenieure ist AutomationML ein Hilfsmittel 

zum Austausch von Engineering-Daten in einer 

heterogenen Werkzeuglandschaft. SPS-Programmierer 

tauschen Ablaufsequenzen, Hardwarehierarchien 

oder Signaldaten untereinander oder 

mit Ingenieuren der HMI- oder Elektroplanung aus. Roboterprogrammierer 

speichern Bahnverläufe oder importieren 

3D-Geometrien und Kinematiken. 

Diese unterschiedlichen Sichtweisen lassen die dahinterstehende 

Problemstellung erahnen: In der Anlagenplanung 

sind viele Personen mit jeweils individuellen Planungswerkzeugen 

beteiligt. Alle diese Gewerke sind in 

einer unsichtbaren Wertschöpfungskette miteinander 

verbunden: In einem Werkzeug werden Daten erzeugt, 

welche in mehreren weiteren Werkzeugen benötigt werden. 

Durch fortwährende Anreicherung, durch wiederholtes 

Kopieren und Verteilen von Engineering-Daten in 

einem solchen Werkzeugnetzwerk entstehen zwangsläufig 

Redundanzen und Inkonsistenzen. Deren Identifizierung 

und Behebung verursacht erheblichen manuellen 

Aufwand [1]. Mit Hinblick auf die Inbetriebnahme (virtuell 

oder real) ist die konsistente Zusammenführung 

aller Engineering-Daten dabei von besonderer Bedeutung. 

Gerade in der Fertigungsautomatisierung werden Antriebe, 

SPSn, Roboter oder Sicherheitseinrichtungen verschiedener 

Hersteller miteinander kombiniert. Jeder 

Gerätehersteller stellt dabei seine eigene Engineering- 

Software bereit mit ihren langjährig gereiften, sinnvollen 

und berechtigten Datenmodellen. Im Ergebnis entstehen 

eine heterogene Werkzeuglandschaft sowie eine erhebliche 

Semantikvielfalt. 

1. GRUNDPROBLEM DER SEMANTIKVIELFALT 

Warum ist Semantikvielfalt ein Problem? Dies lässt sich 

anhand menschlicher Kommunikation darstellen: Menschen 

können einen Text verstehen, wenn sie über ein gemeinsam 

vereinbartes Modell des Alphabets (die Syntax) 

sowie der Bedeutung ihrer Elemente (Semantik) verfügen. 

Schrift ist ein selbstverständliches Mittel der Kommunikation. 

Dennoch sind Fehler bei der Übertragung mittels 

Sprache allgegenwärtig: Kommunikation wird erschwert, 

wenn Verfasser und Leser über ein unterschiedliches Alphabet 

verfügen, unterschiedliche Syntax verwenden oder 

über unterschiedliche Semantikmodelle derselben Sprache 

verfügen, zum Beispiel Doppeldeutigkeiten. Gleiche Begriffe 

unterschiedlicher Bedeutung oder unterschiedliche Begriffe 

gleicher Bedeutungen führen regelmäßig zu Missverständnissen. 

Semantische Vielfalt ist keine Spezialität der 

Automatisierungstechnik, sondern allgegenwärtig. 

Der Datenaustausch zwischen Engineering-Werkzeugen 

in einer heterogenenen Werkzeuglandschaft leidet an denselben 

Problemen: Es fehlt ein vereinbartes gemeinsames 

Datenmodell, syntaktisch und semantisch. Um dies zu 

beheben, beschreibt die Literatur zwei grundsätzliche 

Konzepte: Entweder werden die Werkzeuge miteinander 

in einer gemeinsamen Datenbank auf einem gemeinsamen 

Datenmodell integriert (und somit voneinander abhängig), 

oder sie gehen eine lose Kopplung mit einem dateibasierten 

Datenaustausch ein und bleiben unabhängig. Beide 

Ansätze haben ihre Existenzberechtigung (siehe [2], [4]). 

Dem dateibasierten Datenaustausch kommt in der Praxis 

eine besondere Bedeutung zu, denn die Mehrzahl der 

am Markt befindlichen Werkzeuge stammt nicht von 

einem Hersteller, ist nicht aufeinander abgestimmt und 

besitzt aufgrund ihrer langjährigen Reifung ein eigenes, 

bewährtes und berechtigtes Datenmodell. Ihre Werkzeugintegration 

ist aufgrund wirtschaftlicher Eigentumsverhältnisse 

und Marktbedingungen nicht zu erwarten: 

Die Werkzeuge und ihre Datenmodelle liegen in 

der Hoheit des jeweiligen Werkzeugherstellers und unterliegen 

ständiger Veränderung. Folglich wird ein übergreifendes 

gemeinsames Datenaustauschformat benötigt. 

1.1 Motivation für AutomationML 

Aufgrund fehlender Datenaustauschformate existieren zwischen 

den Gewerkegrenzen nach wie vor erhebliche Brüche 

im Engineeringworkflow – eine Hauptursache für die von 

der AIDA in 2005 bezifferten Engineeringkosten von 50 % 


12 / 2012 

73

HAUPTBEITRAG 

Bild 1 

der Gesamtautomatisierungslösung im Automobilbau [3]. Bild verdeutlicht die Architektur von AutomationML. 

Vor diesem Hintergrund initiierte die Daimler AG 2006 unter 

anderem gemeinsam mit ABB, Siemens und Kuka einen 62424 [5] standardisierte Format CAEX (Computer Aided 

Das Rückgrat von AutomationML bildet das in der IEC 

Arbeitskreis mit dem Ziel, erstmalig ein Datenformat zu Engineering eXchange). Dieses ermöglicht das Modellieren 

und Speichern von Objektnetzwerken mitsamt deren 

entwickeln, das möglichst alle Engineering-Disziplinen 

und -Phasen abdeckt. Im Ergebnis entstand ein schlankes Attributen, Schnittstellen, Relationen sowie Bibliotheken. 

AutomationML definiert darüber hinaus einen Re- 

Datenformat, das bestehende Datenformate kombiniert und 

lediglich deren Verwendung und Interaktion definiert. ferenzmechanismus, mit dem sich Geometrie- und Ki- 

Bild 2 

CAEX IEC 62424 

Dachformat 

Anlagentopologie - 

information 

• Anlage 

• Zelle 

• Komponente 

• Attribute 

• Schnittstellen 

• Relationen 

• Referenzen 

Object A 

AutomationML 

Engineeringdaten 

Object A 1 

Object A 2 

Bild 3 

BILD 1: AutomationML-Architektur 

COLLADA 

Geometrie 

Kinematik 

PLCopen XML 

Verhalten 

Abfolgen 

a 

h 

Standardisierung 

Praktischer Einsatz 

BILD 2: Standardisierungs- 

Deadlock 

g 

DB 

Quell- 

Tool 

1 

Exporter 

2 

3 

Ziel- 

Tool 

Importer 

DB 

4 

BILD 3: 

Idealer Datenaustausch 

mit CAEX 

Mapping 

Quell – Neutral 

Bild 4 

AutomationML 

Mapping 

Neutral – Ziel 

Quell- 

Tool 

Daten liegen gemischt 

neutral/privat vor 

DB 

1 

Exporter 2 

3 

Mapping 

1. Quell – neutral 

AutomationML 

Ziel- 

Tool 

Importer 

DB 

4 

Mapping 

1. neutral – Ziel 

2. Quell CAEX – Ziel 

BILD 4: 

Realer Datenaustausch 

mit CAEX 

74 


12 / 2012

nematikdaten eines Objektes referenzieren lassen. Diese 

werden in einer separaten Collada-Datei gespeichert. 

Darüber hinaus kann diskretes Verhalten in separaten 

PLCopen XML-Dateien beschrieben werden. Einen vertiefenden 

Einblick in AutomationML gibt [4]. 

Bezüglich Geometrie, Kinematik und diskreter Logik 

besitzt AutomationML bereits eine definierte Syntax und 

Semantik. AutomationML ist aber mehr als nur Geometrie 

oder Logik: Auch Objektmodelle sind mit CAEX modellierbar, 

beispielsweise eine Hardwarehierarchie. CAEX liefert 

jedoch keine fertigen Objekt-Bibliotheken, keine Ontologien 

oder gar ein Engineering-Weltmodell. Stattdessen trennen 

die Entwickler von CAEX bewusst Syntax und Semantik. 

CAEX schreibt kein Objektmodell vor, sonden bietet 

Mechanismen zur Modellierung beliebiger nutzerdefinierter 

Datenmodelle. Diese werden syntaktisch neutralisiert, 

die Semantik hingegen bleibt nutzerdefiniert. Auf diese 

Weise kann CAEX von Anbeginn unterschiedliche Objektmodelle 

abbilden und so Semantikvielfalt aufnehmen. 

Damit ist es für zukünftige Standard-Datenmodelle gerüstet. 

Doch die Standardisierungs-Community hat bis heute 

kein Engineering-Weltmodell etabliert – die Beherrschung 

der Semantikvielfalt ist bisher nicht gelungen. Warum? 

1.2 Das Grundproblem der Semantik-Standardisierung 

Die Ur-Idee eines neutralen Datenformates besteht darin, 

Daten herstellerneutral und verlustlos zu speichern. Es 

liegt daher der Gedanke nahe, die Semantikvielfalt durch 

ein Super-Datenmodell zu beherrschen, das sämtliche 

Konzepte aller verwendeten Datenmodelle vereint und 

eine eindeutige und verlustlose Abbildung aller Daten 

ermöglicht. Dies ist die treibende Kraft aller Standardisierungsaktivitäten. 

Damit eine solche Standardisierung 

gelingt, müssen folgende Schritte absolviert werden: 

1.2.1 Schrittfolge einer Semantik-Standardisierung 

a | Eine Gruppe von Experten trägt für jedes beteiligte 

Gewerk beziehungsweise Engineeringwerkzeug 

alle benötigten Datenmodelle und Konzepte bei. 

b | Experten einigen sich auf die gemeinsamen Grundkonzepte. 

c | Experten einigen sich auf ein neutrales semantisches 

Datenmodell, das alle Grundkonzepte berücksichtigt, 

zum Beispiel UML. 

d | Experten einigen sich auf eine neutrale Syntax, 

beispielsweise basierend auf XML. 

e | Die gemeinsamen Grundkonzepte, das semantische 

Datenmodell und die Umsetzung in einer gemeinsamen 

Syntax werden in einem Dokument niedergeschrieben, 

beispielsweise in einem Normtext 

oder White Paper. 

f | Die Industrie und Akademia schaffen die Voraussetzungen 

dafür, dass genügend Experten zur Verfügung 

stehen, die den Standard beurteilen und 

implementieren können. 

g | Anwender und Werkzeughersteller implementieren 

und nutzen den Standardentwurf in ihren 

Werkzeugen. 

h | Erfahrungen aus der praktischen Nutzung des Standards 

fließen in (a) zurück und tragen zur Standard-Reifung 

bei. 

1.2.2 Der Standardisierungs-Deadlock 

Die Entwicklung neutraler Datenmodelle wurde und wird 

in unterschiedlichen Aktivitäten versucht, zum Beispiel 

NE100 [6], Plant-XML [7], STEP [8], Engineering Service 

Bus [9], mit wissensbasierten Systemen [10] oder ISO 15926 

[11]. Ein Engineering-Weltmodell ist dennoch nicht in 

Sicht und unter globalen Randbedingungen vermutlich 

nicht erreichbar. Während die Standardisierung nur reifen 

kann, wenn Erfahrungen aus der praktischen Nutzung 

einfließen, warten Werkzeughersteller typischerweise auf 

einen gereiften Standard, bevor sie ihre Software mit Exund 

Importern ausstatten. Daraus resultiert der in Bild 2 

veranschaulichte Standardisierungs-Deadlock: die Rückführungen 

(g) und (h) sind gestört. 

Ein bekanntes Beispiel für dieses Paradoxon ist die STEP- 

Initiative. In diesem Ansatz beschreiben tausende Textseiten 

vielfältige Aspekte der Anlagenplanung und deren Life- 

Cycle. Diese Aktivität hat unter jahrelangen Bemühungen 

(a) bis (e) erfolgreich durchlaufen, scheitert in der Praxis 

jedoch aufgrund seiner Komplexität an (f), (g) und (h). 

Ein anderes Beispiel ist PlantXML. Innerhalb eines 

Unternehmens wurden über mehrere Jahre für eine Auswahl 

von Werkzeugen hunderte Attribute und Objekttypen 

standardisiert. PlantXML hat erfolgreich (a) bis (h) 

durchlaufen und ist produktiv. Leider ist es für andere 

Unternehmen oder Gewerke nicht wiederverwendbar, 

da es an seine Werkzeuge gebunden ist. Folglich besitzt 

es Schwächen in (f), (g) und (h) – es ist keine Anwendung 

außerhalb ihrer Entstehungsquelle bekannt. 

Fazit: Die Erfahrung zeigt, dass das Engineering-Weltmodell 

aufgrund der Vielzahl von Werksnormen, regionalen 

und nationalen Standards nicht in einem Schritt 

erreichbar ist. Es wird daher ein Konzept benötigt, welches 

bereits heute den Umgang mit der Semantik-Vielfalt 

ermöglicht, statt auf ein künftiges übergreifendes Semantik-Modell 

zu warten. 

2. UMGANG MIT HETEROGENEN DATENMODELLEN 

2.1 Grundlagen und Herleitung 

Die ursprüngliche Idee eines neutralen Datenformates 

beruht darauf, Daten herstellerunabhängig und verlustfrei 

zu modellieren und zu speichern. Das vorgestellte 

Konzept leitet sich direkt aus den in Bild 3 dargestellten 

Aufgaben idealer CAEX-Exporter und -Importer der teilnehmenden 

Werkzeuge ab. 

Schritt 1: Ein CAEX-Exporter exportiert Daten aus 

einer proprietären Datenbank eines Quell-Engineering-Werkzeugs. 

Dazu benötigt er Zugriff auf die 

Quelldaten. 

Schritt 2: Der CAEX-Exporter transformiert die proprietären 

Daten verlustfrei in das vereinbarte neutrale 

CAEX-Datenmodell und speichert dies als Au- 


12 / 2012 

75

HAUPTBEITRAG 

tomationML-Dokument ab. Dazu benötigt er Wissen 

über das proprietäre Datenmodell sowie das neutrale 

Datenmodell und zugleich über zugehörige Transformationsregeln. 

Schritt 3: Der CAEX-Importer liest das AutomationML- 

Dokument und transformiert die Daten aus dem 

neutralen Datenmodell in das proprietäre Datenmodell 

des Zielwerkzeugs. Dazu benötigt er Wissen 

über das neutrale und das proprietäre Datenmodell 

des Zielwerkzeugs sowie über die zugehörigen 

Transformationsregeln. 

Schritt 4: Der CAEX-Importer importiert die transformierten 

Daten in das proprietäre Datenmodell des 

Zielwerkzeugs. Dazu benötigt er Zugriff auf die Daten 

des Zielwerkzeugs. 

Leider fehlt das neutrale Datenmodell. Für eine Vielzahl 

vereinzelter Objekte finden sich zwar aus aktuellen Standardisierungsergebnissen 

Daten-Teilmodelle, beispielsweise 

für ein Signal (NE 100) oder einen Sensor (ISO 

15926). Für viele Daten lassen sich in Schritt 2 jedoch keine 

oder wenige Transformationsregeln implementieren. 

2.2 Die Idee eines gemischten Datenmodells 

Was passiert, wenn man private Datenmodelle zuließe, 

statt sie zu vermeiden? Fehlende neutrale Datenmodelle 

sind für AutomationML kein Hindernis: CAEX erlaubt 

explizit das Speichern gemischt proprietär/neutraler 

Daten-Teilmodelle. Proprietäre Daten werden immerhin 

syntaktisch neutralisiert, semantisch bleiben sie proprietär. 

Auch wenn das Zielwerkzeug diese Daten nicht 

interpretieren kann (zu Beginn ein sehr wahrscheinlicher 

Fall), stellt dies bereits einen erheblichen Gewinn 

dar: Erstmalig werden proprietäre Datenmodelle außerhalb 

ihres Werkzeugs syntaktisch neutralisiert und explizit 

sichtbar. Dies erleichtert die Schritte (a) und (b) der 

beschriebenen Standardisierungskette. Dies ändert die 

Aufgabe des Exporters (Bild 4): 

Schritt 2: Der Exporter transformiert nur diejenigen 

proprietären Daten, für die ein neutrales Datenmodell 

vorliegt. Die privaten Daten lässt er unverändert 

und überträgt sie 1:1 nach CAEX. Das resultierende 

CAEX-Dokument enthält in diesem Fall 

eine Mischung aus neutralen und privaten Daten- 

Teilmodellen. 

Andere Engineering-Werkzeuge können diese Datei zumindest 

öffnen, Inhalte untersuchen, Änderungsberechnungen 

durchführen und Versionsmanagement betreiben. Während 

neutrale Datenmodelle identifiziert und importiert 

werden können, gelingen die Interpretation und der Import 

proprietärer Daten nicht unmittelbar. Dazu muss ein Zielwerkzeug 

den Absender wissen und dessen Datenmodelle 

kennen, um geeignete Transformationsroutinen aufrufen 

zu können. Dies ändert die Aufgabe des Importers: 

Bild 5 

Schritt 3: Der Importer transformiert die neutralen 

Daten in das proprietäre Datenmodell des Zielwerkzeugs. 

Private Daten müssen jedoch mithilfe zuge- 

Reifegrad 1 

Reifegrad 2 

Reifegrad 3 

Reifegrad 3 3 

Reifegrad 4 

Standardisierungsgrad = 0% 

Standardisierungsgrad > 0% 

lokaler 

Standardisierungsgrad = 100% 

übergreifender Standard 

Praktischer 

Einsatz 

Praktischer 

Einsatz 

Praktischer 

Einsatz 

Praktischer 

Einsatz 

Unbek. priv. Datenmodelle 

Kandidaten für das 

Lastenheft? 

Unbek. priv. Datenmodelle 

Kandidaten für das 

Lastenheft? 

Neutrale Datenmodelle 

NeutraleTransformationen 

Standard Datenmodelle 

Standard Transformationen 

SW-Entwicklung 

SW-Entwicklung 

Bekannte priv. Datenmodelle 

Private Transformationen 

Kandidaten für lokale 

Standardisierung? 

Bekannte priv. Datenmodelle 

Priv.Transformationen 

Neutrale Datenmodelle 

Neutrale Transformationen 

Standardisierung 

Lokale Standardisierung 

von Mini-Datenmodellen 

BILD 5: Reifegrade der 

semantischen Standardisierung 

76 


12 / 2012

schnittener privater Transformationsregeln interpretiert 

werden, oder sie werden ignoriert. 

2.3 Identifikation des Quellwerkzeugs 

Doch wie kann ein Importer erkennen, welche privaten 

Transformationsroutinen angewendet werden müssen? 

AutomationML führt dazu erstmalig einen standardisierten 

Etikettiermechanismus ein. Die CAEX-Datei bekommt 

ein Etikett, dieses wird während des Exports in Schritt 2 

eingebettet und enthält Informationen über das Quellwerkzeug 

(siehe Abschnitt 1). Ein Importer kann dieses 

Etikett auswerten und private Transformationsroutinen 

anstoßen. Dies führt für den Praktiker zu schnellen Lösungen 

ohne Warten auf das Engineering-Weltmodell. 

Doch ist das nicht ein Rückfall in die Situation, in der 

jedes Werkzeug seine Daten in seinem eigenen proprietären 

Datenformat exportiert? Nein! Folgende Aspekte verdeutlichen 

das: 

Das Etikettierkonzept erlaubt die automatische Absendererkennung. 

Excel-Sheets und andere bekannte 

Austauschmechanismen verfügen über keine 

standardisierte Methodik dafür. 

Das neutrale Datenformat ermöglicht die Neutralisierung 

proprietärer Datenmodelle auf Syntax- 

Ebene. Dies ermöglicht datenmodellunabhängige 

Operationen wie Versionsmanagement oder Änderungsberechnungen 

([2], [9]). Derartige Funktionalität 

müsste für jedes proprietäre Datenformat erneut 

entwickelt werden. Basierend auf einem neutralen 

Datenformat genügt eine einzige Implementierung. 

Ein Großteil des Importers kann daher 

unabhängig vom Quellwerkzeug wiederverwendet 

werden. 

2.4 Praktische Relevanz 

Der vorgeschlagene Ansatz ändert den Weg zu einem 

neutralen Datenmodell erheblich: Eine AutomationML- 

Datei wird nach dem Datenexport teilweise proprietär. 

Dies verletzt die Ur-Idee eines neutralen Datenformates 

und verlässt scheinbar bewährte Pfade. Zu Recht: Der 

hier vorgeschlagene Ansatz nutzt die Heterogenität bewusst, 

anstatt sie überwinden zu wollen. 

Entwickler von Exportern und Importern müssen 

nicht mehr auf einen gereiften Standard warten. 

Dies überwindet den beschriebenen Deadlock 

(Bild 2) und beschleunigt die Entwicklung von Datenaustauschlösungen. 

Für die Gremien ist die Mischung von privaten und 

neutralen Daten-Teilmodellen ein fruchtbarer Boden 

für eine erfolgreiche schrittweise Evolution der 

Standardisierung. Sie erlaubt, gänzlich ohne Standardisierung 

mit ausschließlich privaten Daten zu 

beginnen, um schrittweise eine vollständige Standardisierung 

zu erreichen. Dabei werden Zwischenschritte 

durchlaufen, aus denen die Autoren ein 

Reifegradmodell ableiten. 

3. REIFEGRADE DER STANDARDISIERUNG 

3.1 Überblick 

Aus der Idee eines gemischt privat/neutralen Datenmodells 

entwickeln die Autoren ein Reifegradmodell der 

semantischen Standardisierung, dessen Stufen in Bild 5 

abgebildet sind. Das Ziel dieses Reifegradmodells besteht 

darin, den erläuterten Standardisierungs-Deadlock zu 

durchbrechen und den Datenaustausch in einem heterogenen 

Werkzeugumfeld auch ohne beziehungsweise 

nur mit teilweiser Standardisierung durchführen zu 

können. Im Vordergrund jedes Reifegrades steht immer 

dessen praktischer Einsatz. Die Entwicklung neutraler 

Daten-Teilmodelle erfolgt schrittweise und ist nicht 

mehr Voraussetzung für den praktischen Einsatz. Dies 

bedeutet, dass die Standardisierung der Nutzung folgt, 

nicht umgekehrt wie bisher. 

3.2 Reifegrad 1 – das vollständig private Datenmodell 

Reifegrad 1 beginnt mit einem Standardisierungsgrad 

von 0 % (das heißt mit 100 % privaten Daten). Betrachten 

wir den Exporter und Importer eines Quell- und Ziel- 

Engineering-Werkzeugs nach Reifegrad 1: Beide verwenden 

keinerlei lokale/globale Vereinbarungen oder Standards, 

die Werkzeuge sind völlig unabhängig. Der Exporter 

exportiert die Daten in Schritt 2 nach CAEX unter 

Verwendung der CAEX-Syntax, aber unter Verwendung 

des privaten Datenmodells des Quellwerkzeugs. 

Die Entwicklung des quellwerkzeugspezifischen Exporters 

ist wegen des fehlenden Standards besonders einfach, 

der Aufwand wird maßgeblich durch die Offenheit des 

Quellwerkzeugs bestimmt [12]. Den Erfahrungen der Autoren 

zufolge ist ein Exporter, je nach angestrebter Produktreife, 

in wenigen Tagen zu implementieren [15]. 

Die Entwicklung des quellwerkzeugspezifischen Importers 

erfordert mehr Aufwand, wird durch das beschriebene 

Konzept aber erheblich unterstützt. Aufgrund 

der standardisierten CAEX-Syntax kann der Importer 

(selbst ohne Wissen über das Quell-Datenmodell) 

die Datei öffnen, durchsuchen und darstellen. Doch das 

ist nicht alles: Darüber hinaus sind wesentliche Funktionen 

eines Importers wie Navigation, Änderungsberechnungen 

sowie Versions-Managementfunktionen unabhängig 

vom Datenmodell und lassen sich generisch entwickeln 

und wiederverwenden – nicht denkbar mit einem 

syntaktisch unstandardisierten Datenformat wie 

beispielsweise einer Excel-Liste. 

Das Etikettierkonzept ermöglicht dem Importer, das 

Quellwerkzeug festzustellen. Dies ist der Schlüssel zum 

„Erkennen“ von privaten Datenmodellen. Zu Beginn 

wird der Importer keine bekannten Datenmodelle (Klassen) 

finden (siehe Bild 5), dafür müssen zuerst geeignete 

private quellwerkzeugspezifische Subroutinen für die 

Interpretation und den Import entwickelt werden. Dies 

wird ebenfalls unterstützt: Der Importer kann konzeptbedingt 

unbekannte private Datenmodelle explizit erkennen 

und in einer CAEX-Bibliothek speichern. Aus 

dieser lässt sich der Standardisierungsbedarf automatisch 

ableiten und anhand von Häufigkeitsuntersuchun- 


12 / 2012 

77

HAUPTBEITRAG 

gen sogar priorisieren. Private Transformationsroutinen 

können mit diesem Wissen schnell und in lokaler Verantwortung, 

das heißt ohne Abhängigkeiten zu höheren/ 

öffentlichen Standardisierungsaktivitäten, entwickelt 

werden. Dies könnte auch eine Quick–and-dirty-Lösung 

sein, das Konzept ist nicht an ein kommerzielles Produkt 

eines Werkherstellers gebunden. Das Ziel ist der Einsatz 

und die Reifung unter realen Bedingungen. 

Im Ergebnis werden aus unbekannten somit bekannte 

Datenmodelle. Die entwickelten privaten Transformationsroutinen 

lassen sich für jeden weiteren Datenaustausch 

mit demselben Quellwerkzeug wiederverwenden. 

Die Vorteile von Reifegrad 1 liegen in seiner unmittelbaren 

Einsetzbarkeit: Da ein Standard nicht abgewartet 

werden muss, können zwei Werkzeughersteller oder 

-nutzer unmittelbare Export-Import-Partnerschaften eingehen. 

Ein dritter Teilnehmer kann sich (auch später) 

einbinden, je mehr Teilnehmer, desto geringer der Gesamtaufwand. 

Lediglich die werkzeugpaarspezifischen 

Transformationsroutinen sind unterschiedlich. 

Reifegrad 1 kombiniert die Kosteneffizienz eines 

leichtgewichtigen Excel-basierten Datenaustausches mit 

den Vorteilen höherwertiger Funktionen wie Änderungsmanagement. 

Kosteneinsparungen werden zeitnah erzielt. 

Zudem bietet Reifegrad 1 einen weiteren neuartigen 

Vorteil: Ein Importer kann alle Objekttypen feststellen, 

die ihm unbekannt sind. Auf diese Weise werden nicht 

nur alle bekannten, sondern auch alle unbekannten Daten 

explizit sichtbar. Diese Sichtbarkeit ist ein Schlüssel 

für die Identifizierung von Standardisierungsbedarf und 

eröffnet den Weg zu einer automatischen Erzeugung von 

Lastenheften. Der Wissensaufbau im Umgang mit CAEX 

erfolgt schrittweise. Der Datenaustausch kann so bedacht 

eingeführt und praktiziert werden und reifen. 

Reifegrad 1 ist somit ein wichtiger Meilenstein in der 

Evolution eines Standardisierungsprozesses. Er erleichtert 

die Schritte (a) und (b) und belebt die Rückführung 

von Erfahrungen (h) aus Bild 2. Dies löst den Standardisierungs-Deadlock. 

Dieser Reifegrad ist für Werkzeuge mit wenigen Datenaustauschpartnern 

geeignet und möglicherweise sogar 

ausreichend. Die Entwicklung privater Transformationsroutinen 

benötigt deutlich weniger Aufwand als eine 

Standardisierung. Reifegrad 1 ist weiterhin ideal für 

Werkzeuge, die lediglich ihre eigenen Daten archivieren 

beziehungsweise extern manipulieren und anschließend 

wieder einlesen möchten. 

Mit der Zeit und wachsender Zahl von Teilnehmern 

wird eine Bibliothek aus Transformationsroutinen entstehen. 

Dies ist ein geeigneter Indikator für den Start 

einer Konsolidierung des Entwicklungsaufwandes und 

somit ein guter Übergangspunkt zu Reifegrad 2, denn 

ähnliche Datenmodelle sind Kandidaten für eine erste 

Standardisierung. 

3.3 Reifegrad 2 – 

das gemischt standardisierte/private Datenmodell 

Reifegrad 2 entsteht aus der Konsolidierung der Standardisierungskandidaten 

aus Reifegrad 1 (siehe Bild 5). Für 

ähnliche private Datenmodelle entwickelt sich im Kreise 

der Teilnehmer der Wunsch nach lokaler Standardisierung 

im Zuge einer kosteneffizienten Softwareentwicklung. 

Dies erhöht die Standardisierungsbereitschaft 

und führt zu ersten neutralen Mini-Datenmodellen. 

Jede solche Standardisierung wird belohnt: Für jedes 

neutralisierte Mini-Datenmodell kann in jedem Importer 

die Zahl (n) der privaten Transformationsroutinen für n 

Quellwerkzeuge auf eine einzige Transformationsroutine 

reduziert werden. Auf diese Weise entsteht ein Pool 

an neutralen Datenmodellen, während der Pool privater 

Transformationsroutinen schrumpft. 

Wichtig dabei ist das Verständnis für den Evolutionsprozess 

hin zu Reifegrad 2, welcher ausschließlich aus 

praktischen Projektbedürfnissen getrieben wird. Dies 

stellt einen natürlichen und evolutionären Prozess dar. 

Unter Verwendung erster neutraler Daten-Teilmodelle 

erzeugt ein Exporter in Reifegrad 2 ein gemischt standardisiert/privates 

CAEX-Datenmodell. Ein Importer 

kann alle bekannten Datenmodelle anhand ihres Klassennamens 

sowie des Etiketts erkennen, interpretieren 

und importieren. Hierbei können dieselben Transformationsroutinen 

wiederverwendet werden, die in Reifegrad 

1 entstanden sind. Aus erkannten unbekannten Datenmodellen 

lässt sich auch hier automatisiert Standardisierungsbedarf 

ableiten. Bild 6 illustriert anhand privater 

oder unbekannter Objekttypen Kandidaten, die als 

Standardisierungs- beziehungsweise Entwicklungskandidaten 

in Frage kommen. Reifegrad 2 ist für überschaubare 

und feststehende Datenaustauschszenarien geeignet 

und in vielen Fällen sogar ausreichend. 

3.4 Reifegrad 3 – das neutrale Datenmodell 

Reifegrad 3 wird erreicht, wenn alle benötigten Daten- 

Teilmodelle durch neutrale Datenmodelle abgebildet 

werden – er ist das Gegenstück zu Reifegrad 1 – der Anteil 

an privaten Datenmodellen beträgt 0 Prozent. Seine 

Reife erlangt er durch Erfahrungen im praktischen Einsatz. 

Reifegrad 3 ist nicht an internationale Standards 

gebunden – es könnte ebenso ein Standard eines einzelnen 

Projektes oder eines Konsortiums sein. Dieser Reifegrad 

kommt der eigentlichen Idee eines neutralen Datenaustauschformates 

bereits nahe: private Transformationsroutinen 

sind nicht mehr notwendig – das Datenmodell 

ist aus Erfahrungen der Reifegrade 1–2 gewachsen 

und gereift. Als Beispiel könnte das für das Engineering 

von Automatisierungssystemen zentrale Element „Signal“ 

international standardisiert werden, wohingegen 

ein anderes Datenmodell „Safety IO Module“ zunächst 

proprietär oder lokal standardisiert bliebe. 

3.5 Reifegrad 4 – 

das standardisierte neutrale Datenmodell 

Reifegrad 4 wird erreicht, wenn mehrere Reifegrad 3 

Standards zu einem übergeordneten Standard kombiniert 

werden (siehe Bild 5). Die Datenmodelle aus Reifegrad 

3 bilden aufgrund praktischer Erfahrungen eine 

belastbare Basis für die Schritte (a) und (b) eines übergreifenden 

Standardisierungsvorhabens, zum Beispiel 

78 


12 / 2012

für einen internationalen Standard. Dieser Reifegrad ist 

als langfristiges Ziel zu verstehen und ein evolutionäres 

Ergebnis des Durchlaufens der vorigen Reifegrade. 

4. DISKUSSION DES KONZEPTES 

4.1 Vorteile 

Das vorgestellte Reifegradmodell der Semantik-Standardisierung 

ist ein neuer Ansatz und eröffnet eine Vielzahl 

neuer Möglichkeiten und Vorteile. 

Vorteil 1: Schnellstart mit hoher 

Wiederverwendungsquote 

Werkzeughersteller oder Anwender können unmittelbar 

starten. Sobald ein Datenaustauschbedarf identifiziert 

ist, kann der Projektleiter eine individuelle Entwicklung 

der wichtigsten Subroutinen für den automatischen Import 

privater Daten aus einem Quell-Engineering-Werkzeug 

in das von ihm gewünschte Zielwerkzeug initiieren. 

Die privaten Transformationsroutinen eines Importers 

können später von Projekt zu Projekt wiederverwendet 

werden. Der Aufwand zur CAEX-Programmierung 

wird mit [15] abschätzbar. 

Vorteil 2: Datenmodelle werden explizit sichtbar 

Normalerweise sind Datenmodelle in ihren Werkzeugen 

verborgen und sind nur Experten zugänglich. Das von 

AutomationML verfolgte Konzept macht proprietäre und 

unbekannte Datenmodelle jedoch explizit sichtbar. Dies 

Bild 6 

vereinfacht die Entwicklung im Projekt, befördert die 

Diskussion über Datenmodelle und beschleunigt die 

Standardisierungsschritte (a)–(c). 

Vorteil 3: Automatische Ableitung von Entwicklungsund 

Standardisierungsbedarf 

Konzeptbedingt können unbekannte Datenmodelle erkannt 

und in Bibliotheken gespeichert werden. Diese 

Bibliotheken lassen sich als Lastenheft für eine Importer- 

Softwareentwicklung einsetzen, da sie die privaten Datenmodelle 

möglicher Datenaustauschkandidaten explizit 

spezifizieren. Mithilfe von Häufigkeitsuntersuchungen 

lassen sich sogar Prioritäten ableiten. 

Statistische Analysen beflügeln wiederum den Standardisierungsprozess, 

da sie die Schritte (a) und (b) vereinfachen. 

Der vorgestelle evolutionäre Ansatz optimiert 

das Verhältnis zwischen dem Aufwand zur Entwicklung 

privater Transformationsroutinen und der Standardisierung. 

Durch das explizite Wissen über unbekannte oder 

ähnliche Datenmodelle können Standardisierungsaktivitäten 

fokussiert werden. Dies wird durch einen impliziten 

Regelkreis erreicht: Die Entwicklung privater 

Transformationsroutinen für jedes Quellwerkzeug ermöglicht 

schnelle Ergebnisse, führt aber mit der Zeit zu 

redundanter Entwicklung pro Quellwerkzeug. Diese 

Kosten sind Treiber für eine vernünftige und zielgerichtete 

Standardisierung, die mittelfristig die Entwicklungskosten 

senkt. Seltene private Datenmodelle können 

in privaten Transformationsroutinen verbleiben. Aus 

diesen Gründen behindert das Etikettierkonzept nicht 

die Standardisierung, sondern fördert sie. 

Neutrale Objekt-Typen 

Neutral_Signal 

Neutral_Master_Controller 

Neutral_Fieldbus_Device 

Neutral_IO_Module 

Private Objekt-Typen 

Force_Torque_Sensor 

Unbekannte Objekt-Typen 

HMI_Panel 

IPC_Socket 

BILD 6: Automatisch ermittelter Entwicklungs- und Standardisierungsbedarf 

Bereits 

standardisiert 

Standardisierungskandidat 

Kandidat für das 

Entwicklungslastenheft 

Bild 8 

Private Klassen-Bibliothek 

Standard Klassen-Bibliothek 

Private Interface Class library 

Standard Interface Class library 

BILD 8: CAEX-Modelle mit privaten 

und standardisierten Daten 

BILD 7: AutomationML-Beispiel-Etikett 


12 / 2012 

79

HAUPTBEITRAG 

Vorteil 4: Speed-Standardisierung von 

Mini-Datenmodellen 

Das Etikettierkonzept sowie die Mischung privater und 

neutraler Daten eliminiert den Bedarf nach einem umfassenden 

und gereiften Engineering-Weltmodell: Der 

Schwerpunkt verlagert sich stattdessen auf kleine und 

flexible Mini-Datenmodelle, wie beispielsweise das „Signal“. 

Signallisten werden vielfältig ausgetauscht, die Standardisierung 

eines Signalobjektes ist im Fertigungsumfeld 

realisierbar und bereits aus rein praktischen Erwägungen 

ein lohnenswertes und erreichbares Ziel. Eine solche 

Speed-Standardisierung kann von erfahrenen Projektleitern 

oder Lead-Ingenieuren in kurzer Zeit erfolgen. Das 

Ergebnis dieser Arbeit ist ein lokaler Standard und lässt 

sich umgehend in Importer und Exporter implementieren 

und im Praxisgebrauch prüfen. Kostenersparnisse könnten 

vor Ort unmittelbar von den Beteiligten im Initialprojekt 

realisiert und in Nachfolgeprojekten vervielfacht werden. 

Diese Mikro-Standardisierung zwischen zwei Werkzeugen 

ist ein agiler, pragmatischer Weg auch für kleinere 

Ingenieurbüros, ohne jede Abhängigkeit von Standards. 

Die Standardisierungsschritte (a) bis (c) können 

sogar automatisiert werden, (f) wird innerhalb des Teams 

gelöst und (h) wird durch die unmittelbare praktische 

Anwendung erreicht. 

Vorteil 5: Zeitliche Entkopplung von 

Standardisierung und Projektarbeit 

Die Behandlung privater Transformationsroutinen erfolgt 

in der Verantwortung und Zeitleiste des Projektes und 

kann schnell umgesetzt und lokal priorisiert werden. Die 

Standardisierung hingegen erfolgt außerhalb in einem 

übergeordneten Regelkreis und fließt erst mit seiner Finalisierung 

in das Projekt ein. Diese Entkopplung ermöglicht 

das gleichzeitige Agieren in kurzfristigen Projekterfordernissen 

und in langfristigen Standardisierungsaktivitäten. 

Vorteil 6: Einführung von Standard-Etiketten 

Das Etikettierkonzept ist nicht nur geeignet, um Quellwerkzeuge 

zu identifizieren, es kann ebenso auf einen 

oder mehrere zugrundeliegende Standards verweisen. 

Eine AutomationML-Datei teilt erstmalig aktiv mit, welche 

Semantik-Standards sie verwendet. 

4.2 Diskussion und Potenziale 

Natürlich wäre es einfacher, wenn ein Engineering-Weltmodell 

zur Verfügung stünde. Die Standardisierungsgremien 

und Softwarehersteller haben frühzeitig den Wert 

eines gemeinsamen Datenmodells erkannt und verfolgen 

beziehungsweise benötigen mehrheitlich Reifegrad 3 oder 

4. Dieser Beitrag zeigt, dass das Ziel sinnvoll, der Weg jedoch 

fraglich ist – ein reifer Standard benötigt Erfahrungen 

aus der industriellen Anwendung. Für die Praxis 

macht es keinen Sinn, sogleich mit dem Reifegrad 3 oder 

4 zu beginnen, zumindest – bei einem so weiten Kontext 

wie der Automatisierungsplanung – nicht in einem Schritt. 

Die Evolution beginnt mit Reifegrad 1. Die Reifegrade 1-4 

wachsen aneinander, ein Merkmal der Evolution. 

REFERENZEN 

[1] Drath R. und Barth M.: Concept for interoperability 

between independent engineering tools of heterogeneous 

disciplines. In: Proceedings IEEE Conference on Emerging 

Technologies and Factory Automation (ETFA), 2011. 

[2] Drath R., Fay A., Barth M.: Interoperabilität von Engineering- 

Werkzeugen. at – Automatisierungstechnik 59(9), 598-607, 

2011 

[3] AIDA (2005): Garcia, A. und Drath, R.: AutomationML 

verbindet Werkzeuge der Fertigungsplanung. 

http://www.automationml.org – Whitepaper_Automation- 

ML_2007-11-20_v05.pdf. 

[4] Drath, R.: Datenaustausch in der Anlagenplanung mit 

AutomationML: Integration von CAEX, PLCopen XML und 

COLLADA. Springer, Berlin Heidelberg, 2009 

[5] IEC 62424:2008: Representation of process control 

engineering - Requests in P&I diagrams and data exchange 

between P&ID tools and PCE-CAE tools 

[6] NE 100: Merkmalleisten zur Erstellung von PLT-Gerätespezifikationen. 

Namur, 2003 

[7] Anhäuser, F., Richert, H., Temmen, H.: Degussa Plant-XML 

- integrierter Planungsprozess mit flexiblen Bau-steinen. 

atp – Automatisierungstechnische Praxis 46(4), 63-72, 2004 

[8] ISO10303: Automation systems and integration - Product 

data representation and exchange 

[9] Moser, T. und Biffl, S.: Semantic Tool Interoperability for 

Engineering Manufacturing Systems, In: Proceedings IEEE 

Conference on Emerging Technologies and Factory 

Automation (ETFA’10), S. 1-8, 2010 

[10] Wiesner A., Wiedau M., Marquardt W., Temmen H., 

Richert H., Anhäuser F.: Wissensbasierte Integration und 

Konsolidierung von heterogenen Anlagenplanungsdaten. 

atp edition – Automatisierungstechnische Praxis, 52(4), 

48-58, 2010 

[11] ISO 15926: Industrial automation systems and integration 

- Integration of life-cycle data for process plants including 

oil and gas production facilities 

[12] Fay, A., Drath, R., Barth, M., Zimmer,F., Eckert K.: 

Bewertung der Fähigkeit von Engineering-Werkzeugen 

zur Interoperabilität mithilfe einer Offenheitsmetrik. 

In: Tagungsband Automation 2012, S. 37-40. VDI, 2012 

[13] IEC 62714-1 CD: AutomationML Architecture, 2011 

[14] www.automationml.org 

[15] Drath R.: Let’s talk AutomationML: What is the effort for 

AutomationML programming? In: Proceedings IEEE 

Conference on Emerging Technologies and Factory 

Automation (ETFA’12), 2012 

80 


12 / 2012

Solange die beteiligten Werkzeuge offen genug sind 

[12], wird die semantische Vielfalt mit dem vorgestellten 

Konzept beherrschbar. Hersteller und Anwender können 

leicht Exporter für ihre Werkzeuge erstellen, ohne sich 

auf einen Standard beziehen zu müssen. 

Generische Importer sind erst mit Reifegrad 3–4 sinnvoll 

und deshalb heute für weite Bereiche der Anlagenplanung 

nicht anzutreffen. Um die semantische Vielfalt 

zu beherrschen, sind für die Reifegrade 1–2 quellwerkzeugspezifische 

Importer erforderlich. 

Das vorgestellte Konzept vereinfacht deren Entwicklung 

maßgeblich, weil große Teile typischer Importfunktionalitäten 

generisch angelegt werden können. Anwender 

können diese in Eigenregie deutlich leichter und 

schneller als bisher entwickeln. Gerade für das Umsetzen 

abzählbarer Datenaustauschpartner ist der Entwicklungsaufwand 

für solche Importer deutlich geringer als 

das Standardisieren eines Weltmodells. Zudem können 

Werkzeughersteller im Sinne des Know-how-Schutzes 

mit kommerziellen Importern gezielter als bisher beeinflussen, 

welche Quellwerkzeuge sie mit welchem Detaillierungsgrad 

unterstützen. 

5. UMSETZUNG MIT AUTOMATIONML 

5.1 Etikettierung einer AutomationML-Datei 

Zur Etikettierung einer CAEX-Datei schreibt der AutomationML-Standard 

[13] eine Reihe von Parametern vor. 

Bild 7 zeigt eine vollständige Liste der vorgeschriebenen 

Etikett-Bestandteile im CAEX-XML-Code. Mithilfe der 

frei verfügbaren AutomationML-Engine [14] lassen sich 

diese Parameter mit vertretbarem Aufwand einfügen 

oder auslesen, eine Einführung hierfür gibt [15]. 

5.2 Speicherung gemischt privater/neutraler Daten 

Die Speicherung privater Datenmodelle ist eine der Kernfunktionalitäten 

von CAEX. Bild 7 zeigt einen CAEX- 

Export, der sowohl private als auch standardisierte Klassen 

und Schnittstellen enthält. Ein gemischt privat/neutraler 

Objektbaum wird aus Instanzen dieser Klassen 

erstellt. Analog zu einem veredelten Obstbaum, an dem 

Früchte unterschiedlicher Arten hängen, entsteht in 

CAEX ein Objektbaum, der mehrere Datenmodelle zugleich 

verwaltet, deren Elemente jedoch identifizierbar 

und somit beherrschbar sind. 


In diesem Beitrag wurde die Deadlock-Situation vieler semantischer 

Standardisierungsbemühungen diskutiert und 

ein neues Konzept zur Lösung dieser Probleme vorgestellt. 

Hierin wird nicht wie bisher versucht, die bestehende Heterogenität 

von Engineering-Werkzeugen und Datenmodellen 

durch Vereinheitlichung zu überwinden; das Konzept 

verfolgt vielmehr das Anliegen, den Datenaustausch 

in einem heterogenen Werkzeugumfeld auch ohne beziehungsweise 

nur mit teilweiser Standardisierung durch- 

führen zu können. Die Ur-Idee eines neutralen Datenformates 

wird hierbei bewusst verletzt – aber Innovationen 

werden oft dann erreicht, wenn bekannte Pfade verlassen 

oder zuvor gesetze Einschränkungen hinterfragt werden. 

Das Konzept zur Speicherung gemischt privat/neutraler 

standardisierter Daten in einem AutomationML-Dokument 

führt zu sinnvollen und neuartigen Vorteilen 

und ist unmittelbar anwendbar. Das Warten auf einen 

Standard ist nicht mehr nötig. Der praktische Einsatz 

steht in jedem Reifegrad im Vordergrund, die Standardisierung 

folgt der Nutzung, nicht umgekehrt. Der Praktiker 

erhält über die Erkennung unbekannter Datenmodelle 

automatisch ein Lastenheft für die Softwareentwicklung. 

Proprietäre Datenmodelle werden explizit 

sichtbar. Industrie, Akademia und Gremien können 

aufgrund der expliziten Sichtbarkeit proprietärer Daten- 

Teilmodelle Ähnlichkeitsanalysen durchführen und 

erstmalig Standardisierungsbedarf inklusive Priorisierung 

automatisch ableiten. 

Die für eine Standardisierung von Datenmodellen notwendigen 

Schritte werden deutlich vereinfacht. Kurzfristiger 

Projektdruck und langfristige Standardisierungsvorhaben 

werden zeitlich entkoppelt und somit 

harmonisierbar. Das Konzept eliminiert den Standardisierungs-Deadlock, 

ist sofort einsetzbar und ebnet zugleich 

einen erfolgversprechenden evolutionären Weg 

zur Standardisierung. 


29.06.2012 

AUTOREN 


Dr.-Ing. RAINER DRATH (geb. 1970) ist Senior 

Principal Scientist im ABB Forschungszentrum 

in Ladenburg. Er beschäftigt sich mit 

der Entwicklung neuer Konzepte und 

Methoden zur Verbesserung des Engineerings 

von Automatisierungssystemen. 

ABB Forschungszentrum, 

Wallstadter Str 59, D-68526 Ladenburg, 

Tel. +49 (0) 6203 71 64 71, 

E-Mail: rainer.drath@de.abb.com 

Dr.-Ing. MIKE BARTH (geb. 1981) ist 

Scientist am ABB Forschungszentrum in 

Ladenburg. Seine Forschungsschwerpunkte 

umfassen Methoden und Werkzeuge 

für ein effizientes Engineering von Automatisierungssystemen. 

ABB Forschungszentrum 

Wallstadter Straße 59, D-68526 Ladenburg, 

Tel. +49 (0) 6203 71 64 61, 

E-Mail: mike.barth@de.abb.com 


12 / 2012 

81

IMPRESSUM / VORSCHAU 

IMPRESSUM 

VORSCHAU 

Verlag: 

DIV Deutscher Industrieverlag GmbH 

Arnulfstraße 124, 80636 München 

Telefon + 49 89 203 53 66-0 

Telefax + 49 89 203 53 66-99 

www.di-verlag.de 

Geschäftsführer: 

Carsten Augsburger, Jürgen Franke 

Spartenleiter: 

Jürgen Franke 

Herausgeber: 

Dr. T. Albers 

Dr. G. Kegel 

Dipl.-Ing. G. Kumpfmüller 

Dr. N. Kuschnerus 

Beirat: 

Dr.-Ing. K. D. Bettenhausen 

Prof. Dr.-Ing. Ch. Diedrich 

Prof. Dr.-Ing. U. Epple 

Prof. Dr.-Ing. A. Fay 

Prof. Dr.-Ing. M. Felleisen 

Prof. Dr.-Ing. G. Frey 

Prof. Dr.-Ing. P. Göhner 

Dipl.-Ing. Th. Grein 

Prof. Dr.-Ing. H. Haehnel 

Dr.-Ing. J. Kiesbauer 

Dipl.-Ing. R. Marten 

Dipl.-Ing. G. Mayr 

Dr. J. Nothdurft 

Dr.-Ing. J. Papenfort 

Dr. A. Wernsdörfer 

Dipl.-Ing. D. Westerkamp 

Dr. Ch. Zeidler 

Organschaft: 

Organ der GMA 

(VDI/VDE-Gesell schaft Messund 

Automatisierungs technik) 

und der NAMUR 

(Interessen gemeinschaft 

Automatisierungs technik der 

Prozessindustrie). 

Redaktion: 

Anne Hütter (ahü) 

(verantwortlich) 

Telefon + 49 89 203 53 66-58 

Telefax + 49 89 203 53 66-99 

E-Mail: huetter@di-verlag.de 

Gerd Scholz (gz) 

Einreichung von Hauptbeiträgen: 

Prof. Dr.-Ing. Leon Urbas 

(Chefredakteur, verantwortlich 

für die Hauptbeiträge) 

Technische Universität Dresden 

Fakultät Elektrotechnik 

und Informationstechnik 

Professur für Prozessleittechnik 

01062 Dresden 

Telefon +49 351 46 33 96 14 

E-Mail: urbas@di-verlag.de 

Fachredaktion: 

Dr.-Ing. M. Blum 

Prof. Dr.-Ing. J. Jasperneite 

Dr.-Ing. B. Kausler 

Dr.-Ing. N. Kiupel 

Dr. rer. nat. W. Morr 

Dr.-Ing. J. Neidig 

Dipl.-Ing. I. Rolle 

Dr.-Ing. S. Runde 

Prof. Dr.-Ing. F. Schiller 

Bezugsbedingungen: 

„atp edition – Automatisierungstechnische 

Praxis“ erscheint 

monatlich mit Doppelausgaben im 

Januar/Februar und Juli/August. 

Bezugspreise: 

Abonnement jährlich: € 468,– + € 30,–/ 

€ 35,- Versand (Deutschland/Ausland); 

Heft-Abbonnement + Online-Archiv: 

€ 638,40; ePaper (PDF): € 468,–; 

ePaper + Online-Archiv: € 608,40; 

Einzelheft: € 55,– + Versand; 

Die Preise enthalten bei Lieferung 

in EU-Staaten die Mehrwertsteuer, 

für alle übrigen Länder sind es 

Nettopreise. Mitglieder der GMA: 30% 

Ermäßigung auf den Heftbezugspreis. 

Bestellungen sind jederzeit über den 

Leserservice oder jede Buchhandlung 

möglich. 

Die Kündigungsfrist für Abonnementaufträge 

beträgt 8 Wochen zum Bezugsjahresende. 

Abonnement-/ 

Einzelheftbestellung: 

Leserservice atp 

Postfach 91 61, 97091 Würzburg 

Telefon + 49 931 41 70-4 94 

Telefax + 49 931 41 70-4 92 

E-Mail: leserservice@di-verlag.de 

Verantwortlich für 

den Anzeigenteil: 

Inge Matos Feliz 

Telefon + 49 89 203 53 66-22 

Telefax + 49 89 203 53 66-99 

E-Mail: matos.feliz@di-verlag.de 

Es gelten die Preise der Mediadaten 2012 

Anzeigenverwaltung: 

Brigitte Krawczyk 

Telefon + 49 89 2 03 53 66-12 

Telefax + 49 89 2 03 53 66-99 

E-Mail: krawczyk@di-verlag.de 

Art Direction / Layout: 

deivis aronaitis design | dad | 

Druck: 

Druckerei Chmielorz GmbH 

Ostring 13, 

65205 Wiesbaden-Nordenstadt 

Gedruckt auf chlor- und 

säurefreiem Papier. 

Die atp wurde 1959 als „Regelungstechnische 

Praxis – rtp“ gegründet. 

DIV Deutscher Industrieverlag 

GmbH München 

Die Zeitschrift und alle in ihr enthaltenen 

Beiträge und Abbildungen sind urheberrechtlich 

geschützt. Mit Ausnahme der 

gesetzlich zugelassenen Fälle ist eine 

Verwertung ohne Ein willigung des Verlages 

strafbar. 

Gemäß unserer Verpflichtung nach § 8 

Abs. 3 PresseG i. V. m. Art. 2 Abs. 1c DVO 

zum BayPresseG geben wir die Inhaber 

und Beteiligungsverhältnisse am Verlag 

wie folgt an: 

DIV Deutscher Industrieverlag GmbH, 

Arnulfstraße 124, 80636 München. 

Alleiniger Gesellschafter des Verlages 

ist die ACM-Unternehmensgruppe, 

Ostring 13, 

65205 Wiesbaden-Nordenstadt. 

ISSN 2190-4111 

DIE AUSGABE 1-2 / 2013 DER 

ERSCHEINT AM 18.02.2013 

MIT AUSGEWÄHLTEN BEITRÄGEN DER 

NAMUR-HAUPTSITZUNG 2012: 

Erfahrungen zum Einsatz 

WEB-basierter „As-Built“- 

Dokumentation 

IT im Kontext der Architektur 

eines Prozessleitsystem. Teil 2: 

Cloud Computing 

Versagenseigenschaften 

von Software mit bekannter 

Betriebserfahrung bei 

wechselndem 

Anforderungsprofil 

Integriertes Engineering 

Interview mit 

Dr. Jörg Kiesbauer 

...und vielen weiteren Themen. 

Aus aktuellem Anlass können sich die Themen 

kurzfristig verändern. 

LESERSERVICE 

E-MAIL: 

leserservice@di-verlag.de 

TELEFON: 

+ 49 931 41 70-4 94 

82 


12 / 2012

Erreichen Sie die Top-Entscheider 

der Automatisierungstechnik. 

Sprechen Sie uns an wegen Anzeigenbuchungen 

und Fragen zu Ihrer Planung. 

Inge Matos Feliz: Tel. +49 89 203 53 66-22 

E-Mail: matos.feliz@di-verlag.de

atp edition Automatisierung mit FASA (Vorschau)

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?