24.02.2014 Aufrufe

atp edition Schnittstellen für das integrierte Engineering (Vorschau)

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

1-2 / 2014<br />

56. Jahrgang B3654<br />

DIV Deutscher Industrieverlag GmbH<br />

Automatisierungstechnische Praxis<br />

<strong>Schnittstellen</strong> <strong>für</strong> <strong>das</strong><br />

<strong>integrierte</strong> <strong>Engineering</strong> | 30<br />

Der Prolist-Workflow im<br />

eClass-Umfeld | 38<br />

FDI Usability Style Guide | 48<br />

Package-Unit-Integration<br />

in der Prozessindustrie | 56<br />

Trainingssimulation in der<br />

Prozessindustrie | 66


Rund um die Uhr<br />

erstklassig informiert<br />

• <strong>das</strong> innovative Online-Medium<br />

• Nachrichten gezielt recherchieren<br />

• die ideale Ergänzung zu <strong>atp</strong> <strong>edition</strong><br />

www.<strong>atp</strong>info.de<br />

Automatisierung<br />

auf den Punkt<br />

Noch schneller informiert mit dem Newsletter <strong>atp</strong>!update<br />

Jetzt <strong>für</strong> den Newsletter anmelden:<br />

www.<strong>atp</strong>info.de/newsletter<br />

• <strong>atp</strong> <strong>edition</strong><br />

• Branche<br />

• Veranstaltungen<br />

• Forschung<br />

• Produkte<br />

update


EDITORIAL<br />

Industrie 4.0 in der<br />

Prozessindustrie?<br />

In diesem Heft geht es um <strong>integrierte</strong>s <strong>Engineering</strong>, Datenaustausch, Merkmalleisten<br />

und damit ist die von mir letztes Jahr an dieser Stelle angesprochene<br />

Fragestellung „Integration versus Flexibilität“ weiterhin aktuell. Die<br />

Diskussionen werden derzeit unter dem Stichwort „Industrie 4.0“ geführt.<br />

Wesentliche Elemente von Industrie 4.0 sind die im „Abschlussbericht des<br />

Arbeitskreises Industrie 4.0“ genannte horizontale Integration entlang der<br />

Wertschöpfungskette, die vertikale Integration der Systeme und die Integration<br />

entlang des Lebenszyklus (<strong>integrierte</strong>s <strong>Engineering</strong>).<br />

Wo stehen wir in der Prozessindustrie? Macht uns „Industrie 4.0“ effizienter,<br />

schneller, flexibler, sicherer?<br />

Bei den klassischen kontinuierlichen Prozessanlagen sind wir bezüglich<br />

horizontaler und vertikaler Integration schon gut aufgestellt. Die vertikale<br />

Integration ist über die Feld-, Steuerungs-, Prozessleit- und Betriebsleitebene<br />

realisiert. Über die Prozessleitsysteme regeln wir auch den Gesamtprozess<br />

(horizontale Integration) und stellen eine effiziente Fahrweise sicher. Allerdings<br />

ist dieses Konzept nicht sehr flexibel, was Produktionsmengen und<br />

Produktwechsel angeht. Klassisch wurden daher in solchen Fällen die Produkte<br />

diskontinuierlich in Batch-Anlagen produziert. Die Anlagennutzung<br />

ist allerdings nicht sehr hoch und Umstellungen sind mit Ausbeuteverlusten<br />

verbunden. Hier kommen die neuen Entwicklungen der modularen, kontinuierlichen<br />

Anlagen (F3-Factory) ins Spiel. Die Flexibilität erzielt man dadurch,<br />

<strong>das</strong>s man die Module austauscht. Damit dieser Austausch einfach<br />

möglich ist, müssen die Module eine eigene Intelligenz besitzen und miteinander<br />

kommunizieren. Somit nähern sich bei modularen Anlagen die<br />

Strukturen der Prozessindustrie der Fertigungstechnik an, bei denen die<br />

Teile von Fertigungsinsel zu Fertigungsinsel wandern; mit den gleichen<br />

Fragestellungen.<br />

Und auch bei der dritten Dimension, der Integration entlang des Life Cycle,<br />

von der Entwicklung über <strong>das</strong> <strong>Engineering</strong>, Inbetriebnahme, Betrieb, Rückbau<br />

haben wir in der Prozessindustrie und in der Fertigungstechnik die<br />

gleichen Herausforderungen, zum Beispiel der konsistenten Datenhaltung.<br />

Hier sehen wir <strong>für</strong> die klassische Prozessanlagentechnik weiterhin <strong>das</strong> größte<br />

Optimierungspotenzial, weshalb wir als Thema der letztjährigen NAMUR-<br />

Hauptsitzung <strong>das</strong> Thema „Integrated <strong>Engineering</strong>“ gewählt haben.<br />

Im Zuge der oben beschriebenen Entwicklung modularer Anlagen wird<br />

uns aber auch <strong>das</strong> Thema „horizontale und vertikale Integration“ weiter<br />

beschäftigen, so <strong>das</strong>s wir an dem Thema „Industrie 4.0“ weiter mitarbeiten<br />

werden. Deshalb wundert es auch nicht, <strong>das</strong>s <strong>das</strong> Thema der NAMUR-Hauptsitzung<br />

2014 lautet: „Dezentrale Intelligenz“.<br />

DR. WILHELM<br />

OTTEN,<br />

Vorsitzender NAMUR<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

3


INHALT 1-2 / 2014<br />

VERBAND<br />

6 | Namur-Award 2014: Arbeiten zu „Intelligente<br />

Prozess- und Betriebsführung“ einreichen<br />

VDI-GVC: Claas-Jürgen Klasen beerbt Achim Noack<br />

Neuer Vorstand beim VDE Mikrosystemtechnik<br />

7 | Neue Kurse in diesem Jahr bei der Dechema <strong>für</strong><br />

Chemiker, Ingenieure und Biotechnologen<br />

BRANCHE<br />

8 | Alles begann mit dem Verstärkerbaustein:<br />

Hans Turck feiert 90. Geburtstag<br />

Spezialmesse <strong>für</strong> Mess- und Regeltechnik<br />

steigt am 26. März 2014 in Frankfurt<br />

Führungswechsel bei Lanxess<br />

FORSCHUNG<br />

9 | NI World Class 2014: Robotik-Wettbewerb<br />

sucht Teilnehmer aus Unis und Hochschulen<br />

TU Dresden kooperiert mit der Audi AG<br />

PRAXIS<br />

10 | Endress + Hauser stattet Pharma-Werk <strong>für</strong><br />

Infusionslösungen mit Messstellen aus<br />

12 | Kooperation: Differenzdruck-Transmitter<br />

erleichtert Integration in einen Durchflussregler<br />

14 | <strong>Engineering</strong> Base bündelt Informationen<br />

<strong>für</strong> kürzeren Ausschreibungsprozess<br />

18 | Parametrierbare Master Batch Records gleichen<br />

Prozesse ab und vereinfachen Implementierung<br />

20 | Technik-Kommunikation leicht gemacht:<br />

Cause-and-Effect-Diagramm als Lösungsansatz<br />

22 | Standardisierung mit eClass – Klassifizierung<br />

ermöglicht kürzeres Time-to-Market<br />

4<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


INTERVIEW<br />

26 | „Produkte mit bis zu 50 % Zeitersparnis<br />

einführen“<br />

ECKARD EBERLE UND HANS-GEORG KUMPFMÜLLER<br />

IM INTERVIEW MIT <strong>atp</strong> <strong>edition</strong><br />

Produkte,<br />

Systeme<br />

und Service<br />

<strong>für</strong> die<br />

Prozessindustrie?<br />

Natürlich.<br />

HAUPTBEITRÄGE<br />

30 | <strong>Schnittstellen</strong> <strong>für</strong> <strong>das</strong><br />

<strong>integrierte</strong> <strong>Engineering</strong><br />

T. TAUCHNITZ<br />

38 | Der Prolist-Workflow im<br />

eClass-Umfeld<br />

J. GEORGE<br />

48 | FDI Usability Style Guide<br />

M. STÖSS, F. FENGLER, A. LAUBENSTEIN, L. URBAS<br />

56 | Package-Unit-Integration<br />

in der Prozessindustrie<br />

M. OBST, A. HAHN, L. URBAS<br />

66 | Trainingssimulation in der<br />

Prozessindustrie<br />

K. SCHULZE<br />

RUBRIKEN<br />

3 | Editorial<br />

74 | Impressum, <strong>Vorschau</strong><br />

Zum Beispiel der magnetischinduktive<br />

Durchflussmesser<br />

ProcessMaster. Er setzt neue<br />

Maßstäbe mit umfangreichen<br />

Diagnosemöglichkeiten, einer<br />

Messabweichung von 0,2 %,<br />

Explosionsschutz sowie der<br />

ScanMaster-Software. Erfahren<br />

Sie mehr über die erste Wahl in<br />

der Durchflussmessung <strong>für</strong> die<br />

Prozessindustrie:<br />

www.abb.de/durchfluss<br />

Wussten Sie, <strong>das</strong>s Ihnen ABB<br />

neben dem umfassenden Portfolio<br />

<strong>für</strong> die Instrumentierung ebenso<br />

herausragende Produkte und<br />

Lösungen <strong>für</strong> die Analysentechnik,<br />

maßgeschneiderte Leitsysteme<br />

sowie erstklassigen Service bietet?<br />

Lesen Sie mehr unter:<br />

www.abb.de/<br />

prozessautomatisierung<br />

ABB Automation Products GmbH<br />

Tel.: 0800 111 44 11<br />

Fax: 0800 111 44 22<br />

vertrieb.messtechnik-produkte@de.abb.com


VERBAND<br />

Namur-Award 2014: Arbeiten zu „Intelligente<br />

Prozess- und Betriebsführung“ einreichen<br />

Die Interessengemeinschaft Automatisierungstechnik<br />

der Prozessindustrie (Namur) vergibt in 2014 erneut<br />

einen Preis <strong>für</strong> hervorragende Abschlussarbeiten zum<br />

Thema „Intelligente Prozess- und Betriebsführung“. Die<br />

Arbeiten können aus folgenden Fachgebieten stammen:<br />

Automatisierungstechnik, Elektrotechnik, Informationstechnik,<br />

Mess-, Regelungstechnik, Prozessleittechnik<br />

sowie Verfahrenstechnik. Lehrstuhlinhaber entsprechender<br />

Fachgebiete sollten formlos Anträge <strong>für</strong> die<br />

beste Abschlussarbeit einreichen. Um die Bewerbung<br />

zu unterstützen, können außerdem zugehörige Veröffentlichungen<br />

eingereicht werden. Die Namur nimmt<br />

die Anträge per E-Mail an office@namur.de entgegen.<br />

Die Auszeichnung <strong>für</strong> die beste Promotionsarbeit ist<br />

mit 2000 Euro dotiert. Für die beste Diplom-/Masterarbeit<br />

gibt es 1000 Euro. Einsendeschluss ist am 27. Juni<br />

2014. Die Lehrstuhlinhaber werden am 15. Oktober 2014<br />

benachrichtigt, ob ihre Bewerbung erfolgreich war. Die<br />

Preisverleihung erfolgt bei der Namur-Hauptsitzung am<br />

7. November 2014. (aha)<br />

VOR RUND 600 TEILNEHMERN werden die<br />

Namur-Award-Preisträger bei der Hauptsitzung im<br />

November ausgezeichnet. Bild: Archiv/Purschwitz<br />

NAMUR GESCHÄFTSSTELLE,<br />

c/o Bayer Technology Services, Gebäude K 9,<br />

D-51368 Leverkusen, Tel. +49 (0) 214 307 10 34,<br />

E-Mail: office@namur.de, Internet: www.namur.de<br />

VDI-GVC: Claas-Jürgen Klasen beerbt Achim Noack<br />

Die Nachfolge von Dipl.-Ing. Achim Noack im Vorsitz<br />

der VDI-Gesellschaft Verfahrenstechnik und Chemieingenieurwesen<br />

(VDI-GVC) tritt in diesem Jahr Dr.-<br />

Ing. Claas-Jürgen Klasen an. Als Projektdirektor der Evonik<br />

Degussa Co. Ltd. Shanghai war Klasen in den Jahren<br />

2006 bis 2009 verantwortlich <strong>für</strong> den Aufbau der Methacrylat-Anlage<br />

in China. Er leitet seit 2009 die Verfahrenstechnik<br />

und <strong>Engineering</strong> der Evonik Industries. Praxisbezogene<br />

Weiterbildungen, übernehmensübergreifender<br />

Erfahrungsaustausch und <strong>das</strong> vertrauensvolle Netzwerk<br />

in der Produktion sollen die Arbeit von Klasen künftig<br />

auszeichen. Neben dem Fachbereich „Betrieb verfahrenstechnischer<br />

Anlagen“ informieren „Verfahrenstechnische<br />

Prozesse“ und „Verfahrenstechnische Anlagen“,<br />

koordiniert von der Processnet, Ingenieure über Neuigkeiten<br />

in der Verfahrenstechnik. <br />

(ahü)<br />

VDI VEREIN DEUTSCHER INGENIEURE E.V.,<br />

VDI-Platz 1, D-40468 Düsseldorf,<br />

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

Neuer Vorstand beim VDE Mikrosystemtechnik<br />

Prof. Dr. Christoph Kutter, Leiter der Fraunhofer-Einrichtung<br />

<strong>für</strong> Modulare Festkörper-Technologien<br />

EMFT, ist seit Anfang des Jahres im neuen Vorstand der<br />

VDE/VDI-Gesellschaft Mikroelektronik, Mikrosystemund<br />

Feinwerktechnik (GMM). Auch Stellvertreter wurden<br />

neu bestimmt. Dr. Udo-Martin Gómez, Chief Technical<br />

Officer der Bosch Sensortech GmbH und Prof. Dr.<br />

Wilfried Mokwa, Leiter des Lehrstuhls I des Instituts <strong>für</strong><br />

Werkstoffe und Elektrotechnik an der RTWH Aachen<br />

nehmen diesen Posten nun ein.<br />

Zum Vorstand gehören weiterhin: Prof. Dr.-Ing. Udo<br />

Bechtloff, Vorsitzender der Geschäftsführung der KSG<br />

Leiterplatten GmbH, Dr. Tim Gutheit, Senior Director<br />

Technology & Innovation Automotive der Infineon Technologies<br />

AG, Prof. Dr.-Ing. Gernot Spiegelberg, Leiter<br />

Konzeptentwicklung Elektromobilität der Siemens AG<br />

Corporate Technology, und Prof. Dr. Marc Weber, Leiter<br />

des Instituts <strong>für</strong> Prozessdatenverarbeitung und Elektronik<br />

des Karlsruher Instituts <strong>für</strong> Technologie. (ahü)<br />

VDE/VDI-GESELLSCHAFT MIKROELEKTRONIK,<br />

Mikrosystem- und Feinwerktechnik (GMM),<br />

Stresemannallee 15, D-60596 Frankfurt/Main,<br />

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

6<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


Neue Kurse in diesem Jahr bei der Dechema <strong>für</strong><br />

Chemiker, Ingenieure und Biotechnologen<br />

Die Gesellschaft <strong>für</strong> Chemische Technik und Biotechnologie<br />

(Dechema) bietet <strong>für</strong> 2014 zusätzlich zum<br />

bestehenden Kursangebot neue Seminare an. Die Kurse<br />

geben Chemikern, Ingenieuren und Biotechnologen die<br />

Möglichkeit, sich weiterzubilden. Veranstaltungsort ist<br />

jeweils Frankfurt am Main.<br />

Im Kurs „Prozesstechnische Auslegung von Wärmeübertragern“<br />

(19. bis 21. März 2014) lernen die Seminarteilnehmer<br />

Wärmeübertrager, Kondensatoren und Verdampfer<br />

auszuwählen und prozesstechnisch zu dimensionieren.<br />

Vom 7. bis 8. Mai 2014 bietet die Dechema den<br />

englischsprachigen Kurs Electrochemical Impedance<br />

Spectroscopy (EIS) an. Im Experimentalkurs werden die<br />

Grundlagen der EIS in Theorie und Praxis vermittelt.<br />

Die Optimierung von Prozessen steht vom 19. bis 20.<br />

Mai 2014 im Mittelpunkt. Im Kurs Scale-up in der Verfahrenstechnik<br />

wird die Dimensionsanalyse als Methode<br />

<strong>für</strong> ein Scale-up präsentiert und eingeübt.<br />

Vom 7. bis 8. Juli 2014 haben Teilnehmer die Möglichkeit,<br />

die Grundlagen der Open-Source-Programmiersprache<br />

Python zu erlernen. Der Kurs Introduction<br />

to Python for Biosciences wird ebenfalls in englischer<br />

Sprache abgehalten. Schließlich geht es vom<br />

24. bis 25. Juli 2014 um Produktentwicklung. Im<br />

IN 2014 bietet die<br />

Dechema noch mehr<br />

Weiterbildungsmöglichkeiten<br />

<strong>für</strong><br />

Chemiker, Ingenieure<br />

und Biotechnologen.<br />

Bild: Carsten Böttcher / pixelio.de<br />

gleichnamigen Seminar gehen die Teilnehmer im Zeitraffer<br />

den Weg von der Analyse der Kundenbedürfnisse,<br />

über die Festlegung einer vorübergehenden<br />

Produktspezifikation, zur Ideenentwicklung und Auswahl<br />

der Produktkonzepte und Festlegung der endgültigen<br />

Produktspezifikation und Entwicklung des<br />

Herstellprozesses.<br />

(aha)<br />

DECHEMA GESELLSCHAFT FÜR CHEMISCHE TECHNIK<br />

UND BIOTECHNOLOGIE E.V.,<br />

Theodor-Heuss-Allee 25, D-60486 Frankfurt am Main,<br />

Tel. +49 (0) 69 756 40, Internet: www.dechema.de<br />

HANNOVER MESSE 2014<br />

Intelligente Automation und IT<br />

■ Energieeffizienz und Energieeinsparungen<br />

■ Flexibilisierung der Fertigungsprozesse<br />

■ Softwarelösungen <strong>für</strong> die Fabrik der Zukunft<br />

7.– 11. April 2014<br />

Hannover ▪ Germany<br />

hannovermesse.de<br />

Get new technology first


BRANCHE<br />

Alles begann mit dem Verstärkerbaustein:<br />

Hans Turck feiert 90. Geburtstag<br />

Hans Turck, Mitbegründer des Industrieunternehmens<br />

Turck, beging am 9. Januar 2014 seinen 90.<br />

Geburtstag. Turck, der nach seinem Rückzug aus dem<br />

Unternehmen im Jahr 1998 abwechselnd in Mülheim<br />

an der Ruhr und in Kapstadt lebt, beging den Tag gemeinsam<br />

mit seiner Frau in seiner südafrikanischen<br />

Wahlheimat.<br />

Nach Abschluss seines Ingenieur-Studiums im Jahr<br />

1950 sammelte er zunächst zehn Jahre Vertriebserfahrung,<br />

bevor er sich mit einem Ingenieurbüro in Mülheim<br />

selbständig machte, aus dem später die Hans<br />

Turck GmbH & Co. KG hervorging. 1965 verkaufte er<br />

<strong>das</strong> erste eigene Produkt: einen Verstärkerbaustein,<br />

den sein Bruder Werner im sauerländischen Halver<br />

produzierte.<br />

Seit 1968 unterstützte Hermann<br />

Hermes als Partner die Aktivitäten<br />

des Unternehmens. So gründete<br />

Turck 1975 eine Niederlassung in<br />

den USA. Heute beschäftigt die<br />

Turck-Gruppe in 27 Landesgesellschaften<br />

mehr als 3.350 Mitarbeiter.<br />

Der Gruppenumsatz lag 2013 bei<br />

rund 450 Millionen Euro. (aha)<br />

HANS TURCK GMBH & CO. KG,<br />

Witzlebenstraße 7,<br />

D-45472 Mülheim an der Ruhr,<br />

Tel. +49 (0) 208 495 20,<br />

Internet: www.turck.com<br />

HANS TURCK<br />

feierte sein persönliches<br />

Jubiläum<br />

am 9. Januar 2014<br />

in Kapstadt.<br />

Bild: Turck<br />

Spezialmesse <strong>für</strong> Mess- und Regelungstechnik<br />

steigt am 26. März 2014 in Frankfurt<br />

Die regionale Fachmesse <strong>für</strong> Prozessleitsysteme öffnet<br />

am 26. März 2014 in Frankfurt am Main wieder<br />

ihre Pforten. In der Jahrhunderthalle in Frankfurt-<br />

Höchst organisiert die Meorga die Ausstellung mit 150<br />

Firmen, die Beratung und Produkte aus der Mess-,<br />

Steuer-, Regelungs- und Automatisierungstechnik anbieten.<br />

In der Zeit von 8 bis 16 Uhr können sich interessierte<br />

Besucher über Geräte, Systeme, <strong>Engineering</strong>und<br />

Serviceleistungen sowie neue Trends im Bereich<br />

der Automatisierung informieren. Die Messe richtet<br />

sich dabei vora llem an Fachleute und Entscheidungsträger,<br />

die in ihren Unternehmen <strong>für</strong> die Optimierung<br />

der Geschäftsprozesse entlang der gesamten Wertschöpfungskette<br />

verantwortlich sind. Der Eintritt zur<br />

Messe und die Teilnahme an den Workshops sind <strong>für</strong><br />

Besucher kostenlos. Kleine Snacks und Erfrischungsgetränke,<br />

die gratis bereit gestellt werden, sorgen <strong>für</strong><br />

die nötige Erholung zwischendurch. <br />

(ahü)<br />

MEORGA GMBH,<br />

Sportplatzstraße 27, D-66809 Nalbach,<br />

Tel. +49 (0) 6838 896 00 35,<br />

Internet: www.meorga.de<br />

DER EINTRITT<br />

der Regionalmesse<br />

<strong>für</strong><br />

Fachleute ist<br />

kostenfrei.<br />

Bild: Meorga<br />

Führungswechsel bei Lanxess<br />

8<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

Axel C. Heitmann beendet zum Ende Februar 2014<br />

seine Tätigkeit als Mitglied und Vorsitzender des<br />

Vorstands von Lanxess. Das hat der Aufsichtsrat des<br />

Unternehmens beschlossen. Sein Nachfolger wird<br />

voraussichtlich zum 15. Mai 2014 Matthias Zachert,<br />

der früherere Finanzvorstand bei Lanxess und derzeitiger<br />

Finanzvorstand bei Merck. Bis zum Eintritt<br />

von Zachert übernimmt Bernhard Düttmann, Finanzvorstand<br />

des Konzerns, die Aufgaben des bisherigen<br />

Vorstandsvorsitzenden.<br />

„Lanxess steht vor großen Herausforderungen, beispielsweise<br />

hinsichtlich Marktkapazitäten und Geschäftsportfolio.<br />

Der Aufsichtsrat<br />

hält deswegen den Zeitpunkt<br />

<strong>für</strong> gekommen, einer neuen Führung<br />

Verantwortung zu übertragen,<br />

um diesen Herausforderungen<br />

zu begegnen“, sagte Rolf<br />

Stomberg, Vorstitzender des Aufsichtsrats.<br />

(aha)<br />

LANXESS AG,<br />

Kennedyplatz 1, D-50569 Köln,<br />

Tel. +49 (0) 221 888 50<br />

VORAUSSICHTLICH<br />

AM 15. MAI 2014 tritt<br />

Matthias Zachert<br />

(Bild) die Nachfolge<br />

von Axel C. Heitmann<br />

an. Bild: Lanxess


FORSCHUNG<br />

NI World Class 2014: Robotik-Wettbewerb<br />

sucht Teilnehmer aus Unis und Hochschulen<br />

Praktische Erfahrung in den Bereichen Robotik, Regelungstechnik,<br />

Bildverarbeitung und Messtechnik sammeln<br />

Teilnehmer der National Instruments World Class,<br />

die vom 21. bis 26. Juli 2014 in München stattfindet. National<br />

Instruments, der Anbieter von Software, richtet den<br />

Robotik-Workshop aus. Mit spezieller Hard- und Software<br />

ausgestattet, lernen die Studenten der Ingenieur- und Naturwissenschaft<br />

einen Roboter so zu programmieren, <strong>das</strong>s<br />

er an einem Wettbewerb teilnehmen kann. „Mein größter<br />

Lerneffekt war, selber zu programmieren und die Hardware<br />

anzusteuern,“ so Anna, Teilnehmerin der NI World<br />

Class 2013. Die Studenten lernen Strategien kennen, wie<br />

sie ein Projekt von der Planung bis zur Realisierung<br />

durchführen. Damit sie optimal auf die Aufgabe vorbereitet<br />

sind, ermöglicht der Veranstalter allen Teilnehmern<br />

im Vorfeld den kostenfreien Besuch eines Trainingskurses<br />

zu NI Lab View. Zudem kommt der Veranstalter <strong>für</strong> Fahrtkosten<br />

sowie Unterbringung und Verpflegung während<br />

der gesamten fünf Tage auf. Bewerbungsschluss ist der<br />

DIE NÄCHSTE<br />

NI WORLD<br />

CLASS findet<br />

vom 21. bis 26.<br />

Juli 2014 in<br />

München statt.<br />

Bild: NI<br />

25. April 2014. Das Bewerbungsformular, aktuelle Informationen<br />

sowie Bilder der vergangenen NI World Class sind<br />

online verfügbar unter: www.niworldclass.com. (ahü)<br />

NATIONAL INSTRUMENTS GERMANY GMBH,<br />

Ganghoferstraße 70 b, D-80339 München,<br />

Tel. +49 (0) 89 741 31 30, Internet: www.ni.com/germany<br />

TU Dresden kooperiert mit der Audi AG<br />

Um Leichtbau und Fertigungstechnik soll es am neu<br />

gegründeten „Ingolstadt Institute der Technischen<br />

Universität (TU) Dresden“ gehen. Am 28. Januar 2014<br />

unterzeichneten die Audi AG und die Uni den entsprechenden<br />

Vertrag. „Mit der TU Dresden gewinnen wir<br />

eine Exzellenzuniversität als strategischen Partner, der<br />

über ein profundes wissenschaftliches Know-how in der<br />

Automobiltechnik verfügt“, sagt Prof. Dr.-Ing. Ulrich<br />

Hackenberg, Vorstand der Technischen Entwicklung der<br />

AG. Prof. Dr. Hans Müller-Steinhagen, Rektor der TU<br />

Dresden, betont: „Wir wollen ein Kompetenzzentrum<br />

schaffen, in dem Wissenschaft und Praxis eng vernetzt<br />

sind. Eine Besonderheit ist dabei die interdisziplinäre<br />

Ausrichtung, denn an der Gründung sind Wissenschaftler<br />

verschiedener Fakultäten beteiligt. Neben Physikern,<br />

Elektrotechnikern und Maschinenbauern werden auch<br />

Psychologen und Verkehrswissenschaftler gemeinsam<br />

an Themen rund um den Automobilbau arbeiten.“ Insgesamt<br />

vier Doktoranden aus Dresden befassen sich derzeit<br />

mit Projekten des Ingolstädter Autobauers. (ahü)<br />

TU DRESDEN,<br />

Helmholtzstraße 10, D-01069 Dresden,<br />

Tel.+49 (0) 351 46 33 70 44, Internet: www.tu-dresden.de<br />

INTELLIGENT FIELdbus<br />

KEEps Your procEss ruNNING<br />

Zukunftstechnologie <strong>für</strong> mehr Verfügbarkeit<br />

▪<br />

Advanced Diagnostic Gateways mit I/O Funktion<br />

▪ Segment Protectoren mit intelligenter Fehlerisolation<br />

▪ Diagnosefähiger Blitzschutz mit Leittechnikanbindung ohne<br />

wiederkehrende Prüfungen<br />

▪ Leckagesensoren <strong>für</strong> garantiert wasserdichte Installationen<br />

Feldbus mit intelligenter diagnose: www.pepperl-fuchs.de/intelligent-fieldbus<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

9


PRAXIS<br />

Endress + Hauser stattet Pharma-Werk <strong>für</strong><br />

Infusionslösungen mit Messstellen aus<br />

Informationsportal ermöglicht Direktzugriff auf Dokumentation aller Messgeräte<br />

IN EINEM NEUEN WERK „LIFE NUTRITION“ sind beim<br />

Pharma- und Medizintechnikunternehmen B. Braun neue<br />

Abfüllungslinien <strong>für</strong> die klinische Ernährung entstanden.<br />

DIE NACH ISO/IEC 17025 durchgeführten<br />

Kalibrierungen erfolgten mit eigenen Referenzgeräten,<br />

teilweise <strong>für</strong> die kompletten Messstellen-Loops.<br />

E<br />

ntwicklung und Produktion von innovativen Infusionslösungen<br />

<strong>für</strong> den Weltmarkt sind <strong>das</strong> Ziel<br />

von B. Braun Melsungen. Da<strong>für</strong> investiert <strong>das</strong> Pharmaund<br />

Medizintechnikunternehmen in <strong>das</strong> Projekt Life<br />

Nutrition. Die Leading Infusion Factory Europe (L.I.F.E.)<br />

wurde im April 2005 offiziell eröffnet.<br />

In dem Werk „Life Nutrition“ sind neue Linien zur<br />

Beutelabfüllung entstanden. Künftig werden darin Lösungen<br />

<strong>für</strong> die klinische Ernährung abgefüllt. Das Projekt<br />

mit einer Investitionssumme von 164 Millionen<br />

Euro wurde im April 2008 gestartet. Schon während der<br />

Vergabeverhandlungen formulierten B. Braun und <strong>das</strong><br />

<strong>für</strong> die Generalplanung des Prozesses verantwortliche<br />

Ingenieurunternehmen Chemgineering Technology die<br />

Anforderung an potenzielle Messtechnik-Lieferanten:<br />

Zum einen war ein Komplettanbieter gefordert, der möglichst<br />

alle Messparameter liefern kann, zum anderen<br />

sollte der Anbieter im Rahmen der Qualifizierung die<br />

Erstkalibrierung GMP gerecht durchführen können. Zusätzlich<br />

wurde <strong>für</strong> die Qualitätssicherung und <strong>für</strong> spätere<br />

Instandhaltungstätigkeiten eine sichere Lösung zur<br />

Verfolgung der Gerätedokumentationen gefordert.<br />

GESAMTES PROJEKT IN EINER HAND<br />

Die Wahl fiel schließlich auf Endress + Hauser. Über<br />

700 Messstellen der Prozessparameter Durchfluss,<br />

Füllstand, Grenzstand, Druck, Temperatur und Leitfähigkeit<br />

wurden <strong>für</strong> die Bereiche Water For Injection<br />

(WFI) und Schwarzmedien eingesetzt. Praxisbewährtheit,<br />

Langzeitstabilität sowie die Erfüllung<br />

der GMP- und FDA-Anforderungen waren hier die<br />

Hauptkriterien des Kunden. Eine schnelle und qualitativ<br />

hochwertige Planung bei der Hardwareprojektierung<br />

bildete auch bei Life Nutrition die Basis <strong>für</strong><br />

einen nachhaltigen Projekterfolg. Auf Grundlage des<br />

vom Ingenieurunternehmen vorgelegten Lastenheftes<br />

erfolgte die Auswahl geeigneter Messprinzipien<br />

und später dann im Detail-<strong>Engineering</strong> die<br />

exakte Auslegung und Erstellung der entsprechenden<br />

Messstellenlisten. Entscheidende Erfolgsfaktoren<br />

<strong>für</strong> einen reibungslosen <strong>Engineering</strong>prozess<br />

sind hier ein fundiertes Applikationswissen, Technologiekenntnisse<br />

sowie tiefgreifendes Industrie<br />

Know-how gewesen.<br />

AKKREDITIERTE GMP-SERVICES<br />

Ein weiterer Anspruch des Kunden lautete: Um eine<br />

reibungslose Qualifizierung der Messtechnik ohne<br />

weitere <strong>Schnittstellen</strong> zu externen Dienstleistern zu<br />

gewährleisten, sollte der Lieferant der Messtechnik<br />

auch die Erstkalibrierung <strong>für</strong> alle Messstellen durchführen<br />

können. Die Kalibrierung selbst erfolgte dann<br />

10<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


CRISTINA MOLINA, Project Manager bei B. Braun<br />

Melsungen: „Überzeugt hat uns die große Produktauswahl<br />

in GMP-Qualität und <strong>das</strong> fundierte<br />

Applikationswissen von Endress + Hauser, was sich<br />

später in der unkomplizierten und effizienten Projektabwicklung<br />

widerspiegelte.“ Bilder: Endress + Hauser<br />

schließlich durch <strong>das</strong> Endress + Hauser Kalibrierteam.<br />

Durch die bisherige gute Zusammenarbeit in<br />

vergangenen Projekten war <strong>das</strong> Team mit organisatorischen<br />

Abläufen, Ansprechpartnern und örtlichen<br />

Gegebenheiten bereits vertraut. Die nach ISO/IEC<br />

17025 durchgeführten Kalibrierungen erfolgten mit<br />

eigenen Referenzgeräten, teilweise <strong>für</strong> die kompletten<br />

Messstellen-Loops.<br />

GERÄTEDOKUMENTATION MIT WAM PORTAL<br />

Letztendlich ausschlaggebend <strong>für</strong> die Auftragsvergabe<br />

war jedoch neben den umfangreichen GMP-Services ein<br />

leistungsstarkes Werkzeug zum Management der Gerätedokumentationen.<br />

Mit dem WaM Portal, einem webbasierten Informationsportal,<br />

konnten dem Planer und dem Kunden<br />

durchgängige Informationen entlang des kompletten<br />

Anlagen-Lebenszyklus zur Verfügung gestellt werden.<br />

Das Portal ermöglicht einen Direktzugriff auf die Dokumentation<br />

sämtlicher in <strong>das</strong> Projekt gelieferter<br />

Messgeräte. Dies erleichterte Qualitätsprozesse im<br />

Projekt schon bei der Wareneingangskontrolle. Vorgesehen<br />

ist zusätzlich <strong>das</strong> Einpflegen aller erstellten<br />

Kalibrierzertifikate. Bei Instandhaltungstätigkeiten<br />

und bei externen Audits können damit Zertifikate<br />

leicht abgerufen werden.<br />

Der Schlüssel zum Erfolg ist ein schneller Zugriff auf<br />

Informationen, immer dann, wenn diese benötigt<br />

werden. WaM schafft diese Voraussetzung über die<br />

Prozesse <strong>Engineering</strong>, Beschaffung, Installation,<br />

Inbetriebnahme und Betrieb hinweg und bietet daher ein<br />

großes Potenzial, Kosten zu senken. Mit WaM steht ein<br />

offenes und leistungsstarkes Werkzeug <strong>für</strong> den<br />

gesamten Anlagen-Lebenszyklus zur Verfügung.<br />

WaM kann entweder auf einem Rechner oder einem<br />

zentralen Server im Unternehmensnetzwerk installiert<br />

oder über ein Internetportal zur Verfügung gestellt<br />

werden. Über <strong>das</strong> Internet können Informationen zu<br />

Endress + Hauser-Produkten bei beiden Varianten<br />

automatisch aktualisiert werden. Ein Download neuer<br />

Gerätedaten aus dem WaM Portal garantiert die<br />

Aktualität sämtlicher Daten.<br />

AUTOR<br />

THOMAS KAUFMANN<br />

ist Produktmanager<br />

Life Cycle Management<br />

Endress + Hauser in<br />

Weil am Rhein.<br />

Endress + Hauser Messtechnik GmbH + Co. KG,<br />

Colmarer Straße 6,<br />

D-79576 Weil am Rhein,<br />

Tel. +49 (0) 7621 975 01,<br />

E-Mail: thomas.kaufmann@de.endress.com<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

11


PRAXIS<br />

Kooperation: Differenzdruck-Transmitter<br />

erleichtert Integration in einen Durchflussregler<br />

Überdruckfester Durchflussregler – flexibel durch Digitalisierung<br />

Schon in der Phase der Produktentwicklung führen<br />

enge Absprachen zum Beispiel zwischen einem<br />

Komponenten- und einem Gerätehersteller zu besseren<br />

Lösungen. Hier ist Flexibilität auf beiden Seiten und<br />

vor allem die digitale Signalaufbereitung von Vorteil.<br />

Dies zeigt <strong>das</strong> folgende Beispiel eines Differenzdruck-<br />

Messmoduls, <strong>das</strong> mittlerweile vielfach in einem Durchflussregler<br />

zum Einsatz kommt, der <strong>für</strong> die Prozessmesstechnik<br />

auf Kundenanfrage entwickelt wurde.<br />

Für die Blechbearbeitung wird ein Sprühsystem benötigt,<br />

<strong>das</strong> eine exakte Dosierung von Schmierstoffen<br />

ermöglicht. Diese Applikation stand am Anfang der<br />

Entwicklung einer Liquid Flow Controller Serie von<br />

Bürkert und diente als Pilotprojekt. Sensorik, Regelelektronik,<br />

Stellglied und die üblichen elektrischen Prozessschnittstellen<br />

waren in einem kompakten Gerät<br />

unterzubringen, <strong>das</strong> – wie meist in der Prozessmesstechnik<br />

– <strong>für</strong> sorglosen Dauerbetrieb auszulegen war.<br />

DURCHFLUSSMESSUNG PER DIFFERENZDRUCK<br />

Aus Gründen der eher robusten Prozessumgebung und<br />

der allgemeinen Betriebssicherheit fiel die Entscheidung<br />

zugunsten einer Messung der Durchflussmenge über den<br />

Druckabfall des Messmediums beim Passieren einer<br />

Messblende mit definiertem Durchmesser, und zwar mit<br />

zwei individuellen Drucksensoren. In diesem Planungsstadium<br />

kamen die bereits guten Kontakte zur Deutschen<br />

Niederlassung des schweizer Unternehmens Keller<br />

<strong>für</strong> Druckmesstechnik ins Spiel. „Wir hatten damals<br />

mit der Serie PD-39X nämlich bereits einen Druckdifferenz-Transmitter<br />

vorgestellt, der die wichtigsten der<br />

geforderten Eigenschaften – insbesondere bezüglich<br />

Überlastbarkeit – bereits liefern konnte“, erinnert sich<br />

Geschäftsführer Wolfgang Braun.<br />

GESAMTFEHLERBAND VON ± 0,1 % FS<br />

Bei üblichen Differenzdruck-Transmittern werden beide<br />

Seiten einer Messmembran mit dem Messmedium beaufschlagt.<br />

Mit typischen Messbereichen von 500 mbar<br />

und Systemdrücken bis 10 bar könnte die einseitige Unterbrechung<br />

der Druckbelastung dazu führen, <strong>das</strong>s eine<br />

20-fache Überlastung der Membran entsteht. Die lässt<br />

sich ohne aufwendige und entsprechend teure konstruktive<br />

Maßnahmen nicht auffangen und führt zwangsläufig<br />

zur Zerstörung des Transmitters. Solche Risiken<br />

wollten die Spezialisten <strong>für</strong> Fluid Control Systems bei<br />

Bürkert ausschließen und waren deshalb sehr an dem<br />

Modul zur Messung der Druckdifferenz interessiert.<br />

Die Differenzdruck-Transmitter arbeiten mit zwei<br />

selektierten, gekapselten Silizium-Drucksensoren, die<br />

in etwa 20 mm Abstand montiert werden. Sie liefern<br />

ihre jeweiligen Ausgangssignale an die Eingänge eines<br />

Xemics-Mikroprozessors, mit dessen Rechenleistung<br />

nach einer komfortablen 16 bit A/D-Wandlung alle reproduzierbaren<br />

Nichtlinearitäten und Temperaturabhängigkeiten<br />

mit mathematischen Mitteln weitestgehend<br />

eliminiert werden. Mit diesem Verfahren erreicht<br />

Keller bei seinen Druckdifferenz-Transmittern ein Gesamtfehlerband<br />

von besser als ± 0,1% FS über weite<br />

Temperaturbereiche. Das analoge Ausgangssignal des<br />

Moduls wird bis zu 200 Mal in der Sekunde aktualisiert<br />

und liefert eine gute Dynamikreserve <strong>für</strong> den Folgeprozess.<br />

Als Daumenregel lässt sich sagen, <strong>das</strong>s der Messbereich<br />

bei dieser Art von Differenzdruckmessung etwa<br />

20% des Vordrucks betragen sollte.<br />

Neben den zahlreichen analogen Standardsignalen von<br />

4 … 20 mA und 0 … 10 V bietet der Prozessor eine digitale<br />

RS485 Halbduplex-Schnittstelle. Über diese Schnittstelle<br />

können unter anderem die Druck- und Temperaturmesswerte<br />

der individuellen Sensoren ausgegeben werden,<br />

also nicht nur die Werte der Druckdifferenz. Durch<br />

die Digitalisierung ist die Spanne des analogen Ausgangssignals<br />

flexibel an die gewünschte Spanne des Eingangssignals<br />

(Druckdifferenz) anzupassen.<br />

Am Ende der Gespräche zwischen Keller und Bürkert<br />

und einer Vielzahl von Tests stand eine Liefervereinbarung<br />

über Differenzdruck-Messmodule, die der gemeinsam<br />

ausgearbeiteten Spezifikation entsprechen.<br />

Seither sind die Liquid Flow Controller in verschiedensten<br />

Applikationen im Dauerbetrieb.<br />

Der mechanische Anschluss der Drucksensoren an<br />

den Hauptkanal des Durchflussreglers erfolgt übrigens<br />

jeweils über eine durch einen definierten Spülprozess<br />

zu entlüftende Kapillare, die auch gleichzeitig als Tiefpassfilter<br />

<strong>für</strong> Druckspitzen ausgelegt ist. Bis auf die<br />

Dichtungsringe sind alle vom Messmedium berührten<br />

Teile aus Edelstahl.<br />

AUSFÜHRUNG NACH KUNDENWUNSCH<br />

Die Liquid Flow Controller werden bei Bürkert als Prozessmessgeräte<br />

kundenspezifisch <strong>für</strong> jeden konkreten<br />

Einsatz nach Auftrag gefertigt. Mit nur drei unterschiedlich<br />

bestückten Druckdifferenz-Transmittern lassen sich<br />

je nach Vordruck Durchflussendwerte zwischen 0,9 l/h<br />

und 36 l/h realisieren. Die Feinabstimmung der Messbereiche<br />

erfolgt über die speziellen, im Strömungskanal<br />

<strong>integrierte</strong>n Blenden – wobei die angestrebte Differenz<br />

von Eingangsdruck und Ausgangsdruck bei typischen<br />

500 mbar liegt.<br />

Schließlich setzten die Konstrukteure bei Keller weitere<br />

Details nach Kundenwunsch um: Das Lieferformat<br />

der flexiblen Platine mit den Details der elektrischen<br />

Anschlüsse sowie die mechanische Einbindung wurden<br />

ebenso gemeinsam spezifiziert wie <strong>das</strong> Ausgangssignal<br />

beim Nenndurchfluss, <strong>das</strong> jetzt mit 2,5 V deutlich<br />

von der Katalogware abweicht.<br />

Durch die digitalisierte Signalverarbeitung und die<br />

digitale Schnittstelle des Mikroprozessors stehen die<br />

individuellen Sensorsignale <strong>für</strong> den Eingangsdruck<br />

und Ausgangsdruck zur Verfügung und können im<br />

Durchflussregler intern genutzt werden um Grenzwerte<br />

zu setzen, Überlastungen zu detektieren oder andere<br />

12<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


LIQUID FLOW CONTROLLERS<br />

von Bürkert im Einsatz<br />

Querschnitt eines LiQuid FLow controLLers<br />

Anschlussstecker <strong>für</strong><br />

Sollwert, Istwert,<br />

Betriebsspannung etc.<br />

Regelelektronik<br />

Proportionalventil<br />

Feldbusstecker<br />

Durchflusssensor<br />

Edelstahlgrundkörper<br />

Fluidischer Eingang<br />

mit integr. Filter<br />

SCHEMA-<br />

TISCHER<br />

QUERSCHNITT<br />

eines<br />

Liquid Flow<br />

Controllers<br />

KELLER DOPPELSENSOR-MODUL<br />

Serie PD-9 FLX, mit Elektronik<br />

Bilder: Keller<br />

FUNKTIONSPRINZIP DER MESSWERTERFASSUNG: Gemessen<br />

wird nach dem Differenzdruckverfahren. Eine Blende im Hauptkanal<br />

erzeugt bei Durchfluss einen Druckabfall, welcher von dem<br />

vorhandenen Differenzdrucksensor erfasst wird. Der Differenzdrucksensor<br />

liefert ein präzises und temperaturkompensiertes<br />

Messsignal, aus dem der Durchfluss berechnet wird.<br />

Diagnosefunktionen zu realisieren. Bei der Kalibrierung<br />

der Durchflussmessung (üblicherweise mit Wasser<br />

oder einer Flüssigkeit, die eine ähnliche Viskosität wie<br />

die Prozessflüssigkeit hat) können die Kalibrierdaten<br />

im Prozessor des Differenzdruck-Transmitters komplett<br />

neu parametriert werden. Das erlaubt einen Abgleich<br />

auf die ganz individuellen Prozesse der Kunden und<br />

damit <strong>für</strong> viele Anwender eine optimale Lösung.<br />

ZUSAMMENFASSUNG UND AUSBLICK<br />

Zwei Spezialisten, einer <strong>für</strong> Durchflussregelung und<br />

einer <strong>für</strong> Druckmessung, konnten durch konstruktive<br />

Zusammenarbeit eine sehr konkrete Kundenanfrage gemeinsam<br />

lösen. Die auf einem Mikroprozessor aufbauende<br />

Signalverarbeitung des mit zwei Drucksensoren<br />

arbeitenden Differenzdruck-Transmitters von Keller hat<br />

die Integration in einen Durchflussregler <strong>für</strong> den Dauerbetrieb<br />

in der Prozesstechnik wesentlich vereinfacht<br />

und die Realisierung einer Reihe von Funktionalitäten<br />

ermöglicht. Das Modul zeigt sich in einer Reihe von Applikationen<br />

deutlich überlegen gegenüber klassischen<br />

Differenzdruck-Transmittern mit nur einer Membran,<br />

vor allem in Bezug auf Überlastbarkeit. Die Digitalisierung<br />

der Sensor-Signalverarbeitung bietet vor allem bei<br />

kundenspezifischen Anwendungen eine Reihe von Vorteilen,<br />

die sich auch in einer Gesamtkostenrechnung<br />

deutlich niederschlagen.<br />

AUTOR<br />

BERNHARD VETTERLI,<br />

Dipl. El.-Ing. HTL<br />

KELLER AG <strong>für</strong> Druckmesstechnik,<br />

St. Gallerstrasse 119,<br />

CH-8404 Winterthur,<br />

E-Mail: info@keller-druck.ch,<br />

Tel. +41 (0) 52 235 25 25<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

13


PRAXIS<br />

<strong>Engineering</strong> Base bündelt Informationen<br />

<strong>für</strong> kürzeren Ausschreibungsprozess<br />

Änderungen im Flowsheet werden automatisch in alle Datenblätter übernommen<br />

ZEITSPAREND: Neue Tendering-Lösung ermöglicht schnellere Erfolge bei der Ausschreibung. Bild: Aucotec<br />

Angebote einzuholen ist eine Wissenschaft <strong>für</strong> sich,<br />

besonders beim komplexen Anlagenbau. Schon die<br />

präzise Ausschreibung bedeutet eine Herausforderung<br />

wegen der großen Vielfalt an Komponenten. Das Vergleichen<br />

der Angebote ist eine Prozedur, die Wochen dauern<br />

kann. Einer der Gründe da<strong>für</strong> ist, <strong>das</strong>s die angefragten<br />

Komponenten selten exakt so angeboten werden wie<br />

ausgeschrieben. Der deutsche System-Entwickler Aucotec<br />

hat im Rahmen seiner Software-Plattform <strong>Engineering</strong><br />

Base ein Werkzeug entwickelt, <strong>das</strong> die Angebotsphase<br />

<strong>für</strong> Anlagenbetreiber und ihre Zulieferer vereinfacht<br />

und verkürzt. Die damit erarbeiteten Daten sind<br />

zudem durchgängig weiter <strong>für</strong> <strong>das</strong> <strong>Engineering</strong> nutzbar.<br />

HUNDERTE SPEZIFIKATIONSBLÄTTER<br />

Bislang sieht <strong>das</strong> Prozedere so aus: Das ausschreibende<br />

Unternehmen erstellt zunächst ein Verfahrensfließbild<br />

(Flowsheet oder Process Flow Diagram, PFD) und leitet<br />

daraus in der Regel Datenblätter ab zu all den Maschinen<br />

und Aggregaten, die es sich anbieten lassen möchte.<br />

Diese Datenblätter werden meist, aber nicht durchgängig,<br />

im xls-Format ausgegeben. 600 solcher Spezifikationsblätter<br />

sind bei einer Ausschreibung keine<br />

Seltenheit.<br />

Die Zulieferer, auch Tenderer genannt, müssen zunächst<br />

ihren Themenbereich in diesen Datenblättern<br />

finden. Allein <strong>das</strong> kann bei Hunderten von Blättern eine<br />

Weile dauern. Anschließend füllen die Tenderer diese<br />

Blätter von Hand aus. Dabei spezifizieren sie ihre Komponenten<br />

noch entsprechend ihrem individuellen Portfolio.<br />

Manchmal ändern sie zudem aufgrund ihrer Berechnungen<br />

<strong>das</strong> Flowsheet, zum Beispiel durch Anpassung<br />

eines Antriebs oder der Filterfläche. Dieses Proposal<br />

<strong>Engineering</strong> der verschiedenen Zulieferer muss der<br />

Ausschreiber händisch vergleichen. Das kann Wochen<br />

dauern, denn es müssen die verschiedenen Angebote<br />

miteinander verglichen werden und die Abweichungen<br />

der angebotenen Geräte und Komponenten von der Ausschreibung.<br />

An diesem Vergleich sitzen oftmals gleich<br />

mehrere Fachleute, deren Know-how <strong>für</strong> andere Aufgaben<br />

ebenso dringend gebraucht würde. Dennoch passiert<br />

es häufig, <strong>das</strong>s etwas übersehen wird.<br />

Nach diesem ersten Vergleich wird mit den interessantesten<br />

Tenderern auf einem höheren Level dieselbe Prozedur<br />

noch mindestens ein Mal in Gang gesetzt. Das bedeutet<br />

noch mehr Attribute, noch mehr Zeit <strong>für</strong> die Anbieter<br />

und <strong>für</strong> den anschließend wieder notwendigen<br />

Vergleich. Am Ende muss der Zulieferer, der den Zuschlag<br />

14<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


Unser<br />

Know-how<br />

<strong>für</strong> Sie<br />

erhält, ein weiteres Mal die Unterlagen bearbeiten<br />

<strong>für</strong> seine endgültigen Spezifikationen, die dann<br />

Grundlage sind <strong>für</strong> den abschließenden Vertrag. Einen<br />

Großanbieter in der Zementindustrie kostet die<br />

erste Angebotsphase zum Beispiel rund 100 000 US-<br />

Dollar, die zweite Stufe kann <strong>das</strong> Zehnfache an Zeit,<br />

Arbeitskraft und Geld bedeuten.<br />

EINMALIGE EINGABE – MEHRFACHER ZEITGEWINN<br />

Aucotec hat <strong>für</strong> diese Herausforderung gemeinsam<br />

mit einem großen Zement-Anlagenbetreiber eine<br />

Lösung geschaffen, die den ganzen Prozess der Ausschreibung<br />

gravierend vereinheitlicht und beschleunigt:<br />

Zu der datenbankbasierten Plattform <strong>für</strong> <strong>das</strong><br />

Anlagen-<strong>Engineering</strong>, die dort im Einsatz ist, wurde<br />

ein Werkzeug entwickelt, <strong>das</strong> <strong>das</strong> Tendering mit dem<br />

Prinzip der zentralen Datenhaltung unterstützt.<br />

Ausgangslage <strong>für</strong> den neu entwickelten Prozess<br />

ist <strong>das</strong> Flowsheet beziehungsweise PFD, <strong>das</strong> <strong>das</strong><br />

ausschreibende Unternehmen mit der Plattform <strong>Engineering</strong><br />

Base (EB) auf Basis der Design-Vorgaben<br />

aus der Feasibility-Studie erstellt. Per Knopfdruck<br />

lässt sich aus dem EB-Flowsheet ein Tender-Projekt<br />

generieren. Dieses Projekt können die Zulieferer in<br />

ihre EB-Datenbank einlesen, um dort <strong>das</strong> Datenmodell<br />

mit ihren Angaben zu füllen. Dazu haben sie<br />

rund 7 000 Attribute zur Verfügung, die die Besonderheiten<br />

der Spezifikationen von mechanischen,<br />

prozess- und auch elektrotechnischen Komponenten<br />

berücksichtigen. Alle Eingaben <strong>für</strong> eine bestimmte<br />

Komponente müssen nur einmal erfolgen,<br />

nichts kann übersehen oder vergessen werden. Jede<br />

Darstellung eines Objektes, egal ob in Liste oder<br />

Grafik, greift immer auf dieselbe Datenbasis zurück.<br />

In dem neuen Tendering-Prozess sind alle Datenblätter<br />

mit dem Flow Diagram verlinkt, was im<br />

herkömmlichen Verfahren nicht möglich ist. Diese<br />

Verlinkung ist <strong>für</strong> die Navigation im Projekt ebenso<br />

wichtig wie <strong>für</strong> <strong>das</strong> Änderungsmanagement.<br />

Ein ausgedrucktes PFD kann bis zu 20 Meter lang<br />

werden, <strong>das</strong> macht jede Suche sehr aufwendig. Das<br />

datenbankbasierte EB übernimmt Änderungen im<br />

Flowsheet automatisch <strong>für</strong> alle dazugehörigen Datenblätter<br />

und umgekehrt. So müssen zum Beispiel<br />

Modifikationen an den vorgegebenen Eigenschaften<br />

der zu bearbeitenden Materialien, wie Granularität,<br />

Feuchtigkeitsgrad, Gewicht, Dichte, Temperatur,<br />

nur an einer Stelle korrigiert werden. Diese<br />

Eigenschaften sind an jeder mechanischen Komponente<br />

sichtbar. Selbst bei kleineren Änderungen<br />

müsste nach der herkömmlichen Methode jedes<br />

Datenblatt, in dem diese Eigenschaft eingetragen<br />

ist, ausfindig gemacht und korrigiert werden. Mit<br />

EB reicht die einmalige Änderung an einer beliebigen<br />

Stelle. Alle wiederholten Darstellungen oder<br />

Nennungen ändern sich automatisch mit.<br />

A01120DE<br />

Mit über 50 weitgehend selbstständigen<br />

Tochtergesellschaften<br />

und über 220 Ingenieur- und Verkaufsbüros<br />

ist SAMSON auf allen<br />

Kontinenten kundennah vertreten.<br />

Um Ihnen die gesamte Regeltechnik<br />

in höchster Qualität zu<br />

bieten, hat SAMSON mit hochspezialisierten<br />

Unternehmen die<br />

SAMSON GROUP gebildet.<br />

SAMSON AG · MESS- UND REGELTECHNIK<br />

Weismüllerstraße 3 · 60314 Frankfurt am Main<br />

Telefon: 069 4009-0 · Telefax: 069 4009-1507<br />

E-Mail: samson@samson.de · www.samson.de<br />

SAMSON GROUP · www.samsongroup.net


PRAXIS<br />

FILTERN, FINDEN, DETAILLIEREN<br />

Die auszufüllenden Attribute werden vom Anbieter direkt<br />

im Tender-Projekt bearbeitet. Dabei können die<br />

Supplier verschiedene Filterungen und Vorgehensweisen<br />

auswählen, so<strong>das</strong>s sie nicht Hunderte von Datenblättern<br />

durchgehen müssen, um die <strong>für</strong> sie relevanten<br />

Bereiche zu identifizieren. Vom Flowsheet aus genügt<br />

ein einfacher Klick auf ein bestimmtes Objekt, um seine<br />

Entsprechung auf dem dazugehörigen Datenblatt zu finden.<br />

Und umgekehrt führt der Weg ebenso leicht vom<br />

Datenblatt zur genauen Platzierung im PFD.<br />

Zum einen lassen sich die <strong>für</strong> einen Anbieter interessanten<br />

Themen datenblattbezogen herausfiltern. So<br />

könnte der entsprechende Experte zum Beispiel sein<br />

Angebot <strong>für</strong> eine ganz bestimmte Maschine abgeben<br />

und nach allen dazugehörigen Datenblättern sortieren.<br />

Die andere Möglichkeit wäre eine Listen-Ausgabe, bei<br />

der beispielsweise alle <strong>für</strong> die zukünftige Anlage abgefragten<br />

Förderbänder zusammengefasst werden. Dort<br />

lassen sich die möglichen Motorleistungen, Bandbreiten<br />

und -längen oder Förderkapazitäten und alles, was sonst<br />

noch dazugehört, eintragen. Das EB-Projekt gibt in vielen<br />

Fällen zusätzlich die machbaren Varianten vor, so<strong>das</strong>s<br />

der Anbieter noch einmal Zeit sparen kann, indem<br />

er eine Option nur auswählen muss. Alle Supplier-Angaben<br />

werden beim Ausschreiber automatisiert von EB<br />

in <strong>das</strong> ursprüngliche Tenderprojekt eingelesen.<br />

Mit den verschiedenen Angebotsphasen steigt der Detaillierungsgrad<br />

der gefragten Informationen. In der ersten<br />

Phase werden meist zunächst die gröberen Materialanforderungen<br />

abgefragt, also etwa die <strong>für</strong> den Transport<br />

von 3 000 Tonnen pro Stunde <strong>für</strong> einen bestimmten<br />

Anlagenabschnitt erforderlichen Bänder, Antriebe, Filter,<br />

Trichter, Silos und so weiter. Die nächste Phase würde<br />

bereits so weit ins Detail gehen, <strong>das</strong>s daraus ohne<br />

Weiteres <strong>das</strong> Basic-Konzept einer Anlage mit deutlich<br />

genaueren Informationen, wie zum Beispiel Antriebsleistungen<br />

und genaue Abmaße ableitbar wäre. Bisher<br />

mussten nach der Ausschreibungsphase all diese Ausarbeitungen<br />

per Hand in <strong>das</strong> reale Planungsprojekt eingetragen<br />

werden. Mit EB lassen sich Daten, die vom später<br />

ausgewählten Zulieferer in der Angebotsphase generiert<br />

wurden, in der konkreten Planung weiterverwenden,<br />

es handelt sich hier um die gleichen Projektdaten.<br />

VERGLEICHEN: MINUTEN STATT WOCHEN<br />

Am Ende des Ausschreibungsprozesses importiert der<br />

Tender Manager von EB alle Anbieterinformationen und<br />

vergleicht automatisiert jedes Attribut der eingetragenen<br />

Objektdaten. Wegen der vielfachen Nutzung gleicher<br />

Komponenten in einer Anlage können <strong>das</strong> mehr als<br />

20 000 sein. Werden in einer Zementanlage etwa 15<br />

Conveyor verbaut und jeder hat rund 100 Attribute, so<br />

ist leicht vorstellbar, wie schnell die zu bearbeitende<br />

Datenmenge ansteigt und die Bearbeitungskomplexität<br />

zunimmt. In wenigen Minuten zeigt der Manager die<br />

Unterschiede, die sonst in wochenlanger Arbeit gesichtet,<br />

sortiert und bewertet werden müssten. Auch hier<br />

gibt es arbeitserleichternde Auswahlmöglichkeiten.<br />

Zum Beispiel kann sich der Bearbeiter vom Tender Manager<br />

auf Knopfdruck nur die Angebote anzeigen lassen,<br />

die sich von der Ausschreibung unterscheiden, nur die<br />

Zeilen, die ausgefüllt sind, nur die Spezifikationen, die<br />

untereinander verschieden sind. Oder alle Angebote zu<br />

ganz bestimmten Komponenten. Nur EB ermöglicht <strong>für</strong><br />

<strong>das</strong> Tendering so einen klaren Überblick.<br />

In den Listen, die der Tender Manager ausgibt, sind<br />

alle Angebote nebeneinander aufgeführt. Im Process<br />

Flow Diagram kann der Ausschreiber zusätzlich jedes<br />

einzelne Angebotsprojekt, <strong>das</strong> sich aus den Spezifikationen<br />

der Supplier ergeben hat, mit dem Ursprungsprojekt<br />

des Ausschreibers vergleichen, denn nach dem<br />

Import der Anbieterdaten in <strong>das</strong> Projekt zeigt <strong>das</strong> Revisionsmanagement<br />

alle Änderungen an. Dieser Überblick<br />

über Abweichungen ist einzigartig und spart Zeit.<br />

So vereinfacht und verschlankt die Übernahme des<br />

Tenderprojektes und <strong>das</strong> Ausfüllen der Datasheets in<br />

einem einheitlichen Format Prozesse bei allen Beteiligten,<br />

Ausschreibern wie Tenderern, erheblich.<br />

BESCHLEUNIGTER BIETPROZESS<br />

Von dem <strong>für</strong> und mit einem Betreiber entwickelten Tendering<br />

Tool profitieren auch die Tenderer mehrfach. Ein<br />

Pilotkunde aus der Zement-Zulieferindustrie, der EB<br />

und seine Tendering-Unterstützung nutzte, wurde um<br />

20 Prozent schneller.<br />

Der Tenderer muss nur noch ein Projekt verwalten und<br />

nicht, wie sonst üblich, seine Spezifikationen aufwendig<br />

in verschiedene Systeme einbringen. Der Zeitgewinn<br />

durch die einheitliche Vorgehensweise potenziert sich,<br />

wenn der Zulieferer des Zulieferers wiederum auf derselben<br />

Basis seine Angebote und Spezifikationen abgibt,<br />

die dann in <strong>das</strong> übergeordnete Projekt übernommen<br />

werden können. Denn EB erleichtert die Kooperation mit<br />

Partnern, indem Unterprojekte ausgegliedert werden<br />

können. Die bereits erwähnten automatischen Updates<br />

und <strong>das</strong> schnelle Zurechtfinden und Navigieren in allen<br />

Unterlagen beschleunigen auch den Bietprozess merklich.<br />

Die Anbieter profitieren darüber hinaus genau wie<br />

die Ausschreiber von dem besseren Überblick und können<br />

sicher sein, ihr Angebot passend abzugeben.<br />

AUTOR<br />

OLAF STREIT ist Sales<br />

Director Process<br />

Automation bei Aucotec<br />

in Hannover.<br />

Aucotec AG,<br />

Oldenburger Allee 24,<br />

D-30659 Hannover,<br />

Tel. +49 (0) 511 610 30,<br />

E-Mail: ost@aucotec.com<br />

16<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


Die Referenzklasse <strong>für</strong> die<br />

Automatisierungstechnik<br />

www.<strong>atp</strong>-<strong>edition</strong>.de<br />

<strong>atp</strong> <strong>edition</strong> ist <strong>das</strong> Fachmagazin <strong>für</strong> die Automatisierungstechnik.<br />

Die Qualität der wissenschaftlichen Hauptbeiträge<br />

sichert ein strenges Peer-Review-Verfahren. Bezug<br />

zur automatisierungstechnischen Praxis nehmen außerdem<br />

die kurzen Journalbeiträge aus der Fertigungs- und<br />

Prozessautomatisierung.<br />

Sichern Sie sich jetzt diese erstklassige Lektüre! Als exklusiv<br />

ausgestattetes Heft oder als praktisches ePaper – ideal <strong>für</strong><br />

unterwegs, auf mobilen Endgeräten oder zum Archivieren.<br />

Wählen Sie einfach <strong>das</strong> Bezugsangebot, <strong>das</strong> Ihnen zusagt:<br />

• Heft<br />

• ePaper<br />

• Heft + ePaper<br />

25% ersten Bezugsjahr<br />

Rabatt im<br />

<strong>atp</strong> <strong>edition</strong> erscheint in der DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München<br />

WISSEN FÜR DIE<br />

ZUKUNFT<br />

Vorteilsanforderung per Fax: +49 Deutscher 931 Industrieverlag / 4170-494 GmbH | Arnulfstr. oder 124 abtrennen | 80636 München und im Fensterumschlag einsenden<br />

Ja, ich möchte <strong>atp</strong> <strong>edition</strong> regelmäßig lesen und im ersten Bezugsjahr 25 % sparen.<br />

Bitte schicken Sie mir die Fachpublikation <strong>für</strong> zunächst ein Jahr (10 Ausgaben)<br />

als Heft <strong>für</strong> € 389,25 zzgl. Versand<br />

(Deutschland: € 30,- / Ausland: € 35,-).<br />

als ePaper (Einzellizenz) <strong>für</strong> € 389,25<br />

als Heft + ePaper <strong>für</strong> € 536,03<br />

inkl. Versand (Deutschland) / € 541,03 (Ausland).<br />

Alle Preise sind Jahrespreise und verstehen sich inklusive Mehrwertsteuer. Nur wenn ich nicht bis 8 Wochen<br />

vor Bezugsjahresende kündige, verlängert sich der Bezug zu regulären Konditionen um ein Jahr.<br />

Firma/Institution<br />

Vorname, Name des Empfängers<br />

Straße / Postfach, Nr.<br />

Land, PLZ, Ort<br />

Antwort<br />

Leserservice <strong>atp</strong><br />

Postfach 91 61<br />

97091 Würzburg<br />

Telefon<br />

E-Mail<br />

Branche / Wirtschaftszweig<br />

Telefax<br />

Widerrufsrecht: Sie können Ihre Vertragserklärung innerhalb von zwei Wochen ohne Angabe von Gründen in Textform (z.B.<br />

Brief, Fax, E-Mail) oder durch Rücksendung der Sache widerrufen. Die Frist beginnt nach Erhalt dieser Belehrung in Textform. Zur<br />

Wahrung der Widerrufsfrist genügt die rechtzeitige Absendung des Widerrufs oder der Sache an den Leserservice <strong>atp</strong>, Postfach<br />

9161, 97091 Würzburg.<br />

✘<br />

Ort, Datum, Unterschrift<br />

PAATPE2014<br />

Nutzung personenbezogener Daten: Für die Auftragsabwicklung und zur Pflege der laufenden Kommunikation werden personenbezogene Daten erfasst und gespeichert. Mit dieser Anforderung erkläre ich mich damit einverstanden,<br />

<strong>das</strong>s ich vom DIV Deutscher Industrieverlag oder vom Vulkan-Verlag per Post, per Telefon, per Telefax, per E-Mail, nicht über interessante, fachspezifische Medien und Informationsangebote informiert und beworben werde.<br />

Diese Erklärung kann ich mit Wirkung <strong>für</strong> die Zukunft jederzeit widerrufen.


PRAXIS<br />

Parametrierbare Master Batch Records gleichen<br />

Prozesse ab und vereinfachen Implementierung<br />

Electronic Master Batch Record (eMBR) bei papierloser Dokumentation eingesetzt<br />

MIT EMBR werrden alle Produktionsdaten<br />

elektronisch erfasst und dokumentiert. Bild: Siemens<br />

Die Pharmaindustrie sucht kontinuierlich nach Möglichkeiten<br />

zur Prozessverbesserung, um steigendem<br />

Kostendruck zu begegnen und alle Auflagen der Behörden<br />

zu erfüllen. Electronic Master Batch Record Management:<br />

Die Definition von pharmazeutischen Produktionsprozessen<br />

gemäß GMP basiert auf Master<br />

Batch Records (MBR) und den entsprechenden auftragsbezogenen<br />

Chargenprotokollen (Electronic Batch Records,<br />

EBR). Dabei ist der Aufwand <strong>für</strong> die Erstellung<br />

und Pflege von MBR und EBR in einer Produktionsumgebung,<br />

die auf Papier dokumentiert, hoch.<br />

LÜCKE ZWISCHEN ISA-95/ISA-88, AUTOMATISIERUNG<br />

UND PRODUKTIONS-IT<br />

Ein Electronic Master Batch Record Management arbeitet<br />

mit MBRs, die einer automatischen Versionskontrolle<br />

unterliegen und Bibliotheken mit wiederverwendbaren<br />

Bausteinen nutzen. Dank der standardisierten<br />

Bausteine kann der Anwender problemlos MBRs erstellen<br />

und pflegen.<br />

Das System bietet einen entsprechenden Rahmen und<br />

erzeugt ein nicht ausgefülltes EBR-Formular, in dem<br />

die Daten während der Produktion gesammelt werden.<br />

Danach wird der MBR zur Verarbeitung an die entsprechenden<br />

Systeme weitergeleitet. In diesem Format sorgt<br />

<strong>das</strong> Manufacturing Execution System (MES) <strong>für</strong> die<br />

Erzeugung, Synchronisation, Erfassung und Chargenfreigabe,<br />

während Automatisierungssysteme die Chargenausführung<br />

und Prozesssteuerung übernehmen. Die<br />

entsprechend dem MBR gesammelten Daten werden<br />

dann im Chargenprotokoll erfasst. Bis vor kurzem gab<br />

es jedoch keine <strong>integrierte</strong>n Lösungen, die die Lücke<br />

zwischen ISA-95/ISA-88, Automatisierung und Produktions-IT<br />

schließen konnten.<br />

SCHNELLERE FREIGABE DURCH BAUSTEINPRINZIP<br />

Die Siemens eMBR bietet ein Electronic Master Batch<br />

Record Management, <strong>das</strong> auf einer nativen Integration<br />

von MES und Prozessleitsystem mit Simatic IT XFP,<br />

Simatic PCS 7 und Simatic Batch aufbaut. Dies beschleunigt<br />

die Erstellung, Ausführung, Überprüfung<br />

und Freigabe des MBRs/EBRs und macht die MBR-<br />

Erstellung flexibler.<br />

Im Prozessleitsystem verwaltet die robuste und leistungsstarke<br />

Batch Engine komplexe S88-Rezepte und<br />

führt diese aus. Im MES kann der Anwender dank eines<br />

einfach zu bedienenden MBR-Workflows ohne besondere<br />

IT-Kenntnisse seine Produktionsabläufe definieren und<br />

durch einfache Parametrierung den MBR erstellen. Dabei<br />

stehen ihm die Rezeptinformationen aus dem Leitsystem<br />

zur Verfügung. Die dokumentationspflichtigen Schritte<br />

werden einfach aus der Schritt-Liste der freigegebenen<br />

Grundrezepte ausgewählt. Die Kombination aus wiederverwendbaren<br />

prozessspezifischen Bausteinen und fertigen<br />

Funktionen hilft, die MBR-Erstellung zu standardisieren<br />

und den MBR schneller freizugeben. Außerdem<br />

reduziert sie den Entwicklungsaufwand und <strong>das</strong> Risiko.<br />

Während der Produktion wird jeder Schritt und jeder<br />

Rohstoff überwacht, nachverfolgt und aufgezeichnet. Die<br />

Systeme koordinieren die Echtzeit-Steuerung auf jeder<br />

Ebene, synchronisieren die Ablaufschritte und tauschen<br />

Parameterwerte aus. Die Prozessregeln und -sequenzen<br />

werden über die Workflow Engines ausgeführt. Die Systeme<br />

verwalten dabei alle Abläufe wie Aufträge vom<br />

ERP-System (Enterprise Resource Planning), geführte<br />

manuelle Abläufe, Qualitätsprüfungen und die Nachverfolgung<br />

von Materialien und Rohstoffen.<br />

Durch den gesamten Prozess erfasst <strong>das</strong> MES Alarme<br />

und Warnungen. Sie stehen aktuell zur Verfügung. Warnungen<br />

werden zusammengefasst, so <strong>das</strong>s die Reviews<br />

einfacher, schneller und sicherer werden. Massendaten wie<br />

Trends, Kurven und Berichte können ebenfalls zusammengefasst<br />

in den EBR integriert werden. Der Zugriff auf die<br />

Produktionsdaten aller Systeme ist über alle Terminals<br />

oder Workstations möglich und Chargenberichte lassen<br />

sich in Echtzeit zusammenstellen und visualisieren.<br />

Da <strong>das</strong> MES alle Informationen sammelt, können die<br />

EBRs mithilfe von Ausnahmeregeln analysiert werden,<br />

so<strong>das</strong>s nur etwaige Abweichungen markiert werden.<br />

Auch <strong>das</strong> beschleunigt die Überprüfung und Freigabe<br />

der Charge. Die Freigabe der Charge selbst ist über den<br />

Signaturpfad festgelegt. Dem MBR ist dabei ein Prüfpfad<br />

zugewiesen, der die Anzahl der Signaturen bestimmt.<br />

Die eMBR Lösung stellt auch zusätzliche Tools<br />

zur Analyse bereit, wie etwa Betriebsbücher, einen<br />

kompletten Audit Trail und ein grafisches Genealogie-<br />

Tool. Mit dem Manufacturing Intelligence Tool können<br />

Berichte erstellt und kritische Daten sowohl pro Charge<br />

als auch über mehrere Chargen überwacht und analysiert<br />

werden – ein wichtiges Tool <strong>für</strong> Prozessverbesserungen<br />

und mehr Effizienz.<br />

18<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


EINFACHE ARCHITEKTUR, FLEXIBEL EINSETZBAR<br />

Je nach Kontext, Strategie, Systemlandschaft oder<br />

durchzuführenden Prozessen gibt es verschiedene Einsatzmöglichkeiten<br />

<strong>für</strong> einen automatisierten MBR/EBR-<br />

Prozess, der sowohl die Anforderungen von hochautomatisierten<br />

Prozessen in der Wirkstoffproduktion als<br />

auch von Prozessen mit vielen manuellen Abläufen in<br />

der Arzneimittelfertigung erfüllt.<br />

Die eMBR Lösung ist flexibel und unterstützt viele<br />

Vorgehensweisen. Dabei bietet es die Vorteile einer engen<br />

Integration von MES und Leitsystem und vereinfacht<br />

insgesamt die technische Architektur und deren<br />

Konfiguration. Die Lösung arbeitet gut zusammen mit<br />

dem Prozessleitsystem. Eine bestehende PCS-7-Umgebung<br />

wird mit der eMBR-Lösung um <strong>integrierte</strong> MES-<br />

Funktionalitäten erweitert, die sehr flexibel sind (zum<br />

Beispiel eine Schnittstelle zum unternehmensweiten<br />

ERP-System, Material-Tracking, komplexe elektronische<br />

Arbeitsanweisungen, MBR/EBR Reporting) –<br />

mit nur geringen Modifikationen der bestehenden Leitsystem<br />

Batch-Installation.<br />

DIE VORTEILE AUF EINEN BLICK<br />

Papierloser Prozess: Mit eMBR können alle Produktionsdaten<br />

elektronisch erfasst und dokumentiert<br />

werden.<br />

Weniger Entwicklungsaufwand und -risiken: Die Integration<br />

von MES und Leitsystem vereinfacht die<br />

Architektur, reduziert den Aufwand <strong>für</strong> Schnittstel-<br />

len zwischen Insellösungen und senkt so die Total<br />

Cost of Ownership.<br />

Standardisierte Bibliotheken <strong>für</strong> Prozessoperationen:<br />

Wiederverwendbare Funktionsbausteine und parametrierbare<br />

MBRs harmonisieren Prozesse und vereinfachen<br />

die globale, standortübergreifende Implementierung.<br />

Die zentralisierte Überprüfung und Freigabe der<br />

Charge machen die Prüfung schneller und sicherer,<br />

die Überprüfung und Freigabe erfolgen anhand von<br />

Abweichungen.<br />

AUTOR<br />

NICOLAS TEISSIE ist Business<br />

Development MES Life Science<br />

bei Siemens in Karlsruhe.<br />

Siemens AG,<br />

Siemensallee 84, D-76187 Karlsruhe,<br />

Tel. +49 (0) 721 595 38 19,<br />

E-Mail: nicolas.teissie@siemens.com<br />

E I N L A D U N G<br />

Messtechnik Regeltechnik Steuerungstechnik Prozessleitsysteme<br />

Mittwoch, 26. März 2014<br />

8:00 bis 16:00 Uhr<br />

Jahrhunderthalle<br />

Pfaffenwiese 301<br />

65929 Frankfurt am Main<br />

Führende Fachfirmen der Branche präsentieren ihre Geräte und Systeme und<br />

zeigen neue Trends in der Automatisierung auf. Die Messe wendet sich an<br />

alle Interessierten, die auf dem Gebiet der Mess-, Steuer- und Regeltechnik<br />

sowie der Prozessautomation tätig sind.<br />

Der Eintritt zur Messe, die Teilnahme an den Workshops und der Imbiss<br />

sind <strong>für</strong> die Besucher kostenlos.<br />

Weitere Informationen finden Interessierte auf unserer Internetseite.<br />

www.meorga.de<br />

info@meorga.de<br />

MEORGA GmbH<br />

Sportplatzstraße 27<br />

66809 Nalbach<br />

Tel. 06838 / 8960035<br />

Fax 06838 / 983292<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

19


PRAXIS<br />

Technik-Kommunikation leicht gemacht:<br />

Cause-and-Effect-Diagramm als Lösungsansatz<br />

Gemeinsames Format soll Verfahrens- und Prozessleittechniker zusammenbringen<br />

WENN-DANN-LOGIK<br />

des Verfahrenstechnikers<br />

FUNKTIONSPLAN<br />

des Leittechnikers<br />

Der Rührer XM3008 soll nicht automatisch<br />

eingeschaltet werden können, wenn der<br />

Reaktor3000 LI2003 nicht mindesten WL<br />

10% befüllt meldet und die Temperatur<br />

TI3009 im Reaktor3000 zwischen WL 10°C<br />

und WH 70°C liegt.<br />

Die Abflußpumpe XS3001 soll abschalten,<br />

wenn der Stand LI2003 im Reaktor3000 zu<br />

gering ist (ALL).<br />

Die Heizung XV3005 soll abschalten, wenn<br />

der Stand LI2003 im Reaktor3000 unterhalb<br />

der Heizspirale ist (WL) und die Temperatur<br />

TI3009 über AHH 120°C liegt.<br />

Name<br />

XM3008<br />

XS3001<br />

XV3005<br />

Type<br />

MOT<br />

MOT<br />

MOT<br />

ERWEITERTES<br />

CAUSE & EFFECT<br />

Diagramm<br />

Bilder: ABB<br />

Name Type Trip Point Interlock 3 Interlock 2 Interlock 1<br />

LI2003 LT WL Lock OFF OFF<br />

TI3009 TT WH Lock<br />

TI3009 TT WL Lock<br />

TI3009 TT AHH OFF<br />

Verständigungsprobleme sind zumeist frustrierend<br />

und zeitraubend, egal welchen Bereich es betrifft.<br />

Nur sind diese leider schwer zu vermeiden, wenn verschiedene<br />

Menschen Dinge unterschiedlich interpretieren.<br />

Das ist im geschäftlichen Umfeld leider oft genauso<br />

wie im privaten Umfeld und auch die Planung<br />

einer Anlage bildet hierbei keine Ausnahme, wenn sich<br />

die verschiedenen Gewerke austauschen müssen.<br />

WERKZEUGE MÜSSEN KOMMUNIZIEREN<br />

Nicht nur die verschiedenen Gewerke bringen jeweils<br />

eigene Softwarewerkzeuge mit, teils finden sich innerhalb<br />

eines Gewerks mehrere Tools. Für einen reibungslosen<br />

Datenaustausch sollten diese Werkzeuge miteinander<br />

reden können, <strong>das</strong> heißt, sie sollten über Importund<br />

Exportschnittstellen verfügen, die im Idealfall mit<br />

demselben Datenformat umgehen und die Daten gleich<br />

interpretieren können. Oftmals mangelt es aber an diesem<br />

Austauschformat. Bei einer schrittweisen Annäherung<br />

an ein gemeinsames Datenformat hilft Automation<br />

ML, da mit dessen Hilfe Teile der auszutauschenden<br />

Daten standardisiert werden können.<br />

Mindestens genauso wichtig wie <strong>das</strong> Verständnis<br />

zwischen den Softwarewerkzeugen ist allerdings <strong>das</strong><br />

Verständnis der dabei involvierten Personen untereinander.<br />

Diese benötigen genauso ein Format, <strong>das</strong> von<br />

beiden Seiten verstanden wird und in Meetings diskutiert<br />

werden kann.<br />

Während allerdings der Verfahrenstechniker in<br />

Rohrleitungs- und Industrie-(R&I)-Fließbildern denkt,<br />

ist der Logikplan die Welt des Prozessleittechnikers.<br />

Auf diese Formate wird sich beschränkt, so<strong>das</strong>s der<br />

Prozessleittechniker vom Verfahrenstechniker die<br />

Anforderungen an <strong>das</strong> Automatisierungssystem in<br />

Form eines Stapels R&I-Diagramme mit zusätzlicher<br />

textbasierter Logik in der Form „Wenn…. Dann…“<br />

erhält. Dieser übersetzt daraufhin die Anforderungen<br />

zumeist manuell in Logikpläne. Wenn er beim Übersetzen<br />

jedoch Rückfragen an den Verfahrenstechniker<br />

hat, hat dieser manchmal ein Problem, die Logikpläne<br />

effizient zu verstehen – erst recht, wenn es sich<br />

dabei um Logik im Ruhestromprinzip handelt. Auch<br />

bei Besprechungen wäre ein gemeinsames Format zur<br />

Diskussion hilfreich, da der Funktionsplan dem Ver-<br />

20<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


fahrenstechniker oft zu kompliziert ist, während dem<br />

Leittechniker der frei formulierte Text nicht präzise<br />

genug ist. Hier besteht Optimierungspotenzial.<br />

UNTERSCHIEDLICHE LÖSUNGSANSÄTZE<br />

In der Praxis gibt es mehrere Lösungsansätze, <strong>das</strong> Verständigungsproblem<br />

zwischen Verfahrenstechniker und<br />

Leittechniker zu eliminieren.<br />

In Norwegen hat sich <strong>das</strong> System Control Diagram<br />

(SCD) etabliert. Zu verdanken ist diese weite Verbreitung<br />

des SCD dem Norsok-Standard, den viele Firmen aus dem<br />

Öl- und Gasbereich bereits in ihren Ausschreibungen<br />

festlegen. Das SCD ähnelt auf den ersten Blick einem<br />

R&I-Diagramm, was dem Verfahrenstechniker entgegen<br />

kommt. Bei genauerer Betrachtung ist erkennbar, <strong>das</strong>s es<br />

zum Beispiel Verschaltungen zwischen den einzelnen<br />

Messstellen enthält, die wiederum <strong>für</strong> den Prozessleittechniker<br />

von Interesse sind. Das SCD wird zwar üblicherweise<br />

manuell in Funktionspläne übersetzt, jedoch<br />

kann diese Aufgabe ohne oder zumindest mit weniger<br />

Rückfragen erledigt werden, da es eindeutiger ist als eine<br />

textuelle Beschreibung. Somit hat sich <strong>das</strong> SCD als Kommunikationsformat<br />

zwischen den Gewerken bewährt.<br />

Ein weiterer Ansatz ist <strong>das</strong> „Unit-based-control“ dar.<br />

Hierbei wird die eher komplizierte Kontrolllogik in<br />

Units gekapselt. Dadurch müssen Units nur noch miteinander<br />

verschaltet werden müssen. Diese verfügen<br />

über einen Status und einen begrenzten Satz an Befehlen,<br />

was die Verschaltung vereinfacht. Ein weiterer<br />

Vorteil ergibt sich <strong>für</strong> den Anlagenfahrer: Er erhält eine<br />

übersichtlichere Struktur, da er größere, zusammenhängende<br />

Einheiten in einem Faceplate bedienen und<br />

beobachten kann.<br />

Während sich die beiden vorigen Lösungsmöglichkeiten<br />

bereits in Teilbereichen einzelner Länder oder<br />

Industrien in der Praxis bewährt haben, ist der Ansatz<br />

eines erweiterten Cause-and-Effekt-Diagramms noch relativ<br />

neu. Ausgangspunkt dieser Idee ist <strong>das</strong> bewährte<br />

Cause-and-Effekt-Diagramm, <strong>das</strong> dem Verfahrenstechniker<br />

und dem Prozessleittechniker vertraut ist und bereits<br />

heute als Übergabeformat im Bereich Safety, also bei<br />

verhältnismäßig einfacher Abschaltlogik, ein de-facto-<br />

Standard ist. Vorteilhaft sollte sich außerdem die kompakte<br />

und einfache Darstellung erweisen.<br />

„WENN DANN“ IN DER PROZESSINDUSTRIE<br />

Im Gegensatz zu dem bereits etablierten Cause-and-Effect,<br />

beinhaltet <strong>das</strong> erweiterte Cause-and-Effekt-Diagramm<br />

nicht Safety Code, sondern die normale Prozesslogik.<br />

Um den Anforderungen der Prozesslogik gerecht<br />

zu werden, enthält <strong>das</strong> erweiterte Cause-and-Effekt-Diagramm<br />

einen Bereich, in dem die Signale der Causes mit<br />

verschiedenen Logikfunktionen vorverarbeitet werden<br />

können, bevor sie in der Matrix verschaltet werden, zum<br />

Beispiel verundet oder negiert. Auch bei den Verschaltungen<br />

ist ein Unterschied zum Cause-and-Effect im Bereich<br />

Safety zu finden: In der Verbindungszelle wird statt<br />

eines Kreuzes oder Punkts, der den betreffenden Aktor<br />

bei der Safety-Matrix in den sicheren Zustand bringt, ein<br />

beliebiger Befehl abgelegt. Damit kann zum Beispiel ein<br />

Ventil geschlossen oder geöffnet oder sogar ein kalkulierter<br />

Wert auf einen Setpoint geschaltet werden. Zudem<br />

können in der Matrix auch ganze Templates miteinander<br />

verschaltet werden. Durch diese Erweiterungen wird <strong>das</strong><br />

Format ermächtigt, der komplexeren Prozesslogik gerecht<br />

zu werden. Da jedoch manche Spezialfälle recht aufwendig<br />

in dieser Form darzustellen sind, könnte es in der<br />

Praxis notwendig werden, <strong>das</strong> ein oder andere mit Kommentaren<br />

oder ähnlichem zu beschreiben, die dann im<br />

Leitsystem direkt manuell umgesetzt werden. Dieser Prozentsatz<br />

liegt in der chemischen Industrie – je nachdem,<br />

wie viel Arbeit in die Erstellung der Matrix aufgebracht<br />

wird – bei 0 - 30 %. Für andere Industrien liegen noch<br />

keine Erfahrungswerte vor.<br />

FAZIT<br />

Aufgrund der Diversität der Industrien haben die bestehenden<br />

Formate und <strong>das</strong> neue erweiterte Cause-and-<br />

Effekt-Diagramm ihre Berechtigung. Erste Anwendungsfelder<br />

<strong>für</strong> <strong>das</strong> neue Format haben sich bereits ergeben.<br />

Die Kriterien, aufgrund derer ein Austauschformat<br />

ausgesucht wird, unterscheiden sich von Industrie zu<br />

Industrie oder haben unterschiedliche Gewichtung.<br />

Mögliche Kriterien sind zum Beispiel die Verbreitung<br />

des Formats, die technische Akzeptanz, oder auch<br />

schlicht eine Kundenvorgabe. Daher unterscheiden sich<br />

die Formate je nach Industrie und Kunde. Auch regionale<br />

Standards und Vorgaben beeinflussen <strong>das</strong> Format.<br />

Sogar der Scope of Supply spielt eine große Rolle,<br />

welches Format als sinnvoll erachtet wird. Mittelfristig<br />

werden aufgrund dieser Diversität die bestehenden Formate<br />

weitgehend erhalten bleiben, jedoch wird es auch<br />

Potenzial <strong>für</strong> neue Formate geben.<br />

AUTOREN<br />

KATHARINA GOHR ist<br />

Scientist Automation<br />

<strong>Engineering</strong> beim ABB<br />

Forschungszentrum<br />

Deutschland in Ladenburg.<br />

RALF JESKE ist Produktmanager<br />

DCS <strong>Engineering</strong><br />

System 800xA bei ABB<br />

Process Automation<br />

Deutschland in Minden.<br />

ABB Germany,<br />

Kallstadter Straße 1, D-68309 Mannheim,<br />

Tel. +49 (0) 621 438 10,<br />

E-Mail: katharina.gohr@de.abb.com,<br />

ralf.jeske@de.abb.com<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

21


PRAXIS<br />

Standardisierung mit eClass – Klassifizierung<br />

ermöglicht kürzeres Time-to-Market<br />

Produktdaten liegen <strong>für</strong> <strong>Engineering</strong>-Prozesse vor<br />

BEI ECLASS handelt es sich um ein herstellerneutrales<br />

Produktbeschreibungs-Format <strong>für</strong> den elektronischen<br />

Datenaustausch zwischen dem Gerätehersteller und<br />

dem CAE-Tool<br />

DIE CAE-DATEN aus dem Produkt-<br />

Informationsmanagement-System (PIM) von<br />

Phoenix Contact werden mit entsprechenden<br />

Konverter-Tools in die Zielformate überführt<br />

Die vielfältigen von Maschinen- und Anlagenbauern<br />

sowie Endanwendern eingesetzten Software-Werkzeuge<br />

erfordern immer mehr Produktdaten, die von den<br />

Geräteherstellern bereitgestellt werden müssen. Allein<br />

die Anpassung an die Erfordernisse der verschiedenen<br />

E-CAD-Software gestaltet sich sehr zeitaufwendig. Ein<br />

einheitlicher Klassifizierungs-Standard wie eClass<br />

schafft hier Abhilfe.<br />

Für die Anwender stellen die Funktionen der Geräte<br />

sowie ihre technischen Eigenschaften dabei ein wesentliches<br />

Kriterium bei der Lieferantenauswahl dar.<br />

Ihre Entwicklungsabteilungen sind mit den dort genutzten<br />

<strong>Engineering</strong>-Werkzeuge wie E-CAD oder M-<br />

CAD in die Software-Landschaft des Unternehmens<br />

eingebunden. Diese umfasst unter anderem ERP-Systeme<br />

<strong>für</strong> die kaufmännischen und logistischen Prozesse<br />

sowie PLM-Systeme zur entwicklungstechnischen<br />

Begleitung. Aufgrund der Vielzahl der anfallenden<br />

Daten möchte nicht jeder Nutzer die Daten<br />

seiner Applikation manuell erfassen und aktualisieren.<br />

Daher fragt die Einkaufsabteilung die relevanten<br />

Daten bei ihren Lieferanten ab. Der Konstrukteur benötigt<br />

beispielsweise 3D-Modelle und der Elektroplaner<br />

erwartet, <strong>das</strong>s die Daten der zu verbauenden Komponenten<br />

im Format seines E-CAD-Werkezuge zur<br />

Verfügung stehen. Vor diesem Hintergrund ergibt sich<br />

<strong>für</strong> den Lieferanten die Herausforderung, die verschiedenen<br />

Anfragen nach den Produktdaten zu erfüllen,<br />

um seine Kunden zu unterstützen und sich als Bezugsquelle<br />

zu profilieren.<br />

GRUNDLAGE FÜR EIN KURZES TIME-TO-MARKET<br />

Der Faktor Zeit erweist sich im Entwicklungsprozess<br />

als eine wichtige Einflussgröße. Ein möglichst kurzes<br />

Time-to-Market lässt sich erreichen, indem sämtliche<br />

erforderlichen Daten korrekt in den unterschiedlichen<br />

Software-Werkzeugen vorliegen, so<strong>das</strong>s <strong>das</strong><br />

Produkt termingerecht ausgeliefert werden kann. In<br />

den vergangenen Jahren hat sich im Beschaffungsprozess<br />

mit BME-Cat ein Datenaustausch-Format<br />

durchgesetzt, <strong>das</strong> vom Bundesverband Materialwirtschaft,<br />

Einkauf und Logistik (BME) entwickelt wurde.<br />

BME-Cat zielt darauf ab, den Austausch von Produktkatalogen<br />

zwischen den Lieferanten und den<br />

einkaufenden Unternehmen zu standardisieren und<br />

somit zu vereinfachen. Viele Kunden von Phoenix<br />

Contact fordern deshalb Produktdaten im BME-Cat-<br />

Format an, damit sie diese über eine Standard-<br />

Schnittstelle in ihr System importieren können.<br />

Neben den Stammdaten wird die Klassifizierung<br />

nach eClass verlangt, die <strong>für</strong> <strong>das</strong> Warengruppen-Management<br />

sowie den Aufbau von Multi-Supplier-Katalogen<br />

notwendig ist. Phoenix Contact bietet beide Standards<br />

und unterstützt so die Prozesse seiner Kunden.<br />

22<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


INDEM DIE PRODUKTDATEN im PIM-System<br />

auf die eClass-Struktur gemapped werden,<br />

lassen sie sich direkt im Zielformat darstellen<br />

AUS DER KOMBINATION von Schaltplan-Informationen<br />

und Produktdaten können die Leitungen nach der<br />

Platzierung der Geräte im 3D-Aufbau automatisch<br />

geroutet werden<br />

Bilder: Phoenix Contact<br />

Das gilt auch <strong>für</strong> den Bereich der mechanischen Konstruktion,<br />

wo die Anwender vereinfachte 3D-Step-<br />

Modelle von der Website des Unternehmens herunterladen<br />

können. Denn die 3D-CAD-Systeme arbeiten<br />

heute in der Regel mit dem ISO-Standard Step als Austauschformat.<br />

PRODUKTDATEN IM NOTWENDIGEN FORMAT LIEFERN<br />

Bei den Elektro-CAD-Systemen sind in puncto Klassifizierung<br />

drei Bereiche zu betrachten:<br />

Artikeldaten/Stammdaten<br />

Hierbei handelt es sich um die Artikelnummer,<br />

den Typ, die Beschreibung, Abmessungen und auswahlrelevante<br />

technische Daten wie Strom, Spannung<br />

oder Querschnitt. Diese Informationen können<br />

von zahlreichen Werkzeugen über entsprechende<br />

Import-<strong>Schnittstellen</strong> eingelesen werden.<br />

Schaltplan-Symbole der Produkte<br />

Sie sind <strong>für</strong> die Erstellung des Schaltplans erforderlich,<br />

<strong>für</strong> jedes E-CAD-Werkzeug spezifisch und<br />

müssen den einzelnen Produkten zugeordnet sein.<br />

Grafische Daten<br />

Zur Platzierung der Produkte nutzen die Werkzeuge<br />

maßstäbliche Grafikformate wie dxf-Dateien<br />

zur 2D-Darstellung. E-CAD-Systeme, die auch eine<br />

3D-Konstruktion erlauben, erzeugen aus den Abmessungen<br />

des Produkts ein Volumenmodell oder<br />

verwenden dazu <strong>das</strong> 3D-Step-Modell des Produkts.<br />

Um die Kundenanfragen nach Produktdaten im Format<br />

der von ihnen eingesetzten E-CAD-Software umsetzen<br />

zu können, mussten sich die Verantwortlichen<br />

bei Phoenix Contact auf bestimmte Systeme festlegen.<br />

Zwecks Erstellung der Daten <strong>für</strong> ein E-CAD-System<br />

sind die notwendigen Produkt-Stammdaten im ersten<br />

Schritt im Import-Format des eigenen E-CAD-Werkzeugs<br />

anzulegen. Nach dem Daten-Import müssen<br />

dann systemspezifische Ergänzungen im E-CAD-<br />

Werkzeug vorgenommen werden, um dem Kunden<br />

anschließend die jeweilige Datenbank über <strong>das</strong> Internet<br />

zum Herunterladen zur Verfügung zu stellen.<br />

VORHANDENE STANDARDS HARMONISIEREN<br />

Bei Phoenix Contact sind die Stammdaten Bestandteil<br />

des Produkt-Informationsmanagement-Systems (PIM)<br />

und werden dort gepflegt. Die vom Anwender angefragten<br />

CAE-Daten werden somit aus dem PIM-System<br />

exportiert und über einen Konverter in <strong>das</strong> Import-Format<br />

des E-CAD-Werkzeugs des entsprechenden Kunden<br />

transformiert. Dies führt zu einem hohen Aufwand, da<br />

<strong>für</strong> jede zu unterstützende E-CAD-Software ein passender<br />

Konverter erforderlich ist. Zudem muss der Prozess<br />

bei jeder neuen Version geprüft werden, was sich<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

23


PRAXIS<br />

zeitaufwendig gestaltet. Es fehlte also ein Standard. Das<br />

haben viele Beteiligte erkannt und sich zur Erarbeitung<br />

einer Lösung zusammengeschlossen. Allerdings sollte<br />

kein komplett neuer Ansatz geschaffen, sondern wenn<br />

möglich auf eine vorhandene Lösung aufgesetzt werden.<br />

Im ersten Schritt haben die beteiligten Unternehmen<br />

daher Etim als Klassifizierungs-Standard des<br />

Elektrogroßhandels sowie den branchenübergreifenden<br />

Ansatz eClass untersucht. Etim verfügt zwar<br />

über eine hohe Verbreitung, erweist sich jedoch aufgrund<br />

seines Datenmodells als nicht geeignet. Ferner<br />

bestand seitens der Unterstützer kein Interesse an<br />

einer entsprechenden Erweiterung. Das Datenmodell<br />

von eClass bietet hingegen die benötigten Strukturen<br />

und wird ebenfalls von zahlreichen Unternehmen<br />

genutzt. Auf der Grundlage einer Förderung durch<br />

<strong>das</strong> Bundesministerium <strong>für</strong> Wirtschaft und Technologie<br />

(BMWI) ist eClass deshalb mit Etim sowie Proficlass,<br />

dem Klassifizierungs-Standard der Werkzeugbranche,<br />

und Prolist International als Klassifizierungs-Standard<br />

der Prozesstechnik harmonisiert und<br />

um deren Klassen ergänzt worden.<br />

ERFORDERLICHE DATEN IDENTIFIZIEREN<br />

Die CAx-Fachgruppe des eClass-Vereins beschäftigt<br />

sich mit der Definition der erforderlichen Strukturen<br />

zur Abbildung der Daten in den E-CAD-Tools. Sie setzt<br />

sich aus Mitarbeitern der Anbieter von E-CAD-Software,<br />

der Produkthersteller sowie Anwender zusammen.<br />

Ziel ist es, den Standard <strong>für</strong> den Datenaustausch<br />

zwischen den Geräteanbietern und den E-CAD-Tools<br />

mit der eClass-Advanced-Version bereitzustellen. Vor<br />

diesem Hintergrund hat Phoenix Contact eClass in<br />

seinem PIM-System so implementiert, <strong>das</strong>s die Daten<br />

aus dem internen Klassifizierungs-System auf <strong>das</strong><br />

Zielsystem eClass gemappt werden können. Das Vorgehen<br />

zeigt sich als vorteilhaft, weil die Daten des<br />

jeweiligen Produkts im Zielformat sofort im PIM-System<br />

geprüft werden können.<br />

Durch die Verwendung von eClass lassen sich neben<br />

den CAE-relevanten Stammdaten jetzt beispielsweise<br />

auch sämtliche notwendigen Daten eines Anschlusses<br />

wie Ausführung, Position, Anschlussrichtung<br />

und die zulässigen Leitungsquerschnitte definieren,<br />

die zum automatischen Routen der Leitungen<br />

im Schaltschrank unerlässlich sind. Am Beispiel<br />

einer Stromversorgung sollen die Vorteile dieser Vorgehensweise<br />

erläutert werden.<br />

PRODUKTDATEN IM ECLASS-FORMAT<br />

Um die Stammdaten der Stromversorgung im Zielformat<br />

des entsprechenden CAE-Werkzeugs zu erstellen,<br />

müssen rund 20 Attribute konvertiert werden. Damit<br />

<strong>das</strong> automatische Routen der Leitungen möglich ist,<br />

sind <strong>für</strong> die Stromversorgung außerdem 13 Anschlüsse<br />

festzulegen. Wenn nur die Anschlussposition und<br />

-richtung betrachtet werden, ergeben sich bereits 26<br />

Werte, die in <strong>das</strong> jeweilige Zielformat überführt werden<br />

müssen. Es fehlen allerdings noch die Daten <strong>für</strong><br />

Befestigungspunkte, Anschlussquerschnitte und weitere<br />

Detailangaben, die der Funktionsumfang aktueller<br />

CAE-Tools benötigt. Derartige Datenmengen lassen<br />

sich nicht mehr mit vertretbarem Aufwand in die vielen<br />

unterschiedlichen Zielformate übertragen.<br />

Hier liegt der große Vorteil von Geräteherstellern,<br />

die mit dem eClass-Standard arbeiten. Anstatt in die<br />

Entwicklung und Pflege der spezifischen Konverter<br />

<strong>für</strong> die CAE-Tools zu investieren, können sich die<br />

Mitarbeiter nun darauf konzentrieren, den Kunden<br />

die Produktdaten im eClass-Format zur Verfügung zu<br />

stellen. Auf diese Weise werden die E-Procurement-<br />

Prozesse unterstützt und die gleichen Daten liegen<br />

ebenfalls <strong>für</strong> die <strong>Engineering</strong>-Prozesse vor. Jede Anpassung,<br />

die sich auf die Quantität und Qualität der<br />

Daten beim Gerätehersteller auswirkt, generiert somit<br />

einen n-fachen Nutzen beim Empfänger der Daten.<br />

ECAD-Hersteller, die einen eClass-Datenimport anbieten,<br />

eröffnen ihren Kunden die Möglichkeit, die<br />

Produktdaten der Lieferanten in einem Standard-<br />

Format anzufragen.<br />

AUTOR<br />

Dipl.-Ing.<br />

JOSEF SCHMELTER<br />

ist Master Specialist<br />

Classification im Bereich<br />

Corporate Technology<br />

bei Phoenix Contact in<br />

Blomberg.<br />

Phoenix Contact Deutschland GmbH,<br />

Flachsmarktstraße 8,<br />

D-32825 Blomberg,<br />

Tel. +49 (0) 5235 31 20 00,<br />

E-Mail: jschmelter@phoenixcontact.com<br />

24<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


Der Klassiker <strong>für</strong> die<br />

Prozessautomation geht<br />

ins 21. Jahrhundert<br />

Das Handbuch der Prozessautomation ist ein Standardwerk <strong>für</strong> die Planung<br />

verfahrenstechnischer Anlagen. In der 5., überarbeiteten Version geht es auf<br />

die Herausforderung bei der Digitalisierung der Anlage ein. Das Handbuch<br />

wurde von fast 50 Experten mit umfassenden Praxiskenntnissen gestaltet<br />

und deckt <strong>das</strong> gesamte Feld der Prozessautomatisierung ab.<br />

Hrsg.: K. F. Früh, U. Maier, D. Schaudel<br />

5. Auflage 2014<br />

740 Seiten, 170 x 240mm, Hardcover<br />

Erhältlich in 2 Varianten<br />

www.di-verlag.de<br />

DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München<br />

Jetzt vorbestellen!<br />

Bestellung per Fax: +49 (0) 201 Deutscher / 82002-34 Industrieverlag GmbH oder | Arnulfstr. abtrennen 124 und | 80636 im München Fensterumschlag einsenden<br />

Ja, ich bestelle gegen Rechnung 3 Wochen zur Ansicht<br />

___ Ex.<br />

Handbuch der Prozessautomatisierung<br />

5. Auflage – ISBN: 978-3-8356-3372-8<br />

<strong>für</strong> € 199,90 (zzgl. Versand)<br />

Firma/Institution<br />

Vorname, Name des Empfängers<br />

___ Ex.<br />

Handbuch der Prozessautomatisierung<br />

mit interaktivem eBook (Online-Lesezugriff im MediaCenter)<br />

5. Auflage – ISBN: 978-3-8356-7119-5<br />

<strong>für</strong> € 259,90 (zzgl. Versand)<br />

Straße / Postfach, Nr.<br />

Land, PLZ, Ort<br />

Antwort<br />

Vulkan-Verlag GmbH<br />

Versandbuchhandlung<br />

Postfach 10 39 62<br />

45039 Essen<br />

Telefon<br />

E-Mail<br />

Telefax<br />

Branche / Wirtschaftszweig<br />

Widerrufsrecht: Sie können Ihre Vertragserklärung innerhalb von zwei Wochen ohne Angabe von Gründen in Textform (z.B.<br />

Brief, Fax, E-Mail) oder durch Rücksendung der Sache widerrufen. Die Frist beginnt nach Erhalt dieser Belehrung in Textform.<br />

Zur Wahrung der Widerrufsfrist genügt die rechtzeitige Absendung des Widerrufs oder der Sache an die Vulkan-Verlag GmbH,<br />

Versandbuchhandlung, Huyssenallee 52-56, 45128 Essen.<br />

Ort, Datum, Unterschrift<br />

PAHBPA2014<br />

Nutzung personenbezogener Daten: Für die Auftragsabwicklung und zur Pflege der laufenden Kommunikation werden personenbezogene Daten erfasst und gespeichert. Mit dieser Anforderung erkläre ich mich damit einverstanden,<br />

<strong>das</strong>s ich vom DIV Deutscher Industrieverlag oder vom Vulkan-Verlag per Post, per Telefon, per Telefax, per E-Mail, nicht über interessante, fachspezifische Medien und Informationsangebote informiert und beworben werde.<br />

Diese Erklärung kann ich mit Wirkung <strong>für</strong> die Zukunft jederzeit widerrufen.


INTERVIEW<br />

„Produkte mit bis zu 50 %<br />

Zeitersparnis einführen“<br />

Eckard Eberle und Hans-Georg Kumpfmüller<br />

im Interview mit <strong>atp</strong> <strong>edition</strong><br />

Im November vergangenen Jahres fand in Bad Neuenahr die Namur-Hauptsitzung zum Thema „Integrated <strong>Engineering</strong>“<br />

statt. Das Thema wurde auch vom Hauptsponsor Siemens aufgegriffen. Eckard Eberle, CEO der Siemens Business Unit<br />

Industrial Automation Systems, und Hans-Georg Kumpfmüller, CEO der Siemens Business Unit Sensors and Communication,<br />

stellen sich im Interview den Fragen der <strong>atp</strong>-Redaktion zu CPS, Anlagenlebenszyklus und Energiewende.<br />

<strong>atp</strong> <strong>edition</strong>: Digitalisierung, Virtualisierung, Simulation, Fabrik<br />

der Zukunft und cyber-physische Systeme (CPS) beziehungsweise<br />

Industrie 4.0. – um nur einige Begriffe zu nennen<br />

– sind Themen, die auch die Prozessindustrie durchdringen.<br />

Die Namur wählte mit „Integrated <strong>Engineering</strong>“ ein<br />

Software-orientiertes Thema in diesem Jahr. Warum?<br />

KUMPFMÜLLER: Die fortschreitende Digitalisierung und<br />

Vernetzung industrieller Wertschöpfungsprozesse bewirkt<br />

einen Paradigmenwechsel in der Industrie und bietet neue<br />

Produktivitätshebel. Derzeit gibt es einige große Herausforderungen,<br />

wie zum Beispiel die Ressourcenknappheit,<br />

die wir bewältigen müssen. Gleichzeitig zwingt uns der<br />

internationale Wettbewerb gerade aus Low-Cost-Ländern<br />

flexibler, günstiger und schneller qualitativ hochwertiger<br />

zu produzieren. Nur mit modernen Automatisierungssystemen<br />

mit leistungsfähiger Software, offenen <strong>Schnittstellen</strong><br />

in Zusammenarbeit mit <strong>integrierte</strong>m <strong>Engineering</strong> sind<br />

diese Herausforderungen zu bewältigen. Wir müssen die<br />

einzelnen Prozessschritte intelligent vernetzen und damit<br />

den gesamten Produktionsprozess optimieren.<br />

<strong>atp</strong> <strong>edition</strong>: Wie begegnen Branchen wie Chemie und<br />

Pharma diesem Trend, und wie antworten Sie als Anbieter<br />

von Messtechnik und Automatisierung auf die gestellten<br />

Herausforderungen der Prozessindustrie?<br />

EBERLE: Das vernetzte Denken ist Branchen wie Chemie<br />

und Pharma nicht fremd. Betrachten Sie einmal die großen<br />

Verbundstandorte, in denen Stoff- und Produktströme<br />

auf intelligente Weise abgestimmt, koordiniert und integriert<br />

werden. Diese Vernetzung muss noch mehr auf<br />

Daten- und Informationsebene geschehen, doch diese<br />

Vernetzung hat schon begonnen. Längst beeinflussen Informationstechnologie<br />

und Kommunikationswissenschaft<br />

<strong>das</strong> Ingenieurwesen.<br />

KUMPFMÜLLER: Die Sensorik und Aktorik spielt in diesen<br />

Prozessen eine wichtige Rolle, vor allem liefern sie die<br />

Informationen, die <strong>für</strong> eine solche Vernetzung nötig sind.<br />

Daten allein sind dabei wenig hilfreich, sie müssen auch<br />

entsprechend interpretiert werden. Dazu bietet Siemens<br />

leistungsfähige und intelligente Tools über den gesamten<br />

Lebenszyklus einer Anlage, sowohl <strong>für</strong> Automatisierung<br />

als auch Instrumentierung zur Integration von Planung,<br />

Betrieb und Instandhaltung.<br />

Bisher, wurde häufig die Auslagerung ins Ausland gewählt,<br />

um billiger zu produzieren und im Markt zu bestehen. Unsere<br />

Kunden in den Hochlohnländern können jetzt ihre Wettbewerbsnachteile<br />

zum Teil eliminieren, indem sie bei Planung<br />

und Betrieb der Anlagen Kosten und Zeit weiter optimieren.<br />

Damit lassen sich Capex-Kosten reduzieren zugunsten<br />

einer kürzeren Time-to-Market und effizienteren<br />

Produktion. Wir haben diesen Weg <strong>für</strong> uns konkret beziffert:<br />

Wir wollen unsere Kunden dabei unterstützen, die Produkteinführungszeiten<br />

mit Integrated <strong>Engineering</strong> um bis zu<br />

50 % zu verkürzen.<br />

<strong>atp</strong> <strong>edition</strong>: Inwieweit ist die Siemens-Lösung mit der Namur-Empfehlung<br />

NE 139 „Informationsschnittstellen in der<br />

Prozessautomatisierung“ und der NE 150 „Standardisierte<br />

Namur-Schnittstelle zum Austausch von <strong>Engineering</strong>-Daten<br />

zwischen CAE-System und PCS-<strong>Engineering</strong>-Werkzeugen“<br />

konform oder inwieweit verfolgt Siemens eine eigene Lösung?<br />

EBERLE: Die Systemvielfalt in der Prozessindustrie erfordert<br />

Standards Regeln <strong>für</strong> den Datenaustausch und dergleichen.<br />

Mit der Merkmalleisten-Technik der Namur 2012 nach<br />

NE 100/IEC 61987-10 oder jetzt NE 139, NE 150 wurde hier<br />

bereits ein gutes Stück Vorarbeit geleistet.<br />

Die Ideen einer definierten XML-Struktur <strong>für</strong> eine PLT-<br />

Stelle und <strong>das</strong> Mapping passen zum Siemens-Konzept. Es<br />

ist verständlich, <strong>das</strong>s die Namur den erforderlichen Datenaustausch<br />

zwischen verschiedenen CAE- und PLS-<br />

Systemen möglichst offen gestalten möchte. Der Namur-<br />

Datencontainer widerspricht jedoch nicht der Siemens-<br />

Lösung. Im Gegenteil: Wir sehen die Comos/-Simatic-<br />

PCS-Integration als ersten Schritt in Richtung eines<br />

solchen Containers. Schließlich birgt ein elektronischer<br />

Workflow erhebliche Einsparpotenziale, wie lückenlose<br />

Nachverfolgbarkeit, durchgängiges Änderungsmanagement<br />

und die Vermeidung manueller Eingabefehler. Unabhängig<br />

davon, wie eine solche Lösung aussehen wird,<br />

werden wir mit Anwendern und anderen Anbietern eng<br />

beim Thema Standardisierung zusammenarbeiten.<br />

<strong>atp</strong> <strong>edition</strong>: Welchen Vorteil bietet die Integration Comos/<br />

Simatic- PCS- 7 und die konsistente Datenbasis?<br />

KUMPFMÜLLER: Alle Gewerke und Mitarbeiter haben Zugriff<br />

auf eine konsistente Datenbank mit stets aktuellem<br />

Planungsstand. Dadurch lassen sich an den einzelnen Gewerken<br />

Arbeiten parallelisieren. Dies verkürzt die Planungszeiten<br />

und steigert die Projektqualität. In Projekten konnten<br />

bereits deutlich kürzere Inbetriebnahmezeiten nachgewie-<br />

26<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


ECKARD EBERLE UND HANS-GEORG KUMPFMÜLLER freuen sich auf die Zukunft:<br />

Integrated <strong>Engineering</strong> soll mit der Unterstützung von Siemens zu Integrated Operations<br />

ausgebaut werden und die Kunden ganzheitlich im Anlagenmanagement unterstützen.<br />

sen werden. Auch die Dokumentation ist ein wichtiger Faktor.<br />

Jeder Umbau oder Ersatz eines Gerätes vor Ort wird über<br />

den Lebenszyklus dokumentiert. Durch die Bidirektionaliät<br />

hat man nach der Inbetriebnahme stets konsistente Daten<br />

(„as is“ anstatt „as built“), die die Realität widerspiegeln und<br />

nicht Messgeräte enthalten, die vielleicht vorgesehen, aber<br />

doch in anderen Varianten installiert wurden. Das digitale<br />

Anlagenabbild stellt alle Informationen zu Ersatzteilen und<br />

Anlagengegebenheiten oder Wartungsplänen bereit.<br />

EBERLE: Der nächste Schritt mit Comos 10.1 wird die Integration<br />

der Anlagenfunktionsbeschreibung aus dem<br />

Basic <strong>Engineering</strong> in die Realisierung der Automatisierungsfunktion<br />

sein. Dies führt zu einer ganzheitlichen<br />

funktionalen Betrachtung einer Produktionsanlage basierend<br />

auf den Definitionen der ISA 88, besonders wichtig<br />

<strong>für</strong> chargenorientierte Prozesse. Weitere Vorteile des<br />

Integrierten <strong>Engineering</strong>s bestehen in einer gemeinsamen<br />

Nutzung von Computer Aided <strong>Engineering</strong> (CAE) durch die<br />

Verfahrenstechnik und durch die EMSR-Technik. Es gibt<br />

viele Möglichkeiten, einen homogenen Datenfluss von der<br />

verfahrenstechnischen Planung in die Planung der Elektro-<br />

und Automatisierungstechnik herzustellen.<br />

<strong>atp</strong> <strong>edition</strong>: Welche Rolle spielt die Geräteplanung im Anlagenengineering<br />

und wie werden die Gerätedaten in Comos<br />

integriert?<br />

KUMPFMÜLLER: Während früher die Auswahl und Bestellung<br />

der Feldgeräte in Papierform stattfand, werden diese<br />

Arbeitsschritte heute in einen elektronischen Workflow<br />

eingebunden. Es lassen sich alle Siemens-Feldgeräte in<br />

den Planungsprozess über <strong>das</strong> PIA Life Cycle Portal (LCP)<br />

integrieren. Dabei werden in Comos die Auslegungsdaten<br />

und Gerätemerkmale nur einmal erfasst. Die harmonisierten<br />

technischen Daten ermöglichen die Auswahl des optimalen<br />

Gerätes. Schließlich bestimmen neben den elektrischen<br />

Eigenschaften des Verfahrens, die Parameter und<br />

der Einsatzort maßgeblich die Wahl.<br />

<strong>atp</strong> <strong>edition</strong>: Funktioniert <strong>das</strong> PIA LCP nur im Zusammenspiel<br />

mit Comos? Wird es in der Zukunft einen Standard geben?<br />

KUMPFMÜLLER: Das Portal PIA LCP steht jedem Anlagenplaner<br />

zur Verfügung. Allerdings werden die Daten als xls<br />

oder pdf übergeben. Zum zweiten Teil der Frage: Die Standardisierung,<br />

die eine wesentliche Voraussetzung <strong>für</strong> ein<br />

<strong>integrierte</strong>s Anlagenengineering ist, wird bald Realität. Die<br />

bisherige Norm NE100 3.2 ist in den neuen Industriestandard<br />

eClass <strong>für</strong> den Austausch von Betriebs- und Gerätemerkmalen<br />

eingegangen. Wir sehen in eClass die einheitliche<br />

Sprache <strong>für</strong> den harmonisierten Datenaustausch.<br />

Die Vorteile: bessere Vergleichbarkeit, Fehlersicherheit und<br />

Qualität. Die Zeitersparnis bei der Auswertung und Bereitstellung<br />

von technischen Merkmalen bei Geräteauswahl und<br />

Dokumentation liegt bei bis zu 20 %.<br />

<strong>atp</strong> <strong>edition</strong>: Sie sprechen vom ganzheitlichen <strong>Engineering</strong><br />

über den gesamten Lebenszyklus. Welche Vorteile bietet<br />

dabei <strong>das</strong> <strong>integrierte</strong> <strong>Engineering</strong>?<br />

EBERLE: Man muss Anlagen und ihre Komponenten über<br />

den gesamten Lebenszyklus betrachten, insbesondere wenn<br />

man bedenkt, <strong>das</strong>s prozesstechnische Anlagen bis zu 40<br />

Jahren betrieben werden. Durch die Modernisierung der<br />

Automatisierung lassen sich Einsparpotenziale heben, die<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

27


INTERVIEW<br />

die Pumpenüberwachung, die dem Betreiber dabei helfen,<br />

an die richtigen und wichtigen Informationen heran zu kommen<br />

und dann reagieren zu können. Bei der Überwachung<br />

von Aggregaten in Simatic PCS 7 über Condition Monitoring<br />

kann direkt in Comos MRO ein Wartungsauftrag erstellt<br />

oder ausgeführt werden. Wenn also ein Aggregat<br />

eine gewisse Toleranz überschreitet, kann der Instandhalter<br />

aus dem Leitsystem heraus den Wartungsauftrag<br />

wenn es sein muss sogar auf sein Handy bekommen.<br />

„Während die diskrete Automatisierung<br />

längst Ethernet und vor allem Profinet nutzt,<br />

arbeitet die Prozessautomatisierung noch<br />

mit Standards und langsamen Technologien,<br />

<strong>für</strong> die Industrie 4.0 vermutlich nur begrenzt<br />

realisierbar ist.“ HANS-GEORG KUMPFMÜLLER<br />

digitale Anlagendokumentation erleichtert die Pflege erheblich.<br />

Der Betreiber kann auf stets aktuelle Daten inklusive<br />

Dokumentation, Auslegungsdaten und Historie zurückgreifen.<br />

Umgekehrt werden Änderungen der Automatisierung<br />

ins <strong>Engineering</strong> zurückgespielt. Dieser Datenbestand bietet<br />

die optimale Basis <strong>für</strong> die Modernisierung, Erweiterung und<br />

Migration der Anlagen. Aktuelle Daten sind oft gar nicht<br />

dokumentiert oder nicht elektronisch vorhanden. Auch bei<br />

Inbetriebnahme und Tests im Vorfeld wie FAT (Factory Acceptance<br />

Test) gibt es Vorteile. Die Sicherheit von Anlagen<br />

und Mitarbeitern ist in der Prozessindustrie <strong>das</strong> A und O –<br />

deshalb werden Tests an der realen Anlage, die immer mit<br />

gewissen Risiken verbunden sind, zunehmend durch virtuelle<br />

Anlagentests im Rahmen einer Wasserfahrt ersetzt.<br />

Dank der durchgängigen Datenhaltung stehen diese Daten<br />

im Simulations-Tool Simit zur Verfügung.<br />

<strong>atp</strong> <strong>edition</strong>: In der Betriebsphase, die auch die Optimierung<br />

und die Instandhaltung beinhaltet, fallen sehr viele Informationen<br />

an. Wie kann diese Informationsflut noch bewältigt<br />

werden?<br />

EBERLE: Moderne Bedienerplattformen stellen komplexe<br />

Daten so dar, <strong>das</strong>s sie <strong>für</strong> den Menschen einfach zu verarbeiten<br />

sind. Dazu gehört zum Beispiel, <strong>das</strong>s die Informationen<br />

<strong>für</strong> die Inbetriebnahme-Mannschaft, die Anlagenfahrer<br />

und die Instandhaltungs-Abteilung gesondert aufbereitet<br />

werden. Unser Automatisierungssystem berücksichtigt<br />

spezielle HMI+-Konzepte, etwa APG (Advanced Process<br />

Graphics), mit der die Informationsflut mittels Darstellung<br />

von KPIs intelligent verdichtet wird. Dies bildet die Basis<br />

<strong>für</strong> effiziente Prozessführung. Aber auch im Detail tut sich<br />

einiges, wie <strong>das</strong> Beispiel der Instandhaltung zeigt. Hier ändert<br />

sich die Gewichtung hin zu einer prädiktiven (also zustandsbasierten,<br />

vorausschauenden) Instandhaltung anstatt<br />

reaktiv beziehungsweise präventiv (also zyklisch) zu<br />

handeln. Bei uns gibt es entsprechende Lösungen, wie etwa<br />

<strong>atp</strong> <strong>edition</strong>: Stichwort Prozessleitsystem. Wie wird die Datenflut<br />

in der Leittechnik beherrscht? Was bringt die Zukunft in<br />

Bezug auf die Datenautobahn von der Feldebene bis zu MES<br />

oder ERP-Systemen? Wie wichtig ist leistungsfähige Hardware?<br />

EBERLE: Ganz klar, eine gute Software braucht leistungsfähige<br />

Hardware, denn die Anlagestruktur ist ja im Leitsystem<br />

hinterlegt. Mit den neuen Controllern wie zum<br />

Beispiel CPU 410-5H werden die Anforderungen der Prozessindustrie<br />

nach Robustheit, Flexibilität, Schnelligkeit<br />

und Leistung erfüllt. Der Controller kann in unterschiedlichen<br />

Varianten eingesetzt werden. Dabei lässt sich die<br />

Leistung individuell über eine Systemerweiterungskarte<br />

an die Applikation anpassen. Sie bietet zudem alle Funktionen<br />

<strong>für</strong> sicherheitsgerichtete Applikationen – heute<br />

und in Zukunft.<br />

<strong>atp</strong> <strong>edition</strong>: Feldbusse – wo geht die Reise hin?<br />

KUMPFMÜLLER: Während in der diskreten Automatisierung<br />

längst Ethernet und vor allem Profinet Einzug gefunden<br />

haben, arbeitet die Prozessautomatisierung immer<br />

noch mit relativ alten Standards wie, Profibus PA, Hart oder<br />

FF. Zukünftige Möglichkeiten gerade im Rahmen von Industrie<br />

4.0 sind vermutlich mit diesen langsamen Technologien<br />

nur begrenzt realisierbar. Deshalb wird der Wunsch unserer<br />

Kunden nach einer höher performanten Schnittstelle im<br />

Feld stärker. Es gibt noch keine Ideallösung vor allem <strong>für</strong><br />

den Ex-Bereich. Es sollen auch keine unterschiedlichen<br />

neuen Varianten auf den Markt gebracht werden und zur<br />

nächsten Feldbusschlacht führen. Deshalb ist unter den<br />

Herstellern ein gewisser Pragmatismus in den Vordergrund<br />

getreten. Zusammen mit Anwendern arbeitet man Hand in<br />

Hand um eine effektive Lösung, die von der gesamten Prozessindustrie<br />

getragen wird, zu entwickeln. In Zukunft wird<br />

Ethernet, und hier allen voran, Profinet eine interessante<br />

Alternative sein. Die Vorteile dieser Kommunikation wird<br />

auch die Prozessindustrie nutzen. Entsprechende Gespräche<br />

finden ja in den Arbeitskreisen mit der Namur statt.<br />

<strong>atp</strong> <strong>edition</strong>: Wie sieht es mit der Forderung der Anwender<br />

nach einem einheitlichen Standard <strong>für</strong> die einfachere Integration<br />

von Feldgeräten in die Leittechnik aus – Stichwort FDI?<br />

KUMPFMÜLLER: Zur Spezifikation, Normierung und Einführung<br />

von FDI wurde die FDI Cooperation LLC gegründet.<br />

Hier arbeiten führende Herstellerfirmen eng mit Anwendern<br />

zusammen. Ziel ist es, den Einsatz unterschiedlicher<br />

Feldgeräte und ihrer verschiedenen Kommunikationsprotokolle<br />

(FF, HCF, Profibus, Profinet) zu unterstützen. Die<br />

Basis sind offene und standardisierte <strong>Schnittstellen</strong>, die<br />

möglichst viele Systeme unterstützen. FDI vereint die Vorteile<br />

von EDDL und FDT. FDI ist auch in anderer Hinsicht<br />

wegweisend – ohne die enge Zusammenarbeit mit Anwendern<br />

wäre die schnelle Umsetzung unmöglich gewesen. So<br />

28<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


hat die FDI Cooperation auf der vergangenen Namur-Hauptsitzung<br />

die fertig gestellten FDI-Spezifikationen zur Geräteintegration<br />

(Field Device Integration) sowie die Vorabversion<br />

der FDI-Entwicklertoolkits vorgestellt. Damit können<br />

Automatisierungsanbieter die Entwicklung von Produkten<br />

und Host-Systemen vorbereiten, die mit der FDI-Spezifikation<br />

kompatibel sind. Die veröffentlichte Spezifikation und<br />

die harmonisierte EDDL-Spezifikation (Electronic Device<br />

Description Language) wurden an die International Electrotechnical<br />

Commission (IEC) übergeben, was die nächste<br />

bedeutende Phase (Committee Draft for Vote) im internationalen<br />

Standardisierungsprozess einleitet. Die FDI-Spezifikation<br />

wird in den Standard IEC 62769 aufgenommen.<br />

<strong>atp</strong> <strong>edition</strong>: Unter Berücksichtigung der großen Basis von Geräten<br />

mit EDDL und FDT/DTM, wie sieht es bei der neuen vereinheitlichten<br />

Integration mit der (Rück-) Kompatibilität aus?<br />

KUMPFMÜLLER: Sicherlich wird die Umstellung und damit<br />

Marktdurchdringung eine gewisse Zeit dauern. Ich bin aber<br />

überzeugt, <strong>das</strong>s die Migration reibungs- und geräuschlos<br />

vorsich gehen wird. Zur Markteinführung gibt es Software-<br />

Tools, die die Konvertierung der bisherigen EDD’s und<br />

DTM’s einfach und automatisiert möglich macht. Damit<br />

sinkt die Hemmschwelle FDI zu nutzen beträchtlich. In Zukunft<br />

gibt es sicher noch einige Aufgaben zu lösen, wie eine<br />

einheitliche Bedienoberfläche. Aber dem Wunsch der Kunden<br />

wird Rechnung getragen. Wichtig ist uns dabei, <strong>das</strong>s<br />

FDI nicht nur EDDL und FDT/DTM ersetzt, sondern durch<br />

den synergetischen Ansatz der beiden Konzepte die beiden<br />

Welten zusammenbringt.<br />

<strong>atp</strong> <strong>edition</strong>: Stichwort Industrie 4.0. Welche Rolle spielt<br />

Integriertes <strong>Engineering</strong> in Bezug auf Industrie 4.0 und<br />

den Konzepten zur Modularisierung von Anlagen?<br />

KUMPFMÜLLER: Das Stichwort Industrie 4.0 umfasst<br />

viele Themen, dabei ist ganz sicher die Frage, wie Hardund<br />

Software über die gesamte Produktionskette hinweg<br />

noch enger verschmelzen und wie wir die Intelligenz noch<br />

weiter in die Anlagen und ins Feld verlagern können. Ohne<br />

ein <strong>integrierte</strong>s <strong>Engineering</strong> werden diese Konzepte nicht<br />

umsetzbar sein.<br />

EBERLE: Auch der zweite Trend, die Konzepte zur modularen<br />

Automatisierung, ist nur mit Standardisierung und<br />

Betrachtung aller Gewerke realisierbar. Insellösungen<br />

haben kaum eine Chance. Interessant am modularen Automatisierungskonzept<br />

ist, <strong>das</strong>s die Anlage hochkomplex<br />

ist und mit nationalen und internationalen Aufsichtsbehörden<br />

in Einklang gebracht wird. Der Weg zu einer papierlosen<br />

Qualifizierung einer Anlage ist vorgezeichnet –<br />

mit allen seinen Facetten, wie Compliance Druck, Dokumentenmanagementsystem<br />

sowie der regelkonformen<br />

Archivierung. Dateninkonsistenzen an den <strong>Schnittstellen</strong><br />

der Gewerke und Fehler bei der Übertragung fallen umso<br />

schwerer ins Gewicht. Die Vorzüge einer konsistenten Datenbasis:<br />

einmal eingegebene Informationen lassen sich<br />

bereichsübergreifend wiederverwenden.<br />

<strong>atp</strong> <strong>edition</strong>: Die Branchen der Prozessindustrie benötigen<br />

enorme Energiemengen. Vor dem Hintergrund der Energiewende<br />

stellen sich die Fragen nach Energiestabilität und Gestaltung<br />

der Energiepreise. Welchen Beitrag kann Siemens<br />

dazu liefern?<br />

EBERLE: Das Portfolio von Siemens bietet viele Möglichkeiten<br />

die Energieströme transparent zu machen – sei es<br />

Gas, Dampf oder elektrische Energie - und gezielt Maßnahmen<br />

zur Effizienzsteigerung zu ergreifen. Nur wer<br />

weiß, wo Energie verbraucht wird, kann an der Stelle<br />

gezielt eingreifen. Hier<strong>für</strong> bieten wir zuverlässige Messinstrumente<br />

oder Geräte zur Erfassung und Anzeige<br />

sämtlicher elektrischer Verbrauchsmengen. Das Energie-Management-System<br />

B.Data optimiert die Arbeitsabläufe,<br />

indem es alle <strong>für</strong> die Energie- und Energiever-<br />

„Die Konzepte zur modularen Automatisierung<br />

sind nur mit Standardisierung und<br />

Betrachtung aller Gewerke realisierbar.<br />

Integrated <strong>Engineering</strong> und eine konsistente<br />

Datenbasis sind die Basis <strong>für</strong> Industrie 4.0.“<br />

ECKARD EBERLE<br />

sorgung relevanten Prozesse automatisiert. Ferner haben<br />

wir energiesparende Schaltanlagen und Schaltgeräte<br />

sowie Motoren und Frequenzumrichter im Programm.<br />

Die Integration der Mittel- und Hochspannungsschaltanlagen<br />

gemäß IEC 61850 wird über PCS 7 Powercontrol<br />

ermöglicht. Und nicht zuletzt haben wir viele zukunftweisenden<br />

Lösungen zu bieten, die Denkanstöße zum Thema<br />

Energiewende liefern, etwa Consulting im Bereich Energiemanagement<br />

oder effiziente Speicherung von Energie.<br />

<strong>atp</strong> <strong>edition</strong>: Kommen wir zurück zu den langen Laufzeiten<br />

der Anlagen. Welche Rolle spielt der Service?<br />

KUMPFMÜLLER: Das Thema Service wird immer wichtiger,<br />

da die Anwender sich inzwischen auf ihr Kerngeschäft<br />

konzentrieren möchten und auch müssen. Sie<br />

benötigen einen kompetenten Service-Partner, der Vertragssicherheit<br />

bietet aber auch die TCO (Total Cost of<br />

Ownership) über den gesamten Lebenszyklus im Blick<br />

hat. Wir haben den klaren Fokus, die Wirtschaftlichkeit,<br />

die Effizienz, die Qualität und die Transparenz der Anlagen<br />

unserer Kunden zu verbessern. Daher will ich den Begriff<br />

des <strong>integrierte</strong>n <strong>Engineering</strong> zu einem „Integrated Operations“<br />

ausweiten. Das digitale Anlagenabbild über die<br />

gesamte Laufzeit, welches wirklich alle Phasen von <strong>Engineering</strong>,<br />

Betrieb, Optimierung, Erweiterung und Instandhaltung<br />

berücksichtigt, ist die Basis da<strong>für</strong>.<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

29


HAUPTBEITRAG<br />

<strong>Schnittstellen</strong> <strong>für</strong> <strong>das</strong><br />

<strong>integrierte</strong> <strong>Engineering</strong><br />

Wege zu einer schnellen Realisierung<br />

Für Planung und Betrieb von prozesstechnischen Anlagen wird eine Vielzahl von<br />

Software-Werkzeugen verwendet. Der manuelle Austausch und Abgleich der Daten<br />

ist aufwendig und fehlerbehaftet. Das <strong>integrierte</strong> <strong>Engineering</strong> ermöglicht eine effiziente<br />

und konsistente Datenbasis <strong>für</strong> den gesamten Lebenszyklus. In diesem Beitrag<br />

wird gezeigt, <strong>das</strong>s weder eine zentrale Datenbank noch individuelle <strong>Schnittstellen</strong><br />

zwischen allen beteiligten Systemen zum gewünschten Erfolg führen. Vielmehr<br />

wird ein Vorgehen zur schrittweisen Standardisierung vorgeschlagen, <strong>das</strong> auf der<br />

Definition von Objekten und ihren Attributen basiert. Ein kooperativer Standardisierungsansatz<br />

führt zügig zum <strong>integrierte</strong>n <strong>Engineering</strong>.<br />

SCHLAGWÖRTER Integriertes <strong>Engineering</strong> / Schnittstelle / objektorientiert / XML<br />

Interfaces for Integrated <strong>Engineering</strong> –<br />

Ways of quick Realization<br />

During engineering and operation of processing plants a multitude of software tools<br />

is used. A manual exchange and replication of data is laborious and has a high risk of<br />

errors. An Integrated <strong>Engineering</strong> allows an efficient and consistent data base for the<br />

whole plant life cycle. This article shows that neither a central data base nor individual<br />

tool-to-tool interfaces are appropriate. Rather a stepwise standardization is proposed,<br />

basing on the definition of objects and their attributes. A cooperative approach<br />

for standardization seems to enable a rapid realization of Integrated <strong>Engineering</strong>.<br />

KEYWORDS integrated engineering / interface / object oriented / XML<br />

30<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


THOMAS TAUCHNITZ, Sanofi-Aventis Deutschland<br />

Während der Planung und beim Betrieb von<br />

Anlagen der Prozessindustrie werden unterschiedliche<br />

Software-Werkzeuge – im folgenden<br />

<strong>Engineering</strong>-Tools genannt – verwendet.<br />

Diese Werkzeuge nutzen und erzeugen<br />

Daten, die von anderen Tools bereitgestellt beziehungsweise<br />

eingesetzt werden. Bild 1 zeigt eine Auswahl solcher Software-Werkzeuge<br />

aus den Phasen Vorplanung, Basic <strong>Engineering</strong>,<br />

Detail <strong>Engineering</strong>, Errichtung und Betrieb und <strong>für</strong> die<br />

verschiedenen Gewerke wie Verfahrenstechnik, Elektrotechnik<br />

und Automatisierung. Jedes dieser Werkzeuge hat einen<br />

eigenen Datenbestand, in der Regel eine Datenbank.<br />

Unter dem Begriff <strong>integrierte</strong>s <strong>Engineering</strong> wird im<br />

Beitrag verstanden,<br />

1 | <strong>das</strong>s <strong>für</strong> den kompletten Anlagenlebenszyklus nur<br />

ein einziges, zusammenhängendes System von<br />

<strong>Engineering</strong>-Tools verwendet wird,<br />

2 | <strong>das</strong>s die Daten nur ein einziges Mal eingegeben<br />

sowie nur an einer Stelle geändert werden und<br />

3 | <strong>das</strong>s <strong>das</strong> System von <strong>Engineering</strong>-Tools die Konsistenz<br />

aller Daten während des Anlagenlebenszyklus<br />

sicherstellt.<br />

Dieser weitreichende Begriff des <strong>integrierte</strong>n <strong>Engineering</strong><br />

ist deutlich abzugrenzen von Diskussionsbeiträgen<br />

und Veröffentlichungen, die sich zum Beispiel nur mit<br />

dem einmaligen Datentransfer in der Projektphase oder<br />

mit der Schnittstelle zwischen nur zwei Systemen beschäftigen.<br />

Integriertes <strong>Engineering</strong> ist wesentlich mehr<br />

als der Transfer von Kalkulationstabellen!<br />

Auf der Namur-Hauptsitzung 2012 wurde in einem Plenarvortrag<br />

dargelegt, <strong>das</strong>s die Zeit reif ist, <strong>das</strong> <strong>integrierte</strong><br />

<strong>Engineering</strong> zu verwirklichen, siehe [1]. Dieser Beitrag, der<br />

auf einen Plenarvortrag auf der Namur-Hauptsitzung 2013<br />

fußt, enthält konkrete Vorschläge zur Realisierung.<br />

1. ZWEI EXTREME LÖSUNGSANSÄTZE<br />

Zur Realisierung des <strong>integrierte</strong>n <strong>Engineering</strong>s bieten<br />

sich zwei extreme Ansätze an: die Verwendung einer<br />

zentralen Datenbank und die Verwendung vieler direkter<br />

<strong>Schnittstellen</strong> zwischen einzelnen Systemen.<br />

1.1 Zentrale Datenbank mit Werkzeugsuite<br />

Beim Ansatz mit einer zentralen Datenbank würden<br />

alle <strong>Engineering</strong>-Systeme ihre Daten, eventuell nur<br />

die mit anderen Systemen auszutauschenden Daten,<br />

in einem zentralen Datenpool ablegen, siehe Bild 2.<br />

Das lässt sich, zumindest solange ein solcher zentraler<br />

Datenpool keine standardisierten <strong>Schnittstellen</strong><br />

hat, nur im Rahmen einer Werkzeugsuite eines<br />

einzelnen Herstellers oder einer Herstellergruppe<br />

realisieren.<br />

Vorteil wäre, <strong>das</strong>s die <strong>Schnittstellen</strong>problematik<br />

innerhalb der Werkzeugsuite gelöst wäre und damit<br />

weder den Betreiber belastet noch eine Standardisierung<br />

erfordert. Voraussetzung wäre aber, <strong>das</strong>s diese<br />

Werkzeugsuite alle Anforderungen an <strong>Engineering</strong>werkzeuge<br />

dauerhaft abdeckt. Aktuell gibt es wenige<br />

Hersteller so vielseitig aufgestellter <strong>Engineering</strong>werkzeuge,<br />

und es ist nicht zu erwarten, <strong>das</strong>s diese<br />

in absehbarer Zeit alle Anforderungen abdecken<br />

können. Wegen des immensen Aufwands würde eine<br />

solche Lösung nur von wenigen großen Firmen erstellt<br />

werden, was Abhängigkeiten von Monopol beziehungsweise<br />

Oligopol schaffen und durch Ausschalten<br />

des Wettbewerbs eventuell die Fortentwicklung<br />

verlangsamen würde. Es entstünden Werkzeuge<br />

mit kaum beherrschbarer Komplexität. Eine Migration<br />

von bestehenden Daten und Systemen in eine solche<br />

Lösung ist kaum vorstellbar.<br />

1.2 Dezentrale Datenhaltung<br />

Das radikale Gegenmodell zur zentralen Datenbank<br />

ist die strukturelle Beibehaltung des aktuellen Zustands:<br />

Jedes Werkzeug hat seine eigene Datenbank.<br />

Zwischen den Werkzeugen müssten individuelle<br />

<strong>Schnittstellen</strong> geschaffen werden, siehe Bild 3. Vor-<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

31


HAUPTBEITRAG<br />

teil dieser Lösung wäre, <strong>das</strong>s sie die aktuelle Datensituation<br />

einschließt, die Migration von aktuellen<br />

Lösungen wäre also möglich. Die Modularität erlaubt<br />

es, die Komplexität zu beherrschen und sich<br />

<strong>für</strong> die Best-of-Breed-Strategie zu entscheiden: Die<br />

Anwender können die jeweils <strong>für</strong> die Spezialaufgaben<br />

besten Werkzeuge einsetzen, so<strong>das</strong>s der Markt<br />

offen wäre und technischer Fortschritt ermutigt<br />

würde. Die Nachteile dieser Lösung sind offenkundig:<br />

Für jede Kombination von Systemen müssten<br />

individuelle <strong>Schnittstellen</strong> erstellt werden. Genau<br />

an diesem Problem scheitert bisher die Idee eines<br />

<strong>integrierte</strong>n <strong>Engineering</strong>s, und eine Lösung der<br />

<strong>Schnittstellen</strong>problematik ist nicht in Sicht.<br />

2. ANFORDERUNGEN UND GRUNDLAGEN<br />

BILD 1: Überblick <strong>Engineering</strong>-Tools<br />

Ein Konzept <strong>für</strong> <strong>das</strong> <strong>integrierte</strong> <strong>Engineering</strong> muss nach<br />

Meinung des Autors sechs Anforderungen erfüllen:<br />

Zügige Realisierbarkeit im Sinne von ein bis zwei<br />

Jahren, zumindest in den dringendsten Teilen,<br />

allgemein akzeptierter Standard, zu dem<br />

keine konkurrierenden Ansätze entwickelt<br />

werden,<br />

Offenheit <strong>für</strong> Ergänzungen und den technischen<br />

Fortschritt (dies ermöglicht den Start<br />

mit einer 80-Prozent-Lösung),<br />

Unabhängigkeit von Monopolen oder Oligopolen,<br />

beherrschbare Komplexität und<br />

Migrationsmöglichkeit <strong>für</strong> vorhandene Werkzeuge<br />

und Daten.<br />

BILD 2: Zentrale Datenbank <strong>für</strong> alle <strong>Engineering</strong>-Tools<br />

BILD 3: <strong>Schnittstellen</strong> zwischen allen <strong>Engineering</strong>-Tools<br />

2.1 Grundlagen zum Verständnis: XML und Mapping<br />

Zur Beschreibung der zu übertragenden Objekte erscheint<br />

Extensible Markup Language (XML) bestens<br />

geeignet. XML ist gemäß [2] „eine Sprache zur Darstellung<br />

hierarchisch strukturierter Daten in Form<br />

von Textdateien“ und „wird u. a. <strong>für</strong> den plattformunabhängigen<br />

Austausch von Daten zwischen<br />

Computersystemen eingesetzt“. Die in der geplanten<br />

Namur-Empfehlung NE 150 [3] verwendete Darstellung<br />

der Daten einer PLT-Stelle, siehe Bild 4, verwendet<br />

zwar nicht unmittelbar XML, lässt sich jedoch<br />

problemlos damit abbilden.<br />

Mapping, genauer Datenmapping, ist <strong>das</strong> Aufeinanderabbilden<br />

von Elementen zwischen zwei unterschiedlichen<br />

Datenmodellen beziehungsweise Datenbeständen.<br />

Diese Abbildung ist im einfachsten<br />

Fall eins zu eins, wenn dieselbe Information in beiden<br />

Datenbeständen vorliegt und direkt zugeordnet<br />

werden kann. Mapping erlaubt auch kompliziertere<br />

Verknüpfungen und Berechnungen, indem beispielsweise<br />

Maßeinheiten umgerechnet oder Kombinationen<br />

von Information erstellt werden.<br />

32<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


3. SECHS GRUNDIDEEN ZUR<br />

SCHNITTSTELLENDEFINITION<br />

3.1 Nur benötigte Daten übertragen<br />

Jedes <strong>Engineering</strong>-Tools hat einen eigenen Daten-Pool,<br />

in der Regel realisiert über eine Datenbank. Die Daten<br />

lassen sich in zwei Klassen aufteilen:<br />

Transfer-Daten: Das sind alle Daten, die auch von<br />

anderen Werkzeugen benötigt werden und daher<br />

über <strong>Schnittstellen</strong> zu transferieren sind.<br />

Lokale Daten: Dabei handelt es sich um alle übrigen<br />

Daten, die in dem <strong>Engineering</strong>-Tool entstehen<br />

und verwendet werden, aber von anderen<br />

Systemen weder erzeugt noch benötigt werden.<br />

Die Unterscheidung zwischen diesen Datenklassen ist<br />

wichtig, um den Aufwand zu verringern, denn die<br />

<strong>Schnittstellen</strong> und damit die Standardisierung müssen<br />

nur die Transfer-Daten festlegen. Die Lokalen Daten<br />

können auf ihrer Dateninsel verbleiben.<br />

BILD 4: Daten der<br />

PLT-Stelle gemäß<br />

Namur-Empfehlung<br />

NE 150<br />

3.2 Neutrale und private Daten gemeinsam übertragen<br />

Es wäre wünschenswert, <strong>das</strong>s <strong>für</strong> alle Transfer-Daten<br />

von Anfang an Standards vorliegen. Das würde aber<br />

einen vollständigen Abschluss des Standardisierungsprozesses<br />

vor dem ersten Einsatz erfordern und<br />

damit diesen Einsatz verzögern. Außerdem muss im<br />

Lebenszyklus einer Schnittstelle immer wieder mit<br />

Erweiterungen dieser Schnittstelle gerechnet werden,<br />

so<strong>das</strong>s aufgrund unterschiedlicher Versionsstände die<br />

gemeinsame Übertragung von schon standardisierten<br />

und noch nicht standardisierten Daten immer wieder<br />

auftreten wird.<br />

Glücklicherweise gibt es in der modernen <strong>Schnittstellen</strong>technologie<br />

einfache Methoden <strong>für</strong> den gemeinsamen<br />

Transport von standardisierten (neutralen) und<br />

nicht standardisierten (privaten) Daten. Dies wird beispielsweise<br />

im Datenformat AutomationML zum Austausch<br />

von Anlagenplanungsdaten genutzt [4] und<br />

wird in Bild 5 am XML-Beispiel aus der Namur-Empfehlung<br />

NE 150 gezeigt: Der Sender der Daten, <strong>das</strong> R&I-<br />

Werkzeug A, schreibt zusätzliche Daten zur Archivierung<br />

in die XML-Nachricht. Diese Daten sind nicht<br />

standardisiert, also privat. Jetzt hängt es vom Empfänger<br />

ab, ob er diese Daten versteht, weil ihm diese privaten<br />

Objekte bekannt sind, oder nicht. Falls er sie<br />

nicht versteht, bleiben sie uninterpretiert im Speicher,<br />

stören aber die Kommunikation nicht.<br />

Die Idee, private und standardisierte Information<br />

gemeinsam zu übertragen, wird in [5] am Beispiel AutomationML<br />

ausführlich diskutiert und in CAEX 3.0<br />

bereits in die Standardisierung [6] eingebracht. Dabei<br />

werden jedem einzelnen Objekt Attribute über seine<br />

individuelle Quelle mitgegeben, so<strong>das</strong>s der Empfänger<br />

BILD 5: Gemeinsame Übertragung neutraler und privater Daten<br />

BILD 6: Schrittweises Füllen des Objektes PLT-Stelle<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

33


HAUPTBEITRAG<br />

diese privaten Daten der jeweiligen Quelle entsprechend<br />

interpretieren kann.<br />

3.3 Schrittweise Standardisierung<br />

Der Teufelskreis der Standardisierung wird in [7] beschrieben:<br />

Standardisierung, zumindest eine gute, benötigt<br />

Feedback aus dem praktischen Einsatz, und Werkzeughersteller<br />

sowie Kunden warten auf einen Standard,<br />

bevor sie in Tools und Produkte investieren. Dieser Teufelskreis<br />

hat manche Standardisierung um zehn Jahre<br />

verzögert, in Einzelfällen auch verhindert.<br />

Die aufgezeigte Möglichkeit, neutrale und private Daten<br />

gemeinsam zu übertragen, lässt eine schrittweise<br />

Standardisierung zu: Wenn Sender und Empfänger sich<br />

über die Bedeutung privater Daten verständigen, können<br />

erweiterte Datensätze übertragen und interpretiert werden.<br />

Werden diese erweiterten Daten in die Standardisierungsgremien<br />

eingebracht, wandeln sich die anfangs<br />

privaten Daten zu neutralen. So kann die Standardisierung<br />

schnell und relativ schlank beginnen, mit einfachen<br />

und häufig benutzten Elementen, und nach Bedarf weiterwachsen.<br />

Damit wird der Angst begegnet, Standardisierung<br />

würde den Funktionsumfang beschränken, denn<br />

neue Ideen können jederzeit hinzugefügt werden.<br />

Grundlage <strong>für</strong> die schrittweise Standardisierung ist<br />

eine strenge Aufwärtskompatibilität: Definitionen dürfen<br />

immer nur hinzugefügt werden. Löschen und Ändern<br />

von alten Elementen ist streng verboten, weil sich<br />

alte Datensätze sonst nicht mehr lesen lassen.<br />

3.4 Orientierung am Objekt<br />

Im Laufe des <strong>Engineering</strong>-Prozesses wächst die Datenmenge<br />

an. Bei PLT-Stellen werden beispielsweise im<br />

R&I-Schema der PLT-Stellenname sowie Alarmbezeichnungen<br />

vergeben. In der PLT-Stellenplanung kommen<br />

PLS-Signale sowie Feldbusparameter hinzu, im PLS-<br />

<strong>Engineering</strong> schließlich die Reglerparameter. Wenn<br />

Anwender und Systemhersteller nun, um bei diesem<br />

einfachen Beispiel zu bleiben, individuelle <strong>Schnittstellen</strong><br />

von R&I-Werkzeug zum PLT-Planungswerkzeug und<br />

schließlich zum PLS-<strong>Engineering</strong> definieren wollen,<br />

müssen sie festlegen, welche Informationen genau in<br />

welchem Schritt und in welchem System zu erzeugen<br />

sind. Damit würde der Funktionsumfang dieser Werkzeuge<br />

festgeschrieben. Das ist ein unmögliches Unterfangen,<br />

weil die verschiedenen Werkzeuge meist überlappende<br />

Funktionen bieten, und es in der Hand des<br />

Anwenders liegt, wie die Arbeitsabläufe im Detail sind<br />

und was mit welchem Werkzeug gemacht wird.<br />

Der Namur-Arbeitskreis 1.10 PLS-<strong>Engineering</strong> hat bei<br />

der Erarbeitung der Namur-Empfehlung NE 150 eine<br />

bessere Lösung gewählt: Er definiert <strong>das</strong> Objekt PLT-<br />

Stelle, siehe Bild 4, mit allen seinen möglichen Attributen.<br />

Und diese Definition lässt offen, welche Werkzeuge<br />

in welchen Planungsphasen welche Attribute<br />

erzeugen. Bild 6 verdeutlicht, wie <strong>das</strong> Objekt PLT-Stelle<br />

nach und nach gefüllt wird. Deshalb ist es viel einfacher,<br />

sich im Rahmen von Standardisierungsgremien<br />

über den Inhalt von Objekten zu einigen als über die<br />

Frage der Werkzeuge und Planungsphasen.<br />

Dieser Gedanke, Objekte zu definieren, sollte fortgesetzt<br />

und auf andere Objekte der PLT übertragen werden.<br />

So könnten die Einzelregelungen (control module)<br />

und Technische Einrichtungen (equipment module) <strong>für</strong><br />

Chargen-Betriebe gemäß DIN EN 61512 ebenso als Objekte<br />

definiert werden wie Elektroversorgung oder Bussysteme.<br />

Durch die Aufteilung auf unabhängige Objekte<br />

lässt sich die Standardisierung schrittweise und widerspruchsfrei<br />

durchführen.<br />

3.5 Vorhandene Standardisierungsansätze nutzen<br />

Der Wunsch, <strong>Schnittstellen</strong> zwischen <strong>Engineering</strong>-Tools<br />

zu erstellen, ist zwei Jahrzehnte alt und hat viele Standardisierungsansätze<br />

hervorgebracht. Insbesondere sind<br />

zu nennen:<br />

Die Namur-Empfehlung NE 100 [8] legt Merkmalleisten<br />

<strong>für</strong> den PLT-<strong>Engineering</strong>-Workflow fest. Die<br />

Nutzung wurde im Rahmen des Prolist International<br />

e.V. vorangetrieben und ist jetzt an eClass übergegangen<br />

[9].<br />

Automation Markup Language (AutomationML) ist<br />

ein Datenformat <strong>für</strong> den Austausch von Anlagenplanungsdaten,<br />

siehe [4]. Es wurde inzwischen als<br />

IEC 62714-1 [10] standardisiert.<br />

ISO 15926 definiert ein Modell zur Beschreibung<br />

anlagenbezogener Objekte [15].<br />

XMpLant ist ein Datenmodell, ein neutraler Katalog,<br />

der auf ISO 15926 aufsetzt.<br />

Die Initiative Data Exchange in Process Industry<br />

(DEXPI) [16] nutzt ISO 15926 und XMpLant und<br />

arbeitet an einer einheitlichen Vereinbarung zur<br />

Übertragung von R&I-Daten.<br />

Die IEC 62424 [11] schlägt eine Datenmodellierung<br />

der PLT-Stelle inklusive einer Reihe von Attributen<br />

vor.<br />

Angesichts dieser Standardisierungsansätze ist Wert darauf<br />

zu legen, <strong>das</strong> Rad nicht nochmals zu erfinden. Konkurrierende<br />

Standards können nur vermieden werden,<br />

indem vorhandene Standardisierungsansätze genutzt<br />

und integriert werden. Es gibt im Bereich dieser Ansätze<br />

sicher bessere Spezialisten als den Autor, umso wichtiger<br />

ist die breite Zusammenarbeit, um <strong>das</strong> Vorhandene zu<br />

nutzen und vielleicht auch aus Fehlern zu lernen.<br />

Generell ist allerdings zwischen verschiedenen Ansätzen<br />

zu unterscheiden. Zum Teil werden beispielsweise<br />

Sprachen oder Übertragungsmechanismen standardisiert.<br />

Dieser Diskussionsbeitrag strebt vielmehr<br />

an, Dateninhalte festzulegen, also: WAS wird übertra-<br />

34<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


www.<strong>atp</strong>-<strong>edition</strong>.de<br />

Jetzt bestellen!<br />

gen? Die Frage, WIE es übertragen wird, kann getrost<br />

anderen Fachleuten überlassen werden. Das<br />

WAS sollte den Dateninhalt festlegen, der weitgehend<br />

zeitlos (ewig) ist: Auch in 100 Jahren wird es<br />

noch PLT-Stellen geben mit Information wie Signaldaten,<br />

Grenzwerten und Reglerparametern.<br />

Das WIE der Übertragung ist dagegen zeitlich und<br />

wird sich mit dem technischen Fortschritt alle<br />

zehn Jahre ändern.<br />

3.6 Kooperativer Standardisierungsansatz<br />

Der Standardisierung haftet der Ruf an, zäh und<br />

langwierig zu sein. Die Suche nach Konsens, die<br />

Möglichkeit von Einsprüchen und Schlichtungsverfahren,<br />

die häufigen Kämpfe zwischen Interessengruppen,<br />

all <strong>das</strong> macht Standardisierung mühsam.<br />

In wichtigen technischen Bereichen gibt es<br />

allerdings inzwischen kooperative, Internet-basierte<br />

Ansätze zur Standardisierung. Beispielsweise<br />

wird dies in Open-Source-Projekten und zur Weiterentwicklung<br />

des Internets angewandt, siehe [12].<br />

Einen nachhaltigen Impuls <strong>für</strong> die Entwicklung<br />

von Open-Source-Software enthielt der Vortrag „Die<br />

Kathedrale und der Basar“ von Eric S. Raymond, der<br />

1997 gehalten wurde [13]. Die Kathedrale steht <strong>für</strong><br />

den bisherigen Ansatz, <strong>das</strong>s ein einzelner genialer<br />

Architekt einen häufig geheimen Bauplan hat, der<br />

durch eingeweihte Spezialisten ausgeführt wird.<br />

Der Basar steht <strong>für</strong> einen Marktplatz, an dem kreative<br />

Entwickler ihre guten Ideen präsentieren. Die<br />

Entwickler wollen ein persönliches Problem, beispielsweise<br />

ein Projekt, lösen und stellen ihre Ideen<br />

öffentlich zur Verfügung. Alle Entwürfe sind jederzeit<br />

weltweit einsehbar und lizenzfrei, so<strong>das</strong>s die<br />

Patentproblematik entfällt. Eine Person achtet auf<br />

die Einhaltung des Marktrechts (beispielsweise<br />

<strong>das</strong>s keine Parallelentwicklungen geschehen), und<br />

schließlich reicht ein grober Konsens, so<strong>das</strong>s vernünftige<br />

Entscheidungen nicht durch <strong>das</strong> Veto Einzelner<br />

verhindert werden können.<br />

Der Autor schlägt vor, Ideen aus dieser kooperativen<br />

Standardisierungsarbeit zu nutzen, um in<br />

einem Zeitraum von ein bis zwei Jahren schnelle<br />

Erfolge im Sinne von 80-Prozent-Lösungen zu erreichen.<br />

Ob sich auf diesem Weg Grundlagen <strong>für</strong><br />

globale Normen legen lassen, daraus formalisierte<br />

Richtlinien oder de-facto-Standards entstehen,<br />

wird sich zeigen.<br />

Alle Beteiligten in der Prozessindustrie müssten<br />

ein starkes wirtschaftliches Interesse an der Initiative<br />

zur Standardisierung haben:<br />

Die Hersteller von CAE-Systemen könnten den<br />

Leistungsumfang ihrer Systeme <strong>für</strong> die PLS-<br />

Konfiguration erweitern und so <strong>das</strong> Anlagen-<br />

<strong>Engineering</strong> noch vollständiger anbieten.<br />

<strong>atp</strong> <strong>edition</strong> erscheint in der DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München<br />

Die Referenzklasse <strong>für</strong> die<br />

Automatisierungstechnik<br />

<strong>atp</strong> <strong>edition</strong> ist <strong>das</strong> Fachmagazin <strong>für</strong> die Automatisierungstechnik.<br />

Die Qualität der wissenschaftlichen Hauptbeiträge<br />

sichert ein strenges Peer-Review-Verfahren. Bezug zur<br />

automatisierungstechnischen Praxis nehmen außerdem<br />

die kurzen Journalbeiträge aus der Fertigungs- und Prozessautomatisierung.<br />

Sichern Sie sich jetzt diese erstklassige Lektüre! Als<br />

exklusiv ausgestattetes Heft oder als praktisches ePaper<br />

– ideal <strong>für</strong> unterwegs, auf mobilen Endgeräten oder zum<br />

Archivieren.<br />

Wählen Sie einfach <strong>das</strong> Bezugsangebot, <strong>das</strong> Ihnen zusagt:<br />

als Heft, ePaper oder Heft + ePaper!


HAUPTBEITRAG<br />

REFERENZEN<br />

[1] Tauchnitz, T.: Integriertes <strong>Engineering</strong> – wann, wenn nicht jetzt!<br />

<strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische Praxis 55(1-2), S. 46-53, 2013<br />

[2] W3C: Extensible Markup Language (XML). www.w3.org/XML/<br />

[3] NE 150: Standardisierte NAMUR-Schnittstelle zum Austausch von<br />

<strong>Engineering</strong>-Daten zwischen CAE-System und PCS-<strong>Engineering</strong>-<br />

Werkzeugen (noch nicht erschienen)<br />

[4] www.automationml.org/<br />

[5] Drath, R., Barth, M.: Semantikvielfalt mit Automation ML beherrschen.<br />

<strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische Praxis 55(12), S. 72-81, 2013<br />

[6] IEC 62424: Festlegung <strong>für</strong> die Darstellung von Aufgaben der<br />

Prozessleittechnik in Fließbildern und <strong>für</strong> den Datenaustausch<br />

zwischen EDV-Werkzeugen zur Fließbilderstellung und CAE-<br />

Systemen, 2014. www.iec.ch<br />

[7] Drath, R.: Warum ein <strong>Engineering</strong>-Weltmodell bisher nicht gelang.<br />

In: SPS-Magazin Ausgabe 10/2013, S. 55-57<br />

[8] NE 100: Nutzung von Merkmalleisten im PLT-<strong>Engineering</strong>-Workflow.<br />

Namur, 09/2010<br />

[9] eCl@ss e.V. www.eclass.de<br />

[10] IEC 62714-1: FDIS AutomationML Architecture, 2013. www.iec.ch<br />

[11] IEC 62424: Festlegung <strong>für</strong> die Darstellung von Aufgaben der Prozessleittechnik<br />

in Fließbildern und <strong>für</strong> den Datenaustausch zwischen<br />

EDV-Werkzeugen zur Fließbilderstellung und CAE-Systemen, 2008.<br />

www.iec.ch<br />

[12] IETF: Internet <strong>Engineering</strong> Task Force, www.ietf.org<br />

[13] Raymond, E.S.: The Cathedral & the Bazaar. O’Reilly Media, 1999.<br />

[14] Promotorengruppe Kommunikation der Forschungsunion Wirtschaft<br />

– Wissenschaft (Hrsg.) Umsetzungsempfehlungen <strong>für</strong> <strong>das</strong> Zukunftsprojekt<br />

Industrie 4.0, April 2013<br />

[15] ISO 15926: Industrial automation systems and integration—Integration<br />

of life-cycle data for process plants including oil and gas production<br />

facilities - Part 2: Data model, 2003<br />

[16] DEXPI: Data exchange with ISO 15926. www.dexpi.org<br />

AUTOR<br />

Dr.-Ing. THOMAS TAUCHNITZ (geb. 1957)<br />

studierte in Hannover Elektrotechnik<br />

und promovierte im Bereich der<br />

Regelungstechnik. Bei Sanofi-Aventis<br />

Deutschland GmbH leitet er die <strong>Engineering</strong>-Gruppe<br />

der Abteilung Technologie<br />

in der Site Frankfurt Pharma.<br />

Er ist Vorstandsmitglied der Namur.<br />

Arbeitsschwerpunkte sind Prozess- und<br />

Betriebsleitebene sowie <strong>Engineering</strong>-Systeme.<br />

Sanofi-Aventis Deutschland,<br />

H600 – SFP-PG6, D-65926 Frankfurt am Main,<br />

Tel. +49 (0) 69 305 41 94,<br />

E-Mail: Thomas.Tauchnitz@Sanofi.com<br />

Die Anlagenbetreiber könnten über die Schnittstelle<br />

ihre wertvolle Automatisierungslösung unabhängig<br />

vom jeweiligen Automatisierungssystem<br />

sichern und auf neue Systeme und Anlagen übertragen.<br />

Die datentechnische Integration zwischen<br />

Planungs- und Betriebsphase wäre endlich verlustfrei<br />

gesichert.<br />

Die Anbieter von Automatisierungssystemen<br />

könnten von den erleichterten Migrationen profitieren:<br />

Der durch die Angst vor riskanten Migrationen<br />

entstandene Innovationsstau ließe sich abbauen,<br />

neue Funktionen und Produkte würden<br />

ihren Markt finden.<br />

Die <strong>Engineering</strong>-Kontraktoren und Systemintegratoren<br />

könnten ihre eigenen, effizienten Werkzeuge<br />

verwenden und am Projektende die erzeugten Daten<br />

problemlos in die Systeme der Anlagenbetreiber<br />

übertragen.<br />

Die Initiative Industrie 4.0 setzt „durchgängiges<br />

System <strong>Engineering</strong> über die gesamte Wertschöpfungskette“<br />

[14] voraus, insofern sind die Träger der<br />

Plattform Industrie 4.0 (ZVEI, VDMA und Bitcom)<br />

betroffen.<br />

ZUSAMMENFASSUNG<br />

Im Vorjahr wurde in [1] <strong>für</strong> die Realisierung eines <strong>integrierte</strong>n<br />

<strong>Engineering</strong> motiviert und postuliert: „Wann,<br />

wenn nicht jetzt!“. Nach vielen Gesprächen, insbesondere<br />

zur Vorbereitung der Namur-Hauptsitzung 2013,<br />

wurden Wege erkannt, auf denen die Realisierung innerhalb<br />

weniger Jahre möglich erscheint. Zwei radikale<br />

Ansätze, die zentrale Datenhaltung und die Standardisierung<br />

individueller Werkzeug-<strong>Schnittstellen</strong>, wurden<br />

als Sackgassen erkannt. Auf Basis zweier bekannter<br />

Technologien, XML und Datenmapping, wurden dann<br />

sechs Grundideen entwickelt, die es möglich machen,<br />

<strong>das</strong> <strong>integrierte</strong> <strong>Engineering</strong> zu realisieren.<br />

Am Rande der Namur-Hauptsitzung fand ein Treffen<br />

zwischen ausgewählten Namur-Mitgliedsfirmen, Systemanbietern,<br />

CAE-Anbietern und Verbänden statt, bei<br />

dem <strong>das</strong> Konzept diskutiert wurde. Dazu ist inzwischen<br />

der GMA-Fachausschuss 6.16 Integriertes <strong>Engineering</strong><br />

in der Prozessleittechnik eingerichtet worden.<br />

Der Autor verdankt die in diesem Beitrag dargestellten<br />

Ideen auch dem Gedankenaustausch mit den Kolleginnen<br />

beziehungsweise Kollegen Christmann, Engelhard,<br />

Morr, Zgorzelski (alle Bayer Technology Services),<br />

Maier, Pelz (Clariant), Scherwietes, Stienemeier (Evonik),<br />

Fay (HSU-HH), Manske (Merck), Bauer, Elo,<br />

Fernandez, Forstner, Haus, Kempf, Lorenz, Rougoor,<br />

Spitzer, Stolz (Siemens), Schöler (Wacker), Drath (ABB),<br />

sowie seinem Sohn Johannes Tauchnitz.<br />

MANUSKRIPTEINGANG<br />

03.12.2013<br />

Im Peer-Review-Verfahren begutachtet<br />

36<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


Rund um die Uhr<br />

erstklassig informiert<br />

• <strong>das</strong> innovative Online-Medium<br />

• Nachrichten gezielt recherchieren<br />

• die ideale Ergänzung zu <strong>atp</strong> <strong>edition</strong><br />

www.<strong>atp</strong>info.de<br />

Automatisierung<br />

auf den Punkt<br />

Noch schneller informiert mit dem Newsletter <strong>atp</strong>!update<br />

Jetzt <strong>für</strong> den Newsletter anmelden:<br />

www.<strong>atp</strong>info.de/newsletter<br />

• <strong>atp</strong> <strong>edition</strong><br />

• Branche<br />

• Veranstaltungen<br />

• Forschung<br />

• Produkte<br />

update


HAUPTBEITRAG<br />

Der Prolist-Workflow<br />

im eClass-Umfeld<br />

Klassen und Merkmalleisten im Anlagenlebenszyklus<br />

In den Lebenszyklusphasen der Produktionsanlagen der Prozessindustrie arbeiten<br />

unterschiedliche Funktionen zusammen. Das Prolist-Merkmalleistenlexikon <strong>für</strong><br />

Prozessautomatisierungskomponenten ermöglicht einen automatisierten Datenaustausch<br />

zwischen den einzelnen Gewerken. Trotz der Vorteile scheint der Einstieg in<br />

die Technologie schwer, doch die Einstiegshürden lassen sich senken. Der Beitrag<br />

schildert, wie FDI, <strong>integrierte</strong>s <strong>Engineering</strong> und Industrie 4.0 neue Anwendungen<br />

bringen werden. Die Verlagerung der Prolist-Aktivitäten zu eClass sichert die Zukunft<br />

der Merkmalleistentechnologie.<br />

SCHLAGWÖRTER eClass / Prolist / <strong>Engineering</strong> / Prozessautomatisierung /<br />

Merkmalleisten<br />

The Prolist Workflow in the eClass Environment –<br />

Use Cases for Classes and Lists of Properties regarding common Plant Life Cycles<br />

Different functions cooperate during the life cycles of production facilities of the<br />

process industries. The Prolist dictionary of list of properties for process automation<br />

devices enables an automated data exchange between the different sections. In spite<br />

of the advantages, difficulties seem to exist applying this technology, however<br />

they might be overcome. FDI, Integrated <strong>Engineering</strong> and Industry 4.0 will open new<br />

applications. The transfer of the Prolist-activities to eClass will guarantee the future<br />

availability of the lists of properties.<br />

KEYWORDS eClass / prolist / engineering / process automation / lists of properties<br />

38<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


JÜRGEN GEORGE, Pepperl+Fuchs<br />

Einrichtungen der Produktionsanlagen in der<br />

Prozessindustrie, zum Beispiel Öfen, Reaktoren<br />

und Rohrleitungen, werden mit den Mitteln<br />

der Prozessleittechnik gesteuert, geregelt<br />

und gesichert. Die eingesetzten Messgeräte,<br />

Ventile, Steuer-, Regel- und Anzeigegeräte, Stromversorgungseinrichtungen<br />

und so weiter werden in technischen<br />

Spezifikationen durch Merkmale beschrieben<br />

und als Stammdaten in den Datenbanken der an den<br />

Lebenszyklen der Anlagen beteiligten Workflow-Partner<br />

abgelegt. Für die Errichtung werden die Geräte geplant,<br />

beschafft, montiert und in Betrieb genommen.<br />

Das Ergebnis dieses <strong>Engineering</strong>prozesses ist eine umfassende<br />

Anlagen-Dokumentation.<br />

Das <strong>Engineering</strong> bestimmt entscheidend die verschiedenen<br />

Lebenszyklusphasen der Produktionsanlagen der<br />

Prozessindustrie. Unterschiedliche Partner, Gewerke<br />

und Funktionen wickeln diese Prozesse ab. Ein vielfältiger<br />

Austausch von Daten beziehungsweise Information<br />

ist die notwendige Folge. Die Arbeiten werden rechnergestützt<br />

durchgeführt, aber der Austausch der Daten geschieht<br />

weitgehend händisch, also per Post, Fax, allenfalls<br />

per E-Mail und selten in maschinenlesbarer Form.<br />

In der Bürokommunikation ist ein elektronischer Datenaustausch<br />

zwischen unterschiedlicher Anwendungssoftware<br />

schon lange üblich. Excel versteht Word-Daten und<br />

-Objekte, systemübergreifend kann Lotus MS-Office-<br />

Daten verarbeiten. Aber <strong>das</strong> Vertriebssystem des Geräteherstellers<br />

kann die Daten aus dem CAE-System des<br />

Planers nicht verarbeiten, auch <strong>das</strong> Instandhaltungssystem<br />

des Betreibers bleibt außen vor. Mehrfacheingaben<br />

mit der Wahrscheinlichkeit von Abschreib- und Kopierfehlern<br />

werden in Kauf genommen, vom Aufwand nicht<br />

zu reden. Eine konsistente Datenhaltung über die Gewerke<br />

hinweg gibt es nicht. Dieses anachronistische Abschreiben<br />

ist nicht mehr Stand der Technik.<br />

1. WORKFLOW MIT MASCHINENLESBAREN DATEN<br />

Genau hier setzten bereits 2004 die gemeinsamen Arbeiten<br />

der Namur und des Zentralverbandes Elektrotechnik-<br />

und Elektronikindustrie (ZVEI) an, die später<br />

unter dem Logo Prolist zusammengefasst wurden und<br />

deren Ergebnisse heute beim eClass e.V. verfügbar sind<br />

[1, 2]. Im Kern geht es um einen elektronischen Datenaustausch<br />

zwischen unterschiedlichen Rechnersystemen<br />

beziehungsweise unterschiedlicher Software oder<br />

Werkzeuge in einer Weise, <strong>das</strong>s die jeweilige Software<br />

die Daten verarbeiten kann. Es geht um den automatisierten<br />

Austausch von Informationen, die von Maschinen<br />

verstanden werden können. Dazu bedarf es zunächst<br />

einer normierten Schnittstelle <strong>für</strong> den Datenaustausch.<br />

Im gegebenen Fall ist dies ein XML-Format,<br />

siehe Bild 1. Der Austausch der Daten ist die Voraussetzung,<br />

jedoch müssen die Systeme die Daten interpretieren<br />

können, sie müssen aus ihnen die Informationen<br />

herauslesen. Dies ermöglicht eine gemeinsame<br />

Sprache, wie sie im Prolist-Lexikon in Form von Merkmalleisten<br />

festgeschrieben ist. Darin sind die Merkmalleisten<br />

<strong>für</strong> Prozessautomatisierungskomponenten<br />

definiert und in eClass 8.0ff, Prolist NE 100 und IEC<br />

61987 standardisiert [3, 4].<br />

In entsprechend verabredeten Arbeitsabläufen (Workflow),<br />

lassen sich damit in allen Lebenszyklusphasen<br />

einer Anlage die auslegungsrelevanten Daten <strong>für</strong> Prozessautomatisierungsgeräte<br />

systemübergreifend zwischen<br />

den Gewerken automatisiert austauschen. Die<br />

Idee ist, die Daten nur einmal zu erzeugen und an dieser<br />

Stelle auch die Änderungen im Laufe der Lebenszyklen<br />

auf einfache und sichere Weise zu dokumentieren.<br />

Die so erzeugte Information wird von den Werkzeugen<br />

aller Partner genutzt.<br />

2. ANLAGENLEBENSZYKLEN<br />

Die Lebenszyklusphasen einer Produktionsanlage der<br />

Prozessindustrie können unterschiedlich definiert werden.<br />

Einen ganzheitlichen Ansatz zeigt Tabelle 1, die<br />

aufzeigt, wer in welcher Lebensphase beteiligt ist.<br />

Meist laufen die Geschäftsprozesse wie in Bild 2 dargestellt<br />

und in den folgenden Abschnitten detailliert<br />

beschrieben ab.<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

39


HAUPTBEITRAG<br />

BILD 1: Austausch maschinenlesbarer Daten<br />

Beteiligte Partner<br />

BILD 2: Geschäftsprozesse und Datenaustausch<br />

Planer<br />

Betreiber/Einkauf<br />

Hersteller/<br />

Vertrieb<br />

Betreiber/<br />

Instandhaltung<br />

Hersteller/<br />

After Sales Service<br />

Planung: Anfrage und Angebot x x<br />

Planung: Bestellung x x x<br />

Planung: Abschluss und<br />

Inbetriebnahme<br />

After Sales Service x x<br />

Instandhaltung: Ersatzteilanfrage x x<br />

Instandhaltung: Ersatzteilbestellung x x x<br />

Planung: Erweiterung x x<br />

x<br />

x<br />

TABELLE 1: Lebenszyklusphasen einer Produktionsanlage<br />

und beteiligte Partner<br />

BILD 3: Klassen und Merkmalleisten <strong>für</strong> einen<br />

Coriolis-Durchflussmesser in Ausschnitten<br />

2.1 Planung: Anfrage und Angebot<br />

Wenn ein Betreiber eine neue Anlage errichten lässt,<br />

beauftragt er in ihrer ersten Lebenszyklusphase seine<br />

eigene Abteilung oder einen externen Dienstleister<br />

mit der Planung der Anlage. An seinem CAE-System<br />

spezifiziert der Planer die Prozessautomatisierungsgeräte,<br />

die er einzusetzen gedenkt und schickt die<br />

Spezifikationen als technische Anfrage an einen Hersteller<br />

solcher Komponenten. Dessen Vertrieb nutzt<br />

ein Vertriebssystem, mittels dessen der Vertriebssachbearbeiter<br />

Zugriff auf die Produktdatenbank hat, aus<br />

der er geeignete Geräte auswählt. Als technisches<br />

Angebot übermittelt er deren Daten dem Planer. Hersteller<br />

und Planer arbeiten mit hochfunktionalen<br />

Rechnersystemen, die meist innerhalb der Häuser<br />

weiter vernetzt sind, so ist <strong>das</strong> Vertriebssystem des<br />

Herstellers mit seiner Produktdatenbank, die wiederum<br />

auf die Entwicklungsdatenbank aufsetzt, verbunden.<br />

Trotzdem geschieht der Datenaustausch zwischen<br />

dem CAE-System des Planers und dem Vertriebssystem<br />

des Herstellers überwiegend mit Papier,<br />

allenfalls als E-Mail-Text, jedenfalls nicht in Form<br />

von maschinenverarbeitbaren Daten.<br />

Die Spezifikation wird aus dem CAE-System ausgedruckt<br />

und dem Hersteller gefaxt, der dann im technischen<br />

Angebot <strong>das</strong> Gerätedatenblatt dem Planer<br />

zurück faxt. Dieser muss es dann händisch in sein<br />

CAE-System eingeben. Bei der Vielzahl der eingeplanten<br />

Geräte sind Abschreibfehler zu erwarten. Mit<br />

einem automatisierten Datenaustausch kann dagegen<br />

<strong>das</strong> Vertriebssystem des Herstellers, eine entsprechende<br />

Schnittstelle vorausgesetzt, die Spezifikation<br />

aus dem CAE-System lesen und aus der angeschlossenen<br />

Produktdatenbank eine Vorauswahl der Geräte<br />

treffen. Praktisch auf Tastendruck schickt der Vertriebsmitarbeiter<br />

deren Daten als technisches Angebot<br />

in <strong>das</strong> CAE-System zurück. Dies präsentiert dem<br />

40<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


Planer einen automatischen Vergleich der Anfragemit<br />

den Angebotsdaten, wobei die Unterschiede markiert<br />

sind und nur diese Merkmale bedacht werden<br />

müssen. Passen die Daten, übernimmt sie der Planer<br />

per Tastendruck in seine Dokumentation, effizient<br />

und fehlerfrei.<br />

der Bestellung vorgeschaltet. Nach Lieferung der neuen<br />

Geräte, mit Datenblatt wie geliefert, werden sie<br />

eingebaut und in Betrieb gesetzt. Die Arbeitsabläufe<br />

dieser Phasen ähneln denen der Planung, sie werden<br />

aber vom Instandhaltungssystem aus gesteuert anstatt<br />

vom Planungssystem.<br />

2.2 Planung: Bestellung und Beschaffung<br />

Nach Abschluss der Detailplanung ist die endgültige<br />

Spezifikation der Komponenten Bestandteil der Bestellung.<br />

Die Geräte werden beschafft. Bei der Lieferung<br />

gibt der Hersteller seinen Geräten eine Dokumentation<br />

der Daten wie geliefert (as built) mit. Geschieht dies<br />

maschinenlesbar, kann die Dokumentation im Planungssystem<br />

auf einfachste Weise und sicher auf den<br />

realen Stand gebracht werden.<br />

2.3 Inbetriebnahme<br />

Änderungen während der Inbetriebnahme, die bespielsweise<br />

den Messbereich und andere Parameter<br />

betreffen, werden beim Prolist-eClass-Workflow automatisch<br />

dokumentiert. Nach dem erfolgreichen Abschluss<br />

seiner Arbeiten übergibt der Planer die Daten<br />

der Anlage, zumindest was die Prozessautomatisierungsgeräte<br />

angeht, nicht mehr in Form einer Bibliothek<br />

von Ordnern an die Betriebsbetreuung und Instandhaltung,<br />

sondern einfach durch Übermittlung im<br />

elektronischen Format. Voraussetzung ist, <strong>das</strong>s deren<br />

Systeme die Daten ebenfalls interpretieren können, also<br />

über geeignete <strong>Schnittstellen</strong> verfügen.<br />

2.4 After Sales Service<br />

Während des jahrzehntelangen Betriebs der Anlage<br />

versorgt der After Sales Service den Betreiber mit aktueller<br />

Information über die Lieferbarkeit der eingesetzten<br />

Komponenten und gegebenenfalls über anwendbare<br />

Alternativen. Durch einfaches Einlesen hält<br />

die Instandhaltung ihre Datenbank stets auf dem neusten<br />

Stand.<br />

2.5 Instandhaltung: Ersatzteilmanagement<br />

Es ist wahrscheinlich, <strong>das</strong>s die Originalgerätetypen<br />

nach einigen Jahren nicht mehr lieferbar sind. Für<br />

die Ersatzbeschaffung ist es ist hilfreich, und es verkürzt<br />

die Reparaturzeit der Anlage deutlich, wenn<br />

dem Hersteller die exakten Spezifikationen der ursprünglichen<br />

Planung und der tatsächlich eingesetzten,<br />

jetzt defekten oder verschlissenen Geräte übermittelt<br />

werden können. Bei teureren oder kritischen<br />

Komponenten wird meist eine technische Anfrage<br />

2.6 Erweiterungsplanung<br />

Die langlebigen Anlagen unterliegen ständigen Änderungen<br />

und Erweiterungen. Wenn der damit befasste<br />

Planer den elektronisch gestützten Workflow nutzt,<br />

kann er durch einen Upload aus dem Instandhaltungssystem<br />

den Istzustand der Anlage auf einfache Weise<br />

in sein CAE-System einlesen und zur Grundlage seiner<br />

Arbeit machen. Die Änderungs- oder Erweiterungsplanung<br />

läuft dann wie bei der ursprünglichen<br />

Planung ab.<br />

3. MERKMALLEISTEN UND KLASSEN<br />

Die im Beitrag dargestellten Lebenszyklusphasen sind<br />

als Beispiel zu betrachten. Es ist möglich, <strong>das</strong>s der Anwender<br />

<strong>für</strong> sich andere Lebenszyklusphasen definiert<br />

und in anderen Workflows arbeitet. Die Effektivierung<br />

der Arbeitsabläufe durch einen maschinenverarbeitbaren<br />

Datenaustausch mit Merkmalleisten ist aber<br />

prinzipiell gegeben. Andererseits arbeiten nicht alle<br />

beteiligten Funktionen mit Merkmalleisten. Die Beschaffung<br />

wird die technische Spezifikation des Planers<br />

nicht verändern, sondern sie einfach dem Hersteller<br />

weiterleiten. Ein Lieferant, zum Beispiel ein Großhändler,<br />

wird <strong>das</strong> Datenblatt des Herstellers ebenfalls<br />

inhaltlich nicht verändern, sondern die Daten in seinen<br />

Katalog übernehmen. Da diese Funktionen unterschiedliche<br />

Dinge beschaffen beziehungsweise liefern,<br />

brauchen sie eine klare Produktklassifizierung, wie sie<br />

eClass zur Verfügung stellt. Im Beispiel in Bild 3 ist<br />

<strong>für</strong> einen Coriolis-Massedurchflussmesser ein kleiner<br />

Ausschnitt aus den Merkmalleisten mit ihrer Blockstruktur<br />

gezeigt. Auch <strong>das</strong> Kardinalitätsprinzip ist<br />

erkennbar. Wird beispielsweise im CAE-System <strong>das</strong><br />

Merkmal Anzahl der Signalkanäle auf 3 gesetzt, so<br />

erscheint der darunter stehende Block Signalkanal<br />

dreimal und kann jeweils etwa <strong>für</strong> die Spezifikation<br />

der Messungen von Massestrom, Druck und Temperatur<br />

genutzt werden.<br />

Andererseits ist auch <strong>für</strong> die Beschaffung eine prägnante<br />

Aussage zum Gerät erkennbar. Aus der Klassifizierung<br />

27-20-04-02 Durchflussmesser (Masse-,<br />

Coriolis) geht hervor, <strong>das</strong>s es sich um ein Messgerät<br />

<strong>für</strong> Durchfluss und Menge (Gruppe 27-20-04), also<br />

eine Komponente <strong>für</strong> die Messtechnik, Prozessmesstechnik<br />

(Hauptgruppe 27-20) aus dem Bereich Elektro-,<br />

Automatisierungs- und Prozessleittechnik (Klasse<br />

27) handelt. Mit diesem ganzheitlichen Ansatz<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

41


HAUPTBEITRAG<br />

bietet eClass allen beteiligten Funktionen die Hilfsmittel<br />

<strong>für</strong> einen effizienten, gewerkeübergreifenden<br />

Workflow [5].<br />

4. GEGENWÄRTIGE ANWENDUNGEN<br />

Den optimalen Nutzen generieren alle am Workflow beteiligten<br />

Partner, wenn die Technologie mit maschinenlesbaren<br />

Merkmalleisten möglichst flächendeckend<br />

angewendet wird. Der Betreiber und sein Planer können<br />

dann Partner unter vielen Herstellern und Lieferanten<br />

und unter unterschiedlichen Gewerken auswählen und<br />

in ihren jeweiligen automatisierten Workflow einbinden.<br />

Der Hersteller kann seine Geschäftsprozesse mit seinen<br />

Kunden automatisieren und optimieren. Dabei bedient<br />

er nur eine einzige Schnittstelle <strong>für</strong> den Austausch der<br />

<strong>Engineering</strong>daten.<br />

Wacker Chemie und Evonik hatten die Entwicklung<br />

der Merkmalleisten <strong>für</strong> die Geräte der Prozessautomatisierung<br />

aktiv vorangetrieben und sie auch angewendet.<br />

Andere, darunter Bayer Technology Services, hatten<br />

Piloterprobungen durchgeführt. Im großen Rahmen<br />

hat die BASF in Kooperation mit Rösberg die Nutzung<br />

der Merkmalleisten eingeführt, dessen CAE-System<br />

Prodok eine Prolist-NE-100-Schnittstelle besitzt. Ausgewählte<br />

Hersteller waren und sind in den Workflow<br />

eingebunden.<br />

Was aber sind die Ursachen, <strong>das</strong>s trotzdem von<br />

einem flächendeckenden Einsatz nicht die Rede sein<br />

kann? Es ist zum einen ein Henne-Ei-Problem: Die<br />

Planer und Betreiber fordern, <strong>das</strong>s die gängigen CAE-<br />

Systemhäuser in Vorleistung gehen und eine passende<br />

Schnittstelle in ihren Systemen bereitstellen. Die<br />

Systemhäuser wollen ihre dazu notwendigen Entwicklungsarbeiten<br />

absichern und warten auf konkrete<br />

Auftragsprognosen. Bei den Beziehungen zwischen<br />

Betreibern und Herstellern sieht es ähnlich aus. So<br />

scheinen sich die Partner im Kreis zu drehen und erreichen<br />

nicht <strong>das</strong> Stadium der Anwendung. Zum anderen<br />

müssen die nach den bisherigen Gegebenheiten<br />

optimierten Arbeitsabläufe zumindest punktuell verändert<br />

werden, teilweise muss die Bedienung neuer<br />

Software verinnerlicht werden. Dazu bedarf es einiger<br />

Investitionen und vor allem auch Arbeitszeit, um die<br />

neue Technologie einzuführen. Das geht nur Topdown!<br />

Geld muss bereitgestellt werden und die Mitarbeiter<br />

müssen einen angemessenen Aufwand zur<br />

Einführung leisten dürfen. Meist wird ferner ein gewisses<br />

Risiko gesehen, <strong>das</strong>s die Lernphase die Abwicklung<br />

der laufenden Projekte behindert. Professor<br />

Ahrens, der ehemalige Geschäftsführer des Prolist-<br />

Vereins hat einmal die Analogie zur Einführung der<br />

CAD-Systeme gezogen: „Ich kann kein CAD-System<br />

einführen, da ich schnellstens mein laufendes Projekt<br />

am Reißbrett fertig stellen muss.“ Das Reißbrett ist<br />

heute nicht mehr vorstellbar, letztendlich setzen sich<br />

vorteilhafte Technologien durch.<br />

5. VEREINFACHTER EINSTIEG<br />

Die Einstiegshürden zur Nutzung der Merkmalleistentechnologie<br />

sind deutlich niedriger, wenn nicht in<br />

einem Schlag über alle Lebenszyklen der Anlage und<br />

alle Partner hinweg der Workflow verändert wird. Die<br />

Abdeckung konkreter, singulärer Anwendungsfälle<br />

bringt zwar zunächst weniger Effizienzgewinn, aber<br />

dieser lässt sich schneller und einfacher realisieren. Es<br />

sind weniger Veränderungen in den Arbeitsabläufen<br />

notwendig, und am Anfang sind weniger Partner involviert.<br />

Wichtig ist eine migrierende Einführung mit verringertem<br />

Zeitaufwand.<br />

5.1 Instandhaltungsszenario<br />

Ein solcher Hotspot ist <strong>das</strong> Ersatzteilmanagement und<br />

in weiterer Sicht die Instandhaltung. Im Prinzip sind<br />

die Vorgänge oben in der Beschreibung der Lebenszyklusphasen<br />

Instandhaltung (Abschnitt 2.5) und<br />

Erweiterungsplanung (2.6) enthalten, sie sollen nun<br />

vertieft werden: Angenommen, ein externer Dienstleister<br />

kann den Auftrag <strong>für</strong> eine existierende Anlage<br />

bekommen. Für sein Angebot braucht er detaillierte<br />

Kenntnis über die Anlage und ihre Einrichtungen, je<br />

profunder desto exakter wird sein Angebot ausfallen<br />

und desto geringer ist <strong>das</strong> Risiko, <strong>das</strong> er mit der Übernahme<br />

der fremden Anlage eingeht. Der Business<br />

Case rechnet sich nur, wenn er mit geringeren Kosten<br />

als der Betreiber arbeitet und noch ausreichend Gewinn<br />

erzielt. Das bedeutet, seine Instandhaltungsdienstleistung<br />

muss weitgehend automatisiert und<br />

rechnergestützt durchgeführt werden. Wahrscheinlich<br />

kann der Betreiber die Daten der Anlage im Planungszustand<br />

bereitstellen, aber wurde sie auch so in<br />

Betrieb genommen? Welche Veränderungen wurden<br />

im Laufe der Zeit vorgenommen und sind diese nachvollziehbar<br />

dokumentiert worden? Natürlich hat der<br />

Betreiber alles in seinen Ordnern abgelegt, aber ist die<br />

Information zentral festgehalten, einfach zu finden<br />

und gab es wirklich keine Zettelwirtschaft während<br />

der Inbetriebnahme?<br />

Wenn die Anlage entsprechend dem Prolist-Workflow<br />

errichtet und betrieben worden wäre, läge die Information<br />

über alle Prozessautomatisierungsgeräte elektronisch,<br />

tagesaktuell und wohlgeordnet im Instandhaltungssystem<br />

des Betreibers. Bei dem beschriebenen<br />

Szenario mit einem externen Instandhalter wird die<br />

Aufgabenstellung besonders deutlich. Vergleichbares<br />

gilt <strong>für</strong> die interne Instandhaltung. Auch sie muss effizient<br />

arbeiten, die Mitarbeitzahl ist beschränkt. Trotzdem<br />

müssen zunehmend mehr Aufgaben erledigt werden.<br />

Es besteht kein prinzipieller Unterschied zwischen<br />

Neu- und Altanlagen. In beiden Fällen erhält die Instandhaltung<br />

nach der Inbetriebnahme die Anlagendokumentation<br />

vom Planer, allerdings wächst im Laufe<br />

der Zeit die Zahl der Änderungen, auf deren Protokol-<br />

42<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


lierung zugegriffen werden muss. Die Frage ist also, wie<br />

einfach sich der reale Stand der Prozessautomatisierungskomponenten<br />

in einer existierenden Anlage erhalten<br />

lässt.<br />

5.2 Migration mittels Ersatzgerätedaten<br />

Der einfachste Einstieg scheint zu sein, <strong>das</strong>s der Anwender<br />

von den Lieferanten die Daten der Ersatzgeräte<br />

(wie geliefert) in maschinenlesbarer Form anfordert,<br />

zur Verfügung gestellt bekommt und in sein Instandhaltungssystem<br />

einliest. So würde im Laufe der Zeit<br />

ein Archiv mit den maschinenlesbaren Gerätedaten<br />

entstehen, aufwandsarm und mit minimalen Kosten.<br />

Realistisch ist dieser einfache Ansatz aber nicht. Denn<br />

bei den üblicherweise niedrigen Ausfallraten der<br />

Komponenten, würde es rein statistisch Jahrzehnte<br />

dauern, bis <strong>das</strong> Archiv komplett wäre. Bei 10 000 Geräten<br />

in der Anlage und 2% zu ersetzenden Geräten<br />

pro Jahr, wären es 50 Jahre. Hinzu kommt, <strong>das</strong>s manche<br />

Gerätetypen weniger häufig als der Durchschnitt<br />

ausfallen. Für diese würde die automatische Archivierung<br />

entsprechend länger dauern. Der Ansatz, nur<br />

die Gerätetypen und nicht die einzelnen Geräte elektronisch<br />

zu archivieren, führt nicht zum Ziel, da <strong>für</strong><br />

ein 100%-Ersatzgerät auch die tatsächliche Konfiguration<br />

und die eingestellten Parameter des Geräts bekannt<br />

sein müssen. Die Konsequenz ist, <strong>das</strong>s dieser<br />

einfache Einstieg nur in Kleinanlagen und <strong>für</strong> Anlagenteile<br />

funktioniert.<br />

5.3 Migration durch Inventur<br />

Der reale Bestand der Prozessautomatisierungsgeräte<br />

muss also festgestellt werden. Als Basis einer solchen<br />

Inventur dient die vorhandene Anlagendokumentation,<br />

wahrscheinlich muss die tatsächliche Konfiguration der<br />

Geräte aber vor Ort geprüft werden. Dazu bedarf es qualifizierter<br />

Mitarbeiter, denn es genügt nicht, nur die Typenschilder<br />

der Geräte abzulesen – so sie denn im rauen<br />

Betrieb noch lesbar sind. Die Konfiguration steht meist<br />

nicht auf dem Typenschild. Diese Vorgehensweise ist<br />

aufwändig, führt aber in angemessen kurzer Zeit zum<br />

Ziel, der Nutzen bei der Ersatzteilbeschaffung stellt sich<br />

relativ schnell ein. Im Bedarfsfall steht damit ein guter<br />

Nachweis über die eingebauten Geräte <strong>für</strong> Aufsichtbehörden<br />

zur Verfügung.<br />

5.4 Inventur mit externem Support<br />

Doch es gibt Unterstützung. Die Hersteller, zum Beispiel<br />

von Sensoren und Ventilen, haben in ihren Vertriebsund<br />

Produktionsdatenbanken dokumentiert, welche<br />

Geräte wie konfiguriert geliefert wurden und <strong>das</strong> nicht<br />

nur <strong>für</strong> die Neuanlage, sondern auch <strong>für</strong> die Ersatzgerätelieferungen.<br />

Sie können diese Daten maschinenlesbar<br />

bereitstellen. Trotzdem muss auch hier eine Überprüfung<br />

der Istkonfiguration stattfinden. Es gibt Hersteller,<br />

die sich bereit erklären, auch die Daten von Fremdgeräten<br />

zu liefern. Es ist zu erwarten, <strong>das</strong>s die Bereitstellung<br />

der Basisdaten und die Erfassung der Istkonfiguration<br />

verstärkt als Dienstleistung am Markt geordert werden<br />

können, wobei Kosten von etwa sieben Euro pro Messstelle<br />

anzusetzen sind.<br />

5.5 <strong>Schnittstellen</strong> und Tools<br />

Für <strong>das</strong> Instandhaltungssystem muss eine passende<br />

Schnittstelle, wie zum Beispiel die Prolist-NE-<br />

100-Schnittstelle, beschafft werden. Werkzeuge, wie<br />

Prospec, sind am Markt, <strong>Schnittstellen</strong> <strong>für</strong> spezielle<br />

Systeme werden von Softwarehäusern geliefert. Der<br />

eClass e.V. hilft hier weiter. Es ist auch denkbar, <strong>das</strong>s der<br />

Instandhalter in einer ersten Phase die maschinenlesbaren<br />

Daten nur sammelt und archiviert. Dann genügt<br />

beispielsweise <strong>das</strong> Werkzeug Proview, <strong>das</strong> kostenlos<br />

verfügbar ist, zum Lesen der Daten.<br />

5.6 Früher Einstieg<br />

Ideal ist natürlich, wenn die elektronische Archivierung<br />

bereits bei der Inbetriebnahme der Neuanlage<br />

beginnt. Bei der Erfassung existierender Bestände sollte<br />

Pragmatismus herrschen. Die 80-20-Regel hilft oft sehr.<br />

Es lässt sich damit leben, die Daten von Komponenten,<br />

die nur sehr selten getauscht werden müssen, <strong>für</strong> eine<br />

gewisse Zeit nicht maschinenlesbar in der Datenbank<br />

zu haben. Hier ist es möglich, sich den seltenen Aufwand<br />

zu leisten, die Konfiguration vor Ort festzustellen.<br />

Die Beschränkung auf ein konkretes Szenario im<br />

Lebenszyklus einer Anlage, wie die Instandhaltung<br />

und Ersatzteilbeschaffung, ermöglicht eine migrierende<br />

Einführung der Nutzung der Merkmalleisten mit<br />

überschaubarem Aufwand und schneller Generierung<br />

der Vorteile. Die Arbeitsabläufe sind übersichtlicher.<br />

Man beschränkt sich zunächst auf eine einzige Anlage<br />

mit einer überschaubaren Anzahl von Gerätetypen von<br />

nur wenigen Herstellern. Wahrscheinlich sind nur zwei<br />

Gewerke im Spiel: Die Instandhaltung und der Gerätehersteller.<br />

Die internen Arbeitsprozesse können in Stufen<br />

automatisiert werden.<br />

Ob der Hersteller die XML-Datenblätter händisch aus<br />

seiner Produktdatenbank erzeugt oder vertriebsintern<br />

gleich einen automatisierten Workflow aufsetzt, ist seine<br />

Entscheidung. Für den Instandhalter ist nur wichtig,<br />

<strong>das</strong>s er die Daten in der geeigneten Form bereitgestellt<br />

bekommt oder sie von den Web-Seiten der Hersteller<br />

– auch <strong>das</strong> ist bereits üblich – herunterladen kann. Entsprechend<br />

ist es dem Instandhalter überlassen, ob er<br />

die elektronischen Daten nur zunächst archiviert oder<br />

in einen komplett automatisierten Workflow integriert.<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

43


HAUPTBEITRAG<br />

Zeit, Aufwand und Nutzen sind hier abzuwägen. Sukzessive<br />

sollten dann die Datensätze auch den anderen<br />

am Lebenszyklus der Anlage beteiligten Funktionen<br />

zur Verfügung gestellt werden. Mit den elektronischen<br />

Daten im Instandhaltungssystem kann der Betreiber<br />

mit wenig Aufwand einen internen Katalog mit Stammdaten<br />

der Geräte generieren, die er üblicherweise bevorzugt<br />

einsetzt.<br />

Solche Anwendungen sind Gegenwart. Ein Betreiber<br />

hat in den Ausschreibungen <strong>für</strong> neue Großanlagen in<br />

Deutschland und im Ausland verankert, <strong>das</strong>s die Lieferanten<br />

der Prozessautomatisierungsgeräte maschinenlesbare<br />

Datenblätter gemäß Prolist NE 100 beistellen<br />

müssen. So kann er die Merkmalleistentechnologie<br />

reibungsarm und migrierend einführen. Mit den konkreten<br />

Aufträgen <strong>für</strong> Geräte lohnt sich andererseits der<br />

initiale Aufwand <strong>für</strong> die Hersteller.<br />

6. PLANT ASSET MANAGEMENT<br />

Es ist einleuchtend, <strong>das</strong>s ein Plant Asset Management<br />

(PAM) strukturierte Beschreibungen der Prozessautomatisierungsgeräte<br />

voraussetzt. Im Sinne des ganzheitlichen<br />

Ansatzes wurde deshalb auch <strong>das</strong> PAM-Spezifikationsblatt<br />

des Namur-AK 4.13 und des GMA-FA 6.23<br />

als PAM-Merkmalleiste in die Prolist NE 100 Version<br />

3.2.1 integriert.<br />

7. GERÄTEKONFIGURATION ÜBER FDI<br />

Die Konfiguration der Geräte wurde bereits mehrfach<br />

erwähnt. Der Planer einer neuen Anlage spezifiziert<br />

die einzusetzenden Geräte in allen Details. Bei intelligenten<br />

Geräten legt er an seinem CAE-System auch<br />

deren Konfiguration und die Daten der Parameter fest.<br />

Der Hersteller muss sie kennen, wenn er die Geräte<br />

konfiguriert liefern soll. Andererseits braucht der Inbetriebnehmer<br />

den Auslieferungszustand, wenn es<br />

seine Aufgabe ist, die endgültigen Einstellungen vorzunehmen.<br />

So oder so sind bei der Inbetriebnahme<br />

Parameteränderungen zu erwarten, die in die Dokumentation<br />

der Planung zurückfließen müssen. Die<br />

Einstellungen werden mit entsprechenden Tools vorgenommen,<br />

zum Beispiel vom Leitsystem aus oder mit<br />

Konfigurationstools bis hin zum Handheld-Terminal.<br />

Fehler bei dieser händischen Übertragung der Einstellungen<br />

aus der Spezifikation sind nicht zu vermeiden.<br />

Durch die notwendige Fehlersuche gestaltet sich dann<br />

die Inbetriebnahme entsprechend aufwändig. Es wäre<br />

sehr viel einfacher und sicherer, wenn die Orginalspezifikationsdaten<br />

aus dem CAE-System direkt zur<br />

Konfiguration der Geräte herangezogen werden<br />

könnten. Aus diesem Grund haben die Nutzerorganisationen<br />

die gängigen, schreibbaren Parameter <strong>für</strong><br />

Hart, Foundation Fieldbus und Profibus in die Merkmalleisten<br />

<strong>für</strong> Prozessautomatisierungsgeräte mit digitaler<br />

Kommunikation eingebracht. Sie liegen maschinenlesbar<br />

im XML-Format vor. Andererseits wird<br />

mit Field Device Integration (FDI) eine einheitliche<br />

Schnittstelle <strong>für</strong> die Integration der Geräte ins Leitsystem<br />

zur Verfügung stehen, siehe Bild 4, [6]. Zwar sind<br />

weder die entsprechenden Prolist-Merkmalleisten<br />

noch die FDI-Spezifikation final veröffentlicht, denoch<br />

konnte auf der PI-Konferenz der Profibus-Nutzerorganisation<br />

bereits im März 2013 gezeigt werden,<br />

<strong>das</strong>s die Geräte mittels der Prolist-XML-Daten, wie sie<br />

aus einem CAE-System kommen, in eine FDI-Schnittstelle<br />

des Gerätes eingelesen werden können, wodurch<br />

automatisch dessen Konfiguration geändert wird. In<br />

einer Demonstrationsanordnung wurden die physikalischen<br />

Einheiten des Ausgangssignals eines Profibus-<br />

PA-Temperaturmessumformers mittels der Prolist-<br />

Merkmalleisten über FDI von Celsius auf Kelvin und<br />

zurück umkonfiguriert.<br />

8. INDUSTRIE 4.0<br />

Maschine-Maschine-Kommunikation in Verbindung<br />

mit Mensch-Maschine-Kommunikation ist eine der<br />

Voraussetzungen <strong>für</strong> <strong>das</strong> Industrie-4.0-Szenario. Der<br />

Verein Deutscher Ingenieure (VDI) schreibt in der Einführung<br />

zum VDI-Kongress Industrie 4.0 am 4. bis 5.<br />

Februar 2014 in Düsseldorf [7]: „Industrie 4.0 bedeutet<br />

systematische Erhöhung der Flexibilität von Produkten<br />

und Produktionsprozessen durch Vernetzung, dezentrale<br />

Steuerungsmechanismen sowie intelligente Datenaufnahme<br />

und Integration. Damit geht Industrie 4.0<br />

über <strong>das</strong> Internet der Dinge und Dienste hinaus und<br />

bezieht sich auf alle Ebenen vom Shopfloor über Organisation<br />

und Planung bis zur Schaffung von Standards.<br />

Der Produktions- und Wissensarbeiter steht dabei im<br />

Zentrum der Vernetzung zu den Dingen und Diensten<br />

über ihren gesamten Lebenszyklus und dies in stetem<br />

Austausch mit Kunden, Lieferanten und dem Markt.“<br />

Die intelligente Datenaufnahme und Integration sind<br />

im Bereich der Prolist-Anwendungen verwirklicht.<br />

Alle Ebenen im Lebenszyklus einer Anlage werden<br />

abgedeckt. Standards wurden geschaffen. Der Mensch<br />

„steht dabei im Zentrum der Vernetzung zu den Dingen<br />

und Diensten über ihren gesamten Lebenszyklus und<br />

dies in stetem Austausch mit Kunden, Lieferanten und<br />

dem Markt“ [7]. Für den Workflow aller Beteiligten um<br />

die Prozessautomatisierungsgeräte sind die Voraussetzungen<br />

vorhanden.<br />

9. INTEGRIERTES ENGINEERING<br />

Auf der Namur-Haupsitzung 2013 riss Tauchnitz ein<br />

Konzept <strong>für</strong> <strong>Schnittstellen</strong> <strong>für</strong> <strong>das</strong> <strong>integrierte</strong> <strong>Engineering</strong><br />

an [11]. Die skizzierten Lösungsansätze basieren auf<br />

einem XML-Datenaustausch und wollen vorhandene<br />

Strukturierungen nutzen. In seinem kooperativen Stan-<br />

44<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


BILD 4: Automatisierte Geräteintegration mittels<br />

Prolist-Merkmalleisten über FDI<br />

BILD 5: Internationale Normung der Merkmalleisten<br />

dardisierungsansatz geht er von der Beteiligung der Anlagenbetreiber,<br />

Hersteller von Automatisierungs- und<br />

<strong>Engineering</strong>-Systemen, Systemintegratoren/<strong>Engineering</strong><br />

Contractors und aller Beteiligten bei Industrie 4.0<br />

aus. Konsequenterweise sieht Tauchnitz den Prolist-<br />

Ansatz als einen denkbaren Ansatz: „NE 100 ‚Nutzung<br />

von Merkmalleisten im PLT-<strong>Engineering</strong>-Workflow‘ beschreibt<br />

Merkmalleisten <strong>für</strong> PLT-Equipment (IEC 61987-<br />

10). Prolist stellt Werkzeuge zur Anwendung bereit.“ und<br />

„(DIN) PAS 1040 legt Merkmalleisten <strong>für</strong> Geräte der Verfahrenstechnik<br />

fest.“ Prolist hat Merkmalleisten <strong>für</strong><br />

Druckbehälter (K-36030101), Rohrbündelwärmeaustauscher<br />

(K-36040101) und Kreiselpumpen (K-36410190) aus<br />

der (DIN) PAS 1040-Normenreihe Sachmerkmal-Leiste<br />

<strong>für</strong> Maschinen, Apparate und Rohrleitungen in der chemischen<br />

Industrie in die Prolist NE 100-Datenbank und<br />

die Prolist-Werkzeuge eingeführt, weitere können bei<br />

Bedarf folgen.<br />

10. INTERNATIONALE NORMUNG<br />

Auf längere Sicht wird sich nur dann ein Nutzen einstellen,<br />

wenn die Merkmalleisten flächendeckend angewendet<br />

werden. Darum ist es ein erklärtes Ziel des<br />

eClass e.V., die internationale Normung, vor allem im<br />

Rahmen der IEC 61987, weiter voranzubringen [8, 9]. Den<br />

aktuellen Stand der Arbeiten gibt Bild 5 wieder.<br />

11. ECLASS-MERKMALLEISTEN<br />

2011 wurden mit der Harmonisierung die Prolist-Merkmalleisten<br />

auch in die eClass-Version 7.0 überführt,<br />

um zusammen mit dem bewährten Klassifizierungssystem<br />

einen ganzheitlichen Ansatz zur Verfügung<br />

stellen zu können [10]. Inzwischen hat der eClass e.V.<br />

sämtliche Aktivitäten des Prolist International e.V.<br />

übernommen, wo sie in den einzelnen Fachgruppen<br />

weitergeführt werden. Die Aktivitäten werden von der<br />

Cross Expert Group (CEG) Prozessleittechnik/Prolistkoordiniert.<br />

Der Prolist International e.V. hat seine<br />

Auflösung beschlossen. eClass garantiert als wesentlich<br />

größerer Verein die Nachhaltigkeit und stellt eine<br />

zukunftsorientierte Infrastruktur <strong>für</strong> die weiteren Arbeiten<br />

zur Verfügung. eClass ist ein branchenübergreifender<br />

Produktdatenstandard <strong>für</strong> die Klassifizierung<br />

und eindeutige Beschreibung von Produkten und<br />

Dienstleistungen. Über die klassischen Anwendungen<br />

in Beschaffung, Controlling und Vertrieb hinaus zeigt<br />

eClass seine besondere Stärke im Einsatz <strong>für</strong> <strong>das</strong> unternehmensübergreifende<br />

Prozessdatenmanagement<br />

und im <strong>Engineering</strong>.<br />

eClass deckt mit 39 000 Produktklassen und 16 000<br />

Merkmalen einen Großteil der gehandelten Waren und<br />

Dienstleistungen ab. Viele Branchenstandards (zum<br />

Beispiel aus Elektroindustrie, Medizintechnik, Bauwesen,<br />

Papierwaren/Bürotechnik) suchen die Interoperabilität,<br />

um die Potenziale eines branchenübergreifenden<br />

Standards umzusetzen. Praktisch jeder Klasse ist eine<br />

Merkmalleistenreihe zugeordnet. Diese Application<br />

Class Basic listet unstrukturiert Merkmalleisten, wie<br />

Hersteller-Name, Art der Batterie, Explosionsschutz<br />

oder Produkt überprüft nach ROHS auf. Für den <strong>Engineering</strong>-Workflow<br />

ist eine solche Liste nicht ausreichend.<br />

Deshalb gibt es zusätzlich die Merkmalleisten<br />

vom Typ Application Class Advanced, die auch <strong>für</strong> die<br />

Prolist-Anwendungen genutzt werden. Hier sind die<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

45


HAUPTBEITRAG<br />

Merkmalleisten strukturiert in Blöcken mit Aspekten,<br />

Kardinalitäten und Polymorphismen angeordnet. Die<br />

Weiterentwicklung der Merkmalleisten <strong>für</strong> Prozessautomatisierungsgeräte<br />

findet auf der eClass-Schiene statt.<br />

Die aktuelle Prolist NE 100 in der Version 3.2 bleibt<br />

eingefroren bei eClass verfügbar. Sie kann weiter genutzt<br />

werden, auch neue Anwendungen sind möglich.<br />

Sollte dem Anwender deren Funktionsumfang zu einem<br />

späteren Zeitpunkt nicht mehr ausreichen, so ist eine<br />

automatisierte Datenmigration auf die eClass-Version<br />

9.0 und von dort aus weiter zu höheren Versionen möglich.<br />

Dazu wurde ein passendes Werkzeug entwickelt,<br />

mit dem derzeit die Inhalte von Prolist NE 100 v3.2 migriert<br />

werden. Deren Inhalt wird ab November 2014 in<br />

der eClass-Version 9.0 voll nutzbar zur Verfügung stehen.<br />

Parallel dazu wird aus eClass heraus die internationale<br />

Normung der Merkmalleisten fortgeführt.<br />

FAZIT<br />

Das Merkmalleistenlexikon <strong>für</strong> Geräte <strong>für</strong> die Prozessautomatisierung<br />

bringt Effizienz, Qualität und Nutzen.<br />

Doch ohne gesteigertes Auftragsvolumen aus dem Bereich<br />

der Anwender scheuen die meisten Systemhäuser<br />

die Implementierung der Schnittstelle. Betreiber und<br />

Hersteller empfinden den personellen Aufwand <strong>für</strong> die<br />

Einführung der Veränderungen in den Workflows im<br />

Alltagsgeschäft als störend. Zum Einstieg scheinen<br />

punktuell konzentrierte Anwendungen, wie die Instandhaltung,<br />

besser geeignet. Überschaubarer Anfangsaufwand<br />

und beherrschbare Zeitfaktoren bringen<br />

schnellen Nutzen. Für Industrie 4.0 sind die Merkmalleisten<br />

notwendige, verfügbare Voraussetzungen.<br />

Mit der Übertragung der Aktivitäten zu eClass wurde<br />

<strong>das</strong> Klassifizierungssystem eingebunden. Bestehende<br />

Prolist-Anwendungen können automatisiert in eClass<br />

9.0 migriert werden. So wurde die nachhaltige Weiterentwicklung<br />

der Merkmalleisten in eClass und die Normung<br />

gesichert. Ein <strong>integrierte</strong>s <strong>Engineering</strong> wird die<br />

Anwendung fördern.<br />

AUTOR<br />

Dipl.-Ing. JÜRGEN GEORGE<br />

(geb. 1950) ist seit 1989<br />

Mitarbeiter bei Firma<br />

Pepperl+Fuchs in Mannheim.<br />

2010 bis 2013 war<br />

er Geschäftsführer des<br />

Prolist International e.V..<br />

Seit 2012 leitet er die<br />

Cross Expert Group<br />

Prozessleittechnik / Prolist des eClass e.V..<br />

Pepperl+Fuchs GmbH,<br />

Lilienthalstr. 200, D-68307 Mannheim,<br />

Tel. +49 (0) 621 776 15 42,<br />

E-Mail: jgeorge@de.pepperl-fuchs.com<br />

MANUSKRIPTEINGANG<br />

07.11.2013<br />

Im Peer-Review-Verfahren begutachtet<br />

REFERENZEN<br />

[1] Prolist: PROLIST INTERNATIONAL e.V. (in Liquidation).<br />

http://www.prolist.org<br />

[2] eClass e.V.: PROLIST. http://wiki.eclass.eu/wiki/PROLIST<br />

[3] NE 100: Nutzung von Merkmalleisten im PLT-<strong>Engineering</strong>-<br />

Workflow. Namur, 2010. http://www.namur.de<br />

[4] IEC 61987-10: Industrial-process measurement and control<br />

- Data structures and elements in process equipment<br />

catalogues - Part 10: List of Properties (LOPs) for Industrial-<br />

Process Measurement and Control for Electronic Data<br />

Exchange – Fundamentals. IEC, 2009 http://www.iec.ch<br />

[5] eClass e.V.: eClass – Classification and Product<br />

Description. http://www.eclass.de<br />

[6] George, J., Großmann, D., Pelz, M.: Prolist und FDI. In:<br />

Tagungsband Automation 2012, S. 215-218. VDI, 2012<br />

[7] VDI Wissensforum: Industrie 4.0 2014.<br />

http://www.vdi-wissensforum.de/de/nc/angebot/<br />

detailseite/event/02TA621014<br />

[8] IEC 61360-1: Standard data elements types with<br />

associated classification scheme for electric<br />

items - Part 1: Definitions - Principles and methods.<br />

IEC, 2009. http://www.iec.ch<br />

[9] IEC 61987-11: Industrial-process measurement<br />

and control - Data structures and elements in process<br />

equipment catalogues - Part 11: List of Properties<br />

(LOP) of measuring equipment for electronic data<br />

exchange - Generic structures. IEC, 2012.<br />

http://www.iec.ch<br />

[10] Ahrens, W.: Der Branchenstandard Prolist und die<br />

Harmonisierung mit eCl@ss. In: Tagungsband Automation<br />

2010, S. 149-154. VDI, 2010.<br />

[11] Tauchnitz, Th.: <strong>Schnittstellen</strong> <strong>für</strong> <strong>das</strong> <strong>integrierte</strong><br />

<strong>Engineering</strong>. Wege zu einer schnellen Realisierung.<br />

<strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische Praxis 56(1-2),<br />

S. 30-36, 2014<br />

46<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


Process Control<br />

Systems <strong>Engineering</strong><br />

Process Control Systems (PCS) are distributed control systems (DCS) that are specialized<br />

to meet specific requirements of the process industries. The text book<br />

focuses on PCS engineering basics that are common to different domains of the<br />

process industries. It relates to an experimental research plant which serves for<br />

the exploration of the interaction between process modularization and process<br />

automation methods. This permits to capture features of highly specialized and integrated<br />

mono-product plants as well as application areas which are dominated by<br />

locally standardized general-purpose apparatus and multi-product schemes. While<br />

the text book’s theory is applicable for all PCS of different suppliers, the examples<br />

refer to Siemens’ control system PCS 7. Focusing on a single PCS enables readers<br />

to use the book in basic lectures on PCS engineering as well as in computer lab<br />

courses, allowing students to gain hands-on experience.<br />

Editor: L. Urbas<br />

1 st <strong>edition</strong> 2012<br />

204 pages, content in English,<br />

165 x 230 mm, hardcover<br />

ISBN: 978-3-8356-3198-4<br />

Price € 49,80<br />

www.di-verlag.de<br />

DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München<br />

Order now!<br />

KNOWLEDGE FOR THE<br />

FUTURE<br />

Order now by fax: +49 201 / 820 Deutscher 02-34 Industrieverlag or send GmbH in a letter | Arnulfstr. 124 | 80636 München<br />

Yes, I place a firm order for the technical book. Please send<br />

— copies of the Process Control Systems <strong>Engineering</strong><br />

1st <strong>edition</strong> 2012 (ISBN: 978-3-8356-3198-4)<br />

at the price of € 49,80 (plus postage and packing)<br />

Company/Institution<br />

First name, surname of recipient (department or person)<br />

Street/P.O. Box, No.<br />

Country, Postalcode, Town<br />

reply / Antwort<br />

Vulkan-Verlag GmbH<br />

Versandbuchhandlung<br />

Postfach 10 39 62<br />

45039 Essen<br />

GERMANY<br />

Phone<br />

E-Mail<br />

Line of business<br />

Fax<br />

Please note: According to German law this request may be withdrawn within 14 days after order date in writing<br />

to Vulkan Verlag GmbH, Versandbuchhandlung, Postfach 10 39 62, 45039 essen, Germany.<br />

In order to accomplish your request and for communication purposes your personal data are being recorded and stored.<br />

It is approved that this data may also be used in commercial ways by mail, by phone, by fax, by email, none.<br />

this approval may be withdrawn at any time.<br />

Date, signature<br />

PAPCSE2013


HAUPTBEITRAG<br />

FDI Usability Style Guide<br />

Digitale Feldgeräte – <strong>für</strong> Anwender gebrauchstauglich integriert<br />

Die Integration digitaler intelligenter Feldgeräte ist durch die Anwendung verschiedener<br />

Werkzeuge mit unterschiedlichen Bedienphilosophien geprägt. Trotz gewollter<br />

Vielfalt und Anpassungsmöglichkeiten der Softwareprodukte müssen die Benutzeroberflächen<br />

<strong>für</strong> die Feldgeräteintegration gebrauchstauglich sein. Dieser Beitrag<br />

stellt daher Kernelemente des FDI Usability Style Guide zur Diskussion, der unter<br />

Beteiligung der Autoren entwickelt wurde. Anhand eines Einflussfaktorenmodells<br />

<strong>für</strong> Benutzeroberflächen wird gezeigt, wie diese sich im Hinblick auf Gebrauchstauglichkeit<br />

optimieren lassen.<br />

SCHLAGWÖRTER Usability / Gebrauchstauglichkeit / Feldgeräteintegration / FDI /<br />

EDD / FDT<br />

FDI Usability Style Guide –<br />

Usable Integration of Field Devices for Commissioning and Operation<br />

The integration of digital intelligent field devices is affected by the usage of lots of<br />

different tools with different operation conceptions. Despite intended variety of<br />

modification capabilities of these software products, the usability of their user interfaces<br />

shall be ensured. This article presents the core elements of the FDI Usability<br />

Style Guide, which was developed in cooperation with the authors. The core<br />

elements are discussed on the basis of an improvement model for user interfaces that<br />

especially deals with usability.<br />

KEYWORDS usability / field device integration / FDI / EDD / FDT<br />

48<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


MARKUS STÖSS, Technische Universität Dresden<br />

FRANK FENGLER, ABB<br />

ACHIM LAUBENSTEIN, ABB<br />

LEON URBAS, Technische Universität Dresden<br />

Die Instrumentierung verfahrenstechnischer<br />

Anlagen ist durch eine Vielzahl an Feldgeräten<br />

geprägt. Diese realisieren primär die leittechnischen<br />

Grundfunktionen der Informationsgewinnung<br />

(Messen, Überwachen) und<br />

der Informationsausgabe (Stellen). Hinzu kommen gerätespezifische<br />

Funktionen der Informationsverarbeitung<br />

wie Prozess- und Gerätediagnose, Regelung und<br />

Kalibrierung.<br />

Die hohe gerätespezifische Funktionalität bedingt<br />

unterschiedliche gerätespezifische Parameter, die bei<br />

der Inbetriebnahme eingestellt und im laufenden Betrieb<br />

(beispielsweise beim Austausch oder einer Prozessmodifikation)<br />

gepflegt werden müssen. Hier<strong>für</strong><br />

bieten die Hersteller Bedienschnittstellen am Gerät und<br />

Softwarewerkzeuge an, die sich von Hersteller zu Hersteller<br />

trotz ähnlicher Automatisierungsaufgaben und<br />

-anforderungen bezüglich der Benutzeroberflächen und<br />

deren Verhalten deutlich unterscheiden [15]. Da die<br />

Anwender in der Prozessindustrie aufgrund der langen<br />

Laufzeiten und der kontinuierlichen Optimierung der<br />

Anlagen sowie der heterogenen Anforderungen an die<br />

Instrumentierung (Ex-Schutz, Sicherheit, Qualität) Geräteversionen<br />

unterschiedlicher Hersteller beherrschen<br />

müssen, sind herstellerübergreifende Inbetriebnahmewerkzeuge<br />

mit einheitlichen Anzeige- und Bedienoberflächen<br />

gefordert [16, 17].<br />

Da<strong>für</strong> haben sich in der Prozessindustrie zwei unterschiedliche<br />

Ansätze etabliert [20]:<br />

1 | Bei dem komponentenorientierten Softwareansatz<br />

Field Device Tool/Device Type Manager (FDT/<br />

DTM) [18] stellen die Gerätehersteller Softwarekomponenten<br />

<strong>für</strong> Kommunikation und Bedienung<br />

zur Verfügung, die in einer FDT-Rahmenapplikation<br />

(zum Beispiel Fieldcare [1], Pactware [3]) installiert<br />

und ausgeführt werden. Der Zugriff auf die<br />

unterschiedlichen Geräte erfolgt dadurch zwar<br />

über eine einheitliche Rahmenapplikation, die<br />

hohe Gestaltungsfreiheit „erschwert [aber] in der<br />

Praxis die Wartung und Inbetriebnahme von Anlagen“<br />

[19].<br />

2 | Die Geräteintegration mit Hilfe der Electronic Device<br />

Description (EDD) erfolgt hingegen über die in<br />

IEC 61804 [23] genormte Beschreibungssprache<br />

EDDL, mit der Geräteparameter, -funktionen und<br />

Bedienoberflächen modelliert werden. Diese Gerätebeschreibung<br />

wird von EDD-Interpretern wie<br />

PDM [2] oder AMS [21] interpretiert – dadurch ist<br />

eine einheitliche Bedienphilosophie und Darstellung<br />

gewährleistet. Allerdings beklagen Gerätehersteller,<br />

<strong>das</strong>s sie <strong>für</strong> eine optimale Integration werkzeugspezifische<br />

Versionen der EDD pflegen müssen.<br />

Zudem sind die Möglichkeiten zur Gestaltung<br />

grafischer <strong>Schnittstellen</strong> mit EDD im Vergleich zu<br />

FDT/DTM deutlich eingeschränkt.<br />

Die Field Device Integration-Technologie (FDI) soll die<br />

Vorteile der FDT/DTM- und EDD-Technologien zu einer<br />

Lösung vereinen [24, 22]. In einem FDI Device Package<br />

werden dazu die EDDL-basierten Beschreibungen der<br />

Geräteparameter (Device Definition), der Logik zur Absicherung<br />

von einzuhaltenden Einschränkungen (Business<br />

Logic) und der Mensch-Maschine-Schnittstelle<br />

(User Interface Description) sowie weitere analog zu dem<br />

FDT/DTM-Konzept ausprogrammierte Mensch-Maschine-<strong>Schnittstellen</strong><br />

(User Interface Plug-in) gebündelt, die<br />

in den Komponenten FDI Server und FDI Client interpretiert<br />

beziehungsweise ausgeführt werden (Bild 1). Die<br />

erreichte Vereinheitlichung und Integration der Technologien<br />

führt im Erfolgsfall dazu, <strong>das</strong>s ein Anlagenbetreiber<br />

nur noch ein, möglicherweise nahtlos in <strong>das</strong><br />

Prozessleitsystem und die <strong>Engineering</strong>-Datenbanken<br />

<strong>integrierte</strong>s, Inbetriebnahme- und Wartungswerkzeug<br />

einsetzen und beherrschen muss.<br />

Aufgrund der grundsätzlichen Unterschiede der beiden<br />

Basis-Technologien stehen die Gerätehersteller vor<br />

neuen Herausforderungen. Da mit FDI eine einheitliche<br />

Bedienphilosophie des FDI-Clients vorausgesetzt wird,<br />

fallen hersteller- oder gerätespezifische Abweichungen<br />

unangenehm auf. Es ist zu erwarten, <strong>das</strong>s sich die visuelle<br />

Anmutung von FDI-Anwendungen in der Leitwarte<br />

und mobilen FDI-Anwendungen zum Einsatz im Feld<br />

(beispielsweise [15]) deutlich unterscheiden werden.<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

49


HAUPTBEITRAG<br />

Wie muss nun ein FDI Device Package gestaltet sein,<br />

<strong>das</strong> den Anwendern trotz aller Technologieunterschiede<br />

ein harmonisches Nutzungserleben erlaubt und<br />

sie dazu befähigt, die Inbetriebnahme und Wartungstätigkeiten<br />

effektiv und effizient durchzuführen?<br />

Die im Folgenden beschriebene Gestaltungsrichtlinie<br />

soll diese Frage beantworten. Dazu werden zunächst die<br />

vorhandenen Gestaltungsrichtlinien analysiert und die<br />

Herausforderungen <strong>für</strong> eine gemeinsame FDI-Gestaltungsrichtlinie<br />

vorgestellt. Danach wird auf die Grundlagen<br />

der Gebrauchstauglichkeit und auf die Optimierungspotenziale<br />

eingegangen. Schließlich wird dargestellt,<br />

wie diese Potenziale in der neuen Gestaltungsrichtlinie<br />

im Kontext von FDI gezielt umgesetzt werden.<br />

1. GESTALTUNGSRICHTLINIEN<br />

Eine Gestaltungsrichtlinie (style guide) beschreibt Regeln<br />

und gibt Hinweise, wie statische und interaktive<br />

Elemente einer Mensch-Maschine-Schnittstelle (MMS)<br />

zu gestalten sind. Diese Regeln und Hinweise sollen ein<br />

einheitliches Erscheinungsbild und ein konsistentes<br />

Interaktionsverhalten gewährleisten und sind grundlegende<br />

Voraussetzungen <strong>für</strong> nutzerfreundliche Software.<br />

Da sie sich aber je nach Einsatzbereich unterscheiden,<br />

ist die Ableitung einer Gestaltungsrichtlinie bei der Entwicklung<br />

gebrauchstauglicher MMS ein wesentlicher<br />

Prozessschritt [11].<br />

Für viele Systeme stehen Gestaltungsrichtlinien zur<br />

Verfügung [5, 6]. Ziele dieser Gestaltungsrichtlinien<br />

sind beispielsweise eine hohe Qualität und Konsistenz<br />

<strong>für</strong> alle Anwendungen [5]. Auch <strong>für</strong> die beiden Schlüsseltechnologien<br />

zur Gestaltung von Benutzeroberflächen<br />

<strong>für</strong> Feldgeräte gibt es Gestaltungsrichtlinien, die<br />

in IEC 61804-4 veröffentlichte EDD-Guideline [7] und<br />

den in IEC 6253-61 veröffentlichten DTM Style Guide<br />

(weiterentwickelt in [8]). Die EDD-Guideline nennt keine<br />

Entwurfsprinzipien aus Nutzersicht, sie stellt eine<br />

technische Einführung in die EDDL-Programmierung<br />

dar. Im Gegensatz dazu konzentriert sich der DTM Style<br />

Guide auf die Benennung von domänenspezifischen<br />

Gestaltungsanforderungen und verzichtet nahezu vollständig<br />

auf technische Details von FDT/DTM; es wird<br />

also nicht ausgeführt, wie die Gestaltungsanforderung<br />

umgesetzt werden sollen.<br />

Zur Evaluation der Verwendung der beiden Gestaltungsrichtlinien<br />

führten die Autoren Ende 2012 eine<br />

Umfrage bei den Geräteentwicklern führender Hersteller<br />

von Automatisierungstechnik durch. Im Ergebnis<br />

schrieben die Befragten (n=6) dem DTM Style Guide zu,<br />

die Gebrauchstauglichkeit der Oberflächen mehr zu<br />

erhöhen als die EDD-Guideline. Trotz der Einschätzung,<br />

<strong>das</strong>s beide Gestaltungsrichtlinien verständlich,<br />

überwiegend hilfreich und <strong>für</strong> die tägliche Arbeit geeignet<br />

sind, setzen alle Befragten zusätzlich firmeninterne<br />

Gestaltungsrichtlinien ein. Dabei stellt die Hälfte<br />

der Befragten Inkonsistenzen zwischen den internen<br />

und den öffentlichen Gestaltungsrichtlinien fest.<br />

Da die ausschließliche Verwendung des DTM Style<br />

Guides beziehungsweise des EDD–Guideline zur Erstellung<br />

gebrauchstauglicher Benutzeroberflächen<br />

nicht ausreicht, hat die FDI Cooperation unter Beteiligung<br />

der Autoren eine neue Gestaltungsrichtlinie entwickelt,<br />

den FDI Usability Style Guide. Er greift vorhandene<br />

Konzepte der Style Guides auf und konkretisiert<br />

sie im Kontext von FDI. Leitsystemhersteller, Gerätehersteller,<br />

Integratoren und Anwender (Namur)<br />

haben dabei ihre Anforderungen und Erfahrungen einfließen<br />

lassen.<br />

Um <strong>das</strong> Gestaltungsprinzip der Erwartungskonformität<br />

umzusetzen, werden existierende Elemente und<br />

Konzepte der EDD- und FDT-Gestaltungsrichtlinien<br />

wiederverwendet und den Entwicklern durch Empfehlungen<br />

beschrieben, wie sie diese in der FDI-Technologie<br />

implementieren können. So finden FDI-Nutzer bekannte<br />

Strukturen, bekanntes Verhalten und bekannte<br />

Darstellungen aus EDD- und FDT-Applikationen in<br />

einem FDI Host (siehe Bild 1) wieder. Gelerntes wird<br />

somit auch auf die FDI-Technologie anwendbar.<br />

2. HERAUSFORDERUNGEN<br />

Eine Herausforderung <strong>für</strong> die Entwicklung des FDI<br />

Usability Style Guides war es, Technologieunterschiede<br />

zwischen den in EDD beschriebenen User<br />

Interface Descriptions (UID) und den mit Windows<br />

Presentation Foundation (WPF) programmierten User<br />

Interface Plug-ins (UIP) durch Empfehlungen an den<br />

Entwickler <strong>für</strong> den Benutzer weitgehend unsichtbar<br />

zu machen. Ziel sind FDI Device Packages, die in<br />

einem FDI Host zu einem einheitlichen Nutzererleben<br />

führen, unabhängig von der jeweils eingesetzten Implementierungstechnologie<br />

[26].<br />

Eine weitere Herausforderung war die herstellerübergreifende<br />

Kompatibilität von Benutzeroberflächen.<br />

Dazu nimmt der FDI Usability Style Guide gezielt Einfluss<br />

auf alle wesentlichen Gesichtspunkte, die die<br />

Gebrauchstauglichkeit verbessern.<br />

3. GEBRAUCHSTAUGLICHKEIT<br />

EN ISO 9241-11 [9] definiert Komponenten der Gebrauchstauglichkeit<br />

(usability). Als wesentliche Maße<br />

der Gebrauchstauglichkeit werden Effektivität, Effizienz<br />

und Zufriedenstellung der Nutzer verstanden. Eine anschauliche<br />

Darstellung des Sachverhalts gibt Bild 2.<br />

Weiterhin werden die folgenden Grundsätze der Dialoggestaltung<br />

der EN ISO 9241-10 [10] als Leitlinien<br />

<strong>für</strong> die Oberflächengestaltung definiert:<br />

Aufgabenangemessenheit<br />

Selbstbeschreibungsfähigkeit<br />

Steuerbarkeit<br />

Erwartungskonformität<br />

Fehlertoleranz<br />

50<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


BILD 1: FDI Reference Host<br />

BILD 2: Anwendungsrahmen der<br />

Gebrauchstauglichkeit [9]<br />

BILD 3: Style-Guide-Entwicklung [11]<br />

Individualisierbarkeit<br />

Lernförderlichkeit<br />

Es ist leicht nachzuvollziehen, <strong>das</strong>s diese Grundsätze<br />

der Dialoggestaltung auch Grundsätze <strong>für</strong> die Feldgeräteintegration<br />

mit der FDI-Technologie sind. Die Grundannahme<br />

basiert darauf, <strong>das</strong>s die intelligenten Feldgeräte<br />

über Dialoge auf Desktop-Bildschirmen und mobilen<br />

Geräten in Betrieb genommen beziehungsweise parametriert,<br />

gewartet und Diagnosen erstellt werden.<br />

4. STYLE-GUIDE-ENTWICKLUNG<br />

Mayhew definiert einen Prozess zur Entwicklung von<br />

Style Guides [11]. Das FDI Usability Style Guide Team<br />

hat <strong>das</strong> beschriebene Verfahren aufgegriffen. In vereinfachter<br />

Form (keine Darstellung von Iterationen)<br />

wurde der Style Guide basierend auf einer Anforderungsanalyse<br />

entwickelt. Sie ist in Bild 3 schematisch<br />

dargestellt.<br />

Während der Entwicklung wurden Benutzerprofile,<br />

Aufgaben beziehungsweise Möglichkeiten und Randbedingungen<br />

der Plattform (FDI Reference Host) sowie<br />

generelle Design-Prinzipien analysiert. Als generelle<br />

Prinzipien wurden stellvertretend – wie schon im FDT/<br />

DTM Style Guide – die zehn Usability-Heuristiken von<br />

Nielson [25] herangezogen und <strong>für</strong> den Anwendungsfall<br />

weiter konkretisiert.<br />

5. OPTIMIERUNGSMODELL FÜR BENUTZEROBERFLÄCHEN<br />

Baxley [12] beschreibt und gewichtet Einflussfaktoren,<br />

die sich auf die Gebrauchstauglichkeit von Benutzeroberflächen<br />

auswirken. Nutzer wissen oft nicht, warum<br />

sie eine hohe oder niedrige Gebrauchstauglichkeit<br />

der Benutzeroberflächen wahrnehmen. Auch <strong>für</strong><br />

den Entwickler ist die Optimierung der Gebrauchstauglichkeit<br />

eine nicht zu unterschätzende Herausforderung.<br />

Um diesen Optimierungsprozess zu vereinfachen<br />

und die größten Hebel zur Verbesserung der<br />

Gebrauchstauglichkeit zu identifizieren, hat Baxley<br />

ein Modell entwickelt.<br />

Dieses Modell (siehe Bild 4) teilt die Bestandteile<br />

einer Benutzeroberfläche beziehungsweise die Interaktion<br />

mit dieser in verschiedene Kategorien ein. Es<br />

konkretisiert in einer ersten Ebene die wesentlichen<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

51


HAUPTBEITRAG<br />

BILD 4: Einflussfaktoren auf die Gebrauchstauglichkeit<br />

(in Anlehnung an [12,S. 5])<br />

BILD 5: Hierarchisch aufgebaute Parametergruppen<br />

am Beispiel eines Hart-Gerätes<br />

drei Aspekte, die zur Erstellung gebrauchstauglicher<br />

Nutzeroberflächen zu beachten sind. Absteigend geordnet<br />

nach dem Einfluss auf die Gebrauchstauglichkeit<br />

sind dies (1) Struktur, (2) Verhalten und (3) Darstellung.<br />

Diese werden detaillierter aufgeschlüsselt. Erkennbar<br />

sind neun Einzelaspekte von denen im Folgenden <strong>das</strong><br />

konzeptuelle Modell, der Aufgabenfluss und die Informationsarchitektur<br />

diskutiert werden.<br />

6. BERÜCKSICHTIGUNG DES MODELLS IM STYLE GUIDE<br />

6.1 Konzeptuelles Modell<br />

Im konzeptuellen Modell (Struktur) wird die Beziehung<br />

der Benutzerschnittstelle mit der Umgebung beschrieben<br />

[12]. Ziel ist es, dem Benutzer, basierend auf<br />

seinen Erfahrungen, die Basisfunktionalität der Software<br />

über dem Nutzer bekannte Grundfunktionen zur<br />

Verfügung zu stellen. Da<strong>für</strong> ist der FDI Host verantwortlich.<br />

Basierend auf der Forderung nach Basisfunktionalität<br />

sind weite Teile der FDI-Technologie, speziell<br />

die Benutzeroberflächen, an die FDT- und EDD-Technologie<br />

angelehnt.<br />

Ein weiterer Aspekt des konzeptuellen Modells ist<br />

<strong>das</strong> speziell <strong>für</strong> FDI entwickelte Rollenkonzept. Da<strong>für</strong><br />

beschreibt der FDI Usability Style Guide die unterschiedlichen<br />

Bedürfnisse der unterschiedlichen Nutzerrollen.<br />

In der Praxis zeigte sich, <strong>das</strong>s sich <strong>das</strong> bekannte<br />

Rollenkonzept von FDT nicht durchgesetzt hat.<br />

Zum einen stellt es eine Bevormundung einiger Nutzergruppen<br />

dar und zum anderen ist es zu komplex. Ein<br />

dritter Punkt, der aus der Diskussion mit Vertretern der<br />

Namur hervorging, ist die Abhängigkeit von der Organisationsstruktur<br />

des Unternehmens, <strong>das</strong> die intelligenten<br />

Feldgeräte betreibt und dem Rollenkonzept. Es<br />

ließ sich zeigen, <strong>das</strong>s keine eindeutige Zuordnung von<br />

Funktionen und Parametern auf Nutzerrollen der FDT-<br />

Spezifikation unabhängig von Betrachtungen der Organisationsstrukturen<br />

möglich ist. Es ist somit <strong>für</strong> einen<br />

Gerätehersteller unmöglich, die Nutzerrollen einer<br />

Betreiberfirma mit deren organisationsspezifischen<br />

Befugnissen zu antizipieren und dies in einem FDTkonformen<br />

Rollenkonzept innerhalb eines FDI Device<br />

Packages konsequent umzusetzen.<br />

Der FDI Usability Style Guide wählt deshalb einen<br />

anderen Ansatz. Er spricht von Sichten (views), die<br />

kompatibel zum Namur-Schalenmodell sind und keine<br />

Abhängigkeit von Organisationsstrukturen aufweisen.<br />

Die definierten Sichten Maintenance und Specialist<br />

unterscheiden zwischen Aufgaben, die typischerweise<br />

durch <strong>das</strong> Wartungs- und Instandhaltungspersonal<br />

erledigt werden und anderen Aufgaben, <strong>für</strong> die<br />

tiefes Gerätewissen notwendig ist. Die Umsetzung<br />

dieses vereinfachten Modells basiert auf den im FDI<br />

Usability Style Guide beschriebenen Use Cases. Sie<br />

beschreiben sämtliche Aufgaben des Wartungs- und<br />

52<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


Instandhaltungspersonals (maintenance). Alle anderen<br />

Aufgaben, welche nicht direkt aus den Use Cases ableitbar<br />

sind, werden der Sicht des Gerätespezialisten<br />

(specialist) zugeordnet.<br />

6.2 Aufgabenfluss<br />

Das Modell des Aufgabenflusses (Struktur) beschreibt,<br />

in welcher Art und Weise der Nutzer Operationen mit<br />

dem System beziehungsweise dem Feldgerät durchführt.<br />

Dazu sind, wie im letzten Abschnitt erwähnt, im<br />

Style Guide Use Cases definiert, die im gesamten Gerätelebenszyklus<br />

<strong>für</strong> den Gerätebenutzer relevant sind.<br />

Typische Aufgaben (tasks) aus den Use Cases sind die<br />

Inbetriebnahme, der Tausch oder die Kalibrierung eines<br />

Feldgerätes. Diese Tasks variieren je nach Planungs- und<br />

Betriebsphase einer Anlage und sind abhängig von den<br />

Aufgaben des individuellen Benutzers. Um den Arbeitsablauf<br />

im Sinne der Gebrauchstauglichkeit zu verbessern,<br />

bieten sich Wizards an. Wizards ermöglichen eine<br />

semiautomatische Navigation, die aktiv zur Aufgabenunterstützung<br />

beiträgt.<br />

Das Ergebnis der gezielten Anwendung von Wizards<br />

ist eine Reduktion des Arbeitsaufwandes durch die<br />

Verringerung der Navigationsbeanspruchung. Aufgaben,<br />

die wiederkehrend durchzuführen sind und <strong>für</strong><br />

die es eine vordefinierte Sequenz von Teilaufgaben gibt,<br />

sind <strong>für</strong> die Implementierung in Form von Wizards<br />

prädestiniert. Der FDI Usability Style Guide beschreibt<br />

daher detailliert, wie Wizards innerhalb eines FDI Device<br />

Packages erstellt werden. Zudem verweist er auf<br />

die Use Cases, welche auf typische wiederkehrende<br />

Aufgaben der Benutzer schließen lassen. Sie dienen<br />

dem UI-Entwickler als Empfehlung zur Implementierung<br />

aufgabenspezifischer Wizards.<br />

6.3 Informationsarchitektur<br />

Die Informationsarchitektur (Struktur) beschreibt, wie<br />

der Inhalt und die Funktionen in einem System angeordnet<br />

und kategorisiert sind [9, S.6]. Für einen FDI Host,<br />

der Benutzeroberflächen aus einem FDI Device Package<br />

darstellt, sind dies Parameter und Funktionen des Feldgerätes.<br />

Sie werden in diesem Zusammenhang als Informationsraum<br />

des Gerätes bezeichnet, welcher graphentheoretisch<br />

einen Baum darstellt [13]. Gerätehersteller<br />

stehen nun vor der Herausforderung, diesen Informationsraum<br />

gut angeordnet und kategorisiert auf der Benutzeroberfläche<br />

darzustellen. Sie nutzen dazu die Möglichkeit,<br />

den Informationsraum, basierend auf dem EDD<br />

Teil des FDI Device Packages, zu strukturieren.<br />

Der FDI Usability Style Guide definiert erstmals eine<br />

verbindliche Unterteilung der Gerätefunktionalität, die<br />

durch <strong>das</strong> EDD-Konzept MENU vom Hersteller implementiert<br />

werden muss. Dazu werden Standard-Einstiegspunkte<br />

definiert, die die Erreichbarkeit aller<br />

Funktionen und Parameter eines Gerätes gewährleisten.<br />

Sie werden als top-level menus bezeichnet und sind an<br />

die EDD-Guideline [7] angelehnt. Es gibt je ein Menü <strong>für</strong>:<br />

1 | Bedienen<br />

2 | Diagnose und<br />

3 | Geräteeinstellungen.<br />

Im Menü Bedienen (operate) befinden sich beispielsweise<br />

aktuelle Prozessmesswerte oder Stellgrößen sowie<br />

Mess- und Stellbereiche, während <strong>das</strong> Diagnose-Menü<br />

(diagnostics) sämtliche Informationen über den Gerätezustand<br />

enthält. Das Menü der Geräteeinstellungen (device<br />

setup) enthält zusätzliche Geräteparameter, die <strong>für</strong><br />

<strong>das</strong> Bedienen und <strong>für</strong> Standarddiagnosefunktionen<br />

nicht benötigt werden.<br />

Für die Kategorisierung unterhalb dieser Menüs gibt<br />

der FDI Usability Style Guide weitere Empfehlungen,<br />

zum Beispiel wie Parametergruppen und eine geeignete<br />

Hierarchisierung der Elemente der Benutzeroberfläche<br />

(controls) aussehen können. Ein Beispiel zeigt Bild 5.<br />

Die oben genannte Strukturierung des Informationsraums<br />

eines Gerätes wird herstellerübergreifend und<br />

<strong>für</strong> alle Feldgerätetypen empfohlen. Im Ergebnis wird<br />

durch die Nutzung eines bestimmen Gerätes beim Anwender<br />

ein mentales Modell [14] über dieses Gerät aufgebaut<br />

(Exploration des Informationsmodells), welches<br />

auch auf andere Geräte übertragbar ist. Allgemeiner<br />

formuliert bedeutet <strong>das</strong>, <strong>das</strong>s durch eine ähnliche<br />

Strukturierung der Informationsräume aller Geräte der<br />

Lernprozess des Gerätenutzers aktiv unterstützt wird.<br />

6.4 Anzeige und Navigation<br />

Anzeige und Navigation (Verhalten) stehen im engen<br />

Zusammenhang mit dem Informationsmodell des Gerätes.<br />

Dieses resultiert aus der deskriptiven Beschreibung<br />

von Benutzeroberflächen mit den Mitteln der<br />

EDDL. Durch die EDDL lassen sich Parameter und Methoden<br />

im Informationsraum des Gerätes anordnen. Die<br />

Herausforderung des Entwicklers besteht darin, Parameter<br />

und Methoden derart zu strukturieren, <strong>das</strong>s deren<br />

Anzeige und die Navigation den Workflow des Benutzers<br />

optimal unterstützen. Für die Anzeige von Parametern<br />

und Methoden eines FDI Device Packages ist der FDI<br />

Host verantwortlich, <strong>das</strong> heißt der Entwickler muss sich<br />

darum nicht kümmern.<br />

Auch die Navigation durch den Informationsraum<br />

wird durch den FDI Host sichergestellt. Da<strong>für</strong> bietet<br />

dieser ein <strong>für</strong> die Umgebung typisches Navigationselement<br />

an, beispielsweise eine Baumdarstellung oder eine<br />

Menüleiste. Mit anderen Worten: Auch darum muss sich<br />

ein FDI-Device-Package-Entwickler nicht kümmern.<br />

6.5 Editieren und Manipulieren<br />

Für <strong>das</strong> Editieren und Manipulieren (Verhalten) bietet<br />

der FDI Host einheitliche Bedienmöglichkeiten an, bei-<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

53


HAUPTBEITRAG<br />

spielsweise Edit-Felder oder Checkboxen. Die Bestätigung<br />

oder <strong>das</strong> Abbrechen dieser Eingaben erfolgt durch<br />

standardisierte Aktionen (standard UI actions), die <strong>für</strong><br />

ein konsistentes Verhalten der UID und UIP sorgen.<br />

6.6 Benutzerunterstützung<br />

Um den Nutzer gezielt zu leiten (Verhalten), ist es essenziell,<br />

die der Aufgabe angemessene Information<br />

bereitzustellen. FDI standardisiert da<strong>für</strong> zum Beispiel<br />

den Parameterstatus. Die grafische Repräsentation des<br />

Status wird im FDI Usability Style Guide detailliert<br />

beschrieben, um Konsistenz in UID und UIP zu gewährleisten.<br />

Außerdem werden <strong>für</strong> die Unterstützung<br />

Tooltips angewendet, wie sie aus der EDD-Spezifikation<br />

bekannt sind. Es ist zu beobachten, <strong>das</strong>s in vielen<br />

Applikationen die Tooltips nicht immer <strong>für</strong> den Anwender<br />

hilfreich sind, sondern häufig in der Sprache<br />

der Entwickler formuliert sind. Um dem zu entgegnen,<br />

spricht der FDI Usability Style Guide den Entwickler<br />

konkret an und gibt Hilfestellung, wie Tooltips aufgebaut<br />

sein sollten.<br />

6.7 Text<br />

Der FDI Usability Style Guide beinhaltet ein erweiterbares<br />

Wörterbuch, <strong>das</strong> beispielsweise die Beschriftung<br />

der top-level menus, der Standardbuttons und<br />

die Benennung des Status von Parametern vereinheitlicht.<br />

Die Namur unternimmt bereits Anstrengungen,<br />

REFERENZEN<br />

[1] Endress + Hauser: FieldCare. http://www.de.endress.<br />

com/eh/sc/europe/dach/de/home.nsf/#products/id/0D7<br />

8AA2558750E00C125729100557412<br />

[2] Siemens: Process Device Manager (PDM). http://www.<br />

automation.siemens.com/mcms/process-control-systems/de/simatic-pcs-7/simatic-pcs-7-systemkomponenten/process-device-manager-pdm/Pages/Default.aspx<br />

[3] Vega: DTM Collection + PACTware.<br />

http://www.vega.com/de/Software_DTM.htm<br />

[4] NE 107: Selbstüberwachung und Diagnose von Feldgeräten.<br />

Namur 2006<br />

[5] Microsoft: Windows User Experience Interaction<br />

Guidelines. http://www.microsoft.com/en-us/download/<br />

details.aspx?id=2695<br />

[6] Apple: OS X Human Interface Guidelines.<br />

https://developer.apple.com/library/<br />

mac/#documentation/UserExperience/Conceptual/<br />

AppleHIGuidelines/Intro/Intro.html<br />

[7] IEC/TR 61804-4: Function Blocks (FB) for Process<br />

Control - EDD Interoperability Guideline, 2006<br />

[8] FTD Group: FDT Style Guide Version 2.0. http://www.<br />

fdtgroup.org/sites/default/files/pages/FDT_Style_Guide_V2_0official.pdf<br />

[9] DIN EN ISO 9241-11: Ergonomische Anforderungen <strong>für</strong><br />

Bürotätigkeiten mit Bildschirmgeräten – Anforderungen<br />

an die Gebrauchstauglichkeit – Leitsätze, 1999<br />

[10] DIN EN ISO 9241-10: Ergonomische Anforderungen <strong>für</strong><br />

Bürotätigkeiten mit Bildschirmgeräten - Grundsätze der<br />

Dialoggestaltung, 1996<br />

[11] Mayhew, D. J.: The Usability <strong>Engineering</strong> Lifecycle, a<br />

practitioner‘s hand-book for interface design.Academic<br />

Press 1999<br />

[12] Baxley, B.: Universal model of a user interface. In: Proc.<br />

Conf. Designing for user experiences [DUX 03], S.1-14.<br />

ACM 2003<br />

[13] Corman, Th. H., Leiserson, Ch. E., Rivest, R., Stein, C.:<br />

Algorithmen –Eine Einführung. Oldenbourg 2010<br />

[14] Johnson-Laird, P. N.: Mental Models. University Press 1983<br />

[15] Urbas, L., Ziegler, J., Doherr, F: Produktergonomie in der<br />

Prozessautomatisierung. Zeitschrift <strong>für</strong> Arbeitswissenschaft<br />

66(2-3), S.169-182, 2012<br />

[16] VDI/VDE 2186: Einheitliche Anzeige- und Bedienoberfläche<br />

<strong>für</strong> Antriebsregelgeräte, 1999<br />

[17] VDI/VDE 2187: Einheitliche Anzeige-und Bedienoberfläche<br />

<strong>für</strong> digitale Feldgeräte, 2002<br />

[18] FDT Group: FDT 2.0 Technical Specification 1.0, 2012.<br />

[19] Douma, B., Laubenstein, A.: Geräte Integration - die Realität.<br />

Computer & Automation 4/08, S. 190-193, 2008<br />

[20] Schwibach, M., Pelz, M.: EDD und FDT/DTM – Wo liegen die<br />

Unterschiede? <strong>atp</strong> – Automatisierungstechnische Praxis<br />

48(2), S. 53-55, 2006<br />

[21] Emerson: AMS Suite. http://www2.emersonprocess.com/<br />

en-us/brands/amssuite/amsdevicemanager/pages/<br />

amsdevicemanager.aspx<br />

[22] Kumpfmüller, H.-G., Lange, R.: FDI Device Integration – Best<br />

of Both Worlds. <strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische<br />

Praxis 6(10), S. 16-19, 2010<br />

[23] IEC 61804-2: Function blocks (FB) for process control – Part<br />

2: Specification of FB concept, 2007<br />

[24] Bender, K., Großmann, D., Danzer, B.: FDT + EDD + OPC UA = FDD<br />

UA. Die Gleichung <strong>für</strong> eine einheitliche Gerätebeschreibung?<br />

<strong>atp</strong> – Automatisierungstechnische Praxis 49(2), S. 48-54, 2007<br />

[25] Molich, R., Nielsen, J: Improving a human-computer dialogue<br />

– Communications of the ACM 33, 3 (March), 338-348, 1990<br />

[26] Stöß, M., Fengler, F., Urbas, L.: Harmonisierung des<br />

Nutzererlebens bei der Interaktion mit Feldgeräten durch<br />

FDI. In: Tagungsband KommA’13, [CD]. ifak e.V. 2013<br />

[27] IEC/TR 62453-61: Field Device Tool (FDT) interface specification<br />

– Device Type Manager (DTM) styleguide for common<br />

object model, 2009<br />

54<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


auch Standardparameter <strong>für</strong> verschiedene Feldgerättypen,<br />

wie Druckmessgeräte, Temperaturessgeräte,<br />

Durchflussmessgeräte oder Stellungsregler, zu definieren<br />

und Empfehlungen <strong>für</strong> deren Beschriftung zu<br />

geben (caption). Das beschleunigt insbesondere die<br />

Identifikation der Elemente des Informationsraums,<br />

da Wissen dann von einem Gerät des Herstellers A<br />

auf ein Gerät eines Herstellers B übertragbar wird.<br />

Das Resultat der beschleunigten Identifikation von<br />

Standardparametern verbessert folglich zusätzlich<br />

die Navigation.<br />

ZUSAMMENFASSUNG UND FAZIT<br />

Der Beitrag zeigt, welche Aspekte aus dem vorgestellten<br />

Modell von Baxley zur Verbesserung der Gebrauchstauglichkeit<br />

von Inbetriebnahmeoberflächen<br />

beachtet werden müssen. Um diese Aspekte dem Entwickler<br />

nahe zu bringen, haben die Autoren und <strong>das</strong><br />

FDI Style Guide Team den FDI Usability Style Guide<br />

entwickelt.<br />

Besonders positiv zu bewerten ist, <strong>das</strong>s viele Hersteller<br />

von Automatisierungstechnik wie ABB, Samson,<br />

Siemens, Emerson, Honeywell, Yokogawa und<br />

Endress+Hauser bei der Entwicklung des FDI Usability<br />

Style Guides beteiligt waren. Am Review-Prozess<br />

des Style Guides nahmen zusätzlich die Mitglieder der<br />

FDT Group, der Hart Communication Foundation, der<br />

Fieldbus Foundation, der Profibus-Nutzerorganisation<br />

und der OPC Foundation teil. Ihre Erfahrungen und<br />

<strong>das</strong> Wissen der Anwender (Namur) sind dabei in<br />

einem herstellerübergreifenden Style Guide eingebracht<br />

worden.<br />

Zusätzlich war es vorteilhaft, <strong>das</strong>s der FDI Usability<br />

Style Guide bereits während der Spezifikation der FDI-<br />

Technologie entwickelt wurde. Damit konnte konzeptuellen<br />

Fehlern beziehungsweise Beeinträchtigungen<br />

der Gebrauchstauglichkeit schon in dieser Phase vorgebeugt<br />

werden. Zudem hat die Style-Guide-Entwicklung<br />

auch Optimierungspotenziale in den EDD- und<br />

FDT-Spezifikationen aufgezeigt. Beispielsweise gibt es<br />

derzeit noch keine <strong>Schnittstellen</strong>, um einheitliche<br />

Schriftarten- und Farben im UID und UIP sicherzustellen.<br />

Diese konnten aufgrund der Roadmap nicht mehr<br />

berücksichtigt werden, sind aber bereits als Änderungsvorschläge<br />

vorbereitet.<br />

MANUSKRIPTEINGANG<br />

19.12.2013<br />

Im Peer-Review-Verfahren begutachtet<br />

AUTOREN<br />

Dipl.-Ing. MARKUS STÖSS (geb. 1983) ist wissenschaftlicher<br />

Mitarbeiter an der Professur <strong>für</strong> Prozessleittechnik.<br />

Seine Arbeitsgebiete sind formale Modelle und Unterstützungssysteme<br />

<strong>für</strong> <strong>das</strong> HMI-<strong>Engineering</strong> und Operator-<br />

Training-Systeme.<br />

TU Dresden,<br />

Fak. Elektrotechnik und Informationstechnik,<br />

D-01062 Dresden,<br />

Tel. +49 (0) 351 46 33 21 62, E-Mail: markus.stoess@tu-dresden<br />

Dipl.-Wirt.-Ing. FRANK FENGLER (geb. 1966) ist Head of<br />

Device Integration bei ABB <strong>für</strong> Measurement Products im<br />

Bereich Prozess Automation. Seine Kompetenzen umfassen<br />

im Product & Technology Management die Feldbusprotokolle<br />

Profibus und Foundation Fieldbus, HART,<br />

Wireless, mit den zugehörigen Geräteintegrationstechnologien<br />

EDD, FDT/DTM, FDI und die entsprechenden<br />

Device & Asset Management Tools <strong>für</strong> Feldgeräte.<br />

ABB Automation GmbH,<br />

Schillerstraße 72, D-32425 Minden,<br />

Tel. +49 (0) 571 830 11 71,<br />

E-Mail: frank.fengler@de.abb.com<br />

Dipl.-Ing. ACHIM LAUBENSTEIN (geb. 1955) ist bei ABB in<br />

der Division Process Automation zuständig <strong>für</strong> Feldbusstandardisierung.<br />

Er ist Executive Director der FDI<br />

Cooperation, Mitglied im Executive Committee der FDT<br />

Group und der Fieldbus Foundation sowie im Beirat<br />

der Profibus-Nutzerorganisation.<br />

ABB Automation GmbH,<br />

Schillerstraße 72, D-32425 Minden,<br />

Tel. +49 (0) 571 830 18 47,<br />

E-Mail: achim.laubenstein@de.abb.com<br />

Prof. Dr.-Ing. LEON URBAS (geb. 1965) ist Inhaber der Professur<br />

<strong>für</strong> Prozessleittechnik an der Technischen Universität<br />

Dresden. Seine Arbeitsgruppe untersucht Modelle, Methoden<br />

und Werkzeuge <strong>für</strong> <strong>das</strong> <strong>Engineering</strong> verteilter Prozessführungssysteme<br />

mit Schwerpunkt auf der Analyse, Bewertung<br />

und nutzerfreundlichen Gestaltung der Mensch-Technik-Interaktion<br />

in der Prozessindustrie. Er ist Sprecher des<br />

GMA Fachausschuss 5.16 Middleware in der AT, Mitglied im<br />

Namur AK 1.12 Modularisierung und Beiratsmitglied im<br />

processNet-Gremium PAAT.<br />

TU Dresden,<br />

Fak. Elektrotechnik und Informationstechnik,<br />

D-01062 Dresden, Tel. +49 (0) 351 46 33 96 14,<br />

E-Mail: leon.urbas@tu-dresden.de<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

55


HAUPTBEITRAG<br />

Package-Unit-Integration<br />

in der Prozessindustrie<br />

Was fehlt <strong>für</strong> Plug-and-produce?<br />

Die Integration einer Package Unit in ein übergeordnetes Leitsystem ist mit großem<br />

manuellen Aufwand verbunden. Verschiedene Aspekte der Automatisierung, wie<br />

Bedienbilder, Zustände von Ablaufketten oder Verriegelungen, müssen <strong>für</strong> die Visualisierung<br />

und Führung der Package Unit in einem übergeordneten Leitsystem<br />

manuell nachgebildet werden. Der Beitrag beschreibt, wie sich bei geschickter Nutzung<br />

vorhandener Technologien der Aufwand deutlich reduzieren, sowie die einzelnen<br />

Technologien gleichzeitig zu einer modularen Plug-and-produce-Methodik<br />

ausbauen lassen. Eine wesentliche Voraussetzung hier<strong>für</strong> ist eine einheitlich formalquantitative<br />

Beschreibung verschiedener Aspekte der Package Unit und der darauf<br />

aufbauenden Werkzeugketten.<br />

SCHLAGWÖRTER Package Unit / Integration / Leitsystem / EDDL<br />

Package Unit Integration in Process Industry –<br />

What is missing for plug-and-produce?<br />

The integration of package units in a SCADA or DCS involves considerable manual<br />

efforts. Various aspects of automation such as faceplates, states of sequences or interlocks<br />

are to be reproduced for the visualization and management of the package<br />

unit manually in the master control system. With a clever use of existing technologies<br />

the integration effort can not only significantly be reduced, the existing technologies<br />

also could extended to a modular plug-and-produce methodology. An essential<br />

precondition for this is a uniform formal quantitative description of various<br />

aspects of the package unit and tool chains based on the formal descriptions.<br />

KEYWORDS package unit / integration / control system / EDDL<br />

56<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


MICHAEL OBST, ANNA HAHN, LEON URBAS, Technische Universität Dresden<br />

Die Package Units der Prozessindustrie sind<br />

zumeist nicht <strong>für</strong> einen Plug-and-produce-<br />

Betrieb ausgelegt. Während die physikalische<br />

Integration von Package Units in eine Anlage<br />

über ausgefeilte Kupplungssysteme <strong>für</strong> Stoffund<br />

Energieströme als prinzipiell gelöst bezeichnet<br />

werden kann, ist die nahtlose Integration der Automatisierungstechnik<br />

einer Package Unit in ein übergeordnetes<br />

Leitsystem mit erheblichem manuellen <strong>Engineering</strong>-Aufwand<br />

verbunden.<br />

Aus Sicht des Namur AK 1.12 ist eine Package Unit<br />

ein Modul. Das in [1] beschriebene integrierbare Modul<br />

als eine Variante der vorgeschlagenen Modultypen besitzt<br />

ein eigenes Automatisierungssystem, <strong>das</strong> über ein<br />

übergeordnetes Leitsystem direkt beeinflusst werden<br />

kann. Diese Module sind hinsichtlich ihrer Funktion<br />

und ihres Einsatzbereichs fest definiert und können<br />

nicht verändert werden. Die Integration in eine Anlage<br />

findet stofflich, energetisch und automatisierungstechnisch<br />

statt. Über die <strong>Schnittstellen</strong> zu den Modulen<br />

lassen sich auf dem Leitsystem modulübergreifend Prozessführungsstrategien<br />

verwirklichen.<br />

Aus Sicht der Automation besteht eine Package Unit<br />

im Wesentlichen aus einer modulinternen Steuerung<br />

zum Regeln und Steuern modulspezifischer Abläufe<br />

sowie aus Einzelsteuerfunktionen und einer Sicherheitslogik.<br />

Darüber hinaus werden <strong>Schnittstellen</strong> zur<br />

Integration an eine übergeordnete Anlage bereitgestellt.<br />

Da eine Package Unit herstellerübergreifend und<br />

anlagenunabhängig konzipiert wird, muss dieser eine<br />

eindeutige Nummerierung, beispielsweise in Form von<br />

Tag-Nummern, zugeordnet werden. Diese Zuordnung<br />

kann nach DIN EN 81346 erfolgen und erfüllt somit<br />

ein Mindestmaß an Forderungen nach eindeutiger<br />

Identifizierung [1]. Weiterhin muss die Package Unit<br />

in der Lage sein, der übergeordneten Prozessanlage<br />

Auskunft über ihren Zustand zu übermitteln, beispielsweise<br />

Information über aktive Schritte lokaler<br />

Ablaufketten, den aktuellen Prozesszustand oder der<br />

Bedienzustände.<br />

In [2] wurden verschiedene Beschreibungsmittel im<br />

Hinblick auf ihre Eignung zur effizienten Abbildung<br />

der <strong>für</strong> die Package-Unit-Integration notwendigen Information<br />

analysiert. In diesem Beitrag wird nun aufgezeigt,<br />

<strong>das</strong>s eine Package-Unit-Integration mit den<br />

bei Feldgeräten etablierten Technologien EDD/GSD<br />

nahezu vollständig möglich ist. Im Gegensatz zu den<br />

Analyseergebnissen von [2] werden keine weiteren<br />

Beschreibungsmittel notwendig sein. Dies erlaubt,<br />

analog zur Argumentation in [3], eine effiziente Implementierung<br />

mit den aktuellen Integrationstechnologien<br />

der Automation.<br />

1. TECHNOLOGIEÜBERSICHT<br />

Viele Prozessleitsysteme unterstützen EDD als Integrationstechnologie<br />

<strong>für</strong> Feldgeräte, die über einen<br />

Feldbus wie Profibus angebunden sind. Unter Verwendung<br />

einer Geräteparametrierung durch GSD<br />

wird der zyklische Datenverkehr über Profibus realisiert.<br />

Dies stellt eine sinnvolle Ergänzung zur Geräteparametrierung<br />

durch EDD dar und erfüllt die<br />

Forderung nach der Nutzung standardisierter Technologien.<br />

Durch eine geschickte Ausnutzung dieser<br />

Konzepte und Beschreibungsmittel kann die Package-Unit-Integration<br />

in vollem Umfang realisiert werden,<br />

ohne auf die im FDI-Konzept vorgesehenen<br />

Anhänge ausweichen zu müssen. Dazu ergibt sich<br />

aus dieser Integrationsmethode eine mögliche<br />

Kopplung an <strong>das</strong> FDI Device Package. Erste Ansätze<br />

zur Ableitung von Wartungs- und Diagnoseinformation<br />

aus einem FDI Equipment Package liefert beispielsweise<br />

[4].<br />

1.1 GSD/GSDML<br />

Die Gerätestammdaten-Datei (GSD) beschreibt textuell<br />

die Eigenschaften eines Profibus- oder Profinet-<br />

Feldgerätes. In einer GSD werden neben den Kenndaten<br />

eines Profibusgerätes auch Informationen zu<br />

seiner Kommunikationsfähigkeit sowie Diagnosewerte<br />

verwertet. Für einen rein zyklischen Aus-<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

57


HAUPTBEITRAG<br />

tausch von Messdaten und Stellgrößen zwischen der<br />

Package Unit und dem Prozessleitsystem wäre eine<br />

GSD ausreichend [6].<br />

1.2 EDDL<br />

Die in IEC 61804-3 normierte Electronic Device Description<br />

Language (EDDL) erlaubt eine formale Beschreibung<br />

des nach außen sichtbaren Informationshaushalts<br />

eines Feldgeräts (beispielsweise Parameter),<br />

die Definition des Kommunikationsverhaltens, sowie<br />

die Definition von Navigationsstrukturen und von Bediendialogen.<br />

Ergänzt wird dies durch die Definition<br />

von Methoden zur Beeinflussung des Interaktionsverhaltens<br />

(Wizards, Eingabevalidierung) und zum Ablauf<br />

komplexer Vorgänge, wie beispielsweise eine Kalibrierung.<br />

Die EDD-Datei wird von einem Werkzeug wie zum<br />

Beispiel Simatic PDM oder isEDDview eingelesen, interpretiert<br />

und dargestellt, ganz ähnlich wie eine HT-<br />

ML-Datei von einem Browser.<br />

1.3 FDI<br />

Die Sprache EDDL ist eines der Kernelemente des FDI-<br />

Konzepts zur Beschreibung eines Feldgerätes durch ein<br />

einziges FDI Device Package [7]. In [4] wird an zwei<br />

Beispielen überprüft, ob und in welchem Umfang <strong>das</strong><br />

FDI-Konzept sich eignet, Sinneinheiten zu beschreiben,<br />

die aus mehreren intelligenten Feldgeräten zusammengesetzt<br />

sind. Die Ergebnisse dieser Untersuchungen<br />

machen deutlich, <strong>das</strong>s die Beschreibung einzelner Aspekte<br />

einer aus vielen Feldgeräten komponierten Einheit<br />

mit FDI möglich ist. Verschiedene Restriktionen<br />

von FDI erfordern jedoch komplexe Kommunikationswege,<br />

beispielsweise über den optionalen OPC-UA-<br />

Dienst eines FDI-Servers.<br />

1.4 Integrationsbedarf<br />

In Tabelle 1 werden die zwischen Package Unit und Leitsystem<br />

zu übertragenden Informationen nach der Auffassung<br />

der Autoren aufgelistet und hinsichtlich einer<br />

möglichen Beschreibung mit EDD und GSD anhand des<br />

Übertragungszeitpunktes während eines Plug-and-produce-Schritts,<br />

den Zugriffsrechten und des Übertragungszyklus<br />

klassifiziert. Dieser Vergleich zeigt auf,<br />

<strong>das</strong>s der Informationsaustausch prinzipiell durch EDD<br />

und GSD beschrieben werden kann. Durch eine einheitliche<br />

Implementierung und gut entwickelte Strukturen<br />

lassen sich Vorlagen <strong>für</strong> eine einheitliche Integration<br />

ableiten. Durch deren Einsatz können Package-Unit-<br />

Daten in automatisierten Prozessen eingelesen und interpretiert<br />

werden.<br />

Dieses Vorgehen erlaubt eine weitgehend automatisierte<br />

Integration einer Package Unit in ein Prozessleitsystem<br />

mit bestehenden Technologien, welche mit den<br />

Entdeckungsmechanismen von FDI zu einem vollständig<br />

automatisierbaren Plug-and-produce-System ausgebaut<br />

werden können.<br />

2. PACKAGE-UNIT-INTEGRATION<br />

Ein integrierbares Modul [5] ist als eine in sich geschlossene<br />

Einheit definiert, die ihre Funktion prinzipiell<br />

unabhängig von der Anlage erbringt. Die Basisautomatisierung<br />

zur Realisierung der Grundfunktionen<br />

ist also Bestandteil des Moduls. Damit die Module als<br />

modulare Anlage zusammenwirken können, müssen<br />

sie <strong>Schnittstellen</strong> anbieten, welche den Informationsaustausch<br />

zu anderen Komponenten der Anlage ermöglichen.<br />

NE 148 geht davon aus, <strong>das</strong>s die Visualisierung<br />

verschiedene Aspekte der Rezeptsteuerung, der Diagnose<br />

und der Archivierung auf einem zentralen Prozessleitsystem<br />

realisiert, prinzipiell ist jedoch auch<br />

eine peer-to-peer-Architektur denkbar. Unabhängig<br />

von der Architektur setzt dieser Ansatz standardisierte<br />

<strong>Schnittstellen</strong> und Beschreibungsmittel voraus, mit<br />

denen statische Information wie Bedienfließbilder,<br />

Funktions- und Rezeptschnittstellen sowie dynamische<br />

Daten wie aktuelle Prozess- und Automationszustände<br />

übermittelt werden.<br />

Als Maßgabe <strong>für</strong> die Funktionsallokation empfiehlt<br />

die NE 148, prozessnahe Funktionen mit sehr kurzen<br />

Reaktionszeiten auf der Basisautomatisierung der Package<br />

Unit zu realisieren. Package-Unit-übergreifende<br />

Rezepte und übergeordnete Funktionen ohne harte<br />

Echtzeitanforderungen sind hingegen im PLS anzusiedeln.<br />

Weiterhin fordert die NE 148 <strong>für</strong> die Übertragung<br />

dieser Information die Definition einer geeigneten<br />

Schnittstelle, ohne diese selbst technisch auszuspezifizieren.<br />

Darüber hinaus werden Zusatzfunktionen definiert,<br />

die <strong>das</strong> PLS bereitstellen muss, um eine Integration<br />

zu ermöglichen:<br />

Steuerung und Regelung von modulübergreifenden<br />

Funktionen: Voraussetzung ist die Steuerung einzelner<br />

Funktionen durch <strong>das</strong> PLS.<br />

Rezeptsteuerung der mit dem PLS verbundenen<br />

Package Unit: Da<strong>für</strong> wird eine geeignete Aufrufschnittstelle<br />

benötigt.<br />

Überwachung der Leistungsgrenzen der Module<br />

und der Infrastruktur: Es muss ein spezifikationsgerechter<br />

Betrieb <strong>für</strong> jede Package Unit sichergestellt<br />

werden.<br />

Package-Unit-Identifikation: Jede einzelne Package<br />

Unit muss eindeutig identifizierbar sein.<br />

Für die Einordnung der einzelnen Integrationsaspekte<br />

in einen Integrationsprozess gibt Bild 1 einen Überblick<br />

über die notwendigen Integrationsschritte einer Package<br />

Unit in ein Leitsystem. In einem ersten <strong>Engineering</strong>-<br />

Schritt werden die einzelnen Funktionen einer Anlage<br />

aus Modulen beziehungsweise einer Package Unit zusammengesetzt.<br />

Hier wird auf Ebene einer verfahrenstechnischen<br />

Funktion, beispielsweise einer Reaktion,<br />

die Auswahl getroffen. In unserem Beispiel wird jedes<br />

58<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


Information<br />

Übertragungszeitpunkt<br />

Zugriffsrechte Ü-Zyklus Notwendige<br />

Beschreibungssprache<br />

Stat. Parameter plug lesend 1-malig EDDL<br />

Dyn. Parameter<br />

plug, produce<br />

lesend,<br />

schreibend<br />

1+zyklisch<br />

EDDL<br />

GSD<br />

SFC Struktur plug lesend 1-malig EDDL<br />

SFC Zustand<br />

plug, produce<br />

lesend,<br />

schreibend<br />

Alamierung plug, produce schreibend<br />

1+zyklisch<br />

Ereignisgesteuert<br />

EDDL<br />

GSD<br />

EDDL<br />

TABELLE 1:<br />

Gegenüberstellung<br />

der zu übertragenden<br />

Informationen einer<br />

Package Unit<br />

BILD 1: Schritte<br />

der Integration<br />

einer Package Unit<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

59


HAUPTBEITRAG<br />

Modul vereinfacht über die Anzahl und den Typ der<br />

Ein- und Ausgänge, und die parallel nutzbaren Einheiten<br />

eines Typs beschrieben. Die Modulklasse Tank<br />

(2/2/2) in Bild 1 ist exemplarisch durch zwei Eingänge,<br />

die gleichzeitige Nutzung zweier unabhängiger Tank-<br />

Einheiten in dem Modul sowie zweier Ausgänge charakterisiert.<br />

In diesem Schritt erfolgt eine Spezifizierung<br />

der Module auf Klassen-Ebene, wobei jede Klasse<br />

über einen definierten Satz generischer Eigenschaften<br />

und Funktionen definiert ist.<br />

Im zweiten Schritt, dem modularen Automationsengineering,<br />

wird <strong>das</strong> Gesamtverhalten der Anlage konfiguriert.<br />

Dieser Schritt umfasst die da<strong>für</strong> notwendigen<br />

Teilschritte, beginnend bei der Konfiguration (2.1). Hier<br />

wird zum Beispiel die Kommunikationsschnittstelle<br />

des Moduls mit dem übergeordneten PLS konfiguriert.<br />

Die weiteren Teilschritte (2.2) – (2.4) konfigurieren die<br />

modulübergreifende Logik, die Rezepte und die Bedienbilder.<br />

Aufgrund der Beschreibung der Gesamtfunktion<br />

der Anlage mit Hilfe der Modulklassen und der<br />

entsprechenden generischen Eigenschaften, können<br />

diese Konfigurationen ohne die Kenntnis der konkreten<br />

Modulinstanzen erfolgen. Dies ermöglicht zum einen<br />

ein sehr frühes <strong>Engineering</strong> des Automatisierungssystems<br />

der Gesamtanlage und später einen einfachen<br />

Austausch des Moduls gegen ein anderes, welches die<br />

Fähigkeiten dieser Modulklasse unterstützt. Dieses<br />

Vorgehen kann um Profile, ähnlich wie bei der Integration<br />

von Feldgeräten über Feldbusse, ergänzt werden,<br />

um die Rückwärtskompatibilität zu älteren Modulklassenbeschreibungen<br />

zu gewährleisten. Im dritten Integrationsschritt<br />

wird die Konfiguration auf <strong>das</strong> Automatisierungssystem<br />

der Anlage geschrieben.<br />

Erst in einem vierten Schritt der Integration werden<br />

die konkreten Module, die Modulinstanzen, an <strong>das</strong><br />

überlagerte Automatisierungssystem angeschlossen<br />

(Plug). Nachfolgend werden die Randbedingungen<br />

(zum Beispiel Druckstufen, Grenzwerte) sowie der<br />

Funktionsumfang der angesteckten konkreten Module<br />

gegeneinander überprüft (Check). Bevor die Module in<br />

Betrieb genommen werden können, erfolgt ein Konfigurationsschritt,<br />

in dem die spezifischen Module automatisch<br />

ihre Adressen zugewiesen bekommen oder<br />

entsprechend parametriert werden (Configure). Dieses<br />

Vorgehensmodell implementiert <strong>das</strong> in [12] vorgestellte<br />

Plug-check-configure-and-produce-Konzept <strong>für</strong> die<br />

Prozessindustrie.<br />

2.1 Variablen und Parameter<br />

Die Grundlage jeder Geräteparametrierung bildet die<br />

Beschreibung der Variablen und Parameter. Ziel soll es<br />

sein, auf möglichst einfache und wiederverwendbare<br />

Weise die vollständige Package Unit zu beschreiben.<br />

Diese Beschreibung soll auf ihre Kernkomponenten<br />

abstrahiert und eine einheitliche Bezeichnung eingeführt<br />

werden, so<strong>das</strong>s eine Vorlage <strong>für</strong> die Beschreibungen<br />

einer Package Unit entsteht. Dabei wird zwischen<br />

drei Ebenen der Beschreibung unterschieden:<br />

Ebene 1 – Deklaration aller verwendeten Variablen.<br />

Diese werden vom Package-Unit-Hersteller zur Verfügung<br />

gestellt und in der EDD dokumentiert. Damit auf<br />

Ebene 2 eine Unterscheidung der Variablen möglich ist,<br />

muss die Variablendeklaration folgende Mindestinformation<br />

liefern:<br />

Grundsätzlich wird zwischen statischen und dynamischen<br />

Parametern unterschieden. Darüber hinaus<br />

können dynamische Parameter in zyklische und azyklische<br />

unterteilt werden. Sobald ein Parameter dynamische<br />

Eigenschaften aufweist, wird diese Eigenschaft<br />

im class-specifier festgehalten. Eine weitere Unterscheidung,<br />

sowohl der statischen als auch der dynamischen<br />

Parameter, findet im HANDLING statt. Hier wird definiert,<br />

ob der Nutzer ausschließlich Lese- oder auch<br />

Schreibrechte erhält.<br />

VARIABLE identifier<br />

{<br />

// eindeutige schema-<br />

// tische Bezeichnung<br />

CLASS class-specifier; // beschreibt<br />

// Verwendungsweise<br />

// der Variablen<br />

HANDLING specifier;<br />

TYPE type-specifier;<br />

}<br />

LISTING 1: Eigenschaften einer EDD-Variablen<br />

Ebene 2 – Sinneinheiten: Abhängig von diesen Eigenschaften<br />

und der späteren Verwendung werden sämtliche<br />

Parameter in Ebene 2 in Sammelklassen festgeschrieben.<br />

Eine solche Sammlung von Variablen kann<br />

in EDDL wie folgt dargestellt werden:<br />

COLLECTION OF VARIABLE identifier<br />

{<br />

LABEL string-specifier;<br />

MEMBERS<br />

{<br />

member-specifier; // z. B. Variablen gleichen<br />

// HANDLINGs,<br />

member-specifier; // dynamische/statische<br />

// Eigenschaften,<br />

member-specifier; // gleiche Verwendung<br />

…<br />

}<br />

}<br />

LISTING 2: Package-Unit-Parameter als Teil<br />

einer COLLECTION<br />

Ebene 3 – Kommunikation: Innerhalb der Ebene 3 werden<br />

Kommunikationsregeln festgelegt. Eine EDD-Anwendung-<br />

nutzt <strong>für</strong> die Kommunikation automatisch<br />

Kanal MS02 von Profibus, also eine azyklische Kommunikation<br />

zwischen PLS und der Package Unit. Profibus<br />

ist ein modulbasiertes Kommunikationsprotokoll,<br />

welches die einzelnen Module über SLOT und die genaue<br />

Platzierung innerhalb des Moduls über INDEX<br />

festlegt. Beide Angaben müssen innerhalb der EDD<br />

hinterlegt sein. Darüber hinaus ist es nicht möglich,<br />

60<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


Inhalte gleichzeitig zu lesen und zu schreiben. Was zur<br />

Folge hat, <strong>das</strong>s COLLECTIONS, deren Inhalte gelesen<br />

und geschrieben werden können, innerhalb der Kommunikation<br />

in zwei getrennten Paketen behandelt werden<br />

müssen.<br />

Solche Kommunikationspakete werden folgendermaßen<br />

beschrieben:<br />

COMMAND identifier<br />

{<br />

INDEX<br />

SLOT<br />

1…n;<br />

1…254;<br />

OPERATION READ | WRITE;<br />

TRANSACTION<br />

{<br />

REQUEST<br />

{<br />

data-items-specifier;<br />

data-items-specifier;<br />

}<br />

REPLY<br />

{<br />

data-items-specifier;<br />

data-items-specifier;<br />

}<br />

}<br />

}<br />

LISTING 3: Definition eines Kommunikationspaketes<br />

Die zyklische Kommunikation über MS0 wird innerhalb<br />

der GSD-Datei definiert. Dabei wird beschrieben, welche<br />

Adressen der Package Unit in einem zyklischen Datenaustausch<br />

mit dem PLS unterstützt werden – diese<br />

Adressen werden auf <strong>das</strong> Slot/Index-Modell der EDD<br />

abgebildet. Die Zykluszeit wird von den meisten PLS<br />

automatisch generiert.<br />

2.2 Verhalten von Ablaufsteuerungen<br />

Ablaufsteuerungen ermöglichen die Verarbeitung sequenzieller<br />

oder paralleler Funktionen eines zeit- oder<br />

ereignisdiskreten Prozesses. Sie werden zum Koordinieren<br />

von kontinuierlichen Funktionen eingesetzt und<br />

steuern komplexe Prozesse. Diese bestehen im Allgemeinen<br />

aus einer oder mehreren Schrittfolgen. Die technische<br />

Umsetzung wird mit Hilfe der Sequential Function<br />

Charts (SFC) realisiert. Eine Schrittfolge besteht<br />

immer aus einem Start- und einem Endschritt. Dazwischen<br />

befinden sich Schrittfolgen, bestehend aus Aktionsschritten<br />

und Kanten.<br />

Zur formalen Beschreibung von Ablaufsteuerungen<br />

werden neben der Ablaufsprache nach IEC 61131 auch<br />

Zustandsdiagramme oder Petri-Netze verwendet. Ein<br />

Vorteil der Zustandsdiagramme ist deren einfache Möglichkeit<br />

zur Fehlerdiagnose sowie die einfache Transformation<br />

in bereits existierende Programmiersprachen.<br />

Jedoch funktioniert die Beschreibung mit Hilfe<br />

der Zustandsdiagramme ausschließlich <strong>für</strong> einfache<br />

oder alternativverzweigte Sequenzen, nicht <strong>für</strong> parallele,<br />

da sich <strong>das</strong> Diagramm immer in genau einem Zustand<br />

befinden muss.<br />

Betrachtet man nun die Integration der Ablaufsteuerung<br />

einer Package Unit in ein übergeordnetes Leitsystem,<br />

wird folgende Information während des Betriebs<br />

der Package Unit benötigt:<br />

Strukturinformation zur Visualisierung der<br />

Ablaufkette<br />

Anzahl der Plätze, Transitionen,<br />

einheitliches Bezeichnungsschema,<br />

Strukturinformation zu Verzweigungen und<br />

Zusammenführung, Art der Verzweigung<br />

Information über Verklemmungen<br />

Information über aktive Plätze und Transitionen<br />

Die Struktur einer Ablaufsteuerung lässt sich herstellerneutral<br />

mit Hilfe eines bipartiten Graphs abbilden<br />

(Bild 2). Dabei spielt die aktuell gewählte Bezeichnung<br />

nur eine nebensächliche Rolle, da sich die<br />

Struktur des Graphen eindeutig mit Verknüpfungsmatrizen<br />

fassen lässt. Daraus entstehen zwei Matrizen,<br />

welche sich allein auf der Grundlage ihrer binären<br />

Werte 1:1 zum abgebildeten Graphen wiederherstellen<br />

lassen. Eine Matrix beschreibt die Beziehung<br />

jeder Transition zu jedem Platz, eine zweite die<br />

Beziehung vom Platz zur Transition. Sobald eine<br />

direkte Verbindung vorhanden ist, wird eine 1 in der<br />

Matrix hinterlegt, andernfalls erscheint eine 0. Eine<br />

weitere Informationsquelle innerhalb dieser Matrizen<br />

stellt die Aufeinanderfolge von mehreren Plätzen<br />

nach einer Transition dar, beziehungsweise der Folge<br />

ein und derselben Transition nach zwei unterschiedlichen<br />

Plätzen (blau markierter Bereich). Daraus lässt<br />

sich <strong>für</strong> die Parallelverzweigung folgende Regel ableiten:<br />

Folgen aus einer Transition zwei Plätze, öffnet<br />

sich die Parallelverzweigung. Folgt aus zwei Plätzen<br />

dieselbe Transition, schließt sich die Verzweigung.<br />

Aufgrund dieser Regel lässt sich ohne Übermittlung<br />

zusätzlicher Information der Graph aus einfachen<br />

Matrizen wiederherstellen. Ein wesentlicher Vorteil<br />

dieser Darstellung gegenüber anderen, wie beispielsweise<br />

der Adjazenzmatrix, ist die ausschließliche<br />

binäre Kodierung.<br />

Die Beschreibung der aktivierten Schritte kann über<br />

zwei binäre Vektoren mit Lese- und Schreibrechten<br />

übermittelt werden. Je ein Vektor beschreibt dabei die<br />

aktiven Plätze und einer die Transitionen. Mit Hilfe<br />

eines Manual Override kann der Operateur, mit den<br />

entsprechenden Berechtigungen, bei Verklemmungen<br />

aktiv eingreifen und die Transition manuell weiterschalten.<br />

Die von der Package Unit mitgelieferte Darstellung<br />

in Matrizenform kann problemlos mit der Sprache<br />

EDDL beschrieben werden. Dazu werden die zwei Matrizen<br />

serialisiert, so<strong>das</strong>s zwei binäre Vektoren übertragen<br />

werden müssen. Darüber hinaus können die<br />

aktiven Plätze und Transitionen ebenfalls über zwei<br />

Vektoren oder auch einzeln übertragen werden (siehe<br />

Listing 4 und 5).<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

61


HAUPTBEITRAG<br />

BILD 2: Darstellung einer Ablaufkette<br />

durch einen Graphen und Matrix<br />

Start<br />

p1<br />

t1<br />

Schritt 1 p2<br />

Schritt 1<br />

p3<br />

t2<br />

Ende<br />

p4<br />

BILD 3: Beispiel HMI der<br />

Formalisierung in Listing 6<br />

VARIABLE PU_AS_PzuT<br />

{<br />

LABEL „Struktur der AS: P zu T“;<br />

CLASS LOCAL;<br />

HANDLING READ;<br />

TYPE BITSTRING;<br />

{<br />

DEFAULT_VALUE „10010110“;<br />

}<br />

}<br />

LISTING 4: Beschreibung der Verbindungen<br />

der Plätze zu Transitionen<br />

VARIABLE PU_AS_TzuP<br />

{<br />

LABEL „Struktur der AS: T zu P“;<br />

CLASS LOCAL;<br />

HANDLING READ;<br />

TYPE BITSTRING;<br />

{<br />

DEFAULT_VALUE „01100001“;<br />

}<br />

}<br />

LISTING 5: Beschreibung der Verbindungen<br />

der Transitionen zu Plätzen<br />

Darüber hinaus muss <strong>für</strong> die Deserialisierung im Prozessleitsystem<br />

Information zur Anzahl an Spalten und<br />

Zeilen der Matrix mit übertragen werden. Dies bedeutet<br />

vier zusätzliche Variablen, die jedoch innerhalb derselben<br />

Kommunikationsgruppe wie die serialisierten Matrizen<br />

übermittelt werden können.<br />

2.3 Bedienfließbild<br />

Ein weiterer Aspekt der Integration einer Package Unit<br />

in ein Leitsystem ist die herstellerneutrale Beschreibung<br />

der Bedienfließbilder einer Package Unit, um diese in<br />

einem übergeordneten Leitsystem automatisch zu instanziieren.<br />

Das dies grundsätzlich möglich ist, zeigen<br />

die Ergebnisse des Projekts autoHMI [8, 9]. Hier wurden<br />

Bedienfließbilder über den Zwischenschritt eines neutralen<br />

Datenformates direkt aus Rohrleitungs- und Instrumentierungsdiagrammen<br />

(P&ID) generiert. Basis<br />

dieser Transformation ist die Überführung des P&ID und<br />

der dort hinterlegten Information in eine graphenbasierte<br />

Beschreibung der Anlagentopologie, in welcher Knoten<br />

durch Prozessobjekte (Geräte und Apparate) und<br />

Kanten durch stoffliche, energetische und informationstechnische<br />

Verbindungen dargestellt werden. Knoten<br />

und Kanten führen Attribute, die <strong>für</strong> die Generierung<br />

des Bedienfließbildes notwendig sind.<br />

Im vorhergehenden Abschnitt wurde gezeigt, wie die<br />

als Graph abstrahierte Struktur eines SFC in einer EDD<br />

abgebildet werden kann. Um die Information eines Bedienfließbildes<br />

ebenfalls in einer EDD abbilden zu können,<br />

werden zunächst die Unterschiede zur Ablaufkette<br />

dargestellt:<br />

Für die Bildelemente eines SFC müssen Parallelund<br />

Alternativverzweigungen aus der Topologie<br />

inferiert werden, während die in [9] betrachtete<br />

Struktur der Bedienfließbilder alle Bildelemente<br />

vollständig enthält.<br />

Alle Verbindungen eines SFC werden gleich dargestellt.<br />

Die Verbindungen in Bedienfließbildern<br />

kodieren hingegen die Art der Verbindung (Stoff,<br />

Energie, Information), beispielsweise durch Farben<br />

und Linienstärke.<br />

Alle Visualisierungsobjekte eines SFC werden einheitlich<br />

durch zwei Bildsymbole (Schritt oder<br />

Transition) dargestellt, während in prozessorientierten<br />

Bedienfließbildern Symbolbibliotheken<br />

zum Einsatz kommen.<br />

Der dynamische Informationshaushalt einer SFC-<br />

Darstellung kann durch eine boolesche Variable<br />

62<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


<strong>für</strong> den Zustand eines jeden Schrittes (Aktiv/Inaktiv),<br />

eine boolesche Variable <strong>für</strong> den Schaltzustand<br />

pro Transition (Frei/Gesperrt) und einer booleschen<br />

Variablen <strong>für</strong> die manuelle Überbrückung<br />

der Transition <strong>für</strong> die meisten Zwecke ausreichend<br />

gut dargestellt werden. Die Bildsymbole der Bedienfließbilder<br />

sind jedoch komplexe Bibliothekselemente,<br />

die typspezifische Informationsstrukturen<br />

erwarten.<br />

Für die formale Beschreibung eines Bedienfließbildes<br />

in EDDL bedeuten diese Unterschiede, <strong>das</strong>s<br />

eine reine Abbildung der Strukturinformation wie<br />

im Abschnitt 2.2. nicht ausreichend ist. Um beispielsweise<br />

die Bildsymbole der Bedienfließbilder<br />

möglichst in einem einheitlichen Look-and-feel bereitzustellen,<br />

müssen die Instanzen der Symbole<br />

durch <strong>das</strong> übergeordnete Leitsystem beziehungsweise<br />

durch eine separat zu konfigurierende Symbolbibliothek<br />

bereitgestellt werden. In dem generisch<br />

auszuliefernden Bedienfließbild der Package Unit<br />

wird dann über eine Klassen- oder Typ-Bezeichnung<br />

die Referenz hergestellt (siehe Listing 6). Das formalisierte<br />

HMI orientiert sich an der in Bild 3 dargestellten<br />

Visualisierung.<br />

COLLECTION OF VARIABLE PU_HMI_BBD1_Tank1<br />

{<br />

LABEL „Alle Informationen eines Tanks“;<br />

MEMBERS<br />

{<br />

Type, PU_HMI_BBD1_Tank1_Type;<br />

XCoord, PU_HMI_BBD1_Tank1_XCoord;<br />

YCoord, PU_HMI_BBD1_Tank1_YCoord;<br />

Connections, PU_HMI_BBD1_Tank1_Connections;<br />

}<br />

}<br />

VARIABLE PU_HMI_BBD1_Tank1_Type<br />

{<br />

LABEL „Klasse des Faceplates Tank“;<br />

CLASS LOCAL;<br />

TYPE ASCII;<br />

{<br />

DEFAULT_VALUE „TANK“;<br />

}<br />

}<br />

VARIABLE PU_HMI_BBD1_Tank1_XCoord<br />

{<br />

LABEL „X-Koordinate Tank1“;<br />

CLASS LOCAL;<br />

TYPE DOUBLE;<br />

{<br />

DEFAULT_VALUE 394.0909;<br />

}<br />

}<br />

LISTING 6: Beschreibung eines statischen<br />

HMI-Elements in EDDL<br />

Jedes Bedienfließbild wird über eine COLLECTION beschrieben,<br />

in der alle darzustellenden Objekte zusammengefasst<br />

werden. Ein Objekt wird über den Typ, Koordinaten<br />

auf dem Bedienfließbild, weitere objektspezifische<br />

Eigenschaften sowie Verbindungen (Variable:<br />

PU_HMI_BBD1_Tank1_Connections) zu anderen Objekten<br />

beschrieben.<br />

Für die Beschreibung der dynamisierten Bildelemente,<br />

also Bildelemente. welche mit Prozessdaten oder<br />

Zuständen der Package Unit verknüpft sind, muss innerhalb<br />

einer entsprechenden Struktur auf die im Variablenhaushalt<br />

der Package Unit definierte Information<br />

referenziert werden (Listing 7).<br />

VARIABLE PU_HMI_BBD1_Valve1_Fbk<br />

{<br />

LABEL „Verweise auf Signal der Rückmeldung“;<br />

CLASS LOCAL;<br />

TYPE ASCII;<br />

{<br />

DEFAULT_VALUE „PU_VAR_Valve1_Fbk_Open“;<br />

}<br />

}<br />

LISTING 7: Beschreibung eines statischen<br />

HMI-Elements in EDDL<br />

Die Darstellung einer Rohrleitung oder auch einer Signallinie<br />

kann nicht alleine über eine X-Y-Koordinate<br />

beschrieben werden. Hier muss der Verlauf der einzelnen<br />

Punkte der Linie mit definiert werden, zum Beispiel<br />

in Form einer einfachen Liste.<br />

Mit den Algorithmen der autoHMI-Transformationskette<br />

[8] wird <strong>das</strong> in der EDD gemäß Listing 6 formal<br />

beschriebene HMI der Package Unit eingelesen und mit<br />

der Symbolbibliothek des Zielleitsystems instanziiert.<br />

Je nach Offenheit des Leitsystems erfolgt dies durch<br />

externe oder in <strong>das</strong> Leitsystem <strong>integrierte</strong> Werkzeuge.<br />

2.4 Verriegelung<br />

Für den Betreiber einer Package Unit ist es notwendig,<br />

während des Betriebs der Anlage die Verriegelungen zu<br />

beobachten und gegebenenfalls zu bedienen. Zur Sicherung<br />

seines Know-hows wird der Package-Unit-Hersteller<br />

jedoch nicht in allen Fällen einen vollständigen Zugriff<br />

auf die genaue Implementierung zulassen wollen. Ein<br />

häufig eingesetztes Beschreibungsmittel der Verriegelungen<br />

ist die prozessleittechnische Ursachen-Wirkungs-<br />

Matrix. Diese Matrix verbindet eine Ursache ‐ binäre<br />

Größen, die eine Aussage über den Zustand einer technischen<br />

Einrichtung oder des Prozesses erlauben – mit<br />

einer Wirkung. Die Wirkung wird ebenfalls als binäre<br />

Größe dargestellt, die einen geeigneten Stelleingriff in<br />

den Prozess zur Folge hat. Eine Ursache kann mehrere<br />

Wirkungen zur Folge haben, ein und dieselbe Wirkung<br />

kann von verschiedenen Ursachen ausgelöst werden.<br />

Einige Hersteller von Prozessleitsystemen bieten <strong>für</strong><br />

ihre Systeme Safety-Matrix-Werkzeuge an (siehe [10,<br />

11]), mit der diese Methode nahtlos in <strong>das</strong> prozessleit-<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

63


HAUPTBEITRAG<br />

BILD 4:<br />

Skizze eines<br />

im Leitsystem<br />

generierten<br />

aktiven SFC<br />

technische <strong>Engineering</strong> integriert werden kann. Eine<br />

solche Matrix kann mit Inhalten unterschiedlichen<br />

Datentyps, Länge und Zugriffsrechten in einem Datenpaket<br />

übertragen werden. Wie bereits bei den Ablaufsteuerungen<br />

müssen Mechanismen und Abstraktionsmodelle<br />

entwickelt werden, um die Daten sinnvoll in<br />

EDD zu verpacken und an <strong>das</strong> PLS schicken zu können.<br />

Doch was genau ist eine Safety-Matrix und wie unterscheidet<br />

sich diese von einer Matrix zur Beschreibung<br />

von Struktur der Ablaufsteuerung? Auch diese<br />

Matrix hat eine eindeutige Bezeichnung und besteht<br />

aus einer bestimmten Anzahl an Spalten und Zeilen.<br />

Diese Information muss, wie auch schon bei der Ablaufsteuerung,<br />

separat übergeben werden. Den einzigen<br />

Unterschied stellen die Inhalte dar. Während bei<br />

der Ablaufsteuerung nur binäre Inhalte übergeben<br />

werden, muss an dieser Stelle jeder Inhalt einzeln innerhalb<br />

eines Strings weitergeleitet werden. Selbstverständlich<br />

können diese mit Werkzeugen, welche die<br />

EDD zur Verfügung stellt, gebündelt werden, auch die<br />

Datenrate wird hier erheblich höher sein als bei den<br />

Ablaufsteuerungen. Jedoch bietet diese Methode eine<br />

sichere und einfache Möglichkeit, auch komplexere<br />

Strukturen zu übertragen.<br />

3. INTERPRETATION DER EDD IM LEITSYSTEM<br />

Die Beschreibung der Ablaufsteuerung, der Bedienbilder<br />

und der Verriegelungen einer Package Unit mittels einer<br />

EDD stellt die Hersteller vor eine neue Aufgabe. Bevor<br />

eine Übertragung der Daten stattfinden kann, müssen<br />

beispielsweise die verwendeten Ablaufsteuerungen von<br />

einem da<strong>für</strong> konzipierten Baustein ausgelesen, als bipartiter<br />

Graph interpretiert und in zwei Matrizen überführt<br />

werden. Dieser Schritt unterstützt die Package<br />

Unit Integration im Plug-and-produce und minimiert<br />

manuelle Arbeiten durch den Operator. Darüber hinaus<br />

muss eine einheitliche Serialisierung der ausgelesenen<br />

Daten stattfinden. Auf der Seite des übergeordneten Prozessleitsystems<br />

muss derselbe Vorgang in umgedrehter<br />

Reihenfolge stattfinden.<br />

Wie kann ein solcher Baustein aussehen? Welche Datenmengen<br />

muss er verarbeiten und wie und von wem<br />

kann dieser realisiert werden? Gibt es bereits heute<br />

Möglichkeiten, durch deren geschickte Ausnutzung<br />

solche Daten verarbeitet werden können?<br />

Eine Möglichkeit wäre die Entwicklung eines SPSbasierten<br />

Funktionsblocks, welcher mit den seriellen<br />

Informationen gespeist werden kann und anschließend<br />

aufgrund eines mathematischen Algorithmus unter<br />

Verwendung der Information über die Anzahl von Spalten<br />

und Zeilen eine Matrix generiert. Darauf aufbauend<br />

kann anschließend in einem weiteren Baustein eine<br />

grafische Abbildung (Beispiel siehe Bild 4) der Ablaufsteuerung<br />

mit Hilfe der Information aus den in Abschnitt<br />

3.2 vorgestellten Matrizen generiert werden.<br />

Herausforderung auf Seiten des Package-Unit-Herstellers<br />

wird sein, die Ablaufsteuerung so zu modellieren,<br />

<strong>das</strong>s diese innerhalb der Package Unit mit einem ähnlichen<br />

Baustein in zwei binäre Vektoren interpretiert<br />

werden kann. Vorteil dieser Darstellung ist die Verwendung<br />

von SPS-basierten Funktionsbaublöcken innerhalb<br />

verschiedener Prozessleitsysteme. So können diese in<br />

den meisten Fällen eingelesen und verwendet werden.<br />

ZUSAMMENFASSUNG<br />

Mit diesem Beitrag wurde <strong>das</strong> Potenzial aktueller Beschreibungsmittel<br />

aufgezeigt. Aus den Anforderungen<br />

der Integration von Package Units in übergeordnete Leitsysteme<br />

und der Analyse existierender Beschreibungsmittel<br />

<strong>für</strong> die verschiedenen <strong>Engineering</strong>-Aspekte wurde<br />

ein Konzept zur Beschreibung der identifizierten<br />

<strong>Engineering</strong>-Aspekte mit der bereits etablierten Sprache<br />

EDDL vorgestellt. Das Vorgehen wurde anhand der Modellierung<br />

einer Ablaufkette erläutert und umgesetzt.<br />

Die Synergien zur Beschreibung der Bedienbilder und<br />

der Verriegelungen einer Package Unit wurden aufgezeigt.<br />

Für die Implementierung des vorgestellten Ansatzes<br />

wurde ein Konzept beschrieben und diskutiert.<br />

Noch offen ist die Implementierung des Ansatzes in<br />

aktuellen Leitsystemen, um <strong>das</strong> Konzept praktisch zu<br />

überprüfen. Dabei muss die in diesem Beitrag diskutierte<br />

Praxis der Nutzung von Identifiern zur Beschreibung<br />

von Semantik, die von der EDDL-Maintenance<br />

Group nicht be<strong>für</strong>wortet wird, durch einen merkmalbasierten<br />

Ansatz [3] ergänzt werden.<br />

MANUSKRIPTEINGANG<br />

09.12.2013<br />

Im Peer-Review-Verfahren begutachtet<br />

64<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


REFERENZEN<br />

[1] Urbas, L., Bleuel, S., Jäger, T., Schmitz, S., Evertz, L.:<br />

Automatisierung von Prozessmodulen Von Package-Unit-<br />

Integration zu modularen Anlagen. <strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische<br />

Praxis 54(1-2), S. 44–53, 2012.<br />

[2] Obst, M.; Runde, S.; Wolf, G.; Urbas, L.: Integration<br />

Requirements of Package Units - A Description<br />

Approach with FDI. In: Proc. 18th Int. IEEE Conf.<br />

Emerging Techno logies & Factory Automation (ETFA),<br />

[CD]. IEEE 2013.<br />

[3] John, D., Danzer, B., Riedl, M., Zipper, H.: Selbsterklärende<br />

Geräte. <strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische<br />

Praxis 55(10), S. 56-61, 2013<br />

[4] Theurich, S. Stöß, M., Wollschlaeger, M., Urbas, L.:<br />

Communication and Information <strong>Engineering</strong> of FDI<br />

Equipment Packages. In: Proc. 17th int. IEEE Conf.<br />

Emerging Technologies and Factory Automation (ETFA),<br />

[CD]. IEEE 2012.<br />

[5] NE 148: Anforderungen an die Automatisierungstechnik<br />

durch die Modularisierung verfahrenstechnischer<br />

Anlagen. Namur, 10/2013.<br />

[6] Profibus <strong>Engineering</strong> Flyer, Geräteintegration in der<br />

Feldbustechnik, PROFIBUS-Nutzerorganisation e.V., 2006<br />

[7] Kumpfmüller, H.-G., R. Lange, R.: FDI Device Integration<br />

- Best of Both Worlds. <strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische<br />

Praxis 52(6), S. 16–19, 2010.<br />

[8] Doherr, F., Drumm, O., Franze, V., Urbas, L.: Bedienbilder<br />

auf Knopfdruck - Modellbasierte Erstellung von<br />

Fließbilddarstellungen. <strong>atp</strong> <strong>edition</strong> - Automatisierungstechnische<br />

Praxis 53(11), S. 30-39, 2011.<br />

[9] Obst, M., Drumm, O., Doherr, F., Urbas, L.: Integriertes<br />

HMI-<strong>Engineering</strong>. In: Tagungsband GMA-Kongress<br />

Automation 2012, S. 227–230. VDI-Verlag 2012.<br />

[10] Yokogawa: ProSafe-PLC Safety Matrix. 2003<br />

[11] Siemens: SIMATIC Safety Matrix. Proceed with<br />

Confidence. 2007<br />

[12] Urbas, L., Doherr, F., Krause, A., Obst, M.: Modularisierung<br />

und Prozessführung. Chemie Ingenieur Technik<br />

84(5), S. 615-623, 2012<br />

[13] VDI/VDE 3699-5: Prozessführung mit Bildschirmen.<br />

Bedienfließbilder.<br />

AUTOREN<br />

Dipl. Ing. MICHAEL OBST<br />

(geb. 1985) ist wissenschaftlicher<br />

Mitarbeiter der Professur <strong>für</strong><br />

Prozessleittechnik an der Technischen<br />

Universität Dresden mit<br />

den Schwerpunkten: Informationsmodellierung,<br />

Unterstützungssysteme<br />

<strong>für</strong> modulares Anlagenengineering<br />

und fallbasiertes Schließen.<br />

TU Dresden,<br />

Institut <strong>für</strong> Automatisierungstechnik,<br />

D-01062 Dresden, Tel. +49 (0) 351 46 33 21 62,<br />

E-Mail: michael.obst@tu-dresden.de<br />

ANNA HAHN (geb. 1987) ist<br />

Diplomandin an der Professur<br />

<strong>für</strong> Prozessleittechnik der Technischen<br />

Universität Dresden.<br />

Sie bearbeitet im Rahmen ihrer<br />

Diplomarbeit <strong>das</strong> Thema Vereinfachte<br />

Leitsystemintegration von<br />

Package Units“.<br />

TU Dresden,<br />

Institut <strong>für</strong> Automatisierungstechnik,<br />

D-01062 Dresden,<br />

E-Mail: anna.hahn@mailbox.tu-dresden.de<br />

Prof. Dr.-Ing. LEON<br />

URBAS (geb. 1965) ist<br />

Inhaber der Professur <strong>für</strong><br />

Prozessleittechnik an der<br />

Technischen Universität<br />

Dresden. Seine Hauptarbeitsgebiete<br />

beim<br />

<strong>Engineering</strong> verteilter<br />

sicherheitskritischer<br />

Systeme sind Funktionsintegration, modellgetriebenes<br />

<strong>Engineering</strong>, Modularisierung,<br />

Informationsmodelle der Prozessindustrie<br />

und Middleware in der Automatisierungstechnik.<br />

Einen weiteren Schwerpunkt bildet<br />

die Gebrauchstauglichkeit von mobilen<br />

Informationssystemen <strong>für</strong> die Prozessindustrie,<br />

Analyse, Gestaltung und Bewertung<br />

von Alarmierungs- und Unterstützungssystemen<br />

sowie Methoden der Benutzermodellierung<br />

zur prospektiven Gestaltung von<br />

Mensch-Technik-Interaktion.<br />

TU Dresden,<br />

Institut <strong>für</strong> Automatisierungstechnik,<br />

D-01062 Dresden, Tel. +49 (0) 351 46 33 96 14,<br />

E-Mail: leon.urbas@tu-dresden.de<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

65


HAUPTBEITRAG<br />

Trainingssimulation in der<br />

Prozessindustrie<br />

Umfrageergebnisse zur Anwendung von Trainingssimulatoren<br />

Der Beitrag stellt eine Umfrage des Namur Arbeitskreises 2.2 vor, mit der untersucht<br />

wurde, wie die Prozessindustrie im deutschsprachigen Raum Trainingssimulatoren<br />

einsetzt. Die Ergebnisse sprechen <strong>für</strong> eine Akzeptanz der Trainingssimulation. Sie<br />

zeigen aber Unsicherheiten bei der Implementierung und den Möglichkeiten dieser<br />

Systeme über den gesamten Lebenszyklus einer Anlage auf. Vom Autor werden die<br />

Ergebnisse erörtert, der didaktische Kontext beleuchtet und Schlussfolgerungen <strong>für</strong><br />

die betriebliche Praxis gezogen.<br />

SCHLAGWÖRTER Operator Training Simulator / Operator Training / Prozessindustrie<br />

Training Simulation in the Process Industry –<br />

Results of a Survey showing the Use of Training Simulators<br />

The paper reports a survey conducted by the Namur working group 2.2, looking for<br />

the use of Operator Training Simulators in the process industry in German speaking<br />

countries. The results show an acceptance of training simulation, however, also<br />

identify some uncertainties in the use of these systems in all phases of the life cycle.<br />

The results are reflected in the didactic context, and some conclusions for the industrial<br />

practice are given.<br />

KEYWORDS operator training simulator / operator training / process industry<br />

66<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


KARSTEN SCHULZE, Linde <strong>Engineering</strong> Division<br />

Die Rolle des Anlagenfahrers in der Prozessindustrie<br />

hat sich in den vergangenen Jahrzehnten<br />

grundlegend geändert. Bedingt<br />

durch einen immer höheren Automatisierungsgrad<br />

hat sich die Funktion vom reinen<br />

Operator zum Supervisor gewandelt. Parallel dazu sind<br />

die Anlagen im Sinne einer optimalen Stoff- und Energienutzung<br />

komplexer und prinzipiell schwieriger zu<br />

bedienen. Diese Zusammenhänge wurden bereits in<br />

den 1990er-Jahren in vielfältigen Analysen untersucht,<br />

siehe zum Beispiel [1].<br />

In dieser Dekade hat die Technologie von Operator<br />

Training Simulatoren (OTS) große Fortschritte gemacht.<br />

Während am Anfang die Thematik noch Gegenstand<br />

der Forschung war, galt sie am Ende in einigen Industriebereichen<br />

bereits als Standard. Einen Überblick<br />

über die Technologie geben [2-4]. Schon sehr früh stellte<br />

sich die Frage, wie Projekte zur Trainingssimulation<br />

abzuwickeln sind. Die Diskussion führte zur ersten<br />

Ausgabe des Namur Arbeitsblatts NA 60 [5-6].<br />

Natürlich ist diese Entwicklung in den letzten 15 Jahren<br />

nicht stehen geblieben. Die Systeme haben in Bereiche<br />

Einzug gehalten, <strong>für</strong> die sie vor einigen Jahren noch als<br />

zu komplex und zu teuer galten. Eine Ursache <strong>für</strong> die<br />

Verbreitung liegt darin, <strong>das</strong>s in der Automatisierung vermehrt<br />

Standard-komponenten verwendet werden. Während<br />

in der Anfangsphase von Trainingssimulatoren die<br />

<strong>Schnittstellen</strong>problematik beherrschend <strong>für</strong> die Entwicklung<br />

eines Systems war, und der Umfang des Prozessmodelles<br />

durch die Rechenkapazität bestimmt wurde, stellen<br />

sich diese Fragen heute kaum noch. Dies zeigt sich<br />

auch in der Anwendung von Trainingssimulation in<br />

Deutschland: Aus einer Umfrage aus dem Jahr 2003 zum<br />

Einsatz von Computer-based Training (CBT) wird in [7,<br />

S. 46], festgestellt: „In Deutschland setzt knapp die Hälfte<br />

der Unternehmen der Teilnehmer CBT bei der Schulung<br />

von Anlagenfahrern ein. Operator Trainingssimulation<br />

wird nicht eingesetzt, wohl aber am PLS geschult.“<br />

Um einen Überblick über die aktuelle Verbreitung von<br />

Trainingssimulatoren in der Prozessindustrie zu erhalten,<br />

hat der Namur-Arbeitskreis T 2.2 in 2013 eine entsprechende<br />

Umfrage in deutschsprachigen Unternehmen<br />

durchgeführt. Eine im gleichen Zeitraum gemachte<br />

Umfrage im internationalen Umfeld durch die ARC Advisory<br />

Group (im Folgenden ARC) liegt dem Autor vor,<br />

ist jedoch bislang nicht veröffentlicht. Ergebnisse der<br />

ARC-Umfrage werden daher nur vergleichend herangezogen,<br />

aus rechtlichen Gründen jedoch nicht im Detail<br />

dargestellt. Anhand der Resultate der jüngsten Namur-<br />

Umfrage werden fünf Thesen entwickelt, die durchaus<br />

eine kontroverse Diskussion auslösen sollen.<br />

1. OPERATOR TRAINING AUS DIDAKTISCHER SICHT<br />

Operator Training ist mehr als die reine Wissensvermittlung<br />

bezüglich Prozessverhalten und Orientierung im<br />

Leitsystem. Der Anlagenfahrer ist nicht in der Messwarte,<br />

um <strong>das</strong> Prozesslayout erläutern zu können. Er ist derjenige,<br />

der da<strong>für</strong> sorgt, <strong>das</strong>s die Anlage <strong>das</strong> produziert, wo<strong>für</strong><br />

sie gebaut wurde. Dies beinhaltet die Aufgabe, die Anlage<br />

ruhig und ökonomisch sinnvoll zu betreiben, wobei die<br />

Erfahrung zeigt, <strong>das</strong>s oft die ruhige Fahrweise Priorität<br />

hat. Die weit anspruchsvollere Aufgabe besteht jedoch<br />

darin, bei einer Störung die Anlage in möglichst kurzer<br />

Zeit wieder in den ordnungsgemäßen Zustand zu bringen.<br />

Hier sind Kompetenzen gefragt, die über <strong>das</strong> Wissen um<br />

Prozess und Leitsystem hinausgehen. In [8] wird in diesem<br />

Zusammenhang die Problemlösekompetenz diskutiert,<br />

über die ein Anlagenfahrer verfügen muss.<br />

Entsprechende Fähigkeiten müssen als Richtziele im<br />

Operator Training vermittelt werden. Dabei dienen diese<br />

Richtziele als Leitfaden <strong>für</strong> die anfängliche Ausbildung<br />

und als Zielsetzung in der Weiterbildung. Das von<br />

Linde <strong>Engineering</strong> erprobte Trainingskonzept beinhaltet<br />

beispielsweise die Vermittlung folgender Kompetenzen:<br />

Fachkompetenz: Der Operator muss sicher die Funktion<br />

der Anlage und ihrer Steuereinrichtungen kennen sowie<br />

mit allgemeiner Bezeichnung und Tagnummer benennen<br />

können. In den Steuereinrichtungen eingeschlossen sind<br />

DCS-Grafiken, Alarme, Abschaltungen, lokale und remote<br />

Bedieneinrichtungen, Schlüsselschalter.<br />

Handlungskompetenz: Der Operator muss sicher in seinen<br />

Handlungsabläufen werden. Dies umfasst die Kennt-<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

67


HAUPTBEITRAG<br />

nis der vorgesehenen Prozeduren <strong>für</strong> die verschiedenen<br />

Betriebsfälle und <strong>das</strong> Vertrauen darin, <strong>das</strong>s die vorgesehenen<br />

Aktionen zu einem guten Ergebnis führen und der<br />

Operator weder in Abwarten noch in Aktionismus verfällt.<br />

Problemlösekompetenz: Der Operator muss aufgrund<br />

der Kenntnis von Alarmen und Prozessverhalten in der<br />

Lage sein, die Ursache einer Störung zu identifizieren<br />

und zu beheben.<br />

Teamfähigkeit: Der Operator muss in die Lage versetzt<br />

werden, die anstehenden Aufgaben mit Hilfe von Anderen<br />

(Anlagenfahrer, Feldoperator, Mitarbeiter der<br />

Instandhaltung, Betriebsingenieur) zu lösen.<br />

Verantwortungsbewusstsein: Der Operator muss Bewusstsein<br />

<strong>für</strong> den sicheren Betrieb der Anlage erlangen.<br />

Dies gilt gleichermaßen <strong>für</strong> Sicherheit im Sinne von<br />

Vermeidung und Beherrschung gefährlicher Situationen<br />

wie <strong>für</strong> den unterbrechungsfreien Betrieb der Anlage.<br />

1.1 Lernumgebung <strong>für</strong> <strong>das</strong> Operator Training<br />

Die Richtziele müssen durch eine geeignet gestaltete Lernumgebung<br />

unterstützt werden. In den Sozialwissenschaften<br />

betont [9, S. 269] die Bedeutung des computergestützten<br />

Lernens in der industriellen Praxis in Hinblick auf die<br />

Verfügbarkeit und Wirtschaftlichkeit von Produktionsanlagen.<br />

Wichtig ist dabei die Fähigkeit des Mitarbeiters, als<br />

Problemlöser zu agieren. Damit steht die diagnostische<br />

Kompetenz der Anlagenfahrer im Vordergrund.<br />

Weiterhin werden dort fünf Leitlinien <strong>für</strong> die Gestaltung<br />

der Lernumgebung formuliert, die sich unmittelbar<br />

auf <strong>das</strong> zu erstellende Trainingskonzept <strong>für</strong> Operateure<br />

anwenden lassen:<br />

1 | Situiert und anhand authentischer Probleme lernen.<br />

Die Ausbildung muss anhand der praxisrelevanten<br />

Aufgabenstellungen erfolgen. Dem Bedienerhandbuch<br />

kommt damit eine besondere Bedeutung<br />

als Leitlinie <strong>für</strong> <strong>das</strong> Training zu.<br />

2 | In multiplen Kontexten lernen.<br />

Jedes Szenario sollte in verschiedenen Kontexten<br />

trainiert werden, zum Beispiel Lastreduktion unter<br />

verschiedenen Randbedingungen.<br />

3 | Unter multiplen Perspektiven lernen.<br />

Der Operator muss lernen, eine Problemstellung<br />

aus verschiedenen Perspektiven zu sehen.<br />

4 | Im sozialen Kontext lernen.<br />

Das Training muss bewusst auf Kooperation setzen<br />

und den Teamgeist fördern. Deshalb müssen<br />

Experten im Trainingsteam vertreten sein.<br />

5 | Mit instruktionaler Unterstützung lernen.<br />

Die Operateure müssen bei Bedarf Unterstützung<br />

vom Trainer oder aus der Lernumgebung, beispielsweise<br />

computerbasiertes Lernen, erhalten.<br />

Es muss sichergestellt sein, <strong>das</strong>s <strong>das</strong> zur Problemlösung<br />

erforderliche Wissen bereitgestellt wird.<br />

In Bild 1 sind die Elemente dargestellt, die als Methoden<br />

<strong>für</strong> ein effizientes Operator Training zur Verfügung stehen.<br />

Die Berücksichtigung der Richtziele und Leitlinien<br />

führt zum Schluss, <strong>das</strong>s die Bausteine aufeinander abgestimmt<br />

sein müssen, damit Inhalte von theoretischer<br />

wie praktischer Seite vermittelt und Sachverhalte und<br />

Prozeduren in verschiedenen Kontexten eingebettet<br />

werden können. Dem OTS als simulatorbasierte Trainingsmethode<br />

kommt damit weder eine herausragende<br />

noch eine zu vernachlässigende Rolle zu. Er ist ein<br />

Werkzeug, <strong>das</strong>s in ein übergeordnetes Trainingskonzept<br />

einzubetten ist.<br />

2. AUSWERTUNG DER NAMUR-UMFRAGE<br />

Die Umfrage wurde in Form eines Online-Fragebogens<br />

an die Namur Mitgliedsfirmen im deutschsprachigen<br />

Raum geschickt. Geantwortet haben 32 Unternehmen.<br />

Den Teilnehmern war freigestellt den Namen ihres Unternehmens<br />

zu nennen.<br />

BILD 1: Elemente des Operator Trainings<br />

Classroom Training<br />

Fragebogen<br />

Planspiele<br />

Praxis Training<br />

computerbasiertes Training<br />

simulatorbasiertes Training<br />

Trainingabteilung/Ausbilder<br />

MSR/PLT<br />

Betriebsleitung<br />

Meister<br />

Anlagenfahrer<br />

BILD 2: Akzeptanz von OTS in<br />

verschiedenen Gruppen<br />

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%<br />

hoch mittel nicht vorhanden unbekannt<br />

68<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


Die meisten dieser Unternehmen sind in der Spezialchemie<br />

(24) tätig. Ein geringerer Anteil ordnet sich<br />

auch den Bereichen Petrochemie (5), Zellstoff/Papier<br />

(6) Energie (4), Pharma (3) und Lebensmittelindustrie<br />

(1) zu (Mehrfachzuordnungen waren möglich). Zwei<br />

der Antwortenden stammen aus dem Bereich IT/Automatisierungstechnik.<br />

Von den Umfrageteilnehmern<br />

hatten 22 Erfahrungen mit einem OTS, 18 davon setzen<br />

mindestens ein eigenes System ein. 18 Teilnehmer nutzen<br />

OTS im Zusammenhang mit kontinuierlichen Anlagen,<br />

8 Teilnehmer gaben auch Batchprozesse an.<br />

Aufgrund der geringen Anzahl von Rückläufern , aber<br />

auch der freien Wahl, an der Umfrage teilzunehmen,<br />

kann <strong>das</strong> Ergebnis nicht als repräsentativ angesehen<br />

werden. So ist davon auszugehen, <strong>das</strong>s von den rund 100<br />

angeschriebenen Unternehmen vorwiegend diejenigen<br />

antworteten, die Erfahrungen mit einem OTS haben.<br />

2.1 Akzeptanz eines OTS<br />

Eine Aussage, <strong>das</strong>s basierend auf den zuvor genannten Zahlen<br />

18 von 32, also 56% der Unternehmen in der Prozessindustrie<br />

den OTS in der Ausbildung nutzen, ist nicht seriös.<br />

Dennoch lassen sich Rückschlüsse auf die Akzeptanz von<br />

OTS ziehen: In einer weiteren Frage wurde nach der Anzahl<br />

der in den letzten fünf Jahren installierten Systeme gefragt.<br />

In 13 von 18 Fällen wurden mehr als zwei Systeme in diesem<br />

Zeitraum realisiert. Und 16 der 18 Befragten gaben an,<br />

<strong>das</strong>s sich der Einsatz eines OTS immer gelohnt habe; lediglich<br />

<strong>für</strong> zwei Unternehmen war der Nutzen eher selten. In<br />

praktisch allen Unternehmen, die ein OTS im Einsatz haben,<br />

ist die Akzeptanz in allen Gruppen mittel bis hoch,<br />

siehe Bild 2; die fehlende Zustimmung zu OTS ist bei den<br />

Befragten die Ausnahme. Ein sehr ähnliches Bild lässt sich<br />

aus den Antworten der ARC-Umfrage ableiten.<br />

Aus den vorgestellten Zahlen ergibt sich die erste<br />

These zur Akzeptanz von Trainingssimulatoren in der<br />

Prozessindustrie:<br />

These 1: OTS sind ein anerkanntes Mittel in der Ausbildung<br />

von Anlagenfahrern.<br />

2.2 Technische Umsetzung<br />

Auf die Frage, wer denn einen OTS spezifiziert (Mehrfachnennungen<br />

waren erlaubt), antworten 17 Teilnehmer mit<br />

„Experten der technischen Services“, und nur 10 nennen<br />

den „Betreiber“. Anlagenbauer oder externe Dienstleister<br />

bilden mit zwei beziehungsweise einer Nennung die Ausnahme.<br />

Die genauere Analyse zeigt, <strong>das</strong>s von den 17 Unternehmen,<br />

die den Entwurf den Experten der technischen<br />

Services übertragen, 7 Unternehmen ohne Beteiligung des<br />

Betreibers konzeptionieren und 8 Unternehmen den Entwurf<br />

in Kooperation mit dem Betrieb erstellen.<br />

Nun definiert „Experte in technischen Services“ sicher<br />

nicht eindeutig Fachgebiet und spezifisches Wissen<br />

des Mitarbeiters. Dennoch erstaunt es, <strong>das</strong>s rund<br />

die Hälfte der Befragten ihr Betreiberwissen und ihre<br />

Anforderungen an <strong>das</strong> Training nicht in den Entwurf<br />

einfließen lassen – zumindest wenn davon ausgegangen<br />

wird, <strong>das</strong>s in den technischen Services kein Betreiberwissen<br />

vorhanden ist und keine Vorgaben aus Betrieb<br />

oder Trainingsabteilung kommen. Unter dieser Prämisse<br />

folgt die zweite These dieser Erörterung, die sich mit<br />

den Erfahrungen des Autors aus einer Reihe von Simulatorprojekten<br />

deckt:<br />

These 2: Bei der Spezifikation eines OTS steht die Technik<br />

im Vordergrund, nicht <strong>das</strong> Training.<br />

Ausgehend von diesen Antworten stellt sich die Frage,<br />

ob mit dem OTS ein technisches System definiert und<br />

dann an den Nutzer übergeben wird mit den Worten<br />

„Nun mach mal was draus!“. Oder anders ausgedrückt,<br />

ob dem Design des Trainingssimulators ein adäquates<br />

Design des Trainings gegenübersteht. Tatsächlich wird<br />

in einigen globalen Unternehmen die Devise diskutiert,<br />

Antwortmöglichkeit<br />

Anzahl<br />

Schnellere Lernkurve bei neuen Prozessen / Produkten oder neuen Mitarbeitern 16<br />

Testen einer neuen Leitsystemprogrammierung 11<br />

Regelungstechnische Optimierung 8<br />

Know-how-Verbesserung / -Transfer 5<br />

Verkürzung von An-/Abfahrvorgängen sowie Produktwechsel 4<br />

Erhöhung der Anlagensicherheit 4<br />

Prozessstabilisierung 2<br />

Erprobung unterschiedlicher Fahrweisen 2<br />

Harmonisierung der Betriebsweise 1<br />

Ausbeutemaximierung 0<br />

Reduzierung Energieverbrauch 0<br />

Durchsatzsteigerung 0<br />

TABELLE 1:<br />

Antworten zur<br />

Frage „Welchen<br />

Hauptnutzen<br />

sehen Sie im<br />

Einsatz von OTS?“<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

69


HAUPTBEITRAG<br />

Gleiche Bedineoberfläche wie im PLS<br />

Beschreibt <strong>das</strong> stationäre Verhalten<br />

Simulation von Betriebsstörungen<br />

Simulation des Normalbetriebs und Laständerungen<br />

Simulation von An- und Abfahrvorgängen<br />

Beschreibt <strong>das</strong> dynamische Verhalten<br />

Leichte Adaptierbarkeit bei Prozessänderungen<br />

Qualitative Übereinstimmung mit der realen Anlage<br />

Freie Wahl der Simulationsgeschwindigkeit<br />

Exakte Übereinstimmung mit der realen Anlage<br />

Simulation des Einflusses von externen Bedingungen<br />

Simulation des Verbrauchs von Hilfmedien<br />

Simulation von Langzeiteinflüssen<br />

BILD 3:<br />

Anforderungen<br />

an ein OTS<br />

0 2 4 6 8 10 12 14 16 18 20<br />

Unverzichtbar wünschenswert weniger wichtig unklar<br />

Zu teuer<br />

Wurde noch nie diskutiert<br />

Zu hoher Pflegeaufwand<br />

Zu hoher Modellierungsaufwand<br />

Nein, 7<br />

Sonstiges<br />

Kein Know-how vorhanden<br />

Ja, 10<br />

Vorwiegend Multi-Purpose Anlagen<br />

Kein erkennbarer Nutzen<br />

Schlechte Erfahrungen<br />

Fehlende Informationen<br />

Nur mit messbaren<br />

Garantiewerten, 1<br />

0 1 2 3 4 5 6<br />

BILD 4: Gründe <strong>für</strong> die Nicht-Nutzung eines OTS<br />

BILD 5: Hilfestellung<br />

durch eine Richtlinie<br />

<strong>das</strong>s bis zu 25% des Budgets eines Trainingssystems <strong>für</strong><br />

den Entwurf des Trainings reserviert werden sollten.<br />

2.3 OTS-Nutzung<br />

Ein weiterer Fragenbereich betrifft die Nutzung des OTS.<br />

Wichtigster Punkt hieraus ist die Frage nach dem Hauptnutzen.<br />

Bis zu drei der in Tabelle 1 gelisteten Antworten<br />

konnten angekreuzt werden. Das Ergebnis zeigt den Fokus<br />

auf die Lernkurve bei neuen Anlagen oder Teilanlagen sowie<br />

neuen Mitarbeitern. Ein repetierendes Training scheint<br />

nicht die Regel zu sein, sondern der Trainingssimulator<br />

wird nach dem ersten Training verstärkt von der regelungstechnischen<br />

Wartung genutzt. Diesen Schluss legt die Auswertung<br />

der Antworten auf die Frage nach der Nutzungsdauer<br />

nahe: Rund 70% der Systeme werden nach spätestens<br />

4 Jahren außer Betrieb genommen, nur 5 von 18 Unternehmen<br />

gaben an, den OTS fünf oder mehr Jahre zu betreiben.<br />

Tabelle 1 zeigt ferner, <strong>das</strong>s ein OTS <strong>für</strong> die ökonomische<br />

Verbesserung des Anlagenbetriebes nur wenig<br />

genutzt wird. Die Verkürzung von Anfahrvorgängen ist<br />

ebenso wenig im Fokus eines OTS wie die Harmonisierung<br />

von Betriebsweisen oder die Erprobung unterschiedlicher<br />

Fahrweisen, um so eine Best Practice in<br />

der Bedienmannschaft auszubilden.<br />

Dass sich ein OTS auch da<strong>für</strong> verwenden lässt, Konzepte<br />

zur Anlagenoptimierung zu nutzen, ist gemäß<br />

den erhaltenen Antworten völlig unbekannt – ein<br />

Punkt, der in der weiteren Erörterung wieder aufgegriffen<br />

wird. Zunächst die dritte These:<br />

These 3: Trainingsszenarien konzentrieren sich auf die<br />

reine Wissensvermittlung, weniger auf Kompetenzen.<br />

Der These liegt die Argumentation zugrunde, <strong>das</strong>s sich<br />

Kompetenzen gerade durch Wiederholung ausbilden, durch<br />

die Anwendung von bereits gelerntem Wissen in anderen<br />

Zusammenhängen. Hierzu gehört insbesondere der spielerische<br />

Aspekt, <strong>das</strong> mehrfache Probieren. Interessant ist in<br />

diesem Zusammenhang, <strong>das</strong>s sich in der erwähnten internationalen<br />

Umfrage eine deutliche längere Nutzungsdauer<br />

70<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


des Trainingssimulators ergibt, während sich hinsichtlich<br />

der Nutzung ein ähnliches Bild abzeichnet.<br />

2.4 Anforderungen an ein OTS<br />

Eine weitere Gruppe von Fragen hat die Anforderungen<br />

an ein OTS zum Thema. Naturgemäß hängen diese eng<br />

mit den Nutzungszielen zusammen, und dementsprechend<br />

ergibt sich ein ähnliches Bild. Ganz oben auf der<br />

Liste der Wünsche, siehe Bild 3, steht die gleiche Bedienoberfläche<br />

wie im realen PLS. Dies erklärt sich aus dem<br />

Wunsch, ein möglichst realitätsnahes Umfeld <strong>für</strong> <strong>das</strong><br />

Training zu schaffen. Mit der allgemein üblichen Verwendung<br />

der Grafiken aus dem PLS im OTS ist dieser Forderung<br />

leicht nachzukommen. Von hoher Bedeutung ist <strong>für</strong><br />

viele Umfrageteilnehmer die Simulation des Normalbetriebs,<br />

obwohl dieser Zustand Bestandteil der täglichen<br />

Arbeit ist und der Trainingseffekt sich somit primär auf<br />

den neuen Mitarbeiter an diesem Prozess beschränkt.<br />

Trotz der Forderung nach Realitätsnähe ist der Wunsch<br />

nach einer exakten Übereinstimmung mit der realen<br />

Anlage weniger ausgeprägt. Offensichtlich sind die Unternehmen<br />

bestrebt, nur die <strong>für</strong> <strong>das</strong> Training relevanten<br />

Teile der Anlage abzubilden. Denn höher eingestuft sind<br />

die Forderungen nach stationärer und dynamischer Genauigkeit<br />

der Simulation. Ebenfalls von reduzierter<br />

Wichtigkeit ist die leichte Adaptierbarkeit bei Prozessänderungen.<br />

Hier drückt sich die erwartete geringe Nutzungsdauer<br />

aus, denn bei kurzer Nutzungsdauer benötigt<br />

<strong>das</strong> System keine Anpassung an Umbauten in der<br />

Anlage, oder die Anpassung erscheint in der Kosten-<br />

Nutzen Analyse als zu teuer, so<strong>das</strong>s ein OTS deswegen<br />

außer Betrieb genommen wird. Hier fehlen sicher Konzepte,<br />

die ein Mitwachsen des OTS attraktiver machen.<br />

Bei der Frage nach dem Lebenszyklus der Anlage, in dem<br />

sich ein OTS besonders lohnt, schneidet die Phase des Neubaus<br />

einer Anlage als klarer Favorit ab. Alle Antwortenden<br />

haben zu diesem Aspekt ein „Lohnt sich sehr“ angekreuzt.<br />

Für bestehende Anlagen geht diese Zustimmung deutlich<br />

zurück, es sei denn, es steht eine Leitsystemmigration an,<br />

wo einige einen Vorteil in der Verwendung des OTS sehen.<br />

Bei Initiativen zu Kapazitätserweiterungen oder zu Operational<br />

Excellence wird der Vorteil eines OTS nicht so<br />

deutlich gesehen. Zusammen mit den geringen Antwortzahlen<br />

zu betrieblichen Aspekten in der Nutzung, siehe<br />

Tabelle 1, führen diese Ergebnisse zur vierten These:<br />

These 4: OTS werden nicht in ihrer gesamten Bandbreite<br />

genutzt, nicht alle Möglichkeiten sind bekannt.<br />

2.5 Nicht-Nutzer eines OTS<br />

Die kleinere Gruppe der Rückläufer der Umfrage stammt<br />

von den Nicht-Nutzern eines OTS. Diese wurden gebeten,<br />

die Gründe hier<strong>für</strong> darzulegen siehe Bild 4. Während<br />

die Häufigkeit der Antwort „zu teuer“ nicht überrascht,<br />

haben sieben von zehn entweder kein entsprechendes<br />

Know-how, oder die Thematik wurde noch nie diskutiert.<br />

Das bedeutet allerdings auch, <strong>das</strong>s sich nur drei der<br />

zehn Unternehmen bewusst gegen den Einsatz von Trainingssimulation<br />

entschieden haben. Dabei wurde nicht<br />

näher untersucht, ob die Aussagen, die einen zu hohen<br />

Aufwand betonen, tatsächlich auf einer internen Diskussion<br />

beruhen. Erfreulich an dem Spektrum der Antworten<br />

ist, <strong>das</strong>s der Nicht-Einsatz von OTS nicht auf schlechten<br />

Erfahrungen in der Vergangenheit beruht.<br />

In einer Frage werden die Nutzer eines OTS gebeten,<br />

darzulegen, ob eine Richtlinie bei der Projektierung<br />

eines Trainingssimulators helfen würde, siehe Bild 5.<br />

Die Antworten sind mit 10 „Ja“ von 18 überraschend<br />

deutlich, existiert doch bereits ein Namur-Arbeitspapier<br />

zur Abwicklung von Trainingssimulator-Projekten.<br />

Aus diesen Betrachtungen ergibt sich gemeinsam mit<br />

den vorherigen Erörterungen als Schlussfolgerung eine<br />

weitere These:<br />

These 5: Es besteht hohe Unsicherheit beim Entwurf und<br />

in der Projektierung eines OTS.<br />

3. DISKUSSION<br />

Die im deutschsprachigen Raum durchgeführte Umfrage<br />

zum Einsatz von Trainingssimulation hat eine gute Akzeptanz<br />

von OTS gezeigt. Offensichtlich sind besonders<br />

die Nutzer eines OTS von den Möglichkeiten überzeugt.<br />

Die Ergebnisse legen den Schluss nahe, <strong>das</strong>s, wenn in<br />

einem Betrieb eines Unternehmens die Trainingssimulation<br />

genutzt wird, diese Technologie auch in anderen<br />

Betrieben des Unternehmens eingesetzt wird. Dies<br />

spricht <strong>für</strong> eine weitere Verbreitung von Trainingssimulation<br />

in der Prozessindustrie in den nächsten Jahren.<br />

Auf diesen Trend müssen sich die Unternehmen auch<br />

in anderem Zusammenhang einstellen, denn der Einsatz<br />

von Simulation in der Ausbildung von Anlagenfahrern ist<br />

kein Selbstläufer. Neben den in den letzten Jahren publizierten<br />

Herausforderungen [11-13] muss die Trainingssimulation<br />

in ein übergeordnetes Trainingskonzept einbettet<br />

sein, in inhaltlicher Hinsicht und aus der organisatorischen<br />

Perspektive. Inhalte, die im theoretischen Rahmen<br />

vermittelt werden, müssen in der Praxiseinheit aufgegriffen<br />

und vertieft werden. Umgekehrt sind Praxiseinheiten<br />

am OTS in anderen Einheiten vorzubereiten. Die enge<br />

Verzahnung von Wissensvermittlung im Frontalunterricht<br />

oder Gruppenarbeit und praktischer Ausbildung an einem<br />

Trainingssimulator hat jedoch ihren Preis: Ein signifikanter<br />

Anteil des Gesamtbudgets <strong>für</strong> die Einführung eines<br />

Trainingssimulators muss <strong>für</strong> den Entwurf des Trainings<br />

und des übergeordneten Konzeptes reserviert sein.<br />

Um der herausragenden Möglichkeit eines OTS, Betriebsabläufe<br />

spielerisch zu erarbeiten, Rechnung zu<br />

tragen, muss der entsprechende zeitliche Rahmen gegeben<br />

werden. Dies betont nicht nur die fortlaufende Wiederholung<br />

einer Praxiseinheit am Trainingssimulator,<br />

sondern auch die Möglichkeit <strong>für</strong> den Anlagenfahrer,<br />

im Selbststudium am OTS Abläufe zu probieren – und<br />

hier<strong>für</strong> neben der technischen Möglichkeit und der Aufforderung<br />

ein gewisses Zeitbudget zur Verfügung zu<br />

haben. Diese Art des Trainings sollte regelmäßig erfolgen,<br />

beispielsweise in Zeiten geringer Alltagsanforde-<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014<br />

71


HAUPTBEITRAG<br />

rungen, um so den Vorteil zu nutzen, <strong>das</strong>s der Anlagenfahrer<br />

einmal alles mit seiner Anlage machen kann.<br />

Die kontinuierliche Nutzung eines OTS erfordert die<br />

entsprechende Wartung des Systems. Ebenso wie die<br />

reale Anlage im Laufe der Zeit an ein sich änderndes<br />

Umfeld angepasst wird, muss <strong>das</strong> OTS diesen Umbauten<br />

folgen. Praktischerweise wird daher parallel zu<br />

Umbauten der Anlage der OTS aktualisiert. Idealerweise<br />

erfolgt der Update des OTS sogar zeitlich vorher (vergleichbar<br />

einer Neuanlage), denn dann kann die Bedienmannschaft<br />

noch vor der Wiederinbetriebnahme<br />

geschult werden. Die Wartung verursacht auch Kosten:<br />

In [13] wird der Aufwand <strong>für</strong> den zehnjährigen Betrieb<br />

in derselben Größenordnung beziffert, wie <strong>für</strong> die ursprüngliche<br />

Realisierung des Systems.<br />

FAZIT<br />

Trotz einer guten Akzeptanz der Technologie zeigt die<br />

Namur-Umfrage, <strong>das</strong>s im Umgang mit dem OTS Unsicherheiten<br />

bestehen. Dies betrifft alle Phasen im Lebenszyklus<br />

des Systems. In der Auslegung und Projektierung<br />

wünscht sich ein Großteil der teilnehmenden Unternehmen<br />

eine Unterstützung durch eine Richtlinie oder Empfehlung.<br />

In der Nutzung eines OTS <strong>für</strong> <strong>das</strong> Training<br />

werden scheinbar nicht alle Möglichkeiten genutzt, denn<br />

der positive Effekt von Wiederholungen im Training wird<br />

oft nicht ausreichend berücksichtigt. Auch die Nutzung<br />

eines solchen Systems über <strong>das</strong> Training hinaus <strong>für</strong> andere<br />

betriebliche Belange, wie der Verbesserung der<br />

Fahrweise, wird offensichtlich vernachlässigt.<br />

Der Arbeitskreis 2.2 der Namur wird sich dieser Thematik<br />

annehmen und die NA60 hinsichtlich einer Erweiterung<br />

oder einer Ergänzung durch Empfehlung oder<br />

Richtlinie diskutieren.<br />

AUTOR<br />

MANUSKRIPTEINGANG<br />

10.12.2013<br />

Im Peer-Review-Verfahren begutachtet<br />

Dr. KARSTEN SCHULZE<br />

(geb. 1958) ist seit über zwanzig<br />

Jahren tätig in den Bereichen<br />

Advanced Process Control und<br />

Trainingssimulatoren. Seit 2013<br />

leitet er die Funktionseinheit<br />

„Support on Plant Operations<br />

Petrochemical Plants“ bei Linde<br />

<strong>Engineering</strong>. Hauptarbeitsgebiete<br />

sind Studien zum Erhaltungszustand und zur Engpassbeseitigung<br />

in petrochemischen Anlagen, Implementierung<br />

von gehobenen Automationslösungen sowie<br />

Operator Training inklusive Trainingssimulatoren.<br />

Linde AG <strong>Engineering</strong> Division,<br />

Dr.-Carl-von-Linde-Str. 6-14, D-82049 Pullach,<br />

Tel. +49 (0) 89 74 45 43 99,<br />

E-Mail: karsten.schulze@linde-le.com<br />

REFERENZEN<br />

[1] Urbas, L.: Entwicklung und Realisierung einer Trainingsund<br />

Ausbildungsumgebung zur Schulung der Prozeßdynamik<br />

und des Anlagenbetriebs im Internet.<br />

Dissertation TU Berlin, Düsseldorf 1999<br />

[2] Schaich, D., Friedrich, M.: Operator-Training Simulation<br />

(OTS) in der chemischen Industrie – Erfahrungen und<br />

Perspektiven. <strong>atp</strong> – Automatisierungstechnische Praxis<br />

45 (2), S. 38–48, 2003<br />

[3] Kroll, A.: Trainingssimulation <strong>für</strong> die Prozessindustrien:<br />

Status, Trends und Ausblick – Teil 1. <strong>atp</strong> – Automatisierungstechnische<br />

Praxis 45 (2), S. 50–57, 2003<br />

[4] Kroll, A.: Trainingssimulation <strong>für</strong> die Prozessindustrien:<br />

Status, Trends und Ausblick – Teil 2. <strong>atp</strong> – Automatisierungstechnische<br />

Praxis 45 (3), S. 55–60, 2003<br />

[5] NA 60: Management von Trainingssimulatorprojekten.<br />

Namur, www.namur.de<br />

[6] Göttmann, O., Holl, P.: Management von Trainingssimulator-Projekten.<br />

<strong>atp</strong> – Automatisierungstechnische<br />

Praxis 38 (12), S. 11–26, 1996<br />

[7] Kroll, A.: Zum Einsatz von computerbasierter Schulung<br />

bei Anlagenfahrern in Deutschland und in den USA –<br />

Umfrageergebnisse, <strong>atp</strong> – Automatisierungstechnische<br />

Praxis 48(9), S. 45-49, 2006<br />

[8] Heuer, J: Mentale Modelle komplexer Prozesse. Möglichkeiten<br />

zur Qualifikationsförderung und –erhaltung in Prozess -<br />

leit warten durch Simulation und Hypertext-Handbücher.<br />

Dissertation Universität Kassel, 2002<br />

[9] Schaper, N.: Gestaltung und Evaluation arbeitsbezogener<br />

Lernumgebungen. Habilitationsschrift Ruprecht-Karls-<br />

Universität, Heidelberg, 2000<br />

[10] Badke-Schaub, P.; Hofinger, G.; Lauche, K. (Hrsg.): Human<br />

Factors. Psychologie sicheren Handelns in Risikobranchen.<br />

Springer 2012<br />

[11] Schaich, D., Hanisch, F.: Einsatz von Operator-Training-<br />

Simulatoren (OTS) über den Lebenszyklus von Anlagen.<br />

In Tagungsband Automation 2010, S. 255-256. VDI 2010<br />

[12] Schulze, K.: <strong>Engineering</strong> von Operator Training Simulatoren.<br />

Erfahrungen aus einem Großprojekt. In: Tagungsband<br />

Automation 2010, S. 247-250. VDI 2010<br />

[13] Klatt, K.-U.: Trainingssimulation. Erfahrungen und Perspektiven<br />

aus Sicht der chemisch-pharmazeutischen Industrie. <strong>atp</strong><br />

– Automatisierungstechnische Praxis 51(1-2), S. 66-71, 2009<br />

72<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


<strong>atp</strong> Kompaktwissen<br />

Band 1 –<br />

Erfolgreiches <strong>Engineering</strong><br />

Hrsg. F. Schiller, 1. Auflage 2010, 138 Seiten, Broschur<br />

Buch + CD-ROM <strong>für</strong> € 79,–<br />

ISBN 978-3-8356-3210-3<br />

Band 3 –<br />

Praktische Messtechnik<br />

Hrsg. F. Schiller, 1. Auflage 2010, 70 Seiten, Broschur<br />

Buch + CD-ROM <strong>für</strong> € 59,–<br />

ISBN 978-3-8356-3213-4<br />

Band 5 –<br />

Industrielle Informationssicherheit<br />

Hrsg. L. Urbas, 1. Auflage 2014, 88 Seiten, Broschur<br />

Buch <strong>für</strong> € 59,–<br />

ISBN 978-3-8356-7113-3<br />

<strong>atp</strong> kompakt Kollektion (Bände 1-6)<br />

€ 299,80<br />

ISBN 978-3-8356-7146-1<br />

Band 2 –<br />

Effiziente Kommunikation<br />

Hrsg. F. Schiller, 1. Auflage 2010, 70 Seiten, Broschur<br />

Buch + CD-ROM <strong>für</strong> € 59,–<br />

ISBN 978-3-8356-3212-7<br />

Band 4 –<br />

Automation in der Wasserbranche<br />

Hrsg. F. Schiller, 1. Auflage 2010, 146 Seiten, Broschur<br />

Buch + CD-ROM <strong>für</strong> € 59,–<br />

ISBN 978-3-8356-3226-4<br />

Band 6 –<br />

Safety in der Praxis<br />

Hrsg. L. Urbas, 1. Auflage 2014, 112 Seiten, Broschur<br />

Buch <strong>für</strong> € 59,–<br />

ISBN 978-3-8356-7115-7<br />

DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München<br />

www.di-verlag.de<br />

Jetzt bestellen!<br />

Bestellung per Fax: +49 (0) 201 Deutscher / 82002-34 Industrieverlag GmbH oder | Arnulfstr. abtrennen 124 und | 80636 im München Fensterumschlag einsenden<br />

Ja, ich bestelle gegen Rechnung 3 Wochen zur Ansicht<br />

___ Ex. <strong>atp</strong> kompakt Kollektion (Bände 1-6)<br />

ISBN: 978-3-8356-7146-1 <strong>für</strong> € 299,80 (zzgl. Versand)<br />

Firma/Institution<br />

___ Ex.<br />

___ Ex.<br />

___ Ex.<br />

___ Ex.<br />

___ Ex.<br />

___ Ex.<br />

<strong>atp</strong> kompakt<br />

Band 1 – ISBN: 978-3-8356-3210-3 <strong>für</strong> € 79,– (zzgl. Versand<br />

Band 2 – ISBN: 978-3-8356-3212-7 <strong>für</strong> € 59,– (zzgl. Versand)<br />

Band 3 – ISBN: 978-3-8356-3213-4 <strong>für</strong> € 59,– (zzgl. Versand)<br />

Band 4 – ISBN: 978-3-8356-3226-4 <strong>für</strong> € 59,– (zzgl. Versand)<br />

Band 5 – ISBN: 978-3-8356-7113-3 <strong>für</strong> € 59,– (zzgl. Versand)<br />

Band 6 – ISBN: 978-3-8356-7115-7 <strong>für</strong> € 59,– (zzgl. Versand)<br />

Vorname, Name des Empfängers<br />

Straße / Postfach, Nr.<br />

Land, PLZ, Ort<br />

Antwort<br />

Vulkan-Verlag GmbH<br />

Versandbuchhandlung<br />

Postfach 10 39 62<br />

45039 Essen<br />

Telefon<br />

E-Mail<br />

Telefax<br />

Branche / Wirtschaftszweig<br />

Widerrufsrecht: Sie können Ihre Vertragserklärung innerhalb von zwei Wochen ohne Angabe von Gründen in Textform (z.B.<br />

Brief, Fax, E-Mail) oder durch Rücksendung der Sache widerrufen. Die Frist beginnt nach Erhalt dieser Belehrung in Textform.<br />

Zur Wahrung der Widerrufsfrist genügt die rechtzeitige Absendung des Widerrufs oder der Sache an die Vulkan-Verlag GmbH,<br />

Versandbuchhandlung, Huyssenallee 52-56, 45128 Essen.<br />

Ort, Datum, Unterschrift<br />

Nutzung personenbezogener Daten: Für die Auftragsabwicklung und zur Pflege der laufenden Kommunikation werden personenbezogene Daten erfasst und gespeichert. Mit dieser Anforderung erkläre ich mich damit einverstanden,<br />

<strong>das</strong>s ich vom DIV Deutscher Industrieverlag oder vom Vulkan-Verlag per Post, per Telefon, per Telefax, per E-Mail, nicht über interessante, fachspezifische Medien und Informationsangebote informiert und beworben werde.<br />

Diese Erklärung kann ich mit Wirkung <strong>für</strong> die Zukunft jederzeit widerrufen.<br />

PAATPK2014


IMPRESSUM / VORSCHAU<br />

IMPRESSUM<br />

VORSCHAU<br />

Verlag:<br />

DIV Deutscher Industrieverlag GmbH<br />

Arnulfstraße 124, D-80636 München<br />

Telefon + 49 (0) 89 203 53 66 0<br />

Telefax + 49 (0) 89 203 53 66 99<br />

www.di-verlag.de<br />

Geschäftsführer:<br />

Carsten Augsburger, Jürgen Franke<br />

Verlagsleiterin:<br />

Kirstin Sommer<br />

Spartenleiterin:<br />

Anne Purschwitz geb. Hütter<br />

Herausgeber:<br />

Dr.rer.nat. Thomas Albers<br />

Dr. Gunther Kegel<br />

Dipl.-Ing. Hans-Georg Kumpfmüller<br />

Dr.-Ing. Wilhelm Otten<br />

Beirat:<br />

Dr.-Ing. Kurt Dirk Bettenhausen<br />

Prof. Dr.-Ing. Christian Diedrich<br />

Prof. Dr.-Ing. Ulrich Epple<br />

Prof. Dr.-Ing. Alexander Fay<br />

Prof. Dr.-Ing. Michael Felleisen<br />

Prof. Dr.-Ing. Georg Frey<br />

Prof. Dr.-Ing. Peter Göhner<br />

Dipl.-Ing. Thomas Grein<br />

Prof. Dr.-Ing. Hartmut Haehnel<br />

Dr.-Ing. Jörg Kiesbauer<br />

Dipl.-Ing. Rolf Marten<br />

Dipl.-Ing. Gerald Mayr<br />

Dr. Jörg Nothdurft<br />

Dr.-Ing. Josef Papenfort<br />

Dr. Andreas Wernsdörfer<br />

Dipl.-Ing. Dieter Westerkamp<br />

Dr.rer.nat. Christian Zeidler<br />

Organschaft:<br />

Organ der GMA<br />

(VDI/VDE-Gesell schaft Messund<br />

Automatisierungs technik)<br />

und der NAMUR (Interessengemeinschaft<br />

Automatisierungstechnik<br />

der Prozessindustrie).<br />

Redaktion:<br />

Anne Purschwitz geb. Hütter (ahü)<br />

(verantwortlich)<br />

Telefon + 49 (0) 89 203 53 66 58<br />

E-Mail: purschwitz@di-verlag.de<br />

Aljona Hartstock (aha)<br />

Telefon + 49 (0) 89 203 53 66 78<br />

E-Mail: hartstock@di-verlag.de<br />

Einreichung von Hauptbeiträgen:<br />

Prof. Dr.-Ing. Leon Urbas<br />

(Chefredakteur, verantwortlich<br />

<strong>für</strong> die Hauptbeiträge)<br />

Technische Universität Dresden<br />

Fakultät Elektrotechnik<br />

und Informationstechnik<br />

Professur <strong>für</strong> Prozessleittechnik<br />

D-01062 Dresden<br />

Telefon +49 (0) 351 46 33 96 14<br />

E-Mail: urbas@di-verlag.de<br />

Fachredaktion:<br />

Dr.-Ing. Michael Blum<br />

Dipl.-Ing. Heinrich Engelhard<br />

Prof. Dr.-Ing. Jürgen Jasperneite<br />

Dr.-Ing. Bernhard Kausler<br />

Dr.-Ing. Niels Kiupel<br />

Prof. Dr.-Ing. Gerrit Meixner<br />

Dr.-Ing. Jörg Neidig<br />

Dipl.-Ing. Ingo Rolle<br />

Dr.-Ing. Stefan Runde<br />

Prof. Dr.-Ing. Frank Schiller<br />

Bezugsbedingungen:<br />

„<strong>atp</strong> <strong>edition</strong> – Automatisierungs technische<br />

Praxis“ erscheint monatlich mit Doppelausgaben<br />

im Januar/Februar und Juli/August.<br />

Bezugspreise:<br />

Abonnement jährlich: € 519,– + € 30,–/ € 35,–<br />

Versand (Deutschland/Ausland);<br />

Heft-Abonnement + Online-Archiv: € 704,70;<br />

ePaper (PDF): € 519,–; ePaper + Online-Archiv:<br />

€ 647,70; Einzelheft: € 56,– + Versand;<br />

Die Preise enthalten bei Lieferung in EU-<br />

Staaten die Mehrwertsteuer, <strong>für</strong> alle übrigen<br />

Länder sind es Nettopreise. Mitglieder der<br />

GMA: 30% Ermäßigung auf den Heftbezugspreis.<br />

Bestellungen sind jederzeit über den Leserservice<br />

oder jede Buchhandlung möglich.<br />

Die Kündigungsfrist <strong>für</strong> Abonnement aufträge<br />

beträgt 8 Wochen zum Bezugsjahresende.<br />

Abonnement-/Einzelheftbestellung:<br />

DataM-Services GmbH, Leserservice <strong>atp</strong><br />

Herr Marcus Zepmeisel<br />

Franz-Horn-Str. 2, 97082 Würzburg<br />

Telefon + 49 (0) 931 417 04 59<br />

Telefax + 49 (0) 931 417 04 94<br />

leserservice@di-verlag.de<br />

Verantwortlich <strong>für</strong> den Anzeigenteil:<br />

Inge Spoerel<br />

Telefon + 49 (0) 89 203 53 66 22<br />

E-Mail: spoerel@di-verlag.de<br />

Kirstin Sommer (Key Account)<br />

Telefon + 49 (0) 89 203 53 66 36<br />

E-Mail: sommer@di-verlag.de<br />

Angelika Weingarten (Key Account)<br />

Telefon + 49 (0) 89 203 53 13<br />

E-Mail: weingarten@di-verlag.de<br />

Es gelten die Preise der Mediadaten 2014<br />

Anzeigenverwaltung:<br />

Brigitte Krawczyk<br />

Telefon + 49 (0) 89 203 53 66 12<br />

E-Mail: krawczyk@di-verlag.de<br />

Art Direction / Layout:<br />

deivis aronaitis design | dad |<br />

Druck:<br />

Druckerei Chmielorz GmbH,<br />

Ostring 13,<br />

D-65205 Wiesbaden-Nordenstadt<br />

Gedruckt auf chlor- und<br />

säurefreiem Papier.<br />

Die <strong>atp</strong> wurde 1959 als „Regelungstechnische<br />

Praxis – rtp“ gegründet.<br />

DIV Deutscher Industrieverlag<br />

GmbH München<br />

Die Zeitschrift und alle in ihr enthaltenen<br />

Beiträge und Abbildungen sind urheberrechtlich<br />

geschützt. Mit Ausnahme der gesetzlich<br />

zugelassenen Fälle ist eine Verwertung ohne<br />

Ein willigung des Verlages strafbar.<br />

Gemäß unserer Verpflichtung nach § 8<br />

Abs. 3 PresseG i. V. m. Art. 2 Abs. 1c DVO<br />

zum BayPresseG geben wir die Inhaber<br />

und Beteiligungsverhältnisse am Verlag<br />

wie folgt an:<br />

DIV Deutscher Industrieverlag GmbH,<br />

Arnulfstraße 124, D-80636 München.<br />

Alleiniger Gesellschafter des Verlages<br />

ist die ACM-Unternehmensgruppe,<br />

Ostring 13,<br />

D-65205 Wiesbaden-Nordenstadt.<br />

ISSN 2190-4111<br />

DIE AUSGABE 3 / 2014 DER<br />

ERSCHEINT AM 03.03.2014<br />

MIT DEM SCHWERPUNKT<br />

„ADVANCED PROCESS CONTROL“<br />

Advanced Position<br />

Control <strong>für</strong> Servoachsen<br />

mit Flexibilitäten<br />

Überwachung und<br />

Optimierung der Basisregelung<br />

von Anlagen<br />

Advanced Process<br />

Control in der Praxis<br />

Einsatzmöglichkeiten<br />

Leitsystem-<strong>integrierte</strong>r<br />

Prädiktivregler<br />

Nichtlineare modellprädiktive<br />

Regelung<br />

auf SPS<br />

Aus aktuellem Anlass können sich die Themen<br />

kurzfristig verändern.<br />

LESERSERVICE<br />

E-MAIL:<br />

leserservice@di-verlag.de<br />

TELEFON:<br />

+ 49 (0) 931 417 04 59<br />

74<br />

<strong>atp</strong> <strong>edition</strong><br />

1-2 / 2014


Erreichen Sie die Top-Entscheider<br />

der Automatisierungstechnik.<br />

Sprechen Sie uns an wegen Anzeigenbuchungen<br />

und Fragen zu Ihrer Planung.<br />

Inge Spoerel: Telefon +49 (0) 89 203 53 66-22<br />

E-Mail: spoerel@di-verlag.de


<strong>atp</strong> Kompaktwissen<br />

Band 1 –<br />

Erfolgreiches <strong>Engineering</strong><br />

Hrsg. F. Schiller, 1. Auflage 2010, 138 Seiten, Broschur<br />

Buch + CD-ROM <strong>für</strong> € 79,–<br />

ISBN 978-3-8356-3210-3<br />

Band 3 –<br />

Praktische Messtechnik<br />

Hrsg. F. Schiller, 1. Auflage 2010, 70 Seiten, Broschur<br />

Buch + CD-ROM <strong>für</strong> € 59,–<br />

ISBN 978-3-8356-3213-4<br />

Band 5 –<br />

Industrielle Informationssicherheit<br />

Hrsg. L. Urbas, 1. Auflage 2014, 88 Seiten, Broschur<br />

Buch <strong>für</strong> € 59,–<br />

ISBN 978-3-8356-7113-3<br />

<strong>atp</strong> kompakt Kollektion (Bände 1-6)<br />

€ 299,80<br />

ISBN 978-3-8356-7146-1<br />

Band 2 –<br />

Effiziente Kommunikation<br />

Hrsg. F. Schiller, 1. Auflage 2010, 70 Seiten, Broschur<br />

Buch + CD-ROM <strong>für</strong> € 59,–<br />

ISBN 978-3-8356-3212-7<br />

Band 4 –<br />

Automation in der Wasserbranche<br />

Hrsg. F. Schiller, 1. Auflage 2010, 146 Seiten, Broschur<br />

Buch + CD-ROM <strong>für</strong> € 59,–<br />

ISBN 978-3-8356-3226-4<br />

Band 6 –<br />

Safety in der Praxis<br />

Hrsg. L. Urbas, 1. Auflage 2014, 112 Seiten, Broschur<br />

Buch <strong>für</strong> € 59,–<br />

ISBN 978-3-8356-7115-7<br />

DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München<br />

www.di-verlag.de<br />

Jetzt bestellen!<br />

Bestellung per Fax: +49 (0) 201 Deutscher / 82002-34 Industrieverlag GmbH oder | Arnulfstr. abtrennen 124 und | 80636 im München Fensterumschlag einsenden<br />

Ja, ich bestelle gegen Rechnung 3 Wochen zur Ansicht<br />

___ Ex. <strong>atp</strong> kompakt Kollektion (Bände 1-6)<br />

ISBN: 978-3-8356-7146-1 <strong>für</strong> € 299,80 (zzgl. Versand)<br />

Firma/Institution<br />

___ Ex.<br />

___ Ex.<br />

___ Ex.<br />

___ Ex.<br />

___ Ex.<br />

___ Ex.<br />

<strong>atp</strong> kompakt<br />

Band 1 – ISBN: 978-3-8356-3210-3 <strong>für</strong> € 79,– (zzgl. Versand<br />

Band 2 – ISBN: 978-3-8356-3212-7 <strong>für</strong> € 59,– (zzgl. Versand)<br />

Band 3 – ISBN: 978-3-8356-3213-4 <strong>für</strong> € 59,– (zzgl. Versand)<br />

Band 4 – ISBN: 978-3-8356-3226-4 <strong>für</strong> € 59,– (zzgl. Versand)<br />

Band 5 – ISBN: 978-3-8356-7113-3 <strong>für</strong> € 59,– (zzgl. Versand)<br />

Band 6 – ISBN: 978-3-8356-7115-7 <strong>für</strong> € 59,– (zzgl. Versand)<br />

Vorname, Name des Empfängers<br />

Straße / Postfach, Nr.<br />

Land, PLZ, Ort<br />

Antwort<br />

Vulkan-Verlag GmbH<br />

Versandbuchhandlung<br />

Postfach 10 39 62<br />

45039 Essen<br />

Telefon<br />

E-Mail<br />

Telefax<br />

Branche / Wirtschaftszweig<br />

Widerrufsrecht: Sie können Ihre Vertragserklärung innerhalb von zwei Wochen ohne Angabe von Gründen in Textform (z.B.<br />

Brief, Fax, E-Mail) oder durch Rücksendung der Sache widerrufen. Die Frist beginnt nach Erhalt dieser Belehrung in Textform.<br />

Zur Wahrung der Widerrufsfrist genügt die rechtzeitige Absendung des Widerrufs oder der Sache an die Vulkan-Verlag GmbH,<br />

Versandbuchhandlung, Huyssenallee 52-56, 45128 Essen.<br />

Ort, Datum, Unterschrift<br />

Nutzung personenbezogener Daten: Für die Auftragsabwicklung und zur Pflege der laufenden Kommunikation werden personenbezogene Daten erfasst und gespeichert. Mit dieser Anforderung erkläre ich mich damit einverstanden,<br />

<strong>das</strong>s ich vom DIV Deutscher Industrieverlag oder vom Vulkan-Verlag per Post, per Telefon, per Telefax, per E-Mail, nicht über interessante, fachspezifische Medien und Informationsangebote informiert und beworben werde.<br />

Diese Erklärung kann ich mit Wirkung <strong>für</strong> die Zukunft jederzeit widerrufen.<br />

PAATPK2014

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!