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

atp edition

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

atp edition

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.

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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.

atp edition

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

atp edition

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

atp edition

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

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

Betriebssystem

…

Gast-Betriebssystem

Gast-Betriebssystem

Hypervisor

Hypervisor

…

Applikation

Hypervisor

Appli-kation

Hypervisor

Host-

Host-

Betriebssystem

Betriebssystem

Host-

Host-

Betriebssystem

Betriebssystem

Gast-Betriebssystem

Gast-Betriebssystem

…

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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.

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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.

MANUSKRIPTEINGANG

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

atp edition

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

atp edition

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-

atp edition

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

atp edition

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-

atp edition

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

atp edition

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

Diverse Geräte der


Open DeviceNet Vendor

Association (ODVA)

Componet, Controlnet,

Devicenet, Ethernet/IP

Spezifische

Applikationsprofile

Diverse Geräte der


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

atp edition

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

atp edition

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.

MANUSKRIPTEINGANG

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

Betriebssystem

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

atp edition

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-

atp edition

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

atp edition

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

atp edition

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.

MANUSKRIPTEINGANG

26.07.2012


60

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

2 Prozessführung

3 Prozessführung

4 Prozessführung

5 Prozessführung

6 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

atp edition

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).

atp edition

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

atp edition

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

atp edition

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.

MANUSKRIPTEINGANG

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

atp edition

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

www.atp-online.de

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

atp edition

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 %

atp edition

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

atp edition

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-

atp edition

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

atp edition

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-

atp edition

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

atp edition

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

atp edition

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

atp edition

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.

MANUSKRIPTEINGANG

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

atp edition

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

atp edition

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)

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?