atp edition Automatisierung im Life Cycle modularer Anlagen (Vorschau)

1-2 / 2013 

55. Jahrgang B3654 

DIV Deutscher Industrieverlag GmbH 

Automatisierungstechnische Praxis 

Automatisierung im Life Cycle 

modularer Anlagen | 24 

Erfahrungen mit Web-basierter 

As-Built-Dokumentation | 32 

Genauigkeit von Messgeräten überwachen | 38 

Integriertes Engineering – 

wann, wenn nicht jetzt! | 46 

Anforderungsprofil von Software wechseln | 56 

OPC UA and ISA 95 | 64 

Cloud Computing im Kontext 

eines Prozessleitsystems | 74

Danke! 

atp edition ist vom Verband Deutsche 

Fachpresse als Fachmedium des Jahres 

2012 in der Kategorie Industrie/Produktion/ 

Design ausgezeichnet worden. atp edition 

ist eine Gemeinschaftsleistung aus der 

Branche für die Branche. Hinter der hochwertigen 

Publikation für Automatisierungstechnik 

stecken viele kluge Köpfe. Nicht 

nur Chefredakteur, Herausgeber und Beiräte 

tragen mit ihrem Agenda-Setting dazu bei, 

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

Tradition die maßgeblichen Themen der 

Automatisierungstechnik bestimmt. Auch 

die Fachredaktion leistet mit einem Peer- 

Review-Verfahren für wissenschaftlich 

fundierte Veröffentlichungen einen unverzichtbaren 

Beitrag. Nicht möglich wäre dies 

ohne unsere zahlreichen Fach-Autoren. Ein 

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

edition stehen und das Fachmagazin zu 

einem Erfolg machen – und nicht zuletzt 

an Sie, unsere Leser. 

Ihre Entscheidung für die hochwertige 

Publikation atp edition stärkt die Bedeutung 

wissenschaftlicher Forschungsarbeiten 

in der Automatisierungstechnik.

Print wirkt 

„atp edition“ ist ein Printtitel auf höchster 

Qualitätsstufe und mit Nachhaltigkeit im 

Sinne wiederkehrender Nutzung. Der Titel 

erfüllt den selbstgestellten Anspruch eines 

anspruchsvollen und seriösen Magazins für 

Top-Entscheider zwischen Wissenschaft 

und Praxis konsequent. 

Entsprechend der journalistischen Konzeption 

ist Online hintenangestellt. Die Jury 

sah hier „die beispielhafte Umsetzung einer 

wissenschaftlich ausgerichteten Fachzeitschrift 

mit Magazincharakter“.

EDITORIAL 

Integration versus Flexibilität 

Die technischen Aspekte von „Integration“, „Interoperabilität“ und „Schnittstellen“ 

spielen in dieser Ausgabe der atp edition die zentrale Rolle. Auch in unserer 

Wirtschaft stehen wir vor der Herausforderung, durch Integration Synergien 

zu nutzen. Im Wesentlichen geschieht dies stets durch Vermeidung von Doppelarbeit: 

im Engineering in der Dateneingabe, in der Industrie in den Geschäftsprozessen. 

Daher sucht man Firmen, bei denen man erwartet, dass durch Kauf oder 

Fusion und das anschließende „Mergen“ Synergien generiert und Kosten eingespart 

werden können. 

Ein Blick in die Literatur zu den Erfolgen dieser Firmenfusionen sorgt allerdings 

für Ernüchterung: Nur weniger als die Hälfte der Fusionen erbrachte die gewünschten 

Synergien. Bei den übrigen stellten sich die erhofften Kosten- und Wertsynergien 

(etwa Skaleneffekte) nicht ein oder sie wurden durch Integrations- und Koordinationskosten 

überkompensiert. Dafür finden sich vor allem zwei Gründe. Meist 

wurden die potenziellen Synergien sehr ambitioniert geplant, um die bezahlte 

Prämie (Differenz zwischen Marktwert und Kaufpreis) zu rechtfertigen, oder der 

Changeprozess im Umgang mit den Firmenkulturen hat nicht funktioniert. 

Die Erwartungen bei der Integration von technischen Systemen oder Prozessen 

wie „integriertes Engineering“ sind hoffentlich realistischer. Aber generell führt 

eine Integration zur Erhöhung von Komplexität und Größe. Zunehmende Größe 

führt zu längeren Entscheidungswegen und damit zur Trägheit der Organisation. 

Nicht umsonst sind in unserem Land viele kleine und mittelständische Unternehmungen 

erfolgreich. Die Komplexität bringt außerdem höhere Anforderungen an 

diejenigen mit sich, die das System betreuen oder an die im Prozess mitarbeitenden 

Ingenieure und Techniker. 

Was ist die Konsequenz? Erstens sollte man nur jene Dinge integrieren, die einen 

direkten Mehrwert generieren. Wo kein Mehrwert generiert wird, tut man gut 

daran, Strukturen dezentral und auch in dezentraler Entscheidung zu belassen. 

Zweitens muss Integration gesteuert werden, und vor allem müssen die am Integrationsprozess 

Beteiligten jene Fähigkeiten besitzen oder erlangen, die nötig sind, 

um in den integrierten Systemen zu arbeiten. Dazu sind eine gute Grundausbildung 

und eine Weiterbildung notwendig. Die atp edition leistet hier mit ihren hochwertigen 

Inhalten einen wichtigen Beitrag. 

Den gleichen Überlegungen folgt die Namur bei ihrer Internationalisierung. Wir 

achten sehr darauf, dass die Namur China eine eigene Identität entwickelt und die 

Arbeit sich an den Anforderungen der Region orientiert. Auch in der Diskussion 

mit den europäischen Verbänden werden wir weiter auf Nutzung der dezentralen 

Strukturen setzen und nur die wesentlichen Fragestellungen zentral angehen, dort 

wo die gemeinsame Aktivität einen Mehrwert generiert. 

Der Erfolg des Fortschritts hängt also nicht nur davon ab, was wir machen, sondern 

auch wie (intelligent) wir etwas tun. Die Namur wird den Weg der Integration 

gehen, sowohl technisch als auch in ihrer Organisation. „Integriertes Engineering“ 

wird das Thema auf der Hauptsitzung 2013 sein. 

In unseren Arbeitskreisen verfügen wir über die notwendigen Kompetenzen, 

diese Themen voranzutreiben – aber auch zu erkennen, wo Integration keinen Sinn 

mehr macht. 

DR. WILHELM 

OTTEN, 

Vorsitzender des 

Namur-Vorstands 

atp edition 

1-2 / 2013 

3

INHALT 1-2 / 2013 

VERBAND 

06 | Norbert Kuschnerus tritt in den Ruhestand 

Höchste DKE-Auszeichnung für Hartwig Steusloff 

07 | Profibus: Integration und Diagnose 

Bitkom setzt auf Industrie 4.0 und engere Vernetzung 

Funktionale Sicherheit für die Praxis 

BRANCHE 

08 | GMA-Tagung zum Integrated Plant Engineering 

aus Sicht von Industrie und Wissenschaft 

Ulrich Turck leitet den Fieldbus-Beirat 

Processnet/Namur-Symposium: Digitale Anlagenplanung und -führung 

09 | Die Umsatzdelle soll 2013 ausgebeult werden 

FORSCHUNG 

10 | Leistungsfähige Sensoren einfach aufgesprüht 

Die drahtlose Fabrik baut auf dezentrale Intelligenz 

11 | Dresdener Studenten greifen nach den Sternen 

Namur-Award 2013: Verband nimmt bis zum 

28. Juni 2013 Fachaufsätze entgegen 

PRAXIS 

12 | Lineares Transport-System XTS: Zentraler Antrieb 

mit den Vorteilen eines dezentralen Systems realisiert 

16 | Spezialarmatur für Öl- und Gasindustrie garantiert 

zuverlässige Regelung bei tiefen Temperaturen 

18 | Wirbelfrequenzmessung ermittelt Produktion von Bio-Methan 

auch unter schwierigen Bedingungen 

INTERVIEW 

20 | „Die Diagnose-Informationen sind da – wir müssen Sie nur nutzen“ 

JÖRG KIESBAUER, VORSTANDSMITGLIED DER SAMSON AG, 

IM INTERVIEW MIT ATP-EDITION-CHEFREDAKTEUR LEON URBAS 

4 


1-2 / 2013

HAUPTBEITRÄGE | NAMUR-HAUPTSITZUNG 

24 | Automatisierung im Life Cycle 

modularer Anlagen 

M. OBST, T. HOLM, S. BLEUEL, U. CLAUSSNITZER, L. EVERTZ, 

T. JÄGER, T. NEKOLLA, S. PECH, S. SCHMITZ UND L. URBAS 

32 | Erfahrungen mit Web-basierter 

As-Built-Dokumentation 

M. BRENDELBERGER UND M. DUBOVY 

Produkte, 

Systeme 

und Service 

für die 

Prozessindustrie? 

Natürlich. 

38 | Genauigkeit von Messgeräten 

überwachen 

T. HAUFF, W. LIANG, M. STRAUSS, C. BRECHER 

UND M. OBDENBUSCH 

46 | Integriertes Engineering – 

wann, wenn nicht jetzt! 

T. TAUCHNITZ 

HAUPTBEITRÄGE 

56 | Anforderungsprofil von 

Software wechseln 

W. EHRENBERGER 

64 | OPC UA and ISA 95 

D. BRANDL, P. HUNKAR, W. MAHNKE UND T. ONO 

74 | Cloud Computing im Kontext 

eines Prozessleitsystems 

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

Zum Beispiel der magnetischinduktive 

Durchflussmesser 

ProcessMaster. Er setzt neue 

Maßstäbe mit umfangreichen 

Diagnosemöglichkeiten, einer 

Messabweichung von 0,2 %, 

Explosionsschutz sowie der 

ScanMaster-Software. Erfahren 

Sie mehr über die erste Wahl in 

der Durchflussmessung für die 

Prozessindustrie: 

www.abb.de/durchfluss 

Wussten Sie, dass Ihnen ABB 

neben dem umfassenden Portfolio 

für die Instrumentierung ebenso 

herausragende Produkte und 

Lösungen für die Analysentechnik, 

maßgeschneiderte Leitsysteme 

sowie erstklassigen Service bietet? 

Lesen Sie mehr unter: 

www.abb.de/ 

prozessautomatisierung 

RUBRIKEN 

3 | Editorial: Integration versus Flexibilität 

82 | Impressum, Vorschau 

ABB Automation Products GmbH 

Tel.: 0800 111 44 11 

Fax: 0800 111 44 22 

vertrieb.messtechnik-produkte@de.abb.com

VERBAND 

Norbert Kuschnerus tritt in den Ruhestand 

STABWECHSEL: Dr. Norbert Kuschnerus 

(rechts) verlässt mit seinem Eintritt in den 

Ruhestand auch den Herausgeberkreis der 

atp edition – Automatisierungstechnische 

Praxis. Hier folgt ihm der Namur-Vorsitzende 

Dr. Wilhelm Otten (links). Bild: Namur 

NEUER 

DIVISIONS LEITER 

Operation Support 

& Safety bei Bayer 

Technology 

Services wird 

Dr. Thomas 

Steckenreiter als 

Nach folger von 

Dr. Norbert 

Kusch nerus. 

Bild: BTS 

Nach fast 30 Jahren bei Bayer und einem Jahrzehnt an 

der Spitze der Namur tritt Dr. Norbert Kuschnerus 

zum 30. Juni in den Ruhestand. Kuschnerus ist Divisionsleiter 

Operation Support & Safety bei Bayer Technology 

Services (BTS). Bis 2011 leitete er neun Jahre die Namur 

als Vorstandsvorsitzender, aktuell ist er stellvertretender 

Vorsitzender. Für die Interessen der Automatisierungstechnik-Anwender 

setzt sich Dr. Kuschnerus auch seit 

vielen Jahren als Mitherausgeber der atp edition – Auto- 

matisierungstechnische Praxis ein. Die Aufgabe im Herausgeber-Kreis 

der atp edition wird Dr. Wilhelm Otten, 

Evonik Industries, übernehmen, der seit 2011 Namur- 

Vorstandsvorsitzender ist. 

Neuer Divisionsleiter Operation Support & Safety bei 

Bayer Technology Services wird zum 1. Juli Dr. Thomas 

Steckenreiter (47). Steckenreiter fungiert bislang als Direktor 

Marketing bei der Endress+Hauser Conducta GmbH 

in Gerlingen. Als Mitglied des BTS Management Committees 

übernimmt er die weltweite Verantwortung für die 

Division Operation Support & Safety. 

„Dr. Steckenreiter besitzt fundierte Erfahrung in den 

Bereichen Prozesssicherheit und -analysentechnik. Er 

verfügt über besondere Qualitäten, die für den fokussierten 

Ausbau unseres Portfolios und damit unseres zukünftigen 

Geschäfts von großer Bedeutung sind“, sagte BTS- 

Geschäftsführer Dr. Dirk Van Meirvenne. Er dankte Kuschnerus 

für seine sehr erfolgreiche Arbeit, die das weltweite 

Renommee der BTS wesentlich mitgeprägt hat. 

Kuschnerus implementierte bei BTS unter anderem das 

Konzept der Operational Excellence, also der ganzheitlichen 

Optimierung von Anlagenverfügbarkeit, Energieund 

Rohstoffeinsatz sowie Prozesssicherheit. Darüber 

hinaus wurden unter seiner Leitung neue, intelligente 

Online-Prozessanalytikmethoden und Automatisierungsplattformen 

entwickelt. Er etablierte neue Prozessstandards 

für die chemisch-pharmazeutische Industrie und 

arbeitete weltweit mit renommierten Forschungseinrichtungen 

und Hochschulen zusammen. 

(gz) 

BAYER TECHNOLOGY SERVICES GMBH, 

Gebäude K 9, D-51368 Leverkusen, 

Tel. +49 (0) 214 301, Internet: www.bayertechnology.com 

Höchste DKE-Auszeichnung für Hartwig Steusloff 

HÖCHSTE EHRUNG: Hartwig Steusloff (Mitte) erhielt vom 

DKE-Vorsitzenden Wolfgang Hofheinz (links) und Dr.-Ing. 

Bernhard Thies (rechts), dem Sprecher der DKE-Geschäftsführung, 

die goldene Ehrennadel der Organisation. Bild: DKE 

Für seine herausragenden Leistungen bei der zukunftsorientierten 

Gestaltung des deutschen Normungssystems 

erhielt Prof. Dr. Hartwig Steusloff die DKE-Nadel in 

Gold. Die Nadel in Gold ist die höchste Auszeichnung der 

vom VDE getragenen Normungsorganisation DKE Deutsche 

Kommission Elektrotechnik Elektronik Informationstechnik 

im DIN und VDE (VDE|DKE). Zuvor war sie erst ein 

einziges Mal verliehen worden: Im Jahr 2010 erhielt sie der 

ehemalige DKE-Vorsitzende Dr. Dietmar Harting. 

Der DKE-Vorsitzende Dipl.-Ing. Wolfgang Hofheinz und 

der Sprecher der DKE-Geschäftsführung Dr.- Ing. Bernhard 

Thies hoben in ihrer Laudatio die Verdienste des 

Ehrenpreisträgers für die deutsche Normung hervor. Unter 

anderem war Hartwig Steusloff maßgeblich an der 

Erarbeitung der Deutschen Normungs-Roadmaps Elektromobilität 

und E-Energy/Smart Grid beteiligt. 

Steusloff, heute als Bevollmächtigter Berater der Institutsleitung 

des Fraunhofer-Instituts für Optronik, Systemtechnik 

und Bildauswertung (IOSB) tätig, hat sich in 

zahlreichen Funktionen und Gremien für die deutsche 

Normungsstrategie eingesetzt. 2004 wurde der langjährige 

Vorsitzende des DKE-Fachbereichs 9 „Leittechnik“ 

Mitglied des Lenkungsausschusses und 2. Stellvertretender 

Vorsitzender der DKE sowie Vorsitzender des DKE- 

Beraterkreises Technologie. Von 2009 bis 2011 leitete er 

auch den DKE-Lenkungskreis „Dezentrale Energien“. (gz) 

DKE – DEUTSCHE KOMMISSION ELEKTROTECHNIK 

ELEKTRONIK INFORMATIONSTECHNIK IM DIN UND VDE 

Stresemannallee 15, D-60596 Frankfurt am Main, 

Tel. +49 (0) 69 630 80, Internet: www.dke.de 

6 


1-2 / 2013

Profibus: Integration und Diagnose 

Leistungsfähige Kommunikationssysteme bilden die Basis 

für die Automatisierung. Dazu gehören neben dem 

klassischen Feldbus zunehmend ethernetbasierte Lösungen 

sowie die Sensor-/Aktor-Kommunikation. PI (Profibus 

& Profinet International) stellt dazu mit Profibus, 

Profinet und IO-Link führende Technologien zur Verfügung. 

Entscheidend sind neben der Funktionalität und 

Performance vor allem die Integration in die Systemlandschaft 

und der zuverlässige Betrieb. 

Die PI-Konferenz 2013 am 6. und 7. März 2013 in Düsseldorf 

greift diese Aufgabenstellungen auf und steht unter 

dem Leitthema „Integration und Diagnose“. Das Programm 

adressiert dabei gleichermaßen die Anwendungsfelder 

der Fertigungs- wie auch der Prozessautomation. 

Anwenderberichte und Technologie-Konzepte bilden das 

Rückgrat für den Erfahrungsaustausch. 

Der Weg zur Smart Factory beziehungsweise zur Industrie 

4.0 wird in unterschiedlichen Branchen unterschiedlich 

schnell ablaufen. Die Ideen der Automatisierungstechnik 

sowie industrielle Informationstechnik und Industriesoftware 

gewinnen an Bedeutung, virtuelle und 

reale Fertigung verschmelzen. Die Themen Integration 

und Diagnose in Verbindung mit Kommunikationssystemen 

spielen hierbei eine wichtige Rolle. Auf der PI-Konferenz 

wird in einer Podiumsdiskussion mit namhaften 

Industrievertretern die Bedeutung der industriellen Kommunikation 

im Internet der Dinge thematisiert. 

Ein weiteres Thema der Tagung ist das effektive Gerätemanagement 

bezogen auf technische Weiterentwicklungen, 

Gerätetauschszenarien und Anlagenerweiterungen 

beziehungsweise -modernisierungen. Beleuchtet werden 

auch Systemdesign und -integration, bei denen der Anwender 

den nicht immer einfachen Spagat zwischen Auswahl 

von Komponenten aus einem großen Spektrum verschiedener 

Anbieter und Integration zu einem einheitlichen 

Automatisierungssystem bewältigen muss. Weitere Informationen 

sowie das komplette Programm sind zu finden 

unter www.pi-konferenz.de. 

(gz) 

PROFIBUS-NUTZERORGANISATION, 

Haid-und-Neu-Straße 7, D-76131 Karlsruhe, 

Tel. +49 (0) 721 965 85 90, Internet: www.profibus.com 

Bitkom: Industrie 4.0 und engere Vernetzung 

Der Branchenverband der Informations- und Kommunikationsindustrie 

Bitkom baut seine Aktivitäten zum 

Thema „Industrie 4.0“ stark aus. Dazu bündelt der Verband 

die entsprechenden Aktivitäten in einem neuen 

Kompetenzbereich. 

Dieser Bereich wird zunächst vier Arbeitsplattformen 

haben: Ein Arbeitskreis „Strategie und Markt“ soll vor allem 

Geschäftsmodelle entwickeln und Best Practices nutzen. 

Ein Arbeitskreis „Interoperabilität“ soll die Schnittstellen 

zwischen Fabrik-IT und Büro-IT entwickeln. Nicht-Mitglieder 

haben die Möglichkeit, an den Aktivitäten eines Dialogkreises 

teilzunehmen. Der bisherige Arbeitskreis „Cyber- 

Physical Systems“ mit seinem Kernthema „Embedded Systems“ 

komplettiert den neuen Kompetenzbereich Industrie 

4.0. Bereichsleiter Industrie 4.0 wird Wolfgang 

Dorst, bei Bitkom bislang für Software zuständig. 

Präsident Prof. Dieter Kempf betont: „Durch 

Industrie 4.0 wird die Bitkom-Branche künftig 

stärker denn je mit der Fertigungsindustrie verzahnt 

– nicht nur mit dem Maschinen- und Anlagenbau, 

ebenso mit der Elektrotechnik oder 

dem Automobilbau.“ 

(gz) 

BITKOM BUNDESVERBAND INFORMATIONS- 

WIRTSCHAFT, TELEKOMMUNIKATION 

UND NEUE MEDIEN E.V., 

Albrechtstraße 10 A, D-10117 Berlin, 

Tel. +49 (0) 30 27 57 60, Internet: www.bitkom.org 

BITKOM-PRÄSIDENT 

PROF. DIETER KEMPF 

betont: „Durch Industrie 

4.0 wird die Bitkom- 

Branche künftig stärker 

denn je mit der 

Fertigungs industrie 

verzahnt“. Bild: Bitkom 

Funktionale Sicherheit für die Praxis 

Dem Thema funktionale Sicherheit widmet die DKE Deutsche 

Kommission Elektrotechnik Elektronik Informationstechnik 

im DIN und VDE (VDE|DKE) zwei Tagungen. 

Am 31. Januar 2013 findet das VDE|DKE-Kolloquium 

„Schutzeinrichtungen der Elektrotechnik und funktionale 

Sicherheit nach IEC 61508 (VDE 0803) – Fokus sichere Messtechnik“ 

in Köln statt. Die Grundsätze für die Auslegung 

sicherheitsgerichteter Steuerungen finden sich in der Norm 

IEC 61508, in Deutschland übernommen als DIN EN 61508 

(VDE 0803). Das Kolloquium soll potenziellen Anwendern 

Hilfestellung zu einem besseren Verständnis der funktionalen 

Sicherheit geben. Im Mittelpunkt stehen die Themen 

Sicherheitsnormung, Risikoanalyse und Berechnung von 

sicherheitstechnischen Kennzahlen sowie die Anwendung 

der funktionalen Sicherheit in neuen Gebieten, speziell die 

sichere Messtechnik. 

Die „Tagung zur Funktionalen Sicherheit IEC 61508 (VDE 

0803) IEC 61508 & Co – aber wie anwenden?“ findet am 12. 

und 13. März in Erfurt statt. Dort informieren Experten der 

DKE über die konkrete Anwendung der Norm. Zu groß ist 

oft noch die Lücke, die zwischen dem Text der Norm und 

konkreten Anwendungen liegt. Wie geht man beispielsweise 

vor, wenn diese nicht in der Literatur beschrieben sind, 

die zuverlässigkeitstechnischen Kenngrößen der einzusetzenden 

Geräte nicht vorliegen oder schwierig zu interpretieren 

sind? Hier liefert die Tagung Lösungen. (gz) 

DKE – DEUTSCHE KOMMISSION ELEKTROTECHNIK 

ELEKTRONIK INFORMATIONSTECHNIK 

IM DIN UND VDE 

Stresemannallee 15, D-60596 Frankfurt am Main, 

Tel. +49 (0) 69 630 80, Internet: www.dke.de 


1-2 / 2013 

7

BRANCHE 

GMA-Tagung zum Integrated Plant Engineering 

aus Sicht von Industrie und Wissenschaft 

Der durchgängigen Anlagenplanung widmet die VDI/ 

VDE-Gesellschaft Mess- und Automatisierungstechnik 

eine Tagung. Die „Integrated Plant Engineering Conference 

2013“ findet am 20 März 2013 in der IHK Nürnberg für 

Mittelfranken statt. Praxisnahe Referenten erläutern und 

diskutieren das Thema aus unterschiedlichen Sichtweisen. 

Zum Einstieg wird Dr. Ulrich Löwen (Siemens AG, 

Corporate Technology) das Thema „Herausforderungen 

an die Durchgängige Anlagenplanung“ beleuchten. Die 

weiteren Redner Prof. Dr.-Ing. Uwe Bracht von der Technischen 

Universität Clausthal (VDI-GPL „Fabrikplanung 

und -betrieb“) und Prof. Dr.-Ing. Alexander Fay (Helmut- 

Schmidt-Universität Hamburg) zeigen die Visionen für 

die Durchgängige Anlagenplanung auf. Die Industrie 

Ulrich Turck leitet den Fieldbus-Beirat 

wird mit Vorträgen aus dem Bereich der Prozessindustrie zur 

Integrierten Anlagenplanung in der Wassertechnik durch 

Achim Ewig (Abteilungsleiter Anlagenbau PWT Wasser- und 

Abwassertechnik GmbH) sowie der Diskreten Industrie mit 

Vision und Wirklichkeit der Digitalen Fabrik vertreten sein. 

Eine Podiumsdiskussion soll Wissenschaft und Industrie 

in den Dialog bringen. Die Konferenz schließt mit einem 

Get Together und interessanten Gesprächen ab. (gz) 

VDI/VDE – GESELLSCHAFT MESS- UND 

AUTOMATISIERUNGSTECHNIK (GMA) 

VEREIN DEUTSCHER INGENIEURE E.V., 

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

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

Ulrich Turck, geschäftsführender Gesellschafter der 

Hans Turck GmbH & Co. KG, ist für die Amtsperiode 

2012/13 zum Vorsitzenden des Beirats der Fieldbus 

Foundation für Europa, den Nahen Osten und Afrika 

(EMEA) gewählt worden. Turck übernahm den Vorsitz 

von Jean-Marie Alliet (Honeywell Process Systems). Er 

amtiert bis zur nächsten Wahl. Diese findet am Rande 

der Messe SPS/IPC/Drives statt. 

Dem Beirat gehören ebenfalls an: Gregor Kilian (ABB), 

Travis Hesketh (Emerson Process Management) Dr. Raimund 

Sommer (Endress+Hauser) Jean-Marie Alliet (Honeywell), 

Hartmut Wallraf (Invensys), Günter Pinkowski (Krohne), 

Rob Stockham (Moore Industries), Peter Maxwell (MTL- 

Cooper Crouse Hinds), Dr. Gunther Kegel (Pepperl+Fuchs), 

Paul Brooks (Rockwell Automation), 

Herbert Schober (R. Stahl), Dr. Wolfgang 

Trier (Softing) und Henk van der 

Bent (Yokogawa). Der Beirat soll die 

Anwendung der Technologie durch 

Hersteller und Nutzer von Automatisierungslösungen 

vorantreiben. (gz) 

FIELDBUS FOUNDATION, 

9005 Mountain Ridge Drive, 

Bowie Bldg – Suite 200, 

Austin, TX 78759-5316, USA, 

Tel. +1 (0) 512 794 88 90, 

Internet: www.fieldbus.org 

ULRICH TURCK 

leitet den Beirat 

der Fieldbus 

Foundation für 

Europa, den Nahen 

Osten und Afrika 

Foto: Turck 

Processnet/Namur-Symposium: 

Digitale Anlagenplanung und -führung 

Am 21. und 22. März 2013 findet in Frankurt/Main im 

Dechema-Haus das Processnet/Namur Symposium IDA 

2013 – Integrierte Digitale Anlagenplanung und -führung 

unter der wissenschaftlichen Leitung von Prof. Leon Urbas 

(TU Dresden) statt. Mit Vorträgen aus Hochschule und Praxis, 

Softwaredemonstrationen sowie einer begleitenden 

Ausstellung bietet die Veranstaltung eine ideale Plattform 

zum Informationsaustausch und zur Diskussion aktueller 

Anforderungen an digitale Anlagen und Produkte in Verfahrens- 

und Automatisierungstechnik und der dafür notwendigen 

informationstechnischen Methoden und Werkzeuge. 

Die Schwerpunktthemen der IDA 2013 sind: 

Assistenzsysteme: Modellgestützte Unterstützungssysteme 

für das Engineering, Lebenszykluskostenmodelle 

für Anlagen, Risiko- und Investitionsmanagement, 

Integriertes Workflow Management 

Das Symposium setzt die Diskurstradition des Berlin- 

Aachener Symposiums fort – wie in den vergangenen Jahren 

richtet sich das Symposium sowohl an Softwareentwickler 

als auch an Anwender und Forscher moderner 

Informationstechnologien in der Prozesstechnik und in der 

Prozessleittechnik. Weitere Informationen zur Veranstaltung 

finden Sie unter www.processnet.org/ida2013. (lu) 

Smart Scale Anlagen: Modularisierung, Scale Up/ 

Number Up, Anlagenkonzepte für weltweit verteilte 

Einsatzstoffe und Märkte 

Informationsmodelle für die Digitale Anlagenplanung 

und –führung sowie Einsatz von Standards für den Datenaustausch 

im Engineering und für die Prozessführung 

DECHEMA – GESELLSCHAFT FÜR CHEMISCHE TECHNIK 

UND BIOTECHNOLOGIE E.V., 

Theodor-Heuss-Allee 25, D-60486 Frankfurt/Main, 

Frau Katharina Bauß, Tel. +49 (0) 69 756 42 95, 

E-Mail: bauss@dechema.de, 

Internet: www.processnet.org/ida2013 

8 


1-2 / 2013

Die Umsatzdelle soll 

2013 ausgebeult werden 

Für 2013 zeigt sich der Branchenverband 

ZVEI vorsichtig optimistisch. 

Er erwartet, dass mit einem 

Wachstum von 1,5 Prozent die Delle 

von 2012 weitgehend ausgebeult 

wird. Nach den bis Ende Januar vorliegenden 

Zahlen ging der ZVEI für 

das Jahr 2012 von einem Minus von 

zwei Prozent bei Produktion und 

Umsatz aus. Der Umsatz dürfte 175 

Milliarden Euro betragen haben. 

Für 2012 geht der ZVEI von einem 

Rekordexport aus. Auf Basis der bis 

Ende Januar vorliegenden Zahlen 

prognostizierte ZVEI-Chefvolkswirt 

Dr. Andreas Gontermann „einen Exportanstieg 

um zwei Prozent auf ein 

Allzeithoch von 161 Milliarden 

Euro“. Zwar waren die Ausfuhren 

ZVEI-CHEF- 

VOLKSWIRT 

DR. ANDREAS 

GONTERMANN 

geht für das 

vergangene Jahr 

von einem Exportrekord 

aus. 

Foto: ZVEI 

im November mit 13,7 Milliarden Euro zwei Prozent hinter 

dem Vorjahresniveau zurückgeblieben. Aber von Januar 

bis November waren die Exporte bereits um drei 

Prozent auf 148,0 Milliarden Euro gestiegen. Zwar kann 

sich die Branche der Krise im Euro-Raum nicht entziehen: 

Die Ausfuhren in Euro-Länder nahmen von Januar 

bis November 2012 um vier Prozent auf 48,8 Milliarden 

Euro ab. Dafür wuchs der Export in Nicht-Euro-Staaten 

um sieben Prozent auf 99,2 Milliarden Euro. „Auch die 

Ausfuhren nach China, die in der ersten Jahreshälfte 

rückläufig waren, sind zuletzt wieder kräftig gestiegen“, 

sagte Gontermann. „Im Oktober und November 2012 

legten sie um jeweils 14 Prozent gegenüber Vorjahr zu.“ 

Dieses Auseinanderklaffen machen auch Zahlen zu 

den Auftragseingängen im November 2012 deutlich: Die 

Branche erhielt insgesamt zwei Prozent weniger Bestellungen 

als im Vorjahr (Januar bis November: minus acht 

Prozent). „Allerdings nahmen die Auftragseingänge aus 

dem gesamten Ausland um fünfeinhalb Prozent und aus 

dem Nicht-Euro-Ausland sogar um 15 Prozent gegenüber 

Vorjahr zu“, so Gontermann. „Die Inlandsbestellungen 

waren im November hingegen um neun Prozent rückläufig, 

und aus der Eurozone kamen sieben Prozent weniger 

Orders als vor einem Jahr“. 

75 Prozent der deutschen Elektroexporte kamen in 

den ersten elf Monaten 2012 aus dem Bereich der Investitionsgüter 

(111 Milliarden Euro), 13 Prozent waren 

Vorerzeugnisse oder elektronische Bauelemente (19 Milliarden 

Euro) und zwölf Prozent Gebrauchsgüter (18 

Milliarden Euro). Die Investitionsgüter-Ausfuhren erhöhten 

sich von Januar bis November 2012 um vier Prozent 

gegenüber Vorjahr, wobei besonders elektrische 

Schienenfahrzeuge (plus 13,5 Prozent), Medizintechnik 

(plus zehn Prozent), Batterien (plus 7,5 Prozent), Messtechnik 

und Prozessautomatisierung (plus sieben Prozent) 

oder Energietechnik (plus sechs Prozent) sehr gefragt 

waren. 

(lu) 

Mit Sicherheit 

kompetent 

Mit den Stellventilen Typ 3241 von 

SAMSON sind Sie immer auf der 

sicheren Seite. Dank ihrer hohen 

MTBF brauchen Sie sich um einen 

Ausfall nicht zu sorgen. 

Noch mehr Sicherheit garantieren die 

Stellungsregler der Bauarten 3730 und 

3731. Mit ihrem zertifizierten Magnetventil 

und dem induktiven Grenzkontakt 

führen sie die Sprung antworttests 

automatisch durch und dokumentieren 

die Ergebnisse. 

Gehen Sie auf Nummer sicher mit 

SAMSON. 

SIL 

SIL SIL 

ZVEI – ZENTRALVERBAND ELEKTROTECHNIK- UND 

ELEKTRONIKINDUSTRIE E.V., 

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

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

A01039DE 

SAMSON AG · MESS- UND REGELTECHNIK 

Weismüllerstraße 3 · 60314 Frankfurt am Main 

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

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

SAMSON GROUP · www.samsongroup.net

FORSCHUNG 

Leistungsfähige Sensoren einfach aufgesprüht 

Leistungsfähige Bildsensoren haben Prof. Paolo Lugli 

und Dr. Daniela Baierl von der Technischen Universität 

München (TUM) entwickelt. Die Mikroelemente 

werden einfach aufgesprüht. Dieser hauchdünne Film 

besteht aus Kunststoffen. Aufgebracht wird die Kunststoff-Lösung 

auf die Oberfläche von Bildsensoren. Ein 

Farbsprühgerät oder ein Sprühroboter trägt die Lösung 

so auf, dass die Schicht nur wenige hundert Nanometer 

dünn und ohne Makel ist. Die organischen Sensoren 

sind, laut TU München, bis zu dreimal lichtempfindlicher 

als herkömmliche CMOS-Sensoren, bei denen 

elektronische Bauteile einen Teil der Pixel und damit 

der lichtaktiven Siliziumfläche verdecken. Bei der Herstellung 

der organischen Sensoren entfällt die sonst 

übliche, teure Nachbearbeitung des CMOS-Sensors, 

etwa das Aufbringen von Mikrolinsen zur Verstärkung 

des Lichteinfalls. Jeder Pixel wird vollständig, inklusive 

seiner Elektronik, mit der flüssigen Kunststoff-Lösung 

besprüht und erhält so eine zu 100 Prozent lichtempfindliche 

Oberfläche. Für den Einsatz in Kameras 

sind die organischen Sensoren auch durch ihr geringes 

Bildrauschen und die hohe Bildrate gut geeignet. 

„Mit geeigneten organischen Verbindungen können 

wir Anwendungsgebiete erschließen, die bislang mit hohen 

Kosten verbunden waren“, erklärt Prof. Paolo Lugli 

vom TUM-Lehrstuhl für Nanoelektronik. „Wir können 

etwa Nachtsicht-Fahrassistenzen mit organischen Infrarot-Sensoren 

ausstatten, aber auch ganz normale Kompakt- 

oder Handykameras. Bislang fehlen dafür aber die 

geeigneten Polymere.“ 

(ahü) 

HAUCHDÜNN: Organische Sensoren können klein- und großflächig 

auf CMOS-Chips aufgebracht werden, aber auch auf Glas 

oder biegsame Kunststoff-Folien. Foto: U. Benz / TUM 

TECHNISCHE UNIVERSITÄT MÜNCHEN, 

Lehrstuhl für Nanoelektronik, 

Prof. Dr. Pauli Lugli, 

Arcisstrasse 21, 

D-80333 München, 

Tel. +49 (0) 89 28 92 53 33, 

Internet: www.nano.ei.tum.de 

Die drahtlose Fabrik baut auf dezentrale Intelligenz 

it der Entwicklung einer robusten Wireless-Technologie 

zur Steuerung und Überwachung industrieller 

M 

Produktionsabläufe befördern Wissenschaftler der Helmut-Schmidt-Universität/Universität 

der Bundeswehr 

Hamburg neuartige Automatisierungskonzepte, die die 

Produktion nicht nur flexibler machen, sondern auch 

Energie einsparen. 

Die bislang übliche zentrale Steuerung und Verkabelung 

der Anlagen führt zunehmend zu Energiekosten 

und einem Koordinierungsaufwand, den sich die Industrie 

bei steigenden Energiepreisen im internationalen 

Wettbewerb nicht mehr leisten kann. Besondere Anforderungen 

an die Übertragungssicherheit verhinderten 

bislang die Einführung drahtloser Technologien zur 

Steuerung- und Überwachung der Produktionsabläufe. 

Das Forschungsprojekt MIKOA (Miniaturisierte energieautarke 

Komponenten mit verlässlicher drahtloser 

Kommunikation für die Automatisierungstechnik) verspricht 

Lösungen für autonom arbeitende Sensoren, die 

energieautark betrieben werden können und kaum störanfällig 

sind. Zur Steuerung und Diagnose von Produktionsprozessen 

können diese direkt an den Produktionsanlagen 

angebracht werden. Zentrale Leitrechner werden 

somit von eigenständigen Produktionseinheiten abgelöst. 

Die kabellose Lösung macht nicht nur die Produktion 

flexibel. Auch kosten- und zeitintensive Um- 

baumaßnahmen der Produktionsanlagen können zunehmend 

vermieden werden. Nebenbei ergeben sich 

Einsparmöglichkeiten im Energieverbrauch, wie Prof. 

Dr. Gerd Scholl, Leiter der Professur für Elektrische 

Messtechnik an der Helmut-Schmidt-Universität, erläutert: 

„Mit den Ergebnissen des Projektes wird es 

möglich sein, ein differenziertes Bild des Energieverbrauches 

zu bekommen. Auf dieser Informationsbasis 

können dann Methoden zur Verbesserung der Energieeffizienz 

aufsetzen“. 

Das Verbundprojekt MIKOA lief von 2009 bis Herbst 

2012. Unter Projektkoodinator Festo forschten neben 

der Helmut-Schmidt-Universität die EnOcean GmbH, 

die HSG-IMIT- Hahn-Schickard-Gesellschaft für angewandte 

Forschung, das ifak - Institut für Automation 

und Kommunikation Magdeburg, die Siemens AG, die 

Universität Paderborn und die Zollner Elektronik AG 

forschten. 

(gz) 

HELMUT-SCHMIDT-UNIVERSITÄT 

UNIVERSITÄT DER BUNDESWEHR HAMBURG, 

Prof. Dr.-Ing. Gerd Scholl, 

Holstenhofweg 85, D-22043 Hamburg, 

Tel. +49 (0) 40 65 41 33 41, 

Internet: www.hsu-hh.de 

10 


1-2 / 2013

Dresdener Studenten greifen nach den Sternen 

Studenten der Technischen Universität Dresden (TU 

Dresden) gehen wieder in die Luft. Bereits zum zweiten 

Mal konnten Lehrende am Institut für Luft- und Raumfahrt 

einen Raketenstartplatz im REXUS-Programm des Deutschen 

Zentrums für Luft- und Raumfahrt (DLR) gewinnen. 

REXUS, kurz für Rocket-borne EXperiments for University 

Students, ist eine Experimentierplattform. Jährlich werden 

zwei Raketen mit bis zu zwölf Studenten-Experimenten 

gestartet. Die Studenten führen die Experimente auf der 

Forschungsrakete mit einem verbesserten Orion-Motor mit 

290 Kilogramm Brennmasse durch. Die Rakete erreicht 

dabei 90 Kilometer Höhe. Nachdem bereits im vergangenen 

November ein Experiment von Dresdner Studenten mitfliegen 

konnte, hat sich nun das Projekt MOXA aus Dresden 

durchgesetzt. MOXA (Measurement of Oxygen in the Atmosphere) 

will auf der Forschungsrakete REXUS 15/16 

genaue Messungen in der Erdatmosphäre durchführen. Die 

Sensoren für die Sauerstoff- und Ozonmessung entwickelte 

die Professur Raumfahrttechnik der Dresdner Universität. 

REXUS 15/16 startet im März 2014 in Schweden. (ahü) 

TECHNISCHE UNIVERSITÄT DRESDEN, 

Institut für Luft- und Raumfahrttechnik, 

Professur für Raumfahrttechnik, 

Leiter Sensorentwicklung, Dr. Tino Schmiel, 

Marschnerstraße 32, D-01307 Dresden, 

Tel. +49 (0) 351 46 33 82 87, Internet: www.rexus-moxa.de 

FAST-ASTRONAUTEN: Bastian Klose, Alexander Schultze, Patrick 

Geigen gack, Daniel Becker und Alexander Mager von der TU 

Dresden sicherten sich mit ihrem MOXA-Projekt einen Platz auf der 

Forschungsrakete. Bild: TU Dresden/ K. Eckold 

Namur-Award 2013: Verband nimmt bis zum 

28. Juni 2013 Fachaufsätze entgegen 

Die Namur (Verband von Automatisierungsanwendern in 

der Verfahrenstechnik) lobt erneut den Namur-Award 

aus. Der Zusammenschluss vergibt traditionell seinen Preis 

für hervorragende Arbeiten zum Thema „Intelligente Prozess- 

und Betriebsführung“. Bewerben sollten sich Bachelor-, 

Master-, Diplom- oder Promotionsarbeiten aus den 

Bereichen Automatisierungstechnik, Elektrotechnik, Infor- 

PREISTRÄGER: Den Namur-Award 2012 nahm Dr.-Ing. 

Ala Eldin Bouaswaig (li.) für seine Promotionsarbeit zum 

Thema "Simulation, control and inverse problems in 

particulate processes" entgegen. Den Preis überreichte der 

Namur-Vorsitzende Dr. -Ing. Wilhelm Otten. Bild: Anne Hütter 

mationstechnik, Mess-, Regelungstechnik, Prozessleittechnik 

sowie Verfahrenstechnik. Die Namur möchte einen 

Anreiz schaffen, leistungsfähige Methoden für die 

Prozessautomatisierung zu entwickeln. Dafür sind Fachkenntnisse 

der Automatisierungstechnik als auch der Verfahrens- 

und Prozesstechnik wichtig. Lehrstuhlinhaber 

der genannten Fachgebiete sind nun aufgefordert, einen 

formlosen Antrag an die Namur zu richten. In diesem Antrag 

soll die einzureichende Forschungsarbeit sowie Autor 

kurz vorgestellt werden. Zugehörige Veröffentlichungen 

können ebenso eingereicht werden. Die Kontaktadresse 

lautet office@namur.de. Vollständige Beiträge sollten bis 

28. Juni 2013 eingegangen sein. Bis zum 15. Oktober 2013 

werden alle Bewerber benachrichtigt. Im Rahmen der 

Namur-Hauptversammlung findet dann am 8. November 

2013 in Bad Neuenahr die Preisverleihung statt. Der besten 

Diplom- oder Masterarbeit winken 1000 Euro. Ein Preisgeld 

in Höhe von 2000 Euro erhält die beste Promotionsarbeit. 

Den Namur-Award 2012 erhielten im vergangenen 

Jahr Shen Yin (Universität Duisburg-Essen) und Ala Eldin 

Bouaswaig (TU Dortmund). 

(ahü) 

NAMUR-GESCHÄFTSSTELLE 

C/O BAYER TECHNOLOGY SERVICES, 

Gebäude K 9, D-51368 Leverkusen, 

Tel. +49 (0) 214 307 10 34, E-Mail: office@namur.de, 

Internet: www.namur.de 


1-2 / 2013 

11

PRAXIS 

Lineares Transport-System XTS: Zentraler Antrieb 

mit den Vorteilen eines dezentralen Systems realisiert 

Dynamisches Maschinenkonzept realisiert platz- und energiesparendes Engineering 

– Positionsberechnung 

– Geschwindigkeitsberechnung 

– Positionsregelung 

– Geschwindigkeitsregelung 

– Phasentransformation 

Anbaufläche Führungsschiene – 

mechanisches Interface 

Motor, 

Spulenpakte 

Signale, 

Positionssensor 

Kompletter Regelzyklus 

für alle Mover in 250 μs 

Phasen, 

Stromsollwerte 

Integrierte 

Leistungselektronik 

Power, 

EtherCAT durchkontaktiert 

Integrierte 

Positionserfassung 

Anbaufläche Maschinenbett 

und Kabelabgang Einspeisung 

alle 3 m 

BILD 1: Überblick über das XTS-Gesamtsystem 

BILD 2: Bei den Motormodulen stehen Geraden von 250 mm 

Länge und Bogenstücke von 180° zur Verfügung. 

Das lineare Transport System (XTS) von Beckhoff verbindet 

die Vorteile rotatorischer Motoren mit denen 

von Linearmotoren, ohne die Einschränkungen bisheriger 

Lösungsansätze. 

Bei Servotechnik unterscheidet man im Maschinenbau 

zwischen rotatorischen und linearen Servomotoren. Mit 

rotatorischen Motoren und entsprechender Mechanik, 

wie Zahnriemen oder Förderkette, gelingt die unendlich 

umlaufende, lineare Transportbewegung. Dadurch wird 

jedoch der Riemen oder die Förderkette immer gleichmäßig 

bewegt. Eine Variation der Geschwindigkeit, um 

etwa die Varianz in einem Produktfluss auszugleichen, 

ist nicht möglich. Der Motor verschleißt schnell und die 

mechanischen Komponenten sind nur ungenügend steif. 

Dies kann Dynamik, Performance und Lebensdauer reduzieren. 

Linearmotoren erlauben die direkte Kraftkopplung zwischen 

Motor und dem zu bewegenden Produkt. Sie können 

die Bewegung mit mehreren, voneinander unabhängig beweglichen 

Schlitten ausführen. Ein Nachteil ist allerdings 

der endliche Fahrweg, der eine Rückstellbewegung der 

beweglichen Elemente des Linearmotors erfordert. Dies 

stört den kontinuierlichen Produktfluss einer hochdynamischen 

Maschine und reduziert die Produktionstaktrate. 

Dieser doppelte Brems- beziehungsweise Beschleunigungsvorgang 

verbraucht außerdem zu viel Energie. 

Man kann das Linearmotorprinzip so nutzen, dass auf 

einer aktiven, durch bestrombare Spulen gebildeten Strecke 

passive, kabellose Schlitten oder Mover fahren. Die 

Mover werden dabei auf einer zweiten Strecke zurückbewegt, 

so dass sie nicht gegen den Produktstrom der 

Maschine bewegt werden müssen. Doch: Eine Servoelektronik 

bestromt und regelt einen festen Streckenabschnitt 

mit einem einheitlichen Feld für alle Mover auf 

dieser Strecke. Auch bei einem Übergang zwischen den 

Teilstücken werden beide Abschnitte gleich bestromt. In 

den Bögen erfolgt die Bewegung der Mover über einen 

rotatorischen Motor und eine Hilfsmechanik. Eine geschlossene 

Positionsauswertung ist nicht möglich, so 

dass in einigen Bereichen nur gesteuert gefahren wird. 

MOVER LAGE- UND GESCHWINDIGKEITSGEREGELT 

POSITIONIEREN 

Bei dem Antriebskonzept von XTS sind Einzelspulen des 

Linearmotors entlang des Fahrweges angeordnet. Die 

beweglichen Mover sind mit Permanentmagnetplatten 

versehen. Über die dynamische Ansteuerung der einzelnen 

Spulen entlang des Weges wird für jeden Mover ein 

eigenes drehstromäquivalentes Wanderfeld erzeugt, das 

ihn bewegt. Dabei wird die bisherige feste Verknüpfung 

(Verdrahtung) zwischen Umrichter und Motorwicklung 

aufgebrochen und stattdessen über Software auf einem 

zentralen Industrie-PC (IPC) hergestellt. Bild 1 zeigt die 

Übersicht des gesamten Systems. Signale aus dem Positionssensor 

sind über Ethercat-Kommunikation mit dem 

IPC verbunden. Dort wird per Servoachs-Software die 

Position und Geschwindigkeit des Movers berechnet und 

anschließend die Regelung und Phasentransformation 

12 


1-2 / 2013

ieten geringen leitenden Verlust und kurze Schaltzeiten, 

so dass eine Leistungselektronik mit einem Wirkungsgrad 

von > 99 % möglich wird. Die H-Brücke wird dabei 

mit einer Schaltfrequenz von 32 kHz und einem FPGAbasierten 

Stromregler, mit einer Update-Rate von über 

300 kHz, betrieben. Die Leistungselektronik ist rückspeisefähig 

und erlaubt einen Energieaustausch zwischen 

Bereichen, in denen Mover abbremsen und generatorisch 

Energie zurückspeisen, und solchen, in denen motorische 

Energie entnommen wird. Durch die Integration der 

Leistungs- und Wegerfassungselektronik in die Motormodule 

wird der im Schaltschrank benötigte Platz reduziert. 

Der Magnetkreis des Motors ist mit einem eisenbehafteten 

Doppelluftspalt ausgeführt. Dies ermöglicht 

eine effiziente Spulenausnutzung und die Reduzierung 

der Reibungsverluste in der Führung. Für die auf die 

Führung einwirkende Kraft gilt: 

BILD 3: Vergleich zwischen einem Kreisbogen 

und einer Klothoide 

ausgeführt. In der Phasentransformation werden aus 

dem Sollstrom des Geschwindigkeitsreglers die sinusförmigen 

Phasenströme aller Spulen unterhalb des Movers 

berechnet und über Ethercat als Sollwert dynamisch 

an die Stromregelung der entsprechenden Spulen übertragen. 

So erhält jeder Mover exakt die Ansteuerung, die 

er für sein eigenes Wanderfeld benötigt. Es werden nur 

die Spulen angesteuert und bestromt, über denen sich 

ein Mover befindet. Das System erlaubt, jeden einzelnen 

Mover, zeitlich synchron innerhalb von 250 μs, lage- und 

geschwindigkeitsgeregelt exakt zu positionieren. 

ANTRIEBSLEISTUNG WIRD VON DEZENTRALEN 

ELEMENTEN AUFGEBRACHT 

Die geraden und die bogenförmigen Module (Bild 2) sind 

aneinander gereiht, wobei alle 3 Meter eine Einspeisung 

der 24-V-Steuer- und der 48-V-Leistungsversorgung sowie 

eine Ethercat-Anbindung erfolgen. Das Motordesign 

beruht auf einer Aneinanderreihung von Einzelspulen, 

die jeweils von einer integrierten, als H-Brücke aufgebauten 

Leistungselektronik angesteuert werden. Dies gilt 

auch für den 180°-Bogen, so dass die freie Positionierfähigkeit 

jedes Movers gewährleistet ist. 

Da die Antriebsleistung nicht von einer zentralen Achse, 

etwa einem rotatorischen Motor und einer verbundenen 

Kette, aufgebracht wird, sondern sich auf die einzelnen 

Mover verteilt, kann auch auf eine geringere Zwischenkreisspannung 

von 48 V mit effizienten Mosfet- 

Transistoren gewechselt werden. Diese Transistoren 

Das ungefähr Vierfache der motorischen Vorschubkraft 

wirkt so als Kraft in Richtung des Luftspaltes. Beim Aufbau 

mit einem einfachen Luftspalt muss die Führung der 

Mover diese Kräfte aufnehmen und abfangen, was zu 

erhöhten Reibungsverlusten und Verschleiß der Führung 

führt. Bei einem Aufbau mit Doppelluftspalt, wie er für 

das XTS gewählt wurde, heben sich die Kräfte idealerweise 

auf – mit der Einschränkung von Toleranzen in 

der Mechanik und der Permanentmagnete. Insgesamt 

kommt diese Anordnung bei einer Nenngeschwindigkeit 

von 4 m/s und einer Nennkraft von 30 N sowie Verlusten 

von etwa 12 W auf einen Wirkungsgrad von: 

KRITISCHE PUNKTE MITTELS KLOTHOIDE GELÖST 

Einen kritischen Punkt in der Mechanik bei einem umlaufenden 

Transportsystem zeigt Bild 3 am Übergang 

zwischen Gerade und Bogen. Verläuft dieser Übergang 

auf einer Kreisbahn, ergibt sich dort ein sinusförmiger 

Anstieg der Geschwindigkeit in y-Richtung. Als Folge der 

Beschleunigung entsteht ein sprungförmiger Verlauf, der 

wiederum einen theoretisch unendlich hohen Ruck zur 

Folge hat und insbesondere die Führung stark belastet. 

Darum wurde das 180°-Bogen-Motormodul, inklusive der 

Führung, als Klothoide ausgeführt. Eine Klothoide (blauer 

Verlauf in Bild 3) ist ein Kreisbogen, dessen Radius sich 

verändert. Am Anfang des Übergangs ist der Radius größer 

und wird dann bis zum Scheitelpunkt des Bogens 

kontinuierlich kleiner, bevor sich die Klothoide zur zweiten 

Gerade hin wieder öffnet. Dies führt zu einem kontinuierlichen 

Anstieg der Beschleunigung, wodurch sich 

die Lebensdauer der Mechanik erhöht. 

Um die Mover gegebenenfalls auszutauschen, enthält 

das System eine einfach zu öffnende Schleuse. Damit 

sich mit diesem System aus wenigen Standardkompo- 


1-2 / 2013 

13

PRAXIS 

BILD 4: Ausschnitt aus der Wegerfassung 

BILD 5: Zeitliche Abfolge und 

Übertragung im System 

nenten viele Einsatzbereiche abdecken lassen, haben die 

Motormodule zusätzlich ein mechanisches Interface zur 

Führung. Es bestehend aus Passstift- und Schraubverbindungen. 

So lassen sich für die Standardmotormodule 

verschiedene spezifische Führungen entwickeln und 

anbauen, die Spezialanforderungen erfüllen. Die Einbaulage 

des Systems ist frei wählbar. 

KONTAKTLOSE POSITIONSMESSUNG FÜR ALLE MOVER 

Die Wegerfassung ist in das System integriert und erlaubt 

die Berechnung der absoluten Position jedes Movers 

im System ohne aktive Bauelemente. Das hier eingesetzte 

Prinzip des induktiven Wegsensors ist robust 

gegenüber EMV-Störungen. Man kann es sich wie einen 

abgewickelten Resolver vorstellen: Auf eine ebene Fläche 

werden eine Erregerwicklung und mehrere innenliegende 

sinus- und cosinusförmige Empfangsleiterschleifen 

aufgebracht. Auf dem Mover fährt parallel, 

mit einem Luftspalt von 0,5 Millimeter zum feststehenden 

Wegsensor, eine Geberfahne aus leichtem und faserverstärktem 

Material mit. Auf der Fahne sind mehrere 

metallische Flächen aufgebracht. Hierdurch findet 

Wechselwirkung mit dem elektromagnetischen Feld der 

Erregerwicklung statt. 

In den Sekundärwicklungen kann eine positionsabhängige 

Spannung gemessen werden. Sie verläuft zeitlich 

sinusförmig, wenn die Geberfahne beispielsweise mit 

einer konstanten Geschwindigkeit über den feststehenden 

Sensor bewegt wird. Aus den Spannungen, der inversen 

Tangensfunktion und einer festen Positionszuordnung der 

Sekundärwicklungen, oder deren Spannungen im System, 

kann im IPC zentral die absolute Position aller Mover berechnet 

werden. Die Positionsmessung ist damit kontaktlos 

und absolut für alle Mover. Es ist keine weitere Referenzfahrt 

oder Bewegung zur Kommutierungsfindung 

notwendig. Im Übergang zwischen zwei Modulen ist in 

einem kurzen Überlappungsbereich eine Positionsberechnung 

aus beiden Modulen möglich. Nach dem Einschalten 

wird die Position aller Mover geschlossen berechnet. In 

automatisierten Messfahrten wird nach dem Zusammenbau 

des Systems in der Maschine ein eventueller Positionssprung, 

hervorgerufen durch mechanische Einbautoleranzen, 

eingelernt und ausgeglichen. 

Das induktive Verfahren ist, im Gegensatz zum optischen, 

unempfindlich gegenüber elektrisch nichtleitenden 

Verschmutzungen. Durch geeignete Geometrie lassen 

sich hohe Genauigkeiten erreichen, wie etwa Stillstands-Wiederholgenauigkeit 

von weniger als 10 μm bei 

einer Positionsauflösung von zirka 0,2 μm. Die Erregung, 

Abtastung und Digitalisierung erfolgen, von einem FPGA 

(Field Programmable Gate Array) gesteuert, innerhalb 

einer Zykluszeit von 10 μs (Bild 4). Die Flächen einzelner 

Geberfahnen lassen sich so anpassen, dass ihre Hardware-Identifikation 

und damit die eindeutige Zuordnung 

der Servoachsen in der Applikationssoftware zu den 

realen Movern gegeben ist. 

ETHERCAT VERBINDET DIE ELEMENTE ZU EINEM SYSTEM 

Eine wesentliche Voraussetzung zur Realisierung des 

Linearen Transport Systems XTS ist die schnelle und 

synchrone Ethercat-Kommunikation zwischen IPC und 

Hardware. Ein Motormodul mit einer Länge von 250 Millimetern 

umfasst 132 Byte Prozessdaten. In einem 2 Meter 

langen Transportsystem mit abgewickelter Länge von 

5 Metern, bestehend aus Bögen sowie Hin- und Rückweg, 

entstehen rund 2640 Byte Prozessdaten. Sie werden taktsynchron, 

mit einer Zykluszeit von 250 μs, in zwei Ethercat-Strängen 

übertragen. Dies entspricht einer Datenmenge 

von 84 Mbaud. Das System kann auf verschiedene 

100-MBaud-Stränge aufgeteilt werden, so dass die 

Übertragung der Daten maximal die Hälfte der Zykluszeit 

von 250 μs benötigt. 

14 


1-2 / 2013

BILD 6: Zusammenspiel der XTS-Softwaremodule 

Gegebenenfalls bündelt der Port-Multiplier die Prozessdaten 

der 100-MBit-Stränge zu einer 1-GBaud-Verbindung 

zum IPC und übernimmt per Distributed- Clocks die nanosekundengenaue 

Synchronisation der angeschlossenen 

Hardware. In der restlichen Zykluszeit von mindestens 

125 μs finden die folgenden Berechnungen der Servo- 

Algorithmen aller Mover statt: 

Achsverfolgung der verschiedenen Signale des 

Wegmesssystems 

Positionsberechnung 

Geschwindigkeitsberechnung 

Feininterpolation der Achssollwerte 

Positionsregelung 

Geschwindigkeitsregelung 

Lastfilter höherer Ordnung 

Phasentransformation des Stromsollwertes 

auf die entsprechenden Hardwarekanäle 

Durch kurze Verzögerungszeiten in den FPGA-basierten 

Komponenten werden in diesem zentralen System 

Verzögerungs- und Zykluszeiten wie bei einer dezentralen 

Lösung erreicht. Jedoch mit dem Vorteil, dass die 

einer Achse zugehörige Hardware über eine Achsverfolgungssoftware 

kontinuierlich weiterbewegt und 

umgeschaltet wird. Eine zusätzliche Kommunikation 

ist nicht erforderlich. Bild 5 zeigt den zeitlichen Ablauf 

im System. 

KONFIGURATION UND MASCHINENPROGRAMMIERUNG 

Die Systemänderung verbunden mit der großen Datenmenge 

wirkt komplex. Darum wurde die Bedienbarkeit 

einfach gehalten. Die Hardware wird zusammengesteckt 

und über Ethercat an den PC angeschlossen. Das Scan- 

Kommando erkennt alle Hardwarekomponenten im System 

und nimmt sie in die Konfiguration auf. Der Stromregler 

ist auf Einzelspulen und Mover abgestimmt. Die 

Zuordnung der einzelnen Prozessdaten im System erfolgt 

über den XTS-I/O-Wizard. Dieser erkennt die angeschlossenen 

Systemkomponenten nach einem weiteren Scan- 

Kommando, zeigt sie grafisch an. Er bietet die Möglichkeit, 

die Stränge grafisch zu verschieben. Nach Anordnung 

der Module erzeugt ein weiterer Mausklick alle 

Zuordnungen und Verknüpfungen, so dass alle I/O-Daten 

in einem Servoachs-Interface zur Verfügung stehen. 

Die entsprechende Anzahl von Steuerungsachsen, 

inklusive ihrer Verknüpfung mit den Achs-Interfaces 

der Hardware, wird als Softdrive aus einer Parameterdatei 

angelegt. Diese XML- beziehungsweise tmc-Datei 

kann jeder Anwender selbstständig editieren, um die 

für seine Mechanik ermittelten Werte der Regelung einzustellen. 

Die Parametrierung, etwa aufgrund unterschiedlicher 

Massen in bestimmten Positionsbereichen, 

ist ebenfalls möglich. 

Für die abwechselnde Bewegung der Mover auf demselben 

Fahrweg wurde eine XTS-Gruppe als Softwarekomponente 

entwickelt, welche die Abhängigkeiten 

der Mover untereinander selbstständig überwacht. Die 

Kollisionsüberwachung ermöglicht das Weiterfahren im 

Stau. Ein Mover gibt beispielsweise ein Produkt an einen 

weiteren Produktionsschritt ab. Nun bekommt er, kurz 

vor der Aufnahme eines neuen Produktes, als Zielposition 

eine Warteposition zugewiesen. Wenn nun mehrere 

Mover in einer Art Warteschlange stehen, erkennt der 

neu heranfahrende Mover dies und bremst automatisch. 

Sobald der erste Mover von der Warteposition losfährt, 

um sich auf ein neu einlaufendes Produkt zu synchronisieren, 

fahren alle Mover in der Warteschlange, unter 

Einhaltung der eingestellten Dynamikparameter, weiter. 

Erst wenn der Mover seine Zielposition erreicht hat, meldet 

er, dass die Bewegung abgeschlossen ist. Die Überwachung 

ist auf dem gesamten Fahrweg und in allen 

Bewegungen permanent aktiv. Die Programmierung der 

einzelnen Fahrbefehle erfolgt aus Twincat PLC mit Standardbausteinen 

gemäß PLC open. Die Motion-Sollwertgeneratoren 

einer modernen Steuerung sind ohne Einschränkung 

anwendbar. 

AUTOR 

Beckhoff Automation GmbH, 

Eiserstraße 5, D-33415 Verl, 

Tel. +49 (0) 5246 96 30, 

E-Mail: info@beckhoff.de 

JAN ACHTERBERG 

entwickelt die Grundlagensoftware 

der Antriebstechnik 

bei Beckhoff. 


1-2 / 2013 

15

PRAXIS 

Spezialarmatur für Öl- und Gasindustrie garantiert 

zuverlässige Regelung bei tiefen Temperaturen 

Ölunternehmen Hess setzt bei Prozess zur kryogenen Trennung Spezialventile von Samson ein 

RESISTENT GEGEN 

VERSCHMUTZUNG, 

UNDICHTIGKEIT 

UND TIEFE 

TEMPERATUREN: 

Die Ventile vom 

Typ 3291, die in der 

Gasverarbeitungsanlage 

des Ölunternehmens 

Hess zum 

Einsatz kommen. 

Einfache Wartung und uneingeschränkte Funktionsfähigkeit 

auch bei Tiefsttemperaturen, wie sie bei der 

thermischen Gasverflüssigung entstehen – so lauten 

Kernforderungen der Ölfirma Hess an Ventile für ihre 

Gasverarbereitungsanlage im US-Bundesstaat North Dakota. 

Nachdem Ventile anderer Hersteller die hohen Ansprüche 

nicht erfüllten, setzt Hess nun bei der Erweiterung 

der Anlage Samson-Ventile vom Typ 3291 ein. 

Hess fördert im US-Bundesstaat North Dakota aus dem 

Bakken-Ölfeld auch sogenanntes Schiefergas. Es enthält neben 

dem Hauptbestandteil Methan auch verwandte Verbindungen 

wie Ethan, Butan oder Propan und ist zudem mit 

Wasserdampf, Schwefelwasserstoff, Stickstoff oder Ölrückständen 

vermischt. Zur Energiegewinnung oder zur chemischen 

Weiterverarbeitung müssen die Verunreinigungen 

entfernt und die unterschiedlichen Gase getrennt werden. 

DIE GASE WERDEN DURCH KÄLTE VERFLÜSSIGT 

Dazu betreibt Hess im Provinzstädtchen Tioga eine Gasverarbeitungsanlage, 

die zurzeit mit beträchtlichem Aufwand 

ausgebaut wird. Ihre Kapazität soll von rund drei auf sieben 

Millionen Kubikmeter Gas am Tag gesteigert werden. 

Während für das Raffinieren von Rohöl hohe Temperaturen 

notwendig sind, herrscht bei einigen Schritten der 

Gasverarbeitung fast kosmische Kälte. Bei der Trennung 

der verschiedenen gasförmigen Kohlenwasserstoffe ist 

das kryogene Verfahren – der Einsatz von Tiefsttemperaturen 

– das effektivste. Dabei nutzt man die unterschiedlichen 

Siedepunkte der beteiligten Gase. Wird der Siedepunkt 

eines Gases unterschritten, dann geht es in die 

flüssige Form über und kann von den anderen, noch gasförmigen 

Kohlenwasserstoffen, abgeschieden werden. 

Unter den gasförmigen Kohlenwasserstoffen besitzt Methan 

mit –161,7 °C den niedrigsten Siedepunkt. Die kryogenen 

Teile der Anlage müssen also auch bei extrem 

niedrigen Temperaturen störungsfrei arbeiten können. 

GROSSE KÄLTE BELASTET MATERIAL EXTREM 

Solche Kälte stellt das Material auf eine harte Probe, 

selbst viele Metalle werden dabei spröde. Für Armaturen, 

deren bewegliche Teile dem tiefkalten Medium ausgesetzt 

sind, kommen deshalb nur besonders hochwertige 

Legierungen und spezielle technische Konzepte in Frage. 

„Hess hatte genau in diesem Bereich Probleme mit den 

Ventilen eines anderen Herstellers gehabt“, erinnert sich 

Abraham John. Er leitet die Samson Project Engineering 

Inc. in Houston, Texas, die Öl- und Gasprojekte auf der 

ganzen Welt betreut. „Da wir seit Jahrzehnten eng mit den 

Herstellern technischer Gase zusammenarbeiten, kennen 

wir die Anforderungen auf diesem Gebiet sehr genau und 

haben die technischen Lösungen dafür parat. Das hat 

auch die für Tioga zuständigen Ingenieure überzeugt.“ 

SPEZIALLÖSUNG MIT EINGESPANNTEM SITZ 

Hess hat sich bei der Erweiterung der Anlage für Ventile 

des neuen Typs 3291 entschieden. Sie regeln Druck, Temperatur 

und Volumenstrom der Gase im neu installierten 

Verflüssigungsprozess – zur vollen Zufriedenheit des 

Kunden. Die Armatur wurde speziell für die Öl- und Gasindustrie 

entwickelt. Sie basiert auf den bewährten Konzepten 

der Samson-Ventile, unterscheidet sich aber in 

einem wichtigen Detail: Während bei Samson sonst geschraubte 

Sitze verwendet werden, enthält dieses Ventil 

einen eingespannten Sitz zur Aufnahme des Ventilkegels. 

Der Vorteil dieser Konstruktion ist vor allem die erleichterte 

Wartung. Sie ist in der Öl- und Gasbranche 

besonders wichtig. „Während etwa Chemieanlagen in 

MASSGESCHNEIDERT FÜR DIE ÖL- UND GASINDUSTRIE 

Das Ventil Typ 3291 wurde gezielt für die 

besonderen Anforderungen in der Öl- und 

Gasindustrie entwickelt. 

Es basiert auf der bewährten Ventiltechnologie 

von Samson, verfügt aber statt eines geschraubten 

über einen eingespannten Sitz. 

Anders als die branchenüblichen Cage-Ventile 

verursacht es im Betrieb nur minimale Reibung 

und ist gegen Verschmutzung und Undichtigkeit 

resistent. Die wichtigsten Eigenschaften: 

Eingespannter Sitz 

Wartung ohne Spezialwerkzeug 

Bewährte Konstruktionselemente 

Verschleiß an Sitz und Kegel minimiert 

Hohe Resistenz gegen Verschmutzung und 

Undichtigkeit 

Temperaturbereich –198 bis 450 °C 

Besonders geeignet für Anwendungen mit 

voraussicht licher Spaltkorrosion zwischen 

Sitz und Gehäuse 

16 


1-2 / 2013

estimmten Abständen für Wartungsarbeiten vollständig 

heruntergefahren werden, arbeiten die Anlagen, die direkt 

an der Öl- und Gasförderung hängen, meist ununterbrochen 

durch“, erklärt Abraham John. „Fällt hier ein 

Gerät aus, muss die Reparatur möglichst schnell und einfach 

zu erledigen sein.“ 

Undichtigkeit“, erläutert Abraham John. „Das ist beim 

Typ 3291 konstruktionsbedingt weitgehend ausgeschlossen. 

Da das Gerät im Betrieb außerdem deutlich weniger 

Reibung erzeugt als ein Cage-Ventil, bleibt auch der normale 

Verschleiß wesentlich geringer, was seine Lebensdauer 

und Wartungsintervalle enorm verlängert.“ 

SCHNELLE WARTUNG MIT STANDARDWERKZEUG 

Ventilsitze sind einem natürlichen Verschleiß unterworfen 

– zumal unter den verschärften Bedingungen der Gasverarbeitung. 

Deshalb ist die Wartungsfreundlichkeit der 

Geräte ein entscheidender Vorteil. Beim Typ 3291 lässt 

sich der Sitz in kürzester Zeit einund ausbauen. Dafür 

braucht man nur das Standardwerkzeug, das in solchen 

Anlagen immer vorhanden ist. Gegenüber den Stellventilen 

mit Cage, die in der Branche weit verbreitet sind, hat 

die Samson-Armatur entscheidende Vorteile. „Ein Cage 

ist im druckentlasteten Zustand anfällig für eindringenden 

Schmutz. Zugleich läuft der kolbenförmige Ventilkegel 

über eine lange Strecke im Cage. Beides zusammen 

erleichtert die Entstehung von Riefen oder Rissen und von 

AUTOR 

Dipl.-Ing. MARKUS NEUFELD ist Produktmanager 

Stellventile bei Samson. 

Samson AG, 

Mess-und Regeltechnik, 

Weismüllerstraße 3, 

D-60314 Frankfurt am Main, 

Tel. +49 (0) 69 40 09 11 03, 

E-Mail: mneufeld@samson.de 

2013 

Prozessleitsysteme - Messtechnik - Regeltechnik - Steuerungstechnik 

Produktpräsentation - Fachvorträge 

MSR-Spezialmesse Chemiedreieck 

MSR-Spezialmesse Nord 

MSR-Spezialmesse Südost 

MSR-Spezialmesse Niedersachsen 

am 20. März 2013 in der HALLE MESSE in Halle (Saale) 

am 05. Juni 2013 in der MesseHalle in Hamburg-Schnelsen 

am 18. September 2013 in der Sparkassen-Arena in Landshut 

am 30. Oktober 2013 in der Volkswagen Halle in Braunschweig 

Der Eintritt zur Messe und die Teilnahme an den Workshops ist kostenlos. 

Internet: www.meorga.de 

Email: info@meorga.de 

MEORGA GmbH 

Sportplatzstraße 27 

66809 Nalbach 

Tel. 06838 / 8960035 

Fax 06838 / 983292 


1-2 / 2013 

17

PRAXIS 

Wirbelfrequenzmessung ermittelt Produktion von 

Bio-Methan auch unter schwierigen Bedingungen 

Zuverlässige Ergebnisse trotz geringem Druck, schwankenden Temperaturen und Feuchtigkeiten 

BIO-METHAN AUS ABWASSER: 

Die Stadtwerke Burghausen 

erzeugen in einem Kanalwerk 

mit Kläranlage Faulgas zur 

Befeuerung eines angeschlossenen 

Blockheizkraftwerks. 

GASEINGANG MIT ERSTEM 

WASSERABSCHEIDER: Trotz 

dieser Anlage ist das Gas in den 

Rohrleitungen noch sehr feucht. 

Mit einem Wirbelfrequenz-Durchflussmessgerät können 

die Stadtwerke Burghausen trotz extrem 

schwieriger Bedingungen exakt messen, wie viel Biomethangas 

die Kläranlage ihres Kanalwerks liefert. Die 

messtechnische Herausforderung besteht in sehr niedrigen 

Gasdrücken von 7 bis 8 mbar oder sogar darunter 

sowie schwankenden Temperaturen und Feuchtigkeiten 

des erzeugten Gases. Die Mengenermittlung mit einem 

Differenzdruckmessgerät scheiterte aufgrund fehlerhafter 

Messwerte. Schließlich lieferte Krohne Messtechnik 

mit dem Wirbelfrequenz-Durchflussmessgerät Optiswirl 

4070 C eine Lösung, die sich mittlerweile in der 

Praxis bestens bewährt hat. 

Die Stadtwerke im oberbayerischen Burghausen betreiben 

ein Kanalwerk mit Kläranlage und angeschlossenem 

Blockheizkraftwerk, das mit Faulgas (Methan) 

befeuert wird. Zu diesem Zweck wird der Klärschlamm 

aus der Kläranlage in den Faulturm gefahren, 

wo die Restfeststoffe durch Mikroorganismen 

teilweise abgebaut werden. Das bei diesem Prozess 

freigesetzte Methan wird der Biogasanlage anschließend 

als Energieträger zugeführt. 

SCHWANKENDE DICHTE ERSCHWERT DIE MESSUNG 

Um genaue Informationen über die Energieproduktion 

des Klärwerks zu erhalten, benötigt der Betreiber kontinuierliche 

Messwerte über den Volumen- beziehungsweise 

Energiedurchfluss des vom Faulturm zum Blockheizkraftwerk 

transportierten Methans. Das Abgas ist 

trotz zweier installierter Wasserabscheider in der Rohrleitung 

sehr feucht. Der Druck des erzeugten Gases war 

ursprünglich mit 65 mbar schon sehr gering. Durch den 

Einbau einer Niederdruckanlage sank er im Laufe der 

Zeit auf 20, dann sogar auf durchschnittlich nur noch 7 

bis 8 mbar ab. 

Trotz der Isolierung des Faulturms ist das Gas äußeren 

Einflüssen wie jahreszeitlich bedingten Temperaturschwankungen 

ausgesetzt, die sich auf die Gasdichte 

(0,7177 kg/Nm³) auswirken. Der Kläranlagen-Betreiber 

hatte bereits den Einsatz eines Druckdifferenzgeräts geprüft, 

aber wegen fehlerhafter Messwerte wieder eingestellt. 

Aufgrund dieser Erfahrung war er sehr skeptisch, 

ob sich ein Messprinzip für die vorliegenden Parameter 

finden würde. 

SENSORWECHSEL AUCH BEI LAUFENDEM BETRIEB 

Krohne stellte das Wirbelfrequenz-Durchflussmessgerät 

Optiswirl 4070 C – zunächst als Testgerät – in der empfohlenen 

Nennweite DN 25 zur Verfügung. Dazu musste 

die Rohrleitung von ursprünglichen DN 50 auf DN 25 

eingezogen werden. Die Installation erfolgte auf Wunsch 

des Kunden mit Flanschanschluss in eine fallende Rohrleitung. 

Dabei wurden die notwendigen Ein- und Auslaufstrecken 

berücksichtigt. 

Das Vortex-Gerät (Druckstufe PN 40) misst den Betriebsdruck, 

die Temperatur und den Volumendurchfluss 

und errechnet auf dieser Basis automatisch den Masseund 

Energiedurchfluss des Methangases. Da das Instrument 

zusätzlich auch mit einer Absperrarmatur ausgeliefert 

wurde, kann sein Drucksensor gegebenenfalls 

18 


1-2 / 2013

OPTISWIRL 4070 C IN FALLENDER LEITUNG: 

Dank der Absperrarmatur könnte der Sensor 

auch im laufenden Betrieb gewechselt werden. 

HERAUSFORDERUNG: 

Die Durchflussmessung 

von 

Methangas erfolgt 

in der Anlage der 

Stadtwerke Burghausen 

bei nur 7 mbar. 

FÜR FEUCHTE GASE 

GEEIGNET: Wirbelfrequenze-Durchflussmessgerät 

Optiswirl 

4070 C mit integrierter 

Druck- und Temperaturkompensation. 

Bilder: Krohne 

auch bei laufendem Betrieb und ohne Prozesseingriff 

ausgewechselt werden. 

DRUCK- UND TEMPERATURKOMPENSATION 

Die wichtigsten Eigenschaften des Wirbelfrequenz- 

Durchflussmessgeräts Optiswirl 4070, das in der Anlage 

der Stadtwerke Burghausen zum Einsatz kommt: 

2-Leiter-Gerät mit integrierter Druck- und 

Temperaturkompensation und Umrechnung 

in Energie 

Verschleißfreie, vollverschweißte Edelstahlkonstruktion 

Für feuchte Gase geeignet 

Hohe Korrosions-, Druck- und Temperaturbeständigkeit 

Hohe Messgenauigkeit und Langzeitstabilität 

Sofortige Betriebsbereitschaft durch 

Plug-and-play 

Mit dem Wirbelfrequenz-Durchflussmessgerät kann 

der Betreiber des Kanalwerks Burghausen die Leistungsfähigkeit 

und Energieproduktion seiner Kläranlage 

genau überprüfen und nachweisen. Er profitiert 

dabei von der großen Messspanne des Optiswirl. 

Denn obwohl der Anlagendruck nach den Umbauarbeiten 

auf 7 bis 8 mbar oder sogar darunter absinkt 

und das Gas eine hohe Feuchtigkeit aufweist, misst 

das Gerät kontinuierlich und liefert fehlerfreie Messergebnisse. 

Angesichts der Messparameter waren die Stadtwerke 

Burghausen von der Messleistung des Optiswirl 

überrascht und entschieden sich für die Anschaffung 

des Instruments. Inzwischen läuft der Optiswirl seit 

mehr als drei Jahren unterbrechungsfrei und ohne 

jeglichen Wartungsaufwand. Bis heute hat das Vortex-Gerät 

im Kanalwerk über 620 000 m³ Faulgas gemessen. 

AUTOR 

MICHAEL MÖLLER 

ist Produktmanager 

Wirbelfrequenz- 

Durchflussmess geräte bei 

Krohne Messtechnik. 

Krohne Messtechnik GmbH, 

Ludwig-Krohne-Straße 5, D-47058 Duisburg, 

Tel. +49 (0) 203 301 44 13, 

E-Mail: m.moeller@krohne.com 


1-2 / 2013 

19

INTERVIEW 

JÖRG KIESBAUER: 

Seit Oktober 2008 ist er Mitglied 

im Vorstand des Stellgeräteanbieters 

Samson. Er vertritt 

den Bereich Forschung und 

Entwicklung. Kiesbauer ist seit 

1992 bei der Samson AG tätig. 

Vor fünf Jahren nahm er 

außerdem einen Lehrauftrag an 

der TU Darmstadt zum Thema 

Aktorik in der Prozessautomatisierung 

an. Auf der diesjährigen 

Namur-Hauptversammlung 

stellte Kiesbauer den Beitrag 

„Aktorik – von der Handdrossel 

zum smarten Stellgerät“ vor. 

20 


1-2 / 2013

„Die Diagnose-Informationen sind 

da – wir müssen sie nur nutzen“ 

Jörg Kiesbauer, Vorstandsmitglied der Samson AG, 

im Interview mit atp-edition-Chefredakteur Leon Urbas 

Die Namur-Hauptversammlung am 8. und 9. November 2012 stand unter dem Motto „Aktorik – von der Handdrossel 

zum smarten Stellgerät“. Anlass für atp-edition-Chefredakteur Prof. Dr.-Ing. Leon Urbas, Dr.-Ing. Jörg Kiesbauer, 

Vorstandsmitglied im Bereich Forschung und Entwicklung beim Stellgeräte-Hersteller Samson, zu der historischen 

Entwicklung von Aktorik zu befragen. Im Interview fordert Kiesbauer den standardisierten Zugriff auf Gerätedaten. 

Insgesamt fehle es im Prozessleitsystem an einem effizienten Informationsmanagement. Kiesbauer nimmt in dem 

Gespräch auch Stellung zu Themen wie der internationalen Normung und dem Bachelor/Master-Abschluss. 

Bilder: Anne Hütter 

LEON URBAS: Sie haben in Ihrem Vortrag auf der Namur- 

Hauptsitzung dargestellt, wie sich die Samson AG über die 

Jahre entwickelt hat. Welche Rolle nimmt Ihr Unternehmen 

heute im Markt ein? 

JÖRG KIESBAUER: In der Chemieindustrie sind wir bei Aktorik 

weltweit der Marktführer. Wenn wir über den gesamten Weltmarkt 

reden, positionieren wir uns etwa an vierter Stelle. Die 

Entwicklung hat gezeigt, dass wir von einem mechanischen zu 

einem mechatronischen Aktor gelangt sind. Darin liegt unsere 

Kompetenz, mit einem Baukasten-System und dem entsprechenden 

Engineering zu einer Lösung für jede Anforderung zu 

gelangen. 

LEON URBAS: Der Weg dahin war doch sicher nicht einfach. 

Welches waren in dieser Zeit die größten Schwierigkeiten, die 

es zu überwinden galt? 

JÖRG KIESBAUER: Samson begann mit Reglern ohne Hilfsenergie. 

Dies ist neben der Gebäudeautomation heute immer 

noch ein wichtiges Geschäftsfeld für uns. Weiterentwicklung 

und Kundennähe waren immer wichtig für Samson. Irgendwann 

haben wir uns mit Pneumatik und dem modularen Aufbau einen 

Namen in der Prozessautomation gemacht. Die Entwicklung 

dorthin war nicht einfach. Der Durchbruch kam mit unserer 

heutigen Standardventilbaureihe 240, weil wir erstmals ein 

sehr modularisiertes Konzept umgesetzt hatten. Nach wie vor 

ist gleichmäßiges Wachstum und Gewinn entscheidend. 

LEON URBAS: Ist Aktorik ein Wachstumsmarkt? 

JÖRG KIESBAUER: Ja. Wir haben neue Geschäftsfelder hinzugewonnen, 

wie beispielsweise die Öl-& Gasindustrie oder Kryotechnik. 

Zahlreiche spezialisierte Tochtergesellschaften sind 

dazugekommen (Air Torque, Cera System, Leusch, Pfeiffer, 

Starline und Vetec [Anm. der Redaktion]). Das entscheidende 

war aber in der Tat die Digitalisierung. 

LEON URBAS: Was zeichnet das Samson-Stellgerät denn nun 

aus? 

JÖRG KIESBAUER: Das heutige Stellgerät ist ein modularer 

Baukasten aus Armatur, Antrieb und Anbaugeräten. Dazu 

kommt die Auslegungserfahrung auf Basis von experimentellen 

und auch theoretischen Untersuchungen. Nur ein gut ausgelegtes 

Stellgerät kann später seinen Dienst in der Anlage tun. 

Die Diagnose durch die smarten Anbaugeräte ist nur dann 

sinnvoll nutzbar. Diagnose muss im Leitsystem ankommen, 

aber dann auch im Rahmen eines Plant Asset Managements 

genutzt werden. Eins ist wichtig: Die Besonderheit der Applikation. 

Durch unsere Modularisierung können wir für jede Herausforderung 

die richtige Lösung finden. Jedoch muss man 

den Aktor auch als Ganzes sehen. Es macht für uns keinen Sinn 

eine Gesamtfunktion auseinander zu reißen. Dazu entwickeln 

wir alle Komponenten ständig weiter. 

LEON URBAS: Wo sehen Sie beim Plant Asset Management 

neue Herausforderungen für die Aktorik? 

JÖRG KIESBAUER: Die Namur-Workshops ergaben, dass es 

an vielen Stellen wirklich um Detailarbeit geht. Die Diagnose- 

Informationen im Feldgerät sind da. Um von der Gerätediagnose 

zum Informationsmanagement zu gelangen, werden neue 

Ansätze zur Verdichtung und Archivierung von Diagnose-Informationen 

übergeordnet hinzukommen. 

LEON URBAS: Welche Rolle spielen Standards bei der Leitsystemintegration? 

Kann man sich vorstellen, dass ein Leitsystemhersteller 

eine spezielle Samson-Library anbietet? Ich möchte 

doch als Anwender Diagnose im Leitsystem haben. Die Namur 

arbeitet an einheitlichen Profilen für alle Ventile. 

JÖRG KIESBAUER: Die Geräteintegration ins Leitsystem ist ja 

schon standardisiert, sodass wir keine spezielle Library für 

Samson-Stellgeräte brauchen. Wir haben die komplette Gerätediagnose 

im Stellungsregler mit den Statusinformationen 

nach NE 107 einschließlich aller wichtigen Signaldaten. Wir 

brauchen keine zusätzlichen Diagnoseauswertungen im Leitsystem 

wie einige Marktbegleiter. Wir unterstützen alle Integrations-Standards 

wie EDDL und FDT/DTM. 

LEON URBAS: Sie sagten in einem Interview, dass Samson heute 

„zu allen mechanischen, elektrischen und softwarebezogenen 

Fragestellungen auf dem Gebiet der Stellgeräte Stellung 

beziehen“ kann. Was heißt das konkret? 

JÖRG KIESBAUER: Wir verstehen das gesamte Stellgerät, mechanisch, 

Elektronik- und Software-basiert. Wir haben eine 

starke Entwicklungsmannschaft, die sich auf allen dafür notwendigen 

Kompetenzfeldern auskennt und daraus Produktkonzepte 

mit dem vertriebsbezogenen Produktmanagement fest 


1-2 / 2013 

21

INTERVIEW 

„Die Workshops auf der 

diesjährigen Namur-Hauptversammlung 

zeigten, dass 

es um Detailarbeit geht. Die 

Frage ist ganz klar, wie Geräteinformationen 

zukünftig 

genutzt werden.“ 

legt und abstimmt. Wir nutzen dazu unser Werkstofflabor, einen 

sehr leistungsfähigen strömungstechnischen Prüfstand, eigenes 

EMV-und Explosionsschutz-Know-how sowie unser Smart 

Valve Integration Center für die Leitsystemintegration. 

LEON URBAS: Es gibt verschiedene Gremien, die Profile für 

Stellgeräte erarbeiten. Sind Sie mit dabei? 

JÖRG KIESBAUER: Ja. Wir sind von Anfang an in der Normung, 

an verschiedenen Stellen wie Namur, IEC, ISA, DKE, PNO, HCF, 

FF und anderen dabei. 

LEON URBAS: Zurzeit wird in der Namur versucht, wichtige 

Feldgeräteparameter zu standardisieren. Wann gibt es denn 

einen solchen Standard für Stellungsregler? 

JÖRG KIESBAUER: Relativ knapp vor der Namur-Hauptsitzung 

ist ein erster Vorschlag erarbeitet worden. Der bezieht sich im 

Wesentlichen auf die Grundfunktionen. Dazu müssen wir aber 

unsere Geräte nicht ändern. Es braucht eine saubere Definition 

und eine herstellerunabhängige Übersetzungstabelle. Wie das 

mit den Parametern der einzelnen Hersteller funktioniert, ist 

Sache des Herstellers. Standardisierte Defaultwerte müssen 

dazu führen, dass sich alle Geräte erst einmal gleich verhalten. 

LEON URBAS: Integrationsmethoden sind derzeit EDDL (electronic 

Device Description Language) und FDT/DTM (Field Device 

Tool/Device Type Manager). Ist FDI (Field Device Integration) 

eine bessere Lösung? 

JÖRG KIESBAUER: Wenn FDI kommt, werden wir dies wie EDDL 

und FDT/DTM natürlich auch unterstützen. Wir hoffen, dass 

hier manches einfacher und besser wird. Bisher ist EDDL nicht 

gleich EDDL, denn wir haben EDDLs in unterschiedlichen Ausführungen 

je nach Leitsystem. Auf unserer Wunschliste ganz 

oben steht die standardisierte Zugriffsmöglichkeit auf die über 

die Kommunikation wie Hart, PA oder FF im Leitsystem angekommenen 

Gerätedaten, unabhängig vom Asset-Management 

oder Engineeringsystem des Leitsystems. Sehr viel lässt sich 

durch historische Daten erreichen, die man gerätebezogen 

verwalten und miteinander vergleichen kann. Die OPC UA- 

Schnittstelle, wie sie bei FDI vorgesehen ist, wäre dazu vielleicht 

ein Lösungsansatz. 

LEON URBAS: Wenn FDI im Laufe des Jahres 2013 spezifiziert 

ist, bekommen wir dann FDI Device Packages von Samson? 

JÖRG KIESBAUER: Könnte ich mir vorstellen. Was wir meiner 

Meinung aber nicht brauchen, ist diese Vielzahl von EDDL, FDT/ 

DTM und FDI für die neuen Geräte, sondern endlich dann eine 

standardisierte Möglichkeit für jedes Leitsystem. 

LEON URBAS: Stichwort Energieeffizienz: Sie haben postuliert, 

nicht Drosselregelung und Pumpendrehzahlregelung gegeneinander 

auszuspielen, sondern aufgrund des größeren Einsatzbereiches 

auch über eine Kombination aus smartem Stellgerät 

und drehzahlgeregelter Pumpe als Flow Unit nachzudenken. 

Wann lohnt sich diese Investition? 

JÖRG KIESBAUER: Das hängt von Prozessdaten und Größe ab. 

Das muss man im Einzelfall berechnen, was wir auch mit entsprechenden 

Werkzeugen leisten. Neben verbesserter Energieeffizienz 

sind funktionale Vorteile und weniger Verschleiß 

weitere wichtige Bewertungsparameter. 

LEON URBAS: Was passiert in Zukunft im Bereich der Selbstdiagnose 

von Stellgeräten? 

JÖRG KIESBAUER: Wir haben bereits viel abgedeckt. Die Statusmeldung 

nach NE 107 ist ganz wichtig. Auf dem Weg zum 

Informationsmanagement sind sicherlich ergänzende Schritte 

notwendig. 

LEON URBAS: In Ihrem Vortrag klang es so, als hätte Samson 

jetzt ein eigenes Diagnose-Werkzeug? 

JÖRG KIESBAUER: Ja, wir haben eine zusätzliche Schnittstelle 

am Stellungsregler und eigene Software ähnlich einem FDT. 

Diese Software liest am Stellungsregler alle Daten aus und 

stellt sie entsprechend dar. Wir haben das entwickelt, damit 

unsere Mitarbeiter schnell reagieren zu können. Manchmal 

stand man vor dem Stellungsregler in der Werkstatt oder in der 

Anlage und konnte die Daten nicht auslesen, weil das Feldbussystem 

noch nicht vorhanden oder angeschlossen war. Aber 

man bekommt die gleiche Information auch über das Leitsystem 

per EDDL oder FDT/DTM. Oft sind aber Hart-Geräte in die 

Anlage eingebaut, man kann aber Hart im Leitsystem nicht 

nutzen, weil anlagenseitig gar nicht die Voraussetzungen für 

Hart-Kommunikation umgesetzt wurden. 

LEON URBAS: Wir haben im Vortrag von Herrn Bleuel („Automatisierung 

im Life Cycle modularer Anlagen“, S. 24-31, 

Anm. der Redaktion) gehört, dass, wenn man Modularisierung 

22 


1-2 / 2013

weiter denkt, Hersteller eine gewisse Freiheit haben müssen, 

damit sie Geschäftsmodelle entwickeln können. Eigentlich 

muss dann nur noch die Schnittstelle spezifiziert werden. 

Kann ich bei Ihnen ein Ventilmodul kaufen, in dem Sie eine 

Total Cost of Ownership und Verfügbarkeitsgarantie anbieten? 

Welchen Service bieten Sie da an? Kann man mit so was überhaupt 

Geld verdienen? 

JÖRG KIESBAUER: Klar sehen wir Potenzial in Dienstleistung. 

Wir haben den After Sales-Bereich verstärkt und werden diesen 

noch weiterentwickeln. Hier spielt die Nutzung der Diagnosedaten 

für unsere Stellgeräte eine zunehmend wichtigere 

Rolle. 

LEON URBAS: Welche informationstechnischen Konzepte verfolgen 

Sie hierzu? 

JÖRG KIESBAUER: Wir haben uns ein Datenbank-Tool geschaffen, 

mit dem wir die Daten aus unseren Stellgeräten – woher 

sie auch kommen, ob vorort oder über das Asset Management 

des Kunden ausgelesen – für uns mit der Dokumentation unserer 

Service-Aktionen zusammen archivieren können. 

LEON URBAS: Sie haben OPC UA angesprochen. Das wandert 

derzeit nur zögerlich in die Leitsysteme. Da haben Sie sicherlich 

weitere Wünsche an die Prozessleitsystem- Architektur, oder? 

JÖRG KIESBAUER: Wir treiben schon großen Aufwand für die 

Integration unserer Geräte ins System und sind in Kontakt mit 

den Herstellern. In der Regel funktioniert das, sodass wir auch 

im Bereich von Schulungen gewisse Kompetenz besitzen. 

Es gibt Beschränkungen beim regelmäßigen Auslesen der Feldgeräte. 

Die große Herausforderung wird sein, die Detailinformationen 

aus den Feldgeräten zentral zu sammeln, zu klassifizieren 

und dann noch Suchfunktionen darüber zu legen. Dies soll gezielt 

kritische Anlagenzustände abfragen und definieren, wie sich die 

Geräte in diesem Augenblick zu verhalten haben. Hierfür brauchen 

wir Gerätehersteller und Systemhersteller im selben Boot. 

Solche Auswertungen können wir schon in unserem eigenen 

zuvor angesprochenen Service-Datenbanktool durchführen. 

LEON URBAS: Welche Wünsche haben Sie im Bereich Visualisierung 

oder Einbindung zusätzlicher Informationen in die Leitsysteme? 

Die Leitsystemhersteller versprechen mit FDI erweiterte 

Integrationsmöglichkeiten. Ein Vorteil eines FDI wäre, 

direkt im Leitsystem die UIP einzubinden. Wie sehen Sie das? 

JÖRG KIESBAUER: Ja, EDDL könnte die wichtigsten Basisfunktionen 

integrieren und mit UIP kann man herstellerspezifische 

Auswertungen bei der Diagnose umsetzen. 

LEON URBAS: Welches Fazit zieht Ihr Unternehmen aus der 

Namur-Hauptsitzung? 

JÖRG KIESBAUER: Die Namur-Hauptversammlung war, wie 

immer, eine sehr interessante und hochkarätige Veranstaltung. 

Samson war es schon immer ein Anliegen, die Namur-Hauptversammlung 

zu unterstützen. Schön, dass diesmal auch einmal 

die sehr feldnahe Aktorik im Fokus stand. Zu Themen wie Asset 

Management und Datenverarbeitung gab es interessante Ansätze, 

wie der von uns inhaltlich voll unterstützte Vortrag von Sven 

Seintsch („Von der Gerätediagnose zum Informationsmanagement“, 

voraussichtliche Veröffentlichung in 55 (3), Anm. der 

Redaktion). Auch die Modularisierung lässt die spannende Frage 

zu, was dies für die Aktorik bedeutet. Unsere Flow Unit greift 

Modularisierung als Begriff in einem großen Umfang bereits auf. 

LEON URBAS: Wo könnte die Namur-Hauptversammlung Ihrer 

Meinung nach noch besser werden? 

JÖRG KIESBAUER: Die Verbindung zu den internationalen Verbänden 

ist angestoßen. Es wäre vielleicht nicht schlecht, wenn 

man gerade mit der ISA (International Society of Automation) 

schneller zusammen kommen würde. Ich weiß natürlich, dass 

das schwierig ist. 

LEON URBAS: Welche Aufgaben kommen bei der Normung auf 

die Community Ihrer Meinung nach zu? 

JÖRG KIESBAUER: In den internationalen Arbeitskreisen der 

IEC für Stellgeräte geht viel voran. Das funktioniert sogar oft 

besser als in den ISA-Arbeitskreisen. Das Eclass-Thema ist in 

die Normung zumindest mit aufgenommen worden. Es wird 

allerdings noch dauern bis zur Umsetzung. 

LEON URBAS: Was machen Sie eigentlich aktuell im Bereich 

Eclass? 

JÖRG KIESBAUER: Man versucht bei der IEC (International 

Electrotechnical Commission) die Begriffe für Ventile exakt zu 

normen. Das gibt es schon mit Eclass. Das will man natürlich 

übertragen. In der IEC und ISA gibt es entsprechende Beschreibung 

von Ventilen. Wir brauchen mehr Daten als diejenigen, die 

heute dort definiert sind. Der Prozess ist angestoßen. Die Anwender 

müssen es mittragen. Im Prinzip unterstützen wir dies. 

Wir können auch demonstrieren, dass es funktioniert. Ich 

denke, die Frage, wie wir Daten eingeben und wie wir sie bekommen, 

hat Zukunft. Gerade für integriertes Engineering ist 

das eine Grundvoraussetzung. 

LEON URBAS: Sie haben die vielen Innovationen aufgezeigt, die 

Sie vor sich haben. Dazu brauchen Sie ausgebildete Leute. Woher 

kommen die Fachkräfte? Wachsen Sie nur außerhalb von 

Deutschland? 

JÖRG KIESBAUER: Zwischenzeitlich war der Facharbeiter- 

Mangel in der Tat ein großes Problem. Wir bilden jetzt noch 

mehr selbst aus. Entwicklungsingenieure versuchen wir durch 

Hochschulprojekte, Masterarbeiten und Praktika schon als 

Studenten an das Unternehmen zu binden und für uns zu gewinnen. 

Wir beteiligen uns an von Studenten organisierten Berufsmessen 

wie beispielsweise der Konaktiva in Darmstadt. 

LEON URBAS: Die Hochschulen haben den Bologna-Prozess 

einführen müssen. Finden Sie als Arbeitgeber, das Modell Bachelor/Master 

angemessen? Sind die Absolventen berufsqualifiziert? 

JÖRG KIESBAUER: Ja, grundsätzlich brauchen wir aufgrund 

der Kom plexität unserer Entwicklungen sehr gut ausgebildete 

Absolventen mit hoher Lösungskompetenz. Häufig stellen wir 

Bewerber mit Master oder noch mit Diplom ein, aber auch mit 

Bachelorabschluß, am besten dann mit vorheriger Lehre. 

LEON URBAS: Herr Kiesbauer, wir danken Ihnen recht herzlich 

für das ausführliche Gespräch. 

JÖRG KIESBAUER (links) im Gespräch mit Leon Urbas. 


1-2 / 2013 

23

HAUPTBEITRAG | NAMUR-HAUPTSITZUNG 

Automatisierung im Life Cycle 

modularer Anlagen 

Welche Veränderungen und Chancen sich ergeben 

In Verfahrenstechnik und Anlagenbau werden zunehmend Konzepte zur Standardisierung 

der Modularisierung diskutiert. Dies hat weitreichende Auswirkungen auf das Engineering 

und den Betrieb der Anlagen. Der Beitrag zeigt die Einflüsse eines modularen Anlagendesigns 

auf den Lebenszyklus einer Anlage von der Planung über den Betrieb bis zur 

Demontage. Grundlage der Ausführungen sind die Arbeiten des Namur Arbeitskreises 

1.12 „Anforderungen an die Automatisierungstechnik durch die Modularisierung verfahrenstechnischer 

Anlagen“. 

SCHLAGWÖRTER Modularisierung / Life Cycle / Automatisierungstechnik 

Automation in the lifecycle of modular process plants – 

Modularisation – Which Consequences arise for automation? 

Standardisation and modularisation are intensively discussed in the Process Industries. 

Introducing these concepts will dramatically change plant engineering processes as well 

as plant operation strategies. This paper shows the impact of a modular plant design to 

the plant life cycle from engineering over the operation to disassembling. Basis of the 

paper are the discussions within the Namur working group 1.12 

KEYWORDS modularisation / life cycle / automation 

24 


1-2 / 2013

MICHAEL OBST, Technische Universität Dresden 

THOMAS HOLM, Helmut-Schmidt-Universität 

STEPHAN BLEUEL, Sanofi-Aventis 

ULF CLAUSSNITZER, Merck 

LARS EVERTZ, RWTH Aachen 

TOBIAS JÄGER, Helmut-Schmidt-Universität 

TOBIAS NEKOLLA, Evonik Industries 

STEPHAN PECH, BASF SE 

STEFAN SCHMITZ, Bayer Technology Services 

LEON URBAS, Technische Universität Dresden 

Mit dem Ziel einer drastischen Reduzierung der 

Zeitspanne zwischen Produktidee und 

Markteinführung [1] entstehen aus der Verfahrenstechnik 

heraus neue Anlagenkonzepte 

auf Basis modularer Anlagenkomponenten. 

Neben kürzerer Projektierungsdauer liefern diese Konzepte 

einen erheblichen Gewinn an Flexibilität. Die Automatisierungstechnik 

ist gefordert, diese Entwicklung 

zu unterstützen. Darüber hinaus sollte die Automatisierungstechnik 

in dieser Entwicklung Vorreiter und Innovator 

werden, zumal viele der notwendigen Entwicklungen 

sich in konventionell errichteten Anlagen als Wettbewerbsvorteil 

nutzen lassen. 

Während sich im klassischen Anlagenbau eine Vielzahl 

an Standards etabliert hat, fehlen für den modularen 

verfahrenstechnischen Anlagenbau – besonders im 

Bereich der Automatisierung – passende Rahmenbedingungen. 

Dabei schreitet die Entwicklung des modularen 

Anlagenbaus auf dem Gebiet der Verfahrenstechnik immer 

weiter voran. Es darf nicht passieren, dass die Automatisierungstechnik 

die Einführung modularer verfahrenstechnischer 

Anlagen behindert. Dabei ergeben 

sich durch die Modularität der Anlage für Lieferanten 

und Betreiber und für beteiligte Servicepartner neue 

Herausforderungen und Chancen, zum Beispiel durch 

die Erweiterung bestehender und Einführung neuer Geschäftsmodelle. 

Für eine breite Anwendung modularer Anlagen sind 

allerdings Mindestanforderungen an die Standardisierung 

der Automatisierung erforderlich, um mittelfristig 

die Flexibilität der Produktionsanlage zu akzeptablen 

Kosten zu erhalten. Die Entwicklung und Anwendung 

von Automatisierungskonzepten für modulare Anlagen 

ist von der weiteren Entwicklung des Anlagenkonzepts 

durch die Verfahrenstechnik und von der Nachfrage 

durch die Industrie abhängig. Hier sind die Hersteller 

und Serviceanbieter der Automatisierungsbranche gefordert, 

passende Anwendungen und Dienstleistungen 

zu entwickeln sowie weitere Impulse zu liefern. Dies 

sollte in Abstimmung zwischen Verfahrenstechnik, Apparatetechnik 

und Automatisierung geschehen. 

1. DER MODULBEGRIFF 

Modularität wird im Allgemeinen als Aufteilung eines 

Ganzen in definierte, meist standardisierte Elemente 

verstanden. Die einzelnen Elemente, die Module, agieren 

dabei über Schnittstellen miteinander [2]. So eingängig 

diese Definition ist, so unterschiedlich kann sie ausgelegt 

werden. 

In [3] wird ein Modul unter Verwendung der Definition 

aus der Konstruktionslehre [4] als eine Kombination 

von Bausteinen definiert. Neben der domänenspezifischen 

Betrachtung, finden sich bei der Variation der Granularität 

weitere Moduldefinitionen [10]. 

In der Prozessindustrie ist der Begriff somit nicht eindeutig 

definiert. Dieser Beitrag stellt zunächst den Modulbegriff 

aus Sicht des Namur AK 1.12 und der Prozessindustrie dar. 

Unter einem Modul wird in diesem Zusammenhang eine 

funktionale Einheit, zum Beispiel Teilanlage, verstanden, 

die geschlossen eine technische Funktion ausführen kann 

(vergleiche hierzu auch die NE33 [5]). Ein Modul besteht 

somit aus Apparaten und deren Verrohrung und Verkabelung. 

Es weist Montagestrukturen auf und beinhaltet automatisierungstechnische 

Hardware und gegebenenfalls auch 

Software. In der praktischen Umsetzung entspricht dies 

einer heute bereits verfügbaren Package Unit. 

Ein solches Modul ist in ein übergeordnetes Prozessleitsystem 

(PLS) zu integrieren. Dieses Leitsystem ist 

Bestandteil des Backbone, in welchem sich darüber hinaus 

die Anschlüsse für Hilfsenergie und weitere Einund 

Ausgangsstoffe für die modulare Anlage befinden. 

Der Backbone stellt somit die Infrastruktur der Anlage 

dar. Er kann dabei als eine Halle, in welcher sich die 

Anschlüsse, Schaltraum und Leitwarte befinden, oder 

auch selber als modulare Einheit konzipiert sein. 

2. ANLAGEN LIFE CYCLE 

Das Namur Arbeitsblatt 35 [6] bildet ein Vorgehensmodell 

für die Durchführung der leittechnischen Projektierung 

für verfahrenstechnische Anlagen ab. Darin werden En- 


1-2 / 2013 

25


gineeringtätigkeiten erläutert, ihnen bestimmte Methoden 

zugeordnet und ihre zeitliche Abfolge in Phasen 

vorgenommen. Es gliedert sich in die drei Hauptbereiche 

Projektierung, Qualitäts- und Projektmanagement. Die 

Projektierung beinhaltet insgesamt sieben Phasen, die 

jeweils ein bestimmtes Ziel in Hinblick auf die Realisierung 

einer technischen Anlage verfolgen. Dabei liegt der 

Fokus auf der Planung der Errichtung einer technischen 

Anlage. Darüber hinaus definiert beispielsweise das Process 

Plant Engineering Activity Model, PPEAM [7] die 

gesamte verfahrenstechnische Planung, die Betriebsphase 

und die Demontage einer Anlage. Zusammenfassend 

ergeben sich somit die in Bild 1 dargestellten vier Phasen: 

Planung, Errichtung, Betrieb inklusive Umbauten sowie 

Demontage. Anhand dieser Phasen werden im Folgenden 

die Einflüsse des modularen Anlagendesigns diskutiert. 

3. PLANUNG 

Die Planung der modularen verfahrenstechnischen Anlage 

ist geprägt durch die konstruktive Zusammenarbeit 

des Anlagenplaners, des Entwicklers und/oder späteren 

Betreibers der Anlage sowie den Lieferanten der Apparate, 

Mess- und Stellgeräte. Diese Kooperation im Entstehungsprozess 

beeinflusst den späteren Betrieb der Anlage. 

Diese Vorgehensweise erfordert ein Umdenken bei der 

Auswahl des einzusetzenden Equipments sowie der Beziehung 

zwischen Planer und Hersteller der verfahrenstechnischen 

Anlage beziehungsweise Module. Die Nutzung 

vorgefertigter Lösungen aus einem Katalog (siehe 

Bild 2 und 3) birgt aus verfahrenstechnischer und automatisierungstechnischer 

Sicht erhebliche Einsparpotenziale. 

Dem entgegen steht die verringerte Individualität 

und damit Auslegung der Anlage auf einen optimalen 

Arbeitspunkt. 

Im Planungsprozess einer modularen Anlage kann sich 

das Risiko eines Missverständnisses bei der Auswahl des 

Moduls aus dem Katalog des Lieferanten erhöhen (unzureichende 

Erfüllung der Anforderungen). Wie in [8] beschrieben, 

erscheint es hilfreich, eine gemeinsame Sprache 

(Glossar) zwischen Lieferanten und Anlagenplaner zu 

finden, um Fehlinvestitionen zu vermeiden. Auch kann 

die Auswahl beziehungsweise Auditierung geeigneter 

Lieferanten hinsichtlich der Erfüllung firmenspezifischer 

Standards, beispielsweise Feldgerätetyp, sinnvoll sein. 

Darüber hinaus kann sich eine erhöhte Abhängigkeit 

von den Lieferanten ergeben, die durch deren technische 

Kompetenz begründet ist. So genügt im zukünftigen Planungsprozess 

die Kenntnis einiger relevanter Kenngrößen 

zur Modulauswahl; dies schafft aber keinen tieferen 

Einblick in den Aufbau des Moduls. Daher ist insbesondere 

der Wegfall eines Lieferanten, zum Beispiel durch 

Insolvenz, bei der Lieferantenauswahl zu berücksichtigen 

und gegebenenfalls vertraglich abzusichern. 

Selbst bei einer umfassenden Dokumentation hoher 

Güte wird der Planer mitunter gezwungen sein, den Lieferanten 

in die Maßnahmenbewertung der Risikoanalysen 

zur Produkt- und Anlagensicherheit einzubeziehen. 

Dies muss aus technischer Sicht kein Nachteil sein. In 

einigen Fällen müssen Teile des Produktionsprozesses 

gegenüber Lieferanten offengelegt werden. Dies erfordert 

ein erhöhtes Maß an Vertrauen zwischen Lieferant, Betreiber 

und Planer. 

Innerhalb eines Moduls ist der Modulhersteller für den 

Aufbau des Automatisierungssystems verantwortlich. Bei 

der Zusammenstellung verschiedener Module zu einer 

Anlage ist die Automatisierungshardware innerhalb der 

Module also bereits vorgegeben. Auch Einzelsteuerungen 

und diverse Verriegelungslogiken können auf Modulebene 

bereits implementiert sein. Dies verringert den Planungs- 

und Implementierungsaufwand, setzt aber voraus, 

dass Module herstellerübergreifend kompatibel sind. Diese 

Forderung hat weitreichende Bedeutung für das Engineering 

eines Moduls. Die umfangreichen Aspekte der 

Interoperabilität der Module werden in [8] erläutert. Eine 

Bewertung wie sie beispielweise für Engineeringwerkzeuge 

[9] vorgeschlagen wurde ist hier ebenfalls von nutzen. 

Generell kann sich die Rollenverteilung zwischen (Modul-)Lieferant, 

Planer und Betreiber der Anlage verändern. 

Teile des Detail-Engineering lassen sich an den 

Modullieferanten auslagern. Der Betreiber oder Planer 

wird verstärkt die Aufgabe haben, verschiedene Module 

zu einem Gesamtsystem zu integrieren (Modul-Integrator). 

Der Planungsaufwand verringert sich dadurch, wie 

bereits beschrieben. 

Im Gegensatz dazu wird der Planer bei Auswahl und 

Optimierung des Automatisierungssystems deutlich 

eingeschränkt. Dies setzt ein großes Vertrauen in den 

Lieferanten voraus, da unter anderem sicherheitsrelevante 

Funktionen vom Modulhersteller implementiert 

werden müssen, die sicherheitstechnische Verantwortung 

aber in der Hand des Anlagen- beziehungsweise 

Modulbetreibers bleibt. 

4. ERRICHTUNG 

Die Errichtung und Montage eines Moduls liegt in der 

Verantwortung des Modulherstellers. Er kann die in seinem 

Katalog gelisteten Eigenschaften und Leistungsmerkmale 

des Moduls nach eigenem Ermessen realisieren 

und anbieten. Eine individuelle Konstruktion nach Vorgabe 

des Anlagenbetreibers kann zu einer verzögerten 

Modulbereitstellung und höheren Kosten führen. Nach 

Fertigstellung des Moduls wird die Erfüllung der Spezifikation 

innerhalb eines Factory Acceptance Test (FAT) 

überprüft. Soweit möglich, wird eine Leistungsfahrt des 

Moduls auf einem Teststand durchgeführt. Die Modultests 

liegen im Verantwortungsbereich des Modulherstellers 

und sind als Leistungsnachweis zu dokumentieren. 

Dem FAT kommt bei der Errichtung einer modularen 

Anlage ganz besondere Bedeutung zu. Durch die zeitliche 

Straffung der Anlagenerrichtung müssen zahlreiche 

Aktivitäten in den FAT verlagert werden, um später keine 

Zeitverzögerungen zu erzeugen. Entsprechende Testumgebungen 

müssen von dem Modulhersteller vorgesehen 

werden. Dies bietet die Möglichkeit, Schwachstellen 

und Fehler bereits in der Umgebung des Herstellers und 

nicht erst auf der Baustelle zu erkennen. Durch Verlagern 

von Prüfungen in die Testumgebung des Modulherstellers 

lassen sich neben Zeit- auch Kostenvorteile und eine 

Risikominimierung für das Gesamtprojekt erzielen. 

Besonderes Augenmerk ist auf die Schulung der Anlagenbediener 

und des Instandhaltungspersonals zu legen, 

da bei der späteren Inbetriebnahme nur ein verkürzter 

Zeitrahmen zur Verfügung steht. Die Modulhersteller 

sind hier ebenfalls gefordert, entsprechende Test- und 

26 


1-2 / 2013

27 


1-2 / 2013 

BILD 1: Phasen im Anlagen Life Cycle 

BILD 2: 

Modulauswahl 

anhand Modulkatalog 

(Teil 1) 

BILD 3: 

Modulauswahl 

anhand Modulkatalog 

(Teil 2) 

Planung 

Errichtung 

Betrieb inkl. 

Umbauten 

Demontage 

!"#$%&% 

Modulkatalog(e) 

Engineeringbereich 

YO 

Y0013 

YO 

Y0012 

YO 

Y0010 

YO 

Y0011 

YO 

Y0030 

LS 

L0025 

S- 

LS 

L0021 

S+ 

PIA 

P0022 

TIA 

T0023 

A+ 

A+ 

LIA 

L0020 

A+ 

A- 

US 

U1001 

US 

U1002 

YO 

Y0013 

YO 

Y0030 

LS 

L0021 

S+ 

PIA 

P0022 

TIA 

T0023 

A+ 

A+ 

US 

U1001 

YO 

Y0013 

YO 

Y010 

YO 

Y0011 

YO 

Y0030 

LS 

L0025 

S- 

LS 

L0021 

S+ 

PIA 

P0022 

TIA 

T0023 

A+ 

A+ 

LIA 

L0020 

A+ 

US 

U1001 

US 

U1002 

M 

MCO 

M0026 

YO 

Y0013 

YO 

Y0010 

YO 

Y0011 

YO 

Y0030 

LS 

L0024 

S- 

LS 

L0021 

S+ 

PIA 

P0022 

TIA 

T0023 

A+ 

A+ 

LIA 

L0020 

A+ 

US 

U1001 

US 

U1002 

M 

MCO 

M0025 

Bild 2 

Modulkatalog(e) 

Engineeringbereich 

M 

YO 

Y0010 

FIC 

F0011 

UIC 

U1001 

MCOS 

M0012 

PI 

P9001 

PI 

P9002 

YO 

Y0013 

M 

MOS 

M0012 

YO 

Y0013 

M 

YO 

Y0010 

FIC 

F0011 

UIC 

U1001 

MCO 

M0012 

PI 

P9002 

YO 

Y0013 

YO 

Y0013 

YO 

Y0010 

YO 

Y0011 

YO 

Y0030 

LS 

L0024 

S- 

LS 

L0021 

S+ 

PIA 

P0022 

TIA 

T0023 

A+ 

A+ 

LIA 

L0020 

A+ 

UIC 

U1001 

US 

U1002 

M 

MOS 

M0012 

YO 

Y0013 

M 

YO 

Y0010 

FIC 

F0011 

UIC 

U1001 

MCO 

M0012 

PI 

P9002 

YO 

Y0013 

M 

YO 

Y0010 

FIC 

F0011 

UIC 

U1001 

MCO 

M0012 

PI 

P9002 

YO 

Y0013 

M 

YO 

Y0010 

FIC 

F0011 

UIC 

U1001 

MCO 

M0012 

PI 

P9002 

YO 

Y0013 

YO 

Y0020 

YO 

Y0010 

TI 

T0011 

M 

MCO 

I-236 

Bild 3


Servicepartner 

Zusammenfassend ergibt sich bei der Errichtung modularer 

Anlagen unter dem Aspekt Zeitminimierung 

eine starke Verschiebung von Aktivitäten in den Zeitbereich 

des FAT hinein. Die Modulhersteller sind gefordert, 

stärkere Unterstützung bei der Inbetriebnahme und 

Schulungskonzepte für Bediener und Instandhaltung zu 

einem frühen Zeitpunkt anzubieten. Eine große Herausforderung 

besteht für die Hersteller von Automatisierungssystemen, 

um die Grundlage für das notwendige 

Plug and Produce [8] der Systemkomponeten zu schaffen 

und damit zu verhindern, dass die Automatisierungstechnik 

modulare Anlagenkonzepte ausbremst. 

5. BETRIEB INKLUSIVE UMBAUTEN 

Modulhersteller 

Anlagenbetreiber 

BILD 4: Neue Geschäftsmodelle zwischen 

Modulhersteller und Betreiber 

Schulungsmöglichkeiten vorzusehen. Spätestens zu diesem 

Zeitpunkt muss auch die Umsetzung vereinbarter 

Service Level abgeschlossen sein, zum Beispiel müssen 

Ersatzteile bereitliegen. 

Im Rahmen der Inbetriebnahme eines Moduls gilt es 

das vorher durch den Anlagenbetreiber gewählte Modul 

in die bestehende Infrastruktur eines Betriebsstandorts 

zu integrieren. Hierfür muss es aufgestellt und angeschlossen 

werden. Der Anschluss an die übergeordnete 

Infrastruktur erfolgt durch das Verbinden der vorher 

vereinbarten, idealerweise standardisierten Schnittstellen. 

Der Modullieferant und der Betreiber haben zu überprüfen, 

dass alle festgelegten und im FAT getesteten 

Schnittstellendefinitionen eingehalten wurden. Beim 

Anschluss werden auch die benötigten Informationen 

vom Modul an das übergeordnete Automatisierungssystem 

übertragen und umgekehrt. Dabei ist auf eine rückwirkungsfreie 

Einbindung in das Gesamtsystem zu achten. 

Eine automatisierte Überprüfung der Kompatibilität 

des Moduls zu der jeweiligen Andockstelle ist eine nützliche 

Zusatzfunktion. 

Im Rahmen der Inbetriebnahme werden auch bei einem 

modularen Anlagenkonzept verschiedene Tests 

erforderlich sein. Zum einen gibt es übergreifende Funktionen 

der Module und zum anderen muss die Funktion 

des Backbones im Zusammenspiel mit den Modulen getestet 

werden. Insgesamt stehen für die Inbetriebnahme 

aber ein sehr viel kürzeres Zeitfenster und wenig Eingewöhnungszeit 

für das Betriebspersonal zur Verfügung. 

Ebenso liegt das technische Know-how beim Betreiber 

noch nicht vor und muss erst in der betrieblichen Praxis 

erlangt werden. Bei einer zeitminimierten Inbetriebnahme 

ist daher eine Unterstützung vor Ort durch den Modulhersteller 

nötig. 

In einer klassisch errichteten Produktionsanlage ist die 

über Jahrzehnte gewonnene Betriebserfahrung in der 

Regel berücksichtigt worden. Beispiele hierfür sind die 

durchgängige Bedienung und Nutzung einheitlicher Geräte 

in den Anlagen. Hier wird es zwangsläufig zu Abstrichen 

kommen, da unterschiedliche Modulhersteller 

mit unterschiedlichen Erfahrungen aus den verschiedenen 

Anwendungsbereichen auch eine unterschiedliche 

Ausrüstung ihrer Module vornehmen werden. 

Weiterhin sind die heutigen Geschäftsmodelle optimiert 

und ausgereift für klassische Anlagen. Für modulare 

Anlagen öffnen sich weitere Möglichkeiten der Zusammenarbeit, 

wie zum Beispiel durch Leasingmodelle 

für Module, Ersatzteilvorhaltung und Life Cycle Management 

durch externe Servicepartner (siehe Bild 4). Dies 

bedeutet nicht, dass zwingend neue Geschäftsmodelle 

erforderlich werden. Es ergeben sich aber je nach Verteilung 

des Know-hows und der Ressourcen zwischen 

Modullieferant und Betreiber neue Möglichkeiten, um 

bestehende Geschäftsmodelle zu ergänzen. 

Als Beispiel sei hier das Life Cycle Management im 

Rahmen der Instandhaltung angeführt, welches System- 

Updates oder auch den Gerätetausch am Ende der individuellen 

Nutzungsdauer umfasst. Neue Möglichkeiten 

ergeben sich bei größeren Instandsetzungsmaßnahmen 

durch Modultausch anstelle eines Komponentenwechsels. 

Dabei ist eine Kompatibilität auf Modulebene ausreichend. 

Selbstverständlich muss die Nutzung und die 

Instandhaltung eines Moduls lückenlos dokumentiert 

werden, um bei Tausch eines Moduls eine Checkhefthistorie 

mitgeben zu können. 

Weiterhin muss der Modulhersteller für Schulungen 

über die Funktionalitäten der Module Personal zur Verfügung 

stellen. Dies gilt insbesondere für die Erstinbetriebnahme 

aber auch bei Bedarf in der nachfolgenden 

Zeit. Die Koordination dieser Schulungen für die jeweiligen 

Module obliegt dem Betreiber der Gesamtanlage. 

Wie in [8] bereits ausgeführt, soll für die Gesamtanlage 

eine einheitliche Bedienung und Beobachtung ermöglicht 

werden. Durch Nutzung von Modulen unterschiedlicher 

Hersteller ist diese Einheitlichkeit aber oft nicht 

gewährleistet. Hier sind die PLT-Stellen mit dem jeweiligen 

Modulkennzeichnungssystem des Modulherstellers 

ausgestattet. Um dem Bedien- und Wartungspersonal 

Eingriffsmöglichkeiten zu geben, muss der Bezug zwischen 

örtlicher Kennzeichnung, innerhalb des Moduls 

und der Kennzeichnung im übergeordneten Automatisierungssystem 

bekannt gemacht werden. Gemäß [8] 

28 


1-2 / 2013

www.atp-edition.de 

Jetzt bestellen! 

erfolgt diese Zuordnung im übergeordneten Automatisierungssystem 

und ist auch von diesem zu dokumentieren. 

6. DEMONTAGE 

Bei der Demontage ist grundsätzlich zwischen der 

eines Moduls und der des Backbones, als Bezeichner 

für die eigentliche Anlage, zu unterscheiden. Wird 

ein Modul, als Teil einer Anlage, außer Betrieb genommen, 

ist der Abkoppelvorgang unabhängig von 

der anschließenden Nutzung des Moduls. Somit ist 

dieses Vorgehen auch bei Abkoppelvorgängen im 

Rahmen von Umbauten der Anlage zu beachten. 

Grundsätzlich ist während und nach der Demontage 

eines Moduls auf Rückwirkungsfreiheit zu achten. 

Weder das mechanische, noch das datentechnische 

Entfernen des Moduls aus der Anlage darf die Funktionsfähigkeit 

der verbleibenden Anlage einschränken. 

Nach Abschluss des Demontagevorgangs eines 

Moduls muss die Anlage mit den verbliebenen Funktionalitäten 

wieder funktionstüchtig sein. Wenn identische 

Module im Rahmen eines Up- oder Downscale 

betroffen sind, sollte das Leitsystem in der Lage sein, 

den Abkoppelvorgang ohne Unterbrechung des Produktionsprozesses 

durchzuführen. 

Durch die Anwendung von – vom heutigen konventionellen 

Anlagenbau – abweichenden Geschäftsmodellen 

ist es denkbar, dass ein Modul durch dessen 

Hersteller zurückgenommen, erneut eingelagert oder in 

andere modulare verfahrenstechnische Anlagen integriert 

wird. Dabei stellt sich die Frage nach dem Verbleib 

der im Modul gespeicherten Informationen. Um 

Know-how-Schutz zu gewährleisten, ist die Prozesshistorie 

innerhalb des Moduls zu löschen. Ein generelles 

und vollständiges datentechnisches Rücksetzen des 

Moduls ist allerdings nicht zielführend, da für eine 

weitere und über den aktuellen Gebrauch hinausgehende 

Instandhaltungsplanung alte Betriebszustände und 

Laufzeiten benötigt werden. Verglichen mit der Nutzung 

eines Gebrauchtwagens, werden hier weniger Informationen 

über genauen Ort, Insassen und Fahrten 

des Wagens benötigt werden. Wichtiger ist vielmehr, 

wie viele Kilometer mit dem Fahrzeug zurückgelegt 

wurden und welche Belastungen dabei auf den Wagen 

eingewirkt haben. Angewandt auf die Nutzung eines 

Moduls, müssen Informationen über die Nutzung eines 

Moduls, wie eingebrachte Stoffe, Oberflächenbeeinträchtigungen 

und Lastzustände dokumentiert werden. 

Auch in Hinblick auf das übergeordnete Prozessleitsystem 

muss der datentechnische Abkoppelvorgang 

rückstandslos vonstattengehen. Nach der Entfernung 

eines Moduls dürfen keine Altlasten im 

übergeordneten Backbone zurückbleiben. Alte Bedienbilder, 

dem abgekoppelten Modul entsprechende 

Funktionsbausteine oder Rezeptfunktionen, 

sollten in einem dafür vorgesehenen Archivbereich 

abgelegt werden. Der Vorteil wäre eine vereinfachte 

erneute Anbindung des Moduls an die Anlage. 

Neben der digitalen Reinigung muss das Modul 

auch chemisch gereinigt werden, um einen weiteren 

Einsatz zu gewährleisten. Der eigentlichen Demontage 

muss somit ein Reinigungsvorgang vorgeschaltet 

atp edition erscheint in der DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München 

Die Referenzklasse für die 

Automatisierungstechnik 

atp edition ist das Fachmagazin für die Automatisierungstechnik. 

Die Qualität der wissenschaftlichen Hauptbeiträge 

sichert ein strenges Peer-Review-Verfahren. Bezug zur 

automatisierungstechnischen Praxis nehmen außerdem 

die kurzen Journalbeiträge aus der Fertigungs- und Prozessautomatisierung. 

Sichern Sie sich jetzt diese erstklassige Lektüre! Als exklusiv 

ausgestattetes Heft oder als praktisches ePaper – 

ideal für unterwegs, auf mobilen Endgeräten oder zum 

Archivieren. 

Wählen Sie einfach das Bezugsangebot, das Ihnen zusagt: 

als Heft, ePaper oder Heft + ePaper!


werden. Die Funktionalität und die Belieferung mit Lösungsmitteln 

und weiteren Hilfsmitteln, zum Reinigen 

des Moduls, müssen vom übergeordneten Leitsystem 

beziehungsweise von den dort angeschlossenen Modulen 

stammen. Kann oder soll die Reinigung eines Moduls 

nicht erfolgen, wird der ungereinigte Zustand in dem 

Modullogbuch hinterlegt. 

Die Außerbetriebnahme des Backbones entspricht in 

Umfang und Qualität, dem einer konventionellen verfahrenstechnischen 

Anlage. Um Produktionschargen 

rückverfolgbar zu gestalten ist es unter Umständen notwendig, 

über die Existenz der Anlage hinaus Prozesswerte 

und Zustände zu speichern. Auch hierfür könnte 

die Nutzung eines MES in Frage kommen. 

AUSBLICK 

Die Ergebnisse der Betrachtung von modularen verfahrenstechnischen 

Anlagen und deren Auswirkung 

AUTOREN 

Dipl.-Ing. MICHAEL OBST (geb. 1985) ist 

wissenschaftlicher Mitarbeiter der Professur für 

Prozessleittechnik an der TU Dresden mit den 

Schwerpunkten: Unterstützungssysteme für 

modulares Anlagenengineering, Lifecycle Cost 

Engineering und Fallbasiertes Schließen. 

Technische Universität Dresden, 

Fakultät Elektrotechnik und Informationstechnik, 

Institut für Automatisierungstechnik, 

D-01062 Dresden, Tel. +49 (0) 351 46 33 21 62, 

E-Mail: michael.obst@tu-dresden.de 

Dipl.-Ing. THOMAS HOLM (geb. 1979) ist 

wissenschaftlicher Mitarbeiter der Professur 

Automatisierungstechnik an der Helmut- 

Schmidt-Universität / Universität der Bundeswehr, 

Hamburg. Seine Forschungsschwerpunkte 

sind mechatronische Methoden im Anlagenbau 

und modulares Anlagen Engineering. 

Helmut-Schmidt-Universität / 

Universität der Bundeswehr, Hamburg, 

Professur für Automatisierungstechnik, 


Tel. +49 (0) 40 65 41 33 27, 

E-Mail: thomas.holm@hsu-hh.de 

Dipl.-Ing. STEPHAN BLEUEL (1965) ist Betriebstechnikleiter 

bei Sanofi-Aventis Deutschland 

GmbH. Des Weiteren hat er die Leitung des AF 

Leittechnik bei der IGR (Interessengemeinschaft 

Regelwerksverfolgung) und ist im AK1.12 der 

Namur aktiv. 

Sanofi-Aventis Deutschland GmbH, 

Industriepark Höchst, G680, D-65916 Frankfurt am 

Main, Tel. +49 (0) 69 30 58 30 96, 

E-Mail: stephan.bleuel@Sanofi.com 

Dipl.-Ing. ULF CLAUSSNITZER (geb. 1978) ist Senior Manager 

bei der Merck KGaA. Seine Gruppe ist für das EMSR- 

Engineering von Pilot- und Versuchsanlagen innerhalb der 

Verfahrensentwicklung verantwortlich. 

Merck KGaA, 

Frankfurter Str. 250, D-64293 Darmstadt, 

Tel. +49 (0) 6151 72 86 99, 

E-Mail: ulf.claussnitzer@merckgroup.com 

Dipl.-Ing. LARS EVERTZ (geb. 1987) ist wissenschaftlicher 

Mitarbeiter am Lehrstuhl für Prozessleittechnik der 

RWTH Aachen University. Seine Arbeitsschwerpunkte 

sind Automatisierungskonzepte für modulare Anlagen, 

Dienstsysteme in der Prozessleittechnik sowie Apps für 

die Leittechnik. 

RWTH Aachen University, 

Lehrstuhl für Prozessleittechnik, 

Turmstraße 46, D-52064 Aachen, 

Tel. +49 (0) 241 809 51 60, 

E-Mail: l.evertz@plt.rwth-aachen.de 

Dipl.-Wirt.-Ing. TOBIAS JÄGER (geb. 1984) ist Doktorand 

am Institut für Automatisierungstechnik der Helmut- 

Schmidt-Universität/Universität der Bundeswehr Hamburg. 

Seine Arbeitsschwerpunkte sind Modellassoziationen und 

Abhängigkeitsmanagement im industriellen Lösungsgeschäft 

für eine effiziente Gestaltung des Engineerings. 

Helmut-Schmidt-Universität, 


Tel. +49 (0) 40 65 41 36 63, 

E-Mail: tobias.jaeger@hsu-hh.de 

Dipl.-Ing. TOBIAS NEKOLLA (geb. 1961) ist PLT-Projektmanager 

für die internationale Anlagenplanung beim 

Servicebereich Process Technology & Engineering der 

Evonik Industries AG. Zusätzlich hat er leitende 

Funktionen im PLS-Fachreferat des Servicebereichs. 

Evonik Industries AG, TE-EN-E-A2, 

Rodenbacher Chaussee 4, D-63457 Hanau-Wolfgang, 

Tel. +49 (0) 61 81 59 40 43, 

E-Mail: tobias.nekolla@evonik.com 

30 


1-2 / 2013

auf die Automatisierungstechnik durch den Namur 

AK 1.12 werden derzeit in der geplanten Namur Empfehlung 

148 festgehalten. Die NE148 soll Herstellern 

und Serviceanbietern der Automatisierungsbranche 

aufzeigen, wie die Automatisierungstechnik aus Sicht 

des Anwenders auf die Herausforderungen des modularen 

verfahrenstechnischen Anlagenbaus reagieren 

sollte. Hersteller und Serviceanbieter werden gefordert, 

passende Anwendungen und Dienstleistungen 

zu entwickeln sowie weitere Impulse zu liefern. 

Die Herausforderung in der Anwendung eines modularen 

Konzeptes im Anlagenbau wird allerdings 

auch bei den Betreibern zu Veränderungen führen. 

Der organisatorische Paradigmenwechsel wird je nach 

Geschäftsmodell zu Kompetenzwechseln führen, mittel- 

und langfristig wird ein Übergang von Know-how 

vom Anlagenbetreiber zum Servicebetreiber zu beobachten 

sein. Entscheidend sind dabei sicher auch die 

Wahl des Lieferanten und dessen Einbindung in das 

betriebliche Umfeld. 

Dipl.-Ing. STEPHAN PECH (1979) arbeitet als 

Automation Engineer bei der BASF SE in Ludwigshafen. 

Die Schwerpunkte seiner Arbeit liegen im 

Bereich Manufacturing Operations Management. 

DANKSAGUNG 

MANUSKRIPTEINGANG 

19.12.2012 

Im Peer-Review-Verfahren begutachtet 

BASF SE, 

GTF/ED - M314, 67056 Ludwigshafen, 

Tel. +49 (0) 621 602 08 52, 

E-Mail: stephan.pech@basf.com 

Dr.-Ing. STEFAN SCHMITZ (geb. 1979) ist 

PLT-Projektmanager bei der Bayer Technology 

Services GmbH in Leverkusen. Neben seiner 

Tätigkeit als PLT-Projektleiter in der Anlagenplanung 

war er im F³ Factory Projekt für das 

Automatisierungskonzept der modularen 

Demonstrationsanlagen von BTS verantwortlich. 

Bayer Technology Services GmbH, 

Kaiser-Wilhelm-Allee, D-51368 Leverkusen, 

Tel. +49 (0) 214 304 32 75, 

E-Mail: stefan.schmitz2@bayer.com 

Prof. Dr.-Ing. LEON URBAS (geb. 1965) ist Inhaber 

der Professur für Prozessleittechnik an der 

Technischen Universität Dresden. Seine Hauptarbeitsgebiete 

beim Engineering verteilter sicherheitskritischer 

Systeme sind Funktionsintegration, 

modellgetriebenes Engineering, Modularisierung, 

Informationsmodelle der Prozessindustrie und 

Middleware in der Automatisierungstechnik. 

Einen weiteren Schwerpunkt bildet die Gebrauchstauglichkeit 

von mobilen Informationssystemen 

für die Prozessindustrie, Analyse, Gestaltung und 

Bewertung von Alarmierungs- und Unterstützungssysteme 

sowie Methoden der Benutzermodellierung 

zur prospektiven Gestaltung von Mensch-Technik- 

Interaktion. 

TU Dresden, 

Institut für Automatisierungstechnik, 

D-01062 Dresden, Tel. +49 (0) 351 46 33 96 14, 

E-Mail: leon.urbas@tu-dresden.de 

Die Autoren bedanken sich bei den ehemaligen 

Mitgliedern des Namur AK 1.12 Markus Vogel und 

Andreas Bamberg, Andreas Bamberg, Hisham 

Mubarak und Markus Vogel für die tatkräftige 

Unterstützung im Arbeitskreis. 

REFERENZEN 

[1] Bott, T., Schembecker, G.: Die 50 %-Idee – Vom Produkt 

zur Produktionsanlage in der halben Zeit. Tandemvortrag 

ProcessNet Jahrestreffen 8. – 10.9.2009, 

Mannheim. 

[2] Schuh, G.: Produktkomplexität managen, 2. Auflage, 

Carl Hanser Verlag München Wien, 2005. 

[3] Urbas, L., Doherr, F., Krause, A., Obst, M.: Modularisierung 

und Prozessführung. Chemie Ingenieur Technik 

84(5), S. 615-623, 2012. 

[4] Pahl, G., Beitz, W.: Konstruktionslehre, Springer- 

Verlag, Berlin, 1997. 

[5] NAMUR Empfehlung 33: Anforderungen an Systeme 

zur Rezeptfahrweise, 2003. 

[6] NAMUR Arbeitsblatt 35: Abwicklung von PLT-Projekten, 

2003. 

[7] Früh, K., F. Maier, U.: Handbuch der Prozessautomatisierung, 

3. Auflage, Oldenbourg Industrieverlag, 

München, 2004. 

[8] Urbas, L., Bleuel, St., Jäger, T, Schmitz, St., Evertz, 

L., Nekolla, T.: Automatisierung von Prozessmodulen. 

Von Package-Unit-Integration zu modularen Anlagen. 

atp edition - Automatisierungstechnische Praxis 

54(1-2), S. 44-53, 2012. 

[9] Drath, R., Barth, M., Fay, A.: Offenheitsmetrik für 

Engineering-Werkzeuge, atp edition - Automatisierungstechnische 

Praxis 54(9), S. 46-55, 2012. 

[10] Katzke, U., Fischer, K., Vogel-Heuser, B.: Entwicklung 

und Evaluation eines Modells für modulare Automatisierung 

im Anlagenbau. In: Tagungsband PEARL 

Verteilte Echtzeitsysteme, S. 69-77, 2003. 


1-2 / 2013 

31


Erfahrungen mit Web-basierter 

As-Built-Dokumentation 

Die vollständige Datenintegration bleibt ein Traum 

Das Bestreben, eine vollkommen integrierte CAE-Welt mit stets aktuellen Daten zu generieren, 

auf die alle Gewerke Zugriff haben, scheint ein wünschenswertes Ziel zu sein. Die 

Praxis zeigt jedoch, dass ein anderer Ansatz sinnvoller ist, denn Anlagenplanung, -montage 

und -betrieb stellen an die eingesetzten Werkzeuge völlig unterschiedliche Anforderungen. 

Das zeigt sich, wie in diesem Beitrag beschrieben wird, am Beispiel der BASF SE in Ludwigshafen, 

die 2010 begann, die elektronische Anlagendokumentation Livedok für den 

gesamten Standort einzuführen. Das System unterstützt die Betriebsphase der Anlage und 

sorgt für eine praxisgerechte Ankopplung an Planungssysteme. 

SCHLAGWÖRTER As-Built-Dokumentation / elektronische Anlagendokumentation / 

CAE-System / vollständige Datenintegration / Rotstiftfunktionalität 

The Usefulness of Web-based As-built-Documentation – 

Complete data integration will always remain a dream 

The endeavor to generate a fully integrated CAE world, in which data are always up to date 

and accessible to all departments, would seem to be desirable. However, in practice it emerges 

that because plant engineering, installation and operation make completely different 

demands on the tools used, another approach makes better sense. This is demonstrated, for 

example, by BASF SE in Ludwigshafen, which began the introduction of the electronic plant 

documentation Livedok for the whole site in 2010. Livedok supports the operating phase of 

the plant while also providing a practical link-up to engineering systems. 

KEYWORDS as-built-documentation / electronic plant documentation / E&I-CAE system / 

complete data integration / redline functionality 

32 


1-2 / 2013

MICHAEL BRENDELBERGER, BASF 

MARTIN DUBOVY, Rösberg Engineering 

Wer im täglichen Leben mit Bürokratie zu 

tun hat, dem kommt meist die Redensart 

in den Sinn „Von der Wiege bis zur Bahre, 

Formulare, Formulare“. Wer mit Anlagentechnik 

zu tun hat, dem geht es ähnlich. 

Je komplexer eine Anlage ist, desto mehr Dokumente, 

Listen, Zeichnungen und so weiter entstehen und müssen 

praktikabel gehandhabt werden. Die Entstehung 

dieser Papierberge fängt bereits in der ersten Planungsphase 

an, setzt sich bei der Inbetriebsetzung fort, geht 

während des Anlagenbetriebs weiter und endet erst nach 

Stilllegung und Rückbau. Gleichzeitig ist man in jeder 

dieser Phasen auf Informationen, also Daten angewiesen; 

nicht immer auf alle, aber stets auf die jeweils relevanten. 

Auf der Namur-Hauptsitzung im Jahre 2001 wurde der 

Wunsch nach einer vollständigen Datenintegration formuliert 

[1, 2]. Verglichen mit den heutigen Ansprüchen, ist 

festzustellen, dass sich die damaligen Forderungen keineswegs 

von den derzeitigen unterscheiden. Interessant 

ist aber auch die Feststellung, dass die praktische Realisierung 

dieser Forderungen immer noch auf sich warten 

lässt. Es fehlt ein Werkzeug, das von der Planung bis zur 

Serviceunterstützung und Dokumentation im Betrieb alles 

kann. Ideal wäre ein herstellerneutrales Datenaustausch- 

Format, auf das alle Gewerke mit ihren eigenen, spezifisch 

optimierten Werkzeugen zugreifen und in dem sie wiederum 

ihre Daten ablegen (Bild 1). Das ist offensichtlich nicht 

so einfach, wie es auf den ersten Blick scheint, denn wirklich 

weiterentwickelt hat sich in dieser Richtung wenig. 

Die Praxis zeigt dafür gleich mehrere Gründe. 

Systeme ein Mapping machen. Zurzeit praktiziert die 

BASF SE in Ludwigshafen das mit den Prolist-Merkmalleisten 

für PLT-Feldgeräte [5]. Die Idee ist so genial wie 

einfach, aber selbst für diesen kleinen Bereich ist die 

Umsetzung in der Praxis keineswegs trivial. Hinzu 

kommt die Problematik, dass in den Anlagen immer 

Units, also komplette Maschinen oder Anlagenteile von 

Zulieferern, einzubinden sind, die mit einer eigenen, herstellerspezifischen 

Dokumentation geliefert werden. 

Außerdem würde ein vollintegrierter Datenbestand zu 

keiner Zeit inkonsistente Datensätze erlauben. Das klingt 

zunächst gut, fördert aber letztendlich das Entstehen datentechnischer 

Parallelwelten. Die Erfahrungen der letzten 

Jahre zeigen, dass in der Phase der Konzeptions- (KP) 

und erweiterten Konzeptionsplanung (EKP) mit Daten 

gearbeitet wird, die oftmals nicht gesichert sind und 

durch neue Erkenntnisse oder Vorgaben geändert werden 

müssen. Schließlich ist das der kreative Part der Planung 

– die Zeit der Entwürfe, Verbesserungen, Optimierungen. 

Solche weichen Daten sind aber von gesicherten Daten 

nicht unterscheidbar und das nächste Gewerk kann nicht 

erkennen, ob mit diesem Datensatz weitergearbeitet werden 

kann oder ob nur eine Idee näher untersucht wird. 

Zwingen wir die Planer, nur gesicherte konsistente Daten 

zu produzieren beziehungsweise weiterzugeben, so entstehen 

datentechnische Parallelwelten in Formaten wie 

Excel, Access. Diese bestehen dann mindestens so lange, 

bis mit relativ gesicherten Daten die Massenproduktion 

der Planung begonnen wird. Das sollte spätestens bei Beginn 

der Detailplanung sein. 

1. DIE PROBLEMATIK EINES KONSISTENTEN, 

VOLLINTEGRIERTEN DATENBESTANDS 

Die Erstellung eines gewerkeübergreifenden, universellen 

Datenformats ist gleichbedeutend mit der Errichtung eines 

Stammdatensatzes für alle planenden Gewerke der 

Prozessindustrie weltweit. Eine praktikable Vorgehensweise 

wäre dabei die Generierung von Objekten und 

Merkmalen für alle Teile, auf die die jeweiligen CAE- 

2. WAS IN DER BETRIEBSPHASE DER ANLAGE PASSIERT 

Noch spannender wird es, wenn die Anlage in Betrieb 

geht und planungstechnisch weiterlebt. Bis zur Inbetriebnahme 

kümmerte sich nur das Planungsteam mit 

seinen Gewerken um jeweils seine Datensätze. Nach der 

Inbetriebnahme einer Anlage gehen diese Datensätze 

dann an den Betrieb, die Instandhaltung, die Montage 

und die Vor-Ort-Planung und müssen weiter gepflegt 


1-2 / 2013 

33


werden. Einfach ausgedrückt wird dann jedes der Gewerke 

den jeweils für sich relevanten Teil auf das zu 

pflegende Minimum reduzieren. Das heißt, bestimmte 

Datensätze werden nicht mehr aktuell sein, und insgesamt 

wird der Datenbestand als „As-Built-Dokumentation“ 

unbrauchbar, weil nicht zwischen gepflegten und 

toten Datensätzen unterschieden werden kann. 

Hinzu kommt, dass Neuplanungen oder Änderungen 

auch in diesen Datentopf fließen, der beispielsweise nicht 

zwischen geplant, montiert, oder in Betrieb unterscheiden 

kann. Wieder werden datentechnische Parallelwelten 

entstehen. Letztendlich kann sich dann niemand 

darauf verlassen, was wirklich aktuell ist und wo er auf 

den gültigen Datensatz stößt. Das, was der mit viel Aufwand 

generierte konsistente Datensatz eigentlich leisten 

soll, kann er so nicht leisten. Außerdem wird es immer 

Daten geben, die von mehreren Gewerken gebraucht und 

deshalb auch in jedem Gewerk gebildet beziehungsweise 

verändert werden. Die Integration erzwingt eine kausale 

Bearbeitungskette, die in der Realität keinen Bestand 

hat (Bild 2). In der Theorie reden wir zumeist von 

seriellen Planungsabläufen. Streng gelebte serielle Planungsabläufe 

bekommen aber nahezu immer ein Terminproblem, 

was die Planer veranlasst, parallel mit eigenen 

Planungen zu beginnen, die Datensätze verlangen können, 

die noch nicht festgelegt sind. Die Folge sind Iterationsläufe, 

die wiederum einen vollintegrierten Datensatz 

mehrfach umsetzen. Die Idee, einen Datensatz nur 

einmal zu generieren, ist damit hinfällig [4, 6]. 

Erschwerend kommt noch ein weiteres Problem hinzu: 

Ist die Anlage in Betrieb, dann müssen vor Ort Änderungen 

in die Dokumentation eingebracht werden. Somit ergibt sich 

die Situation, dass ungeübte Mitarbeiter mit mächtigen 

CAE-Werkzeugen auf Datenbanken arbeiten müssen. Hier 

sind massive Berührungsängste vorhanden, da Nicht-Systemspezialisten 

mit einfachen Handgriffen viel Information 

unbeabsichtigt vernichten können. Auch hier wird wieder 

eine parallele Datenwelt, diesmal auf Papier, aufgebaut. 

Idealisierte CAE-Plattform aus Sicht des Inhouse-Planers 

M&A 

Technische 

Spezifikation 

EMR 

Auswertungen 

(Reports) 

ERP-Systeme 

(z.B. SAP-MM/PM/PS) 

Dokumentenmanagement 

(z.B. Documentum) 

Kostenschätzung 

Planungsdaten 

Standardmaterialdaten 

Planungsdokumente, 

(Reports, 

Zeichnungen) 

Herstellerneutrales Datenaustausch-Format 

Projekt- 

Controlling 

BILD 3: Dank zahlreicher Schnittstellen 

lässt sich das Prozessleittechnik- 

Planungssystem Prodok gut integrieren. 

Simulation 

Verfahrens-/ 

R&I-FB 

M&A-Daten 3D-Modell EMR-Daten 

Datensammler/ 

Integrator 

CAE-Modell aus Sicht des Inhouse-Planers 

BILD 1: Idealisiertes CAE-System aus Sicht des 

Inhouse-Planers (Aus dem Vortrag „CAE-Modell 

aus Sicht des Inhouse-Planer“ Dr. Klein, BASF SE 

auf der Namur-HS 2001, Bild Nr. 14) 

Die häufige Realität 

Basisplanung 

Errichtung 

Konzeptplanung 

Betrieb 

Ausführungsplanung 

Inbetriebsetzung 

Ist-Zustand Planungsablauf im Anlagenbau 

BILD 2: Die klassische sequenzielle Abwicklung und 

die (häufige) Realität (Aus dem Vortrag „CAE-Modell 

aus Sicht des Inhouse-Planer“ Dr. Klein, BASF SE auf 

der Namur HS-2001, Bild Nr. 2 und 3) 

34 


1-2 / 2013

3. TRENNUNG VON PLANUNGS- UND 

INSTAND HALTUNGSWERKZEUGEN 

Aus dem beschriebenen Szenarium folgt, dass die vollintegrierte 

Datenwelt nur dann gewisse Vorteile bringt, wenn 

es um eine straff geführte, überschaubare Planungseinheit 

geht, die sich hauptsächlich im Bereich der Detailplanung 

bewegt. Wer im Prinzip immer die gleiche Anlage baut, ist 

damit sicher gut bedient. Die Randgebiete, wie die kreative 

Konzeptions- und erweiterte Konzeptionsplanung sowie 

die Jahrzehnte andauernde Betriebszeit, stellen die 

Praktikabilität dieser Idee bei komplexen Anlagen infrage. 

Hier empfiehlt sich ein anderes Vorgehen: 

Eine Umfrage bei Namur-Firmen hat gezeigt, dass die 

Frage, mit welchem CAE-System gearbeitet wird, eher 

untergeordnet ist. Mit allen Systemen kann ein brauchbares 

Ergebnis erzielt werden. Wird eine Anlage in ihrem 

gesamten Lebenszyklus von Beginn der Planung bis zur 

Stilllegung betrachtet, lässt sich feststellen, dass nicht 

das jeweilige CAE-Werkzeug entscheidend ist, sondern 

der Datensatz. Das Werkzeug ist Mittel zum Zweck, im 

lesbaren Datensatz liegt die Effizienz. Am Ende der Planungsphase 

muss ein lesbares Dokument stehen. Da Planung 

und Betrieb unterschiedliche Anforderungen stellen, 

sollten sie verschiedene Werkzeuge benutzen dürfen, 

vorausgesetzt der zwischen beiden notwendige Informationsfluss 

ist sichergestellt. Die BASF ist mit diesem Vorgehen 

auf große Akzeptanz gestoßen. 

Auf der Namur-Hauptsitzung 2001 wurde auch von 

Dr. Rauprich in seinem Workshop „Unterstützung mit 

Mitteln der Webtechnologie“ eine Idee vorgestellt, die 

den Anlagenbetreibern und Planern ermöglicht, via Web 

auf die Dokumentation zu schauen und diese mit einfachen 

Mitteln (Rotstiftfunktionalität) zu bearbeiten. Eine 

Änderung wird dabei nicht im CAE-System direkt eingepflegt, 

sondern mit Editierwerkzeugen auf dem Planungsdokument 

(zumeist PDF) eingezeichnet. Am Beispiel 

der BASF SE in Ludwigshafen, die 2010 begann, 

die elektronische Anlagendokumentation Livedok für 

den gesamten Standort einzuführen, zeigt sich, wie einfach 

es ist, ein solches Werkzeug in die breite Anwendung 

zu bringen, wenn es praktikabel ist. 

4. WERKZEUGE, DIE PRAKTIKABEL SIND, 

WERDEN AKZEPTIERT 

Am Standort Ludwigshafen gibt es mehrere Planungseinheiten, 

für Großprojekte weltweit und für den Standort 

selbst. Seit dem Jahr 2000 wird die PLT-Planung für Ludwigshafen 

ausschließlich mit dem CAE-System Prodok 

erstellt (Bild 3). Die Verfahrenstechnik- und die Rohrleitungsplanung 

benutzen mehrere unterschiedliche Systeme. 

Die PLT-Datenwelt war bis zu diesem Zeitpunkt schon 

sehr geordnet. Um den Betrieben einen Überblick auf die 

entsprechende Dokumentation zu geben, hatten einige 

Betriebe bereits die Planungsdokumente aus Prodok als 

Webdokumentation zur Verfügung gestellt. Nachteil von 

diesem System war, dass die kurzlebigen Dokumente der 

PLT-Planung relativ schnell dazu führten, dass die Web- 

LiveDOK und Tablet-PCs – Die perfekte Ergänzung. 

LiveDOK bietet die Möglichkeit, Dokumente, Pläne und Unterlagen von industriellen Anlagen 

digital und in Echtzeit zu verwalten. Änderungen, Ergänzungen und neue Dokumente werden 

sofort eingespielt und für alle Projektbeteiligten sichtbar. Mit einem Tablet-PC haben Sie nun 

die ganze Dokumentations-Bibliothek vor Ort in Ihren Händen. Und Dank der Synchronisations- 

Funktion haben Sie immer die Gewissheit, dass alle Dokumente auch aktuell sind. 

Wenn Sie wissen möchten, wie Sie sich das Wühlen, Suchen oder Fragen nach Unterlagen in 

Zukunft sparen können, servieren wir Ihnen gerne weitere Informationen. 

www.livedok.de 

Rösberg Engineering 

Ingenieurgesellschaft mbH 

für Automation 

Industriestr. 9 

76189 Karlsruhe 

Germany 

Telefon +49·7 21·9 50 18–0 

Telefax +49·7 21·50 32 66 

info.ka@roesberg.com 

www.roesberg.com 

Karlsruhe · Ludwigshafen · Rheinfelden · Schwarzheide · Dalian (P.R. China)


BILD 4: Der Livedok-Generator ist offen für nahezu alle 

denk baren Aufgaben und verarbeitet alle gängigen Formate. 

Betriebsführung 

Service, 

Wartung und 

Instandhaltung 

Dokumente 

PDFs mit 

Roteintrag 

Synchronisation 

Qualitätswesen 

BILD 5: Die Bedienung ist einfach und intuitiv. 

Paketaustausch 

Dokumentenverwaltung 

Service 

Betriebsleitung 

BILD 6: Die Redlining-Palette reicht von 

Handschrifteingabe über Markieren, 

Durchstreichen bis hin zu dynamischen 

Stempeln und vielem mehr. 

dokumentation nicht mit Sicherheit dem aktuellen As- 

Built-Stand entsprach. Mit der Einführung von Livedok 

hat sich das nun geändert, und das mit hoher Akzeptanz, 

wie eine Zwischenbilanz vom September 2012 belegt. 

Etwa 1 200 000 Dokumente mit einem Datenvolumen von 

75 GB sind eingepflegt, die von 916 Usern in 155 Betrieben 

genutzt werden. Die Gründe für die Akzeptanz liegen im 

hohen Praxisnutzen der elektronischen Dokumentation. 

Die Trennung des Redlining-Werkzeugs vom CAE-System 

passt sehr gut auf die Organisationsstruktur der BASF 

SE. Mit der Inbetriebnahme geht die Dokumentation an 

den Betrieb und die entsprechenden Serviceeinheiten 

über. Die Planung mit dem CAE-Werkzeug ist abgeschlossen, 

die Informationen befinden sich in der Dokumentation. 

Prozesstechnische Anlagen in der BASF unterliegen 

einer ständigen Optimierung und Anpassung. Es bleibt 

nicht aus, dass die Instandhaltung oder die Vor-Ort- 

Mannschaft Änderungen in der Anlage vornehmen. Diese 

Änderungen wurden bis zur Einführung von Livedok 

auf der Papier festgehalten. Ursprünglich waren die Verantwortlichen 

davon ausgegangen, dass, wenn alle eine 

entsprechende CAE-Schulung haben, dann nur noch im 

CAE-System gearbeitet wird. Dies hat sich in der Praxis 

aus zuvor genannten Gründen als nicht praktikabel erwiesen. 

Also hatte sich mit der Umstellung auf ein einziges 

CAE-System die Welt im Betrieb und in der Instandhaltung 

nicht geändert. Wenn alles im CAE-System liegt, 

kann niemand sagen, ob dies geplant, gebaut oder schon 

in Betrieb ist. Zur Vorlage bei einer Behörde ist eine solche 

Dokumentation dann vollkommen ungeeignet. 

Mit der Trennung von As-Built- und CAE-Werkzeug ist 

dies dagegen jetzt eindeutig festgelegt. Durch eine elegante 

Verwaltung der Änderungen in Livedok wird der PLT- 

Planer (CAE-Systemspezialist) über alle Vor-Ort-Änderungen 

mit Datum und Verursacher informiert und zu 

gegebener Zeit vom Betrieb beauftragt, diese Änderungen 

im CAE-System einzupflegen. So geht keine Information 

verloren, und die Planungseinheit kann über Jahre hinweg 

dokumentieren, wann welche Anlagenänderung in Betrieb 

ging beziehungsweise welchen Umfang sie hatte. Für 

eine Serviceeinheit ist dies ein großer Zusatznutzen. 

5. WIE LIVEDOK FUNKTIONIERT 

Livedok begleitet den kompletten Lebenszyklus der Dokumentation, 

beginnend bei der Erstellung über die Benutzung 

bis hin zur Revision der geänderten Dokumente 

[7]. Dafür sorgt das Herz der Dokumentationssoftware, 

der leistungsfähige Livedok-Generator, der für nahezu 

alle denkbaren Aufgaben offen ist. So sind die Schnittstellen 

zur Planung kein Problem (Bild 4), gleich mit welchem 

CAE-System dort gearbeitet wird. Das Dokumentationssystem 

verarbeitet alle gängigen Formate, kann also 

Grundrisse, Lagepläne, Verfahrensfließbilder und PLT- 

Stellenlisten ebenso managen wie Bedienvorschriften, 

Prüfanforderungen und Wartungsanleitungen. Jeder Mitarbeiter, 

der etwas sucht, wird auf diese Weise schnell 

fündig, denn der Livedok-Browser vereinfacht die Navigation 

und Suche innerhalb der elektronischen Ablage 

36 


1-2 / 2013

dank leistungsstarker und intuitiv nutzbarer Werkzeuge. 

Dazu trägt die Google-artige Suchsyntax ebenso bei wie 

die synchrone Anzeige bei Dokumentvergleich und Aktualisierung 

(Bild 5). Davon profitieren Betriebsführung 

und Servicepersonal ebenso wie das gesamte Qualitätswesen. 

Alle Beteiligten können immer auf die aktuellen 

Informationen zugreifen. Änderungen sind schnell und 

einfach gemacht und obendrein auch jederzeit nachverfolgbar. 

Die Dokumentation lässt sich mit jedem beliebigen 

Webbrowser einsehen. Lediglich für Änderungen 

oder Aktualisierung ist eine Livedok-Lizenz erforderlich. 

Weil auch die beste Dokumentation nur dann genutzt 

wird, wenn sich der Anwender einfach darin zurechtfindet, 

spielt Übersichtlichkeit eine wichtige Rolle. Gliederungen 

der Dokumente und Ansichten lassen sich deshalb 

individuellen Bedürfnissen anpassen. Auch für Änderungen 

gibt es unterschiedliche Möglichkeiten. Die Redlining-Palette 

reicht beispielsweise von Handschrifteingabe 

über Markieren, Durchstreichen und vielem mehr bis 

hin zu dynamischen Stempeln (Bild 6). Dazu nutzt der 

Mitarbeiter den Stift eines Tablets oder Tastatur beziehungsweise 

eine Maus. Wenn keine permanente Netzwerkverbindung 

zur Dokumentation auf dem Fileserver 

besteht, lassen sich mit dem Offline-Modul die Daten auch 

unterwegs ohne Netzwerkverbindung eintragen. Bei der 

anschließenden Synchronisation werden die Roteinträge 

in die zentrale Dokumentation übernommen. Eventuelle 

Konflikte werden angezeigt, falls zum Beispiel parallel 

eine zweite Person dasselbe Dokument geändert hat. 

6. FÜR SMARTPHONES UND ANDROID-TABLETS 

GEEIGNET 

Vor Ort, zum Beispiel im mobilen Feldeinsatz, kann der 

Mitarbeiter die unterschiedlichsten Geräte nutzen. Da die 

elektronische Dokumentation nicht nur das Betriebssystem 

Windows, sondern jetzt auch Android unterstützt, 

lassen sich Tablet-PCs ebenso verwenden wie Smartphones 

(Bild 7) [3]. Bei Bedarf kann der Mitarbeiter dann beispielsweise 

einer Änderung der Dokumentation auch ein 

Foto beifügen, auf das dann ebenfalls jeder Berechtigte 

Zugriff hat. Da kurzfristig die ersten Industrie- und Ex- 

Bereich-tauglichen Tablets auf den Markt kommen werden, 

wird diese Möglichkeit sicher auf reges Interesse stoßen. 

AUSBLICK 

Auch für die Zukunft ist die elektronische Dokumentation 

bestens vorbereitet. Als weitere Ausbaustufe ist beispielsweise 

die Aufbereitung der Daten ins jahrzehntelang elektronisch 

archivierbare PDF/A-Format geplant. Bei der gesetzlich 

vorgeschriebenen Langzeitarchivierung wird dann 

auf Papier verzichtet. Digitale Signaturen werden künftig 

außerdem die Dokumentation von Prüfabläufen erleichtern. 

Für die elektronische Anlagendokumentation steht damit 

ein leistungsfähiges Werkzeug zur Verfügung, das auch 

ohne durchgehend herstellerneutrales Datenformat für die 

notwendige Ankopplung an die planenden Gewerke sorgt. 

Für keinen Planer dürfte es ein Problem sein, an die notwendigen 

und immer aktuellen Datensätze der As-Built- 

Dokumentation zu kommen. 


30.10.2012 


REFERENZEN 

[1] Rauprich, G., Haus, C., Ahrens, W.: PLT-CAE-Integration 

in gewerkeübergreifendes Engineering und Plant- 

Maintenance. atp –Automatisierungstechnische Praxis 

44(2), S. 50-62, 2002. 

[2] Klein, X.: Vortrag Planungswerkzeuge in Chemieanlagen 

- aus Sicht eines inhouse Planers, Namur Hauptsitzung 

2001 

[3] Landgraf, E.: Unabhängig von der Quelle und fit für den 

mobilen Einsatz: Anlagendokumentation mit Windows 

und Android., PC&Industrie 10/2012, S. 52-53, 2012 

[4] Landgraf, E.: PLT-CAE-Systeme nachrüsten: optimal 

integriert dank maßgeschneiderter Schnittstellen Bei 

BASF arbeitet Prodok problemlos mit bereits vorhandenen 

Software-Systemen zusammen. atp edition - Automatisierungstechnische 

Praxis 53(12), S. 20 – 22, 2011 

[5] Still, W., Dubovy, M.: Umsetzung der NE 100 in der BASF, 

atp - Automatisierungstechnische Praxis 50(1), S. 38-43, 

2008 

[6] Dubovy, M.: Bewährte Partnerschaft. atp - Automatisierungstechnische 

Praxis 47(11), S. 28-30, 2005 

[7] Landgraf, E.: Elektronische Anlagendokumentation 

im Ex-Bereich: spart Zeit und Geld bei erhöhter Datenqualität. 

IEE 11/2012, S.148 – 150, 2012 

AUTOREN 

MICHAEL BRENDELBERGER 

(1961) studierte Elektrotechnik 

an der Universität 

Karlsruhe (TH). Seit 1989 ist 

er Mitarbeiter der BASF SE 

und leitet als Senior Engineering 

Manager PLT in der 

Projektplanung LU, Zentrale 

Services, eine Fachgruppe 

der PLT-Planung. In der Namur ist er Obmann 

des Arbeitskreises 1.3 Computer Aided Engineering 

(CAE). 

BASF SE, 

GTE/SB – B 014, D-67056 Ludwigshafen, 

Tel. +49 (0) 621 604 02 31, 

E-Mail: michael.brendelberger@basf.com 

MARTIN DUBOVY (1964) 

arbeitete nach seinem Eintritt 

im Jahr 1987 als Entwicklungsingenieur 

in der CAE- 

Systementwicklung. 1992 

übernahm er die Leitung 

dieser Abteilung. Heute leitet 

er als Prokurist den Geschäftsbereich 

Plant Solutions. 

Rösberg Engineering, 

D-76189 Karlsruhe, Tel. +49 (0) 721 950 18 23, 

E-Mail: martin.dubovy@roesberg.com 


1-2 / 2013 

37


Genauigkeit von Messgeräten 

überwachen 

Erkennen von Drifteffekten von Kanälen in Schutzeinrichtungen 

In komplexen Schutzeinrichtungen, bei denen mehrere Messsignale durch mathematische 

Berechnungen zu einem sicherheitsrelevanten Resultat verknüpft werden, können Messfehler 

das Resultat beträchtlich verfälschen. Bereits eine geringe Verschlechterung der Messunsicherheit 

muss daher zuverlässig erkannt werden. Es wurde eine Strategie entwickelt, um das Driften 

von Messsignalen in Schutzeinrichtungen durch Vergleich redundanter Kanäle automatisch 

zu detektieren. Als partial proof test zwischen Kalibrierungen werden die redundanten Kanäle 

gegeneinander geprüft. Dazu können in regelmäßigen Abständen die Differenzen der Kanäle 

bei ungestörten Testsituationen überwacht werden. Die Zuverlässigkeit dieser Methode zur 

Drifterkennung wurde durch eine Analyse der Fehlerwahrscheinlichkeit verifiziert. Zur Vereinfachung 

sollen normale Betriebsdaten anstelle definierter Testsituationen verwendet werden. 

Das erfordert eine hohe Qualität der zu vergleichenden Signale, was in der Praxis wegen Fluktuationen 

der Messsignale nicht ohne weitere Maßnahmen möglich ist. Daher wurde eine 

Methode zur Trendanalyse der Signale entwickelt. Dazu werden ein rekursives Tiefpassfilter 

und ein Differenzierer zur Vorverarbeitung der Signale verwendet, sodass sich die Methode in 

typischen sicherheitsgerichteten Steuerungen einfach online realisieren lässt. 

SCHLAGWÖRTER Schutzeinrichtungen / Messunsicherheit / Drifterkennung / rekursives Filter 

Inspection of the uncertainty of measurement instruments 

in safety instrumented systems 

Complex safety instrumented systems that determine a safety-relevant result based on mathematical 

calculations with many measurands may accumulate a significant uncertainty of the 

result. Therefore it is necessary to reliably detect even small deviations of the measurement 

uncertainty. To fulfill this demand, a strategy has been developed to automatically detect drifts 

that cause higher uncertainty by comparison of redundant channels. As a “partial proof test” 

between calibrations, the redundant channels are checked against each other. For this purpose, 

the difference of the channels can be monitored in regular time intervals using undisturbed 

test situations. The reliability of this method is verified by analyzing the probability of failure 

on demand. It is advantageous to use normal production data instead of defined test scenarios. 

However, this requires high quality of the compared signals, which is not met in practical 

applications because of signal fluctuations. Therefore a method for analyzing the trends of the 

signals is introduced. A recursive low pass filter and a differentiator for pre-processing of the 

signals are used so that the method can be realized online in typical safety PLCs easily. 

KEYWORDS safety instrumented systems / measurement uncertainty / drift inspection / 

recursive filter 

38 


1-2 / 2013

THOMAS HAUFF, WUSHAN LIANG, MATTHIAS STRAUSS, BASF Ludwigshafen 

CHRISTIAN BRECHER, MARKUS OBDENBUSCH, RWTH Aachen 

Die Sicherheitsmargen in typischen Schutzeinrichtungen, 

zum Beispiel Druck/Temperatur- 

Maximum-Abschaltungen, sind in aller Regel 

durch verfahrenstechnische Betrachtungen 

gegeben. Die sicherheitstechnisch erforderlichen 

Messgenauigkeiten sind meist gering gegenüber den 

tatsächlichen Messgenauigkeiten der Messkette. Fehler 

der Messkanäle lassen sich daher durch Vergleich der 

Signale redundanter Kanäle leicht erkennen. 

Schutzeinrichtungen, bei denen mehrere Messsignale 

durch mathematische Berechnungen zu einem 

sicherheitsrelevanten Resultat verknüpft werden [1], 

müssen genauer betrachtet werden. Die Auswirkungen 

der Messunsicherheiten der Kanäle auf das Resultat 

der Berechnungen (Fehlerfortpflanzung) müssen bei 

der Bestimmung der Sicherheitsmarge berücksichtigt 

werden und können eine relevante Größenordnung 

erreichen. Daher stellt sich die Frage, wie groß die 

sicherheitstechnisch zu berücksichtigenden Messunsicherheiten 

der Messkette sind und wie sich auch 

geringe Fehler der Messkette erkennen lassen. Prozessund 

einbaubedingte Fehlermöglichkeiten sind ebenfalls 

zu betrachten, was aber nicht Gegenstand dieses 

Beitrags ist. 

Im Neuzustand sollen die laut Herstellerangaben spezifizierten 

Messunsicherheiten von nahezu allen Geräten 

erfüllt werden, was durch Kalibrierungsprotokolle aus 

dem Produktionsvorgang der Geräte belegbar ist. Die 

Gültigkeit der Kalibrierung bestätigt die spezifizierte 

Messgenauigkeit. Die ist aber nur eine Momentangabe 

und unabhängig von den Anforderungen der IEC 61508 

zu sehen, da die Komponenten im produktiven Einsatz 

nicht unbedingt ihre Initialkalibrierung beibehalten. Im 

Worst-Case ist das Gerät mit der aus dem Proof-Test beziehungsweise 

Kalibrierungsintervall und der Mean 

Time To Fail (MTTF)) ableitbaren Wahrscheinlichkeit 

defekt. Die Safe Failure Fraction (SFF) drückt aus, ob der 

Fehler gefährlich ist. Der Diagnosegrad beschreibt, ob 

der Fehler erkennbar ist. Voraussetzung für solche Betrachtungen 

ist eine Failure Mode Effect and Detection 

Analysis (FMEDA) [2]. 

Wie aber wird ein Fehler, der keinen Totalausfall, 

sondern nur eine geringe Verschlechterung der Messgenauigkeit 

verursacht, definiert? Drifts stellen einen 

relevanten Teil dieser Fehler dar: Sie können aufgrund 

von sich langsam entwickelnden Messgüteveränderungen 

nach einer Kalibrierung auftreten und möglicherweise 

das Prozessrisiko verdecken [3]. Wird zum Beispiel 

erst eine Messunsicherheit von 2 % einer jeden 

Komponente der Messkette als Fehler definiert, dann 

ist die Fehlerwahrscheinlichkeit, die zur Probability of 

Failure on Demand (PFD), siehe Abschnitt 1.2, des 

Schutzsystems beiträgt, gering. In der gesamten Messkette 

mit typischerweise drei Komponenten (Messinstrument, 

Speisegerät und Analogeingangskarte einer Sicherheitssteuerung) 

addieren sich die Messunsicherheiten 

aber beträchtlich auf [2]. 

Wird bereits eine kleinere Abweichung als Fehler definiert, 

so steigt die Fehlerwahrscheinlichkeit an. Würde 

jede Abweichung von der für nicht sicherheitstechnische 

Anforderungen spezifizierten Genauigkeit bereits als 

Fehler im Sinne der IEC 61508 angesehen, so müssten 

bereits solche Abweichungen erkannt oder mit ausreichend 

hoher Wahrscheinlichkeit ausgeschlossen werden. 

Eine Fehlerart, bei der ein Gerät zwischen Kalibrierungen 

seine spezifizierte Genauigkeit verliert, müsste 

also ausgeschlossen oder detektiert werden. Nur dann 

ließen sich solche Genauigkeiten als Grundlage der Spezifikation 

von Schutzeinrichtungen verwenden. 

Bei einer MTTF von zum Beispiel 20 bis 50 Jahren und 

typischen Kalibrierintervallen im Jahresbereich kann 

durchaus eine beträchtliche Zahl von Geräten während 

des Betriebs defekt werden. Die Erkennung dieser Defekte 

ist jedoch nur aufgrund eines hohen Diagnosegrads 

der betreffenden Schutzeinrichtung möglich. Eine beispielsweise 

durch Alterungseffekte bedingte Drift ist 

aber aus Gerätesicht kaum erkennbar, denn es fehlt die 

Vergleichsgröße. Alterungseffekte, welche beispielsweise 

durch Qualitätsprobleme von Elektronikbauteilen 

oder andere Ursachen entstehen, sind aber nach Größe 

und Häufigkeit schwer vorhersagbar oder quantifizierbar. 

Betriebsbewährung bezieht sich eher auf Totalausfälle 


1-2 / 2013 

39


als auf Drift und ist bezüglich der Qualität von Elektronikbauteilen 

schwer extrapolierbar. Erhebliche Drift ist 

also ein Qualitätsproblem, darf aber keine Schutzeinrichtungen 

blockieren. Besonders bei nicht-diversitärer 

Ausführung redundanter Kanäle kann eine Drift zwischen 

zwei Kalibrierungszeitpunkten auch mehrere Kanäle 

betreffen. Ohne zusätzliche Maßnahmen lässt sich 

also nicht mit sicherheitstechnisch ausreichender Wahrscheinlichkeit 

ausschließen, dass für nicht-sicherheitsrelevante 

Anwendungen definierte Qualitätsangaben von 

Geräten wegen Defekten verletzt werden. 

Häufigere Kalibrierung und gegebenenfalls Justierung/ 

Reparatur erhöhen zwar einerseits den Diagnosegrad 

und verringern die Wahrscheinlichkeit einer unerkannten 

Drift, sind aber andererseits sehr aufwendig. Es stellt 

sich die Frage, ob es möglich ist, durch Teilprüfungen 

zwischen den Kalibrierungen zusätzliche Diagnoseinformationen 

zu gewinnen. Eine solche Teilprüfung kann 

beispielweise folgendermaßen realisiert werden: 

Es wird direkt nach der Kalibrierung und anschließend 

einmal im Monat eine stabile, ungestörte Testsituation 

erzeugt. 

Die Messdaten der redundanten Kanäle werden aufgenommen. 

Die monatlichen Veränderungen der Differenzen der 

Messdaten der redundanten Kanäle seit der letzten 

Kalibrierung werden betrachtet. 

Veränderungen werden als Anzeichen für Drifteffekte 

in einem oder beiden Kanälen gewertet. 

Solche Zwischenprüfungen sind ebenfalls mit einem 

deutlichen Aufwand verbunden und umso wirkungsvoller, 

je häufiger sie erfolgen. Es zeigt sich, dass für einen 

ausreichenden Diagnosegrad der Fehlerart Drift relativ 

genaue Vergleiche erforderlich sind. Eine automatische 

Durchführung anhand aktueller Prozessdaten wäre daher 

wünschenswert. Dazu müssen aber sehr stabile und 

ungestörte Messdaten vorliegen, was typischerweise im 

normalen Produktionsablauf nicht der Fall ist. Jedoch 

besteht die Möglichkeit, mittels geeigneter Filter- und 

Erkennungsmethoden die Messsignale aufzubereiten [4]. 

Die hierzu verwendeten Methoden wurden so entworfen, 

dass sie in typischen sicherheitsgerichteten Steuerungen 

leicht als Online-Funktionen realisiert werden können. 

Die automatische Online-Durchführung der regelmäßigen 

Teilprüfungen mit hohem Diagnosegrad anhand 

entsprechend aufbereiteter Prozessdaten stellt damit 

eine Möglichkeit dar, um die Genauigkeit der Messkette 

sicherzustellen. 

1. BERECHNUNG DER FEHLERWAHRSCHEINLICHKEIT 

1.1 Vergleich der Messketten zwischen Kalibrierungen 

Hier wird als Beispiel eine besonders sensitive Messgröße 

verwendet: Es handelt sich um die Temperaturdifferenz 

im Kühlsystem eines Reaktors (Bild 1). Es existieren 

zwei Kanäle (T A,n und T B,n ), die jeweils den Temperaturunterschied 

zwischen Ein- und Ausgang des Kühlsystems/der 

Kühlflüssigkeit am n-ten Tag messen. Die Differenz 

dieser beiden Kanäle (T A,n - T B,n ) wird als Driftindex 

F n bezeichnet. Wir betrachten die Differenz zwischen 

dem Driftindex des ersten Tages (F 1 ) und dem 

Driftindex des n-ten Tages (F n ). Weicht F n um mehr als 

einen festgelegten Wert von F 1 ab, wurde durch diese 

Vergleichsstrategie eine Drift detektiert. 

Treten Messfehler in der Größe der spezifizierten Genauigkeit 

auf, entsteht durch die Drifteffekte ein gefährlicher 

Fehler, siehe Bild 2 linkes Diagramm. Die Vergleichsmethode 

muss einen Driftalarm auslösen, bevor 

ein gefährlicher Fehler entsteht. Im Beispiel dieser Arbeit 

wird ein Alarm gegeben, sobald F n um mehr als 20 % der 

spezifizierten Genauigkeit von F 1 abweicht. Dies geschieht 

jedoch nicht immer rechtzeitig. Wenn beispielsweise 

T A,n und T B,n in gleicher Richtung und mit ähnlicher 

Geschwindigkeit driften (Bild 2 rechtes Diagramm), 

kann ein gefährlicher Fehler unentdeckt bleiben. In Abschnitt 

1.2 wird auf die Wahrscheinlichkeit eines solchen 

Ereignisses näher eingegangen. 

Um diesen Vergleich mit der notwendigen Genauigkeit 

durchzuführen, können – wie bereits erwähnt – geeignete 

Testsituationen wie ein Nullpunktvergleich bei leerem 

Reaktor, konstanter Zulauftemperatur des Kühlwassers 

mit konstantem Durchfluss und abgeschalteter Temperaturregelung 

verwendet werden. 

1.2 Fehlerwahrscheinlichkeits-Analyse (PFD) 

Zunächst soll untersucht werden, ob durch solche Teilprüfungen 

Drifts mit einer hinreichend hohen Wahrscheinlichkeit 

detektiert werden können. Dabei wird die 

Fehlerwahrscheinlichkeit (PFD) als die Unverfügbarkeit 

der Schutzfunktionen einer Schutzeinrichtung, die zur 

Vermeidung von Gefahren für Mensch und Umwelt benötigt 

werden [5], definiert. Gemäß der Definition des 

Schutzlevels SIL 3 soll die PFD des Schutzsystems im low 

demand mode einen geringeren Wert als 10 -3 aufweisen. 

Zur Berechnung der PFD ist eine Modellvorstellung 

der Driftentwicklung der Messeinrichtungen zwischen 

zwei Proof-Tests (Kalibrierung) erforderlich. Die Drifts 

werden hier als linear in der Zeit angenommen. In einer 

stochastischen Simulation sind Startzeitpunkt und Steigung 

als durch eine Gaußverteilung gegeben angenommen. 

Wir gehen davon aus, dass die Kanalabweichungen 

lediglich durch die Drifts verursacht werden. Zur Vereinfachung 

nehmen wir außerdem an, dass der anfängliche 

Driftindex F 1 null beträgt. Nach der Definition in 

Abschnitt 1.1 gibt es einen Driftalarm zum Zeitpunkt t 1 , 

wenn der Absolutwert des Driftindexes F n (Differenz der 

beiden Kanäle) 20 % der spezifizierten Genauigkeit erreicht. 

Ein gefährlicher Fehler zum Zeitpunkt t 2 tritt auf, 

wenn die Kanalabweichung die spezifizierte Messgenauigkeit 

erreicht. Dabei wird der sicherheitstechnisch konservative 

Wert der redundanten Kanäle genommen, im 

Beispiel ist das der kleinere Wert. Konsequenterweise 

sind Drifts in die negative Richtung ungefährlich. Bild 2 

zeigt entdeckte beziehungsweise nicht entdeckte gefährliche 

Fehler einer Schutzfunktion. Nur wenn t 1 < t 2 , wird 

der Fehler rechtzeitig entdeckt. 

40 


1-2 / 2013

Edukt 

Produkt 

Reaktor 

Messkette A → T A,n Signal im Kanal A am n-tenTag 

Kühlsystem 

Messkette B → T B,n Signal im Kanal B am n-tenTag 

BILD 1: 

Reaktor und Kühlsystem 

Temperatur [K] 

Drift B Driftalarm 

spezifizierte Genauigkeit Driftalarm 

spezifizierte Genauigkeit Drift B 

Drift A entdeckter 

Drift A nicht entdeckter 

gefährlicher Fehler 

gefährlicher Fehler 

Zeit 

t 1 Zeit 

t 1 

t 2 


t 2 

BILD 2: 

Entdeckte und nicht entdeckte 

gefährliche Fehler 

Je mehr unentdeckte gefährliche Fehler während der 

PFD-Analyse auftauchen, desto höher ist die Fehlerwahrscheinlichkeit. 

Unentdeckte gefährliche Fehler 

werden hier als Zeitbereiche zwischen t 2 und t 1 mit t 2 < t 1 

verstanden (siehe Bild 2, rechtes Diagramm). In diesem 

Fall können Schutzeinrichtungen nicht die benötigten 

Schutzfunktionen ausführen, da sie die Gefahr nicht 

rechtzeitig erkennen. 

Zur Vereinfachung des Verifikationsprozesses nehmen 

wir in diesem Beitrag als Fehlermodell an, dass 

Drifts zufällig entstehen und, wie oben bereits erwähnt, 

ein lineares Verhalten zeigen. Während mit dieser Einschränkung 

das Prinzip dargestellt werden kann, sollte 

zur weiteren Ausarbeitung und Präzisierung der 

Fehlermodelle die Zusammenarbeit mit Herstellern 

gesucht werden. Monte-Carlo-Simulationen mit Parametern 

einer realen Schutzeinrichtung von relativ hoher 

spezifizierter Genauigkeit und diesem linearen 

Fehlermodell zeigen, dass eine Fehlerwahrscheinlichkeit 

kleiner als 10 -3 erreichbar ist. Es ist also hinreichend 

unwahrscheinlich, dass in einer redundanten 

Messeinrichtung beide Kanäle den akzeptablen Messfehler 

überschreiten, ohne dass vorher die Abweichung 

beider Kanäle zumindest 20 % dieses Werts erreicht. 

Vollkommen zeit- und wertgleiche Fehlerentwicklung 

redundanter Kanäle ist also hochgradig unwahrscheinlich. 

Als Ergebnis lässt sich festhalten, dass die Strategie 

der Drifterkennung zur Fehlerreduktion geeignet ist 

und mit dieser Strategie Schutzeinrichtungen den 

SIL 3-Standard erfüllen können. 

Neben dem Fehlermodell geht in diese Berechnungen 

auch das Kalibrierintervall ein. Je länger das Kalibrierintervall, 

desto größer die Wahrscheinlichkeit, dass ähnliche 

Drifteffekte der redundanten Kanäle zu unzulässigen 

Messfehlern führen, bevor ihre Abweichungen zu 

einem Driftalarm führen. Weiterhin steigt die Abhängigkeit 

der Detektionsrate von den Parametern des Fehlermodells, 

das heißt, mit zunehmendem Kalibrierintervall 

wird die Methode weniger robust. Umgekehrt bedeutet 

das, dass sich anhand dieser Betrachtungen ein geeignetes 

Kalibrierintervall in Abhängigkeit der geforderten 

Genauigkeit der Messeinrichtung bestimmen und begründen 

lässt. 

2. REALISIERUNG MITTELS PROZESSDATEN 

Es bleibt die Aufgabe, die so definierten Zwischenprüfungen 

anhand der Prozessdaten aus dem normalen 

Produktionsablauf durchzuführen. Dazu müssen die 

Messsignale aufbereitet werden. Insbesondere wird der 

Trend der Signale benötigt. Als Trend wird dabei die 

langfristige Entwicklung des Signals ohne zufällige 

oder betriebsbedingte Abweichungen angesehen. Solche 

betriebsbedingten Abweichungen redundanter Kanäle 

können beispielsweise durch den Einbauort in 

Verbindung mit dynamischen Effekten des Prozesses 

oder durch unterschiedliche Ansprechgeschwindigkeiten 

redundanter Messeinrichtungen auftreten. Diese 

sollen durch geeignete Maßnahmen (siehe Abschnitt 

2.1) entfernt werden, um Drifteffekte nicht zu überdecken. 

Unmittelbar nach der Kalibrierung sind die Abweichungen 

der Trends beider redundanter Kanäle 

durch die Differenzen der Kanäle gemäß Kalibrierungsprotokoll 

gegeben. Sind bis zur nächsten Kalibrierung 

keine Drifteffekte zu beobachten, so kann mit hoher 


1-2 / 2013 

41

10 

5 

0 

-5 

1- 0 

10 

5 

0 

-5 

1- 0 

10 

5 

0 

-5 

1- 0 

10 

5 

0 

-5 

1- 0 

20 0 400 600 800 1000 1200 

20 0 400 600 800 1000 1200 

20 0 400 600 800 1000 1200 

20 0 400 600 800 1000 1200 

5 

4 

3 

2 

1 

0 

-1 

-2 

-3 

-4 

5 

4 

3 

2 

1 

0 

-1 

-2 

-3 

-4 

0 1000 2000 3000 4000 5000 

5 

4 

3 

2 

1 

0 

-1 

-2 

-3 

-4 

0 1000 2000 3000 4000 5000 

5 

4 

3 

2 

1 

0 

-1 

-2 

-3 

-4 

0 1000 2000 3000 4000 5000 

5 

4 

3 

2 

1 

0 

-1 

-2 

-3 

-4 

5 

4 

3 

2 

1 

0 

-1 

-2 

-3 

-4 

0 1000 2000 3000 4000 5000 


Wahrscheinlichkeit angenommen werden, dass der Zustand 

der Geräte sich gegenüber dem Kalibrierungszeitpunkt 

nicht verändert hat. 

Bild 3 zeigt drei charakteristische Eigenschaften des 

Signals, die dies erforderlich machen. Das Signal und 

der Driftindex sind verrauscht und von starken dynamischen 

Effekten beeinflusst, vor allem während ungeeigneten 

Prozesszuständen (siehe Abschnitt 3.3). Weiterhin 

ist der Driftindex aufgrund von Schwankungen, die 

selbst dann auftreten, wenn die Signale in beiden Kanälen 

einen regulären Verlauf zeigen, nicht stationär. 

Schließlich ist die Spanne des Driftindexes so groß (einige 

Kelvin), dass es unmöglich ist, sehr kleine Änderungen 

(im mK-Bereich) genau genug zu entdecken. 

Daher ist es notwendig, die Signale aufzubereiten, um 

vergleichbare und sinnvolle Trends zu erhalten. Mit diesen 

Trends, welche eine schmalere Spanne und ein geringeres 

Rauschen aufweisen, kann der zuvor beschriebene 

Vergleich durchgeführt werden. 

2.1 Rekursive Filter und Differenzierer 

zur Signalaufbereitung 

Gleitende Mittelwertbildung ist eine typische Methode, 

um Fluktuationen aus Signalen zu entfernen und Trends 

zu ermitteln. Jedoch benötigt diese Methode relativ viel 

Speicher und Rechenleistung und ist in einer grafischen 

Programmierumgebung aufwendig zu implementieren, 

siehe Bild 4. Daher wird eine exponentiell gewichtende 

gleitende Mittelwertbildung verwendet, die durch ein 

rekursives Tiefpassfilter realisierbar ist. Ein Tiefpassfilter 

lässt tiefe Frequenzen passieren, filtert hohe Frequenzen 

aus oder schwächt sie ab [6] und kann dadurch den 

Trend vom Originalsignal trennen [7]. 

Rekursive Filter, wie in Bild 5 zu sehen, brauchen weniger 

Funktionsbausteine, weniger Rechenleistung und 

geringere Speicherkapazitäten im Vergleich zu gleitenden 

Mittelwertfiltern. Der in Bild 5 ebenfalls dargestellte Differenzierer 

wird in den folgenden Abschnitten benötigt. 


10 —— Signal des Kanals A 

—— Differenz der KanäleA und B + 4 K 

8 

6 

BILD 3: 

Beispiel des Signals des 

Kanals A (blau) und der 

Differenz der Kanäle A und 

B +4 Kelvin (grün) 

Berechnen der 

Standardabweichung σ N 

Standardabweichung 

σ N 

Trend 

ı 

2 

2 

Standardabweichung σ NS Rausch- 

Signal x 

Signal y i 

σ 2 

x i -x i-1 y 2 

N 

i TPF 1 

TPF 2 


σ NS 

4 

Ungenauigkeitdes Trends σ T 

2 

BILD 6: Berechnung des Trends und dessen Unsicherheit Berechnen der 

0 

-2 

2.214 2.215 2.216 2.217 2.218 2.219 2.22Zeit [s] 

x i -x i-1 

TPF 2 


σ N 

ı 

2 

2 

Standardabweichung σ N 


Signal x 

Signal y i 

σ 2 

y 2 

N 

i TPF 1 


σ NS 

Bild 3: Beispiel des Signals desKanals A (blau) und der Differenz der Kanäle A und B +4 K elvin (grün) 

Trend 

Ungenauigkeitdes Trends σ T 

BILD 6: Berechnung des Trends 

und dessen Unsicherheit 

BILD 6: Berechnung des Trends und dessen Unsicherheit 

BILD 4: Gleitendes Mittelwertfilter 


Signal x 

Signal y i,1 

1000 2000 3000 4000 0 5000 

Rausch- 

Signal y i,2 

HPF 

x i -x i-1 

TPF 2 

Standard - 

abweichung 

Berechnen der σ N,1 


σ N,1 

Konst.1 




Konst.2 

σ N,2 

σ NS,1 

σ NS,2 

Standard - 

abweichung 

σ NS 

Trend 

BILD 5: Rekursives Tiefpassfilter und Differenzierer 

42 


1-2 / 2013 

Standardabweichung σ 

Ungenauigkeit des Trends σ T 

Rauschσ 

N,1 

NS Standard - 

Signal x 

Signal y 

BILD 7: Erweiterung BILD 7: Erweiterung der Berechnung des i,1 

der Trends Berechnung 

und dessen Unsicherheit abweichung 


des Trends x i -x i-1 und dessen Unsicherheit 


Konst.1 σ NS,1 

0 1000 2000 3000 4000 5000 

Rausch- 


Signal y i,2 

HPF 



Konst.2 σ NS,2 

σ N,2 

TPF 2 

Trend 

Standard - 

abweichung 

σ NS

2 

2 

( y Y N) + ( ) 

2 

N , i 

= 

i 

1 

N , i 1 

Y N 

2.2 Zuverlässigkeit des Trendsignals 

Das Originalsignal des Driftindex enthält zwei Komponenten: 

das Trendsignal und das Rauschen. Zur 

Gewinnung des Trendsignals kann das Rauschen 

Y 

durch einen Tiefpassfilter vom Originalsignal abgetrennt 

werden. Vor der Nutzung für den Trendvergleich 

muss jedoch verifiziert werden, inwieweit das Y N 

Originalsignal durch das Trendsignal repräsentiert 

Y N 

wird. Hierzu muss die Genauigkeit des Trends berechnet 

werden. Diese ergibt sich aus der Rauschkomponente 

des Ursprungssignals. Lässt sich die Standardabweichung 

des Rauschens berechnen, kann auch die 

Genauigkeit des Trends (σ T ) ermittelt werden. Die Beziehung 

der beiden Ergebnisse ist durch die Rauschübertragungsfunktion 

des Tiefpassfilters gegeben (siehe 

Abschnitt 2.2.3). 

2.2.1 Standardabweichung der Rauschkomponente 

des Originalsignals σ NS 

Die Standardabweichung (σ NS ) der Rauschkomponente 

des Originalsignals kann durch Differenzierung, Berechnung 

der Standardabweichung des Resultats und Rückrechnung 

gemäß der Rauschübertragungsfunktion erfasst 

werden (Bild 6). 

Zunächst benutzen wir einen Differenzierer, um den 

Trend des Signals zu entfernen. Das Rauschsignal y i am 

Ausgang des Differenzierers hat ähnliche Eigenschaften 

wie die Rauschkomponente des Originals. Deswegen 

kann, nachdem die Standardabweichung σ N von y i berechnet 

wurde, die Standardabweichung (σ NS ) der 

Rauschkomponente abgeschätzt werden. 

Als Erweiterung können anstelle des Differenzierers 

oder zusätzlich auch ein oder mehrere Hochpassfilter 

verwendet werden (Bild 7). Ein Hochpassfilter in rekursiver 

Konstruktion lässt sich durch einen Differenzierer 

und ein Tiefpassfilter darstellen. Der Aufwand für eine 

Online-Realisierung ist damit gering. Ähnlich wie in [8] 

ist es dann möglich, durch Vergleich der rückgerechneten 

Standardabweichungen aus zwei Filtern verschiedener 

Übertragungsfunktionen abzuschätzen, ob das Rauschen 

des Originalsignals gaußverteilt ist, um weitere 

Analysen durchzuführen. 

2.2.2 Standardabweichung σ N des Rausch-Signals 

Die Berechnung der Standardabweichung des Rausch- 

Signals σ N erfolgt durch Quadrieren des Resultats (y i ) des 

Differenzierers und Aufaddieren in einem Tiefpassfilter 

TPF 1, das eine exponentiell gewichtete Summe bildet 

(Bild 6). Wie im R-Test [7] kann ein rekursives Tiefpassfilter 

genutzt werden, um die Standardabweichung einer 

Stichprobe zu berechnen (siehe Gleichung 1). 

2 

2 

( y Y N) + ( ) 

2 

N , i 

= 

i 

1 

N , i 1 

y i 

y 

Y N i 

N,i 

= 

(1) 

= Rausch-Signal nach Differenzierer/ 

Hochpassfilter 

y i 

Y N 

2 

= Mittelwert 2 des Rausch-Signals 

2 

2 

2 

2 

Nα , i 

= = Parameter des Tiefpassfilters TPF 1 

, 

= 

( y 

σ N,i 

( 

i 

Y N 

N i 

y 

) + 

i 

Y )( 1 

+ ( 1) N , i) 1 

N 

N , i 1 

y i = Standardabweichung des Rausch-Signals 

Y i 

N 

Y N = ist der Mittelwert des gefilterten Rauschsignals. Er 

N 

ist N,i sehr = klein und kann mit hinreichender Genauigkeit 

vernachlässigt werden. Es ist daher möglich, die Standardabweichung 

des Rauschsignals mit Gleichung (2) 

N,i 

zu berechnen. Der Ausgang des Tiefpassfilters TPF 1 

ist das Quadrat der Standardabweichung des Rausch- 

Signals 2 y 2 

2 

N , i 

= i . 

y 

i 

+ ( 1 ) 

N , i 1 

2 2 

2 

N , i 

= y 

i 

+ ( 1 ) 

N , i 1 (2) 

( ) 

2 

2 2 

N , i 

= y + 1 

2.2.3 Beziehungen i zwischen N , i σ1 

N , σ Ns und σ T 

Aus σ N kann so die Standardabweichung σ NS des Originalsignals 

berechnet werden und daraus die Unsicherheit 

σ T des Trends (siehe Bild 6). Die Beziehungen zwischen 

den drei Parametern ergeben sich aus den mathematischen 

Beschreibungen des Tiefpassfilters TPF 2 

und des Differenzierers und gegebenenfalls eines Hochpassfilters. 

Gleichung (3) zeigt die mathematische Beschreibung 

eines Tiefpassfilters. 

( 1 ) y 

1 

y 

i 

= xi 

+ 

i , y 0 = 0 ,(3) 

y i 

y i 

x i 

= Ausgang des Tiefpassfilters 

y 

ix= x 

i 

i = + ( Eingang 1 ) yi 

1des , y 0 Tiefpassfilters 

= 0


20 

i 


= xi 

+ ( 1 ) yi 

1 

y , y 0 = 0 

y i 

x i 

y i 

x 

i i 

y y 

= 

x 

Der in Bild 25 gezeigte Differenzierer kann durch Gleichung 

x (7) beschrieben werden. 

geforderten Genauigkeit der Messeinrichtung bestimmen 

und praxisgerecht begründen. 

Ist die Sensitivität der berechneten Größe gegenüber 

den Unsicherheiten der physikalischen Größen bekannt 

(zum Beispiel online berechenbar oder linear 

modellierbar), dann kann die Unsicherheit der 

berechneten Größe aus den Messunsicherheiten der 

physikalischen Größen bestimmt werden. Wenn 

die Unsicherheiten der physikalischen Größen aus 

den aktuellen Differenzen der Signale der redundanten 

Messketten abgeschätzt werden können, 

dann kann die Auswirkung von Drifteffekten auf 

die berechnete Größe online abgeschätzt werden. 

Prozess- und einbaubedingte Fehler können dazu 

führen, dass die beschriebene Methodik hohe Abweichungen 

anzeigt, die nicht durch Fehler der 

Messkette selbst verursacht werden. Daraus lassen 

sich gegebenenfalls Erkenntnisse über Messbedingungen 

gewinnen und Optimierungspotenzial 

ableiten. Im Rahmen der Inbetriebnahme 

kann eine derartige Analyse wertvolle Hinweise 

auf Realisierungsschwachstellen geben. 

REFERENZEN 

[1] Haase, S., Hablawetz, D., Hauff, T., Krauß, M., 


21.05.2012 


Lenhart, F.: Komplexe PLT-Schutzeinrichtungen, 

atp edition – Automatisierungstechnische Praxis 

54(1-2), S. 54-60, 2012 

[2] DIN EN 61508: Functional Safety of Electrical/ 

Electronic/Programmable Electronic Safety-Related 

Systems, 2011 

[3] Resso, M., Bogatine, E.: Signal Integrity Characterization 

Techniques. IEC, 2009 

[4] Anonym: Method for Supervising Measurement 

Instrumentation Devices, 2012, 

http://ip.com, IP.com number: IPCOM000218485D 

[5] DIN EN 61511-3: Functional Safety - Safety Instrumented 

Systems for the Process Industry Sector. Part 3: 

Guidance for the Determination of the Required Safety 

Integrity Levels, 2005 

[6] Wörn, H.: Echtzeitsysteme: Grundlagen, Funktionsweisen, 

Anwendungen. Springer, 2005 

[7] Cao, S.; Rhinehart, R.: An Efficient Method for Online 

Identification of Steady State. Journal of Process 

Control 5(6), S. 363-374, 1995 

[8] Bebar, M.: Regelgütebewertung in kontinuierlichen 

verfahrenstechnischen Anlagen anhand vorliegender 

Messreihen, Dissertation Ruhr-Universität Bochum, 

2005. http://www-brs.ub.ruhr-uni-bochum.de 

AUTOREN 

Prof. Dr.-Ing. CHRISTIAN BRECHER (geb. 1969) leitet seit 2004 den 

Lehrstuhl für Werkzeugmaschinen am WZL der RWTH Aachen 

und ist seit 2013 geschäftsführender Direktor des Werkzeugmaschinenlabors. 

Seine Forschungsgebiete umfassen die Bereiche 

Maschinentechnik, Steuerungstechnik und Getriebetechnik. 

RWTH Aachen, 

Werkzeugmaschinenlabor (WZL), 

Steinbachstr. 19, D-52074 Aachen, 

Tel. + 49 (0) 241 802 74 07, 

E-Mail: c.brecher@wzl.rwth-aachen.de 

Dr.-Ing. THOMAS HAUFF (geb. 1960) ist im Fachzentrum Automatisierungstechnik 

der BASF SE auf dem Arbeitsgebiet der 

Prozessleittechnik tätig. Themengebiete sind unter anderem 

Qualitätssicherung, technische Evaluierung und Consulting für 

Automatisierungslösungen. Er ist Obmann des Namur AK 2.11. 

BASF SE, 

D-67056 Ludwigshafen, Tel. +49 (0) 621 602 03 26, 

E-Mail: thomas.hauff@basf.com 

M. Sc. WUSHAN LIANG (geb. 1986) ist seit 2012 im Fachzentrum 

Automatisierungstechnik der BASF SE in Ludwigshafen tätig. 

Die vorliegende Arbeit basiert auf ihrer Masterarbeit, die bei 

BASF angefertigt und von der RWTH Aachen betreut wurde. 

Sie befasst sich mit der Implementierung modellbasierter Schutzkonzepte. 

BASF SE, 

D-67056 Ludwigshafen, Tel. + 49 (0) 621 607 32 44, 

E-Mail: wushan.liang@basf.com 

Dipl.-Ing. MARKUS OBDENBUSCH (geb. 1986) arbeitet seit 2011 

als wissenschaftlicher Mitarbeiter am Lehrstuhl für Werkzeugmaschinen 

der RWTH Aachen. Seine Forschungsgebiete umfassen 

die automatisierte Anlagendiagnose und Inbetriebnahme von 

Produktionsmaschinen im Maschinenbau. 

RWTH Aachen, 

Werkzeugmaschinenlabor (WZL), 

Steinbachstr. 19, D-52074 Aachen, 

Tel. + 49 (0) 241 802 82 36, 

E-Mail: m.obdenbusch@wzl.rwth-aachen.de 

Dipl.-Phys. MATTHIAS STRAUSS (geb. 1986) arbeitet auf den 

Gebieten der Überwachung sicherheitsrelevanter Messeinrichtungen 

und modellbasierte Schutzsysteme. 

BASF SE, 

D-67056 Ludwigshafen, 

Tel. +49 (0) 621 609 17 25, 

E-Mail: matthias.strauss@basf.com 


1-2 / 2013 

45


Integriertes Engineering – 

wann, wenn nicht jetzt! 

Notwendigkeit, Anforderungen und Ansätze 

Für die Planung und Betriebsbetreuung in der Prozessindustrie werden viele unterschiedliche 

Engineering-Systeme verwendet. Diese sind jeweils für Komponenten, Lebenszyklusphasen 

oder Gewerke spezialisiert, aber auch auf sie begrenzt. In Planungs- und Betriebsphase 

müssen Daten zwischen diesen Systemen transportiert werden. Dieser Beitrag 

schlägt vor, integrierte Engineering-Systeme zu verwenden. Zur Realisierung werden verschiedene 

Ansätze präsentiert. Ein Blick auf Konzepte wie Industrie 4.0 zeigt, dass diese 

Ansätze jetzt dringend fortentwickelt und in der Praxis implementiert werden müssen. 

SCHLAGWÖRTER Engineering-Systeme / Anlagen-Lebenszyklus / Integration / 

Schnittstellen 

Integrated Engineering – 

If not now, then when? 

Many different engineering systems are used for the engineering and maintenance in the 

process industries. These systems are specialized for components, certain phases of the 

plant life cycle and engineering discipline, and they are limited to these areas. During 

Engineering and Operation phase data has to be exchanged between these systems. This 

paper suggests to implement integrated engineering systems. Several realisation approaches 

are presented. A view on innovative concepts like Industry 4.0 shows that these approaches 

urgently need further development and implementation for practical application. 

KEYWORDS engineering systems / plant life cycle / integration / interfaces 

46 


1-2 / 2013

THOMAS TAUCHNITZ, Sanofi-Aventis Deutschland 

Während der Planung und Errichtung von 

Anlagen wird eine große Datenmenge erzeugt, 

es entsteht ein elektronisches Abbild 

der Anlage. Dieses Abbild wird während 

der Betriebsphase ständig fortgeschrieben 

und durch Projekte weiterentwickelt. Der 

Planungsaufwand verschlingt zehn bis fünfzehn Prozent 

des Anlagenwertes, und die Qualität der Daten hat einen 

großen Einfluss auf die Geschwindigkeit der Anlagenerrichtung 

und auf Qualität und Kosten der späteren Betriebsbetreuung. 

Zur Unterstützung der Planungs- und Betreuungsphase 

wird eine Vielzahl von Engineering-Systemen verwendet. 

Dieser Beitrag schlägt – auf Basis eines Vortrags auf 

der Namur-Hauptsitzung vom 9. November 2012 – vor, 

integrierte Engineering-Systeme zu verwenden. 

1. INTEGRIERTES ENGINEERING 

Für den Begriff Engineering gibt es ein enges und ein 

weites Verständnis: Im engeren Sinne bezeichnet Engineering 

– wie im Englischen – im Lebenszyklus von Anlagen 

die Planungsphase: Nach der Engineeringphase 

käme also die Errichtungs- und dann die Betriebsphase. 

Im weiten Verständnis bezeichnet Engineering sämtliche 

Prozesse zur Dokumentation von Anlagen während ihres 

gesamten Lebenszyklus von der Planung über die Betriebsphase 

bis zur Demontage. Wenn man von dem 

Engineering-Tool eines Prozessleitsystems spricht, wird 

dieses weitere Verständnis des Begriffs Engineering verwendet, 

welches auch diesem Beitrag zugrunde liegt. Es 

geht also um die Werkzeuge für die Dokumentation für 

den gesamten Lebenszyklus von Anlagen. 

Der Begriff Integration bezeichnet den Zusammenschluss 

von unabhängigen Einheiten zu einem übergeordneten 

Ganzen. Speziell geht es also um den Zusammenschluss 

unabhängiger Engineering-Werkzeuge zu 

einem Gesamt-Werkzeug. Die angestrebte Integration 

geht über Komponenten-, Lebenszyklus- und Gewerkegrenzen 

hinweg. 

1.1 Kernfragen 

Mit drei Fragen kann schnell bewertet werden, inwieweit 

in dem jeweiligen Bereich integriertes Engineering 

im Sinne dieses Beitrags verwendet wird: 

Wird für die Planung und Betreuung aller Systeme 

und Gewerke des Unternehmens nur ein einziges 

Engineering-Tool beziehungsweise ein zusammenhängendes 

Toolsystem eingesetzt? 

Werden die Daten der technischen Einrichtungen im 

gesamten Lebenszyklus nur einmalig eingegeben? 

Werden diese Daten durch das Engineering-Tool 

während des gesamten Anlagen-Lebenszyklus konsistent 

gehalten? 

In dem Maße, in dem diese Fragen bejaht werden können, 

ist bereits ein integriertes Engineering realisiert. Und 

umgekehrt: Je mehr unabhängige Systeme verwendet 

werden, in je mehr Systemen dieselben Daten manuell 

eingegeben und gepflegt werden müssen, je mehr organisatorischer 

und personeller Aufwand für die Datenkonsistenz 

betrieben werden muss, desto weiter ist man von 

der Realisierung des integrierten Engineerings entfernt. 

2. HERAUSFORDERUNGEN 

Warum ist das integrierte Engineering noch nicht realisiert 

und wie komplex ist diese Aufgabe? Wenn man über 

integriertes Engineering spricht, ist zunächst der sinnvolle 

Umfang der Integration zu definieren. Welche Komponenten, 

welche Lebenszyklusphasen, welche Gewerke 

sollen mit dem integrierten Werkzeug geplant und in der 

Betriebsphase dokumentiert werden? 

2.1 PLT-Systemlandschaft 

Im ersten Schritt wird die Systemlandschaft im Bereich 

der Prozessleittechnik (PLT) betrachtet. Feldgeräte müssen 


1-2 / 2013 

47


Engineering- 

Werkzeug 

mit Konfi-Daten 

ERP 

BDIS 

Produkt.- 

Planungs- 

System 

Energie- 

Managem.- 

Sytem 

Zeit 

Datentransfer 

Datenkonsolidierung 

Datenkontrolle 

Fehlerfolgen 

(SCADA) 

PLS 

(SPS) 

Sicherheits- 

SPS 

Feld geräte- 

Parametr. 

Adv. 

Proc. 

Contr. 

manueller Transfer 

ist Fehlerquelle 

Datentransfer 

Datenkonsolidierung 

Datenkontrolle 

Fehlerfolgen 

Feldgerät 

Qualität 

Kosten 

Globaler Wettbewerb 

BILD 1: Systemlandschaft der Prozessleittechnik mit 

dem jeweiligen spezialisierten Engineering-Werkzeug 

BILD 2: Das Magische Dreieck des Projektmanagements 

mit globalem Wettbewerbsdruck 

parametriert werden. Prozessleitsysteme (PLS) benötigen 

ebenso ein Engineering-Tool wie Sicherheits-SPSen 

(SSPS) oder Systeme für Advanced Process Control 

(APC). Darüber kommen Betriebsdaten-Informationssysteme 

(BDIS), Produktionsplanungssysteme (PPS) und 

Energiemanagementsysteme, darüber schließlich das 

Enterprise Resource Planning System (ERP). Jedes dieser 

Systeme hat ein spezialisiertes Engineering-Werkzeug, 

in dem die Funktionen definiert und konfiguriert werden 

(siehe Bild 1). 

Wenn diese Engineering-Werkzeuge nicht integriert 

sind, muss jede Änderung in ihnen von Hand parallel 

konfiguriert werden. Für ein zusätzliches Feldgerät müssen 

die Geräteparameter, die Verschaltung im PLS und 

in der Sicherheits-SPS, die Anzeige im PLS, die Datenarchivierung 

im BDIS und gegebenenfalls die Auswertung 

im Energiemanagementsystem eingegeben werden, 

und in jedem System häufig die gleichen Daten: PLT- 

Stellen-Bezeichnung, Kurz- und Langtext, Messbereich 

und ähnliches. Nur durch Perfektion und Kontrollen 

kann dabei die Datenkonsistenz sichergestellt werden. 

2.2 Lebenszyklus 

In allen Phasen der Planung und der Betriebsbetreuung 

werden Daten erzeugt und geändert. Die Planung kann 

in verschiedene Phasen unterteilt werden: Konzeptplanung, 

Basic Engineering, Detail Engineering, Errichtung 

und Inbetriebnahme. Jede Planungsphase verwendet 

Daten der vorherliegenden Phasen und detailliert sie 

weiter. Nur, wenn die Daten der früheren Phasen in einem 

integrierten elektronischen System zur Verfügung 

stehen, können sie für die späteren Phasen verwendet 

werden, ohne zusätzlichen Aufwand für den Transfer 

und die Qualitätssicherung zu erfordern. Die Planungsphasen 

sind aber nur in der Theorie aufeinander folgend 

und einmalig. In aller Regel werden verschiedene Phasen 

parallel bearbeitet, und es gibt ständig Änderungen, die 

sich auf die vorhergehende Phase auswirken. Jede dieser 

Umplanungen erfordert wiederum Datentransfers. 

Im Übergang von der Planungs- zur Betriebsphase werden 

Planungsdaten benötigt, um beispielsweise die Wartung 

und Inspektion zu planen. Umgekehrt müssen die 

bei der Inbetriebnahme erzeugten Parametersätze und 

Betriebspunkte in die As-Built-Dokumentation eingepflegt 

werden. 

Während der eigentlichen Betriebsphase entstehen nur 

Daten zur Dokumentation von Wartungs- und Inspektions-Maßnahmen, 

aber das in der Planung erzeugte 

elektronische Anlagenabbild wird für Dokumentation 

und Fehlerbehebung benötigt, es muss also immer aktuell 

und konsistent zur Verfügung stehen. Und es wird 

benötigt, wenn es im Rahmen der Instandhaltung oder 

als separates Projekt Verbesserungen oder Erweiterungen 

gibt. Am Ende des Anlagenlebens dienen die Unterlagen 

zur Demontageplanung und zur Dokumentation, die über 

die Anlagenlebensdauer hinaus aufbewahrt werden 

muss. Die Anforderung an ein integriertes Engineering 

gilt also für den gesamten Lebenszyklus von prozesstechnischen 

Anlagen. 

2.3 Gewerke 

Im Abschnitt 2.1 wurden die Komponenten der PLT- 

Systemlandschaft genannt und deutlich gemacht, wie 

aufwendig das Engineering in all diesen unabhängigen 

Engineering-Werkzeugen ist. Nun stellt die Prozessleittechnik 

aber nur ein Drittel oder Viertel der Anlage 

48 


1-2 / 2013

dar. Auch der Prozess, die Apparate, die Rohrleitungen, 

die Aufstellung, die Versorgungstrassen müssen 

geplant werden, sowie der Bau der Gebäude und der 

Stahlbau für die Apparate. Hierfür gibt es eigene spezialisierte 

Engineering-Werkzeuge. Und wieder werden 

Daten erzeugt und gepflegt, die auch für andere 

Gewerke und Komponenten notwendig sind: Die Prozessauslegung 

legt die Rohrdurchmesser fest, und für 

die Rohrleitungsplanung benötigt man wiederum die 

Abmessungen der Feldgeräte. Die Apparatebezeichnungen 

werden für die Fließbilder des PLS benötigt 

und die Prozessbeschreibungen für die Ablaufketten 

im PLS. 

Wer ein integriertes Engineering anstrebt, muss also 

auch auf die Integration zwischen den verschiedenen 

Gewerken achten. Und es wird deutlich, dass die Werkzeuge 

der Prozessindustrie noch einen weiten Weg vor 

sich haben, bis alle drei Kernfragen zum Engineering 

(siehe Abschnitt 1.1) positiv beantwortet werden können. 

3. ANFORDERUNGEN 

Einen eingängigen Ausdruck für die durch die verschiedenen 

Engineering-Werkzeuge für Komponenten, Lebenszyklus-Phasen 

und Gewerke entstehende Engineering-Landschaft 

hat Biffl geprägt: Er spricht vom Engineering-Polynesien 

[1]. Im Folgenden werden Anforderungen 

an die Integration von solchen Engineering-Inseln 

diskutiert. 

3.1 Datentransport 

Zwischen den Engineering-Systemen – bildlich: den 

Engineering-Inseln – ist ein Datenaustausch erforderlich. 

Und zwar nicht einmalig, sondern immer wieder und 

häufig sogar in beide Richtungen. Im Bild: Es müssen 

Boote zwischen den Inseln hin- und herfahren und Daten 

transportieren, und zwar nicht kleine Schnellboote, sondern 

große Fähren mit Tausenden von Daten. In der realen 

Welt können die Daten per Telefon übertragen werden 

nach dem Motto: „An die PLT: Wir haben den Durchmesser 

der Rohrleitung xyz von DN50 auf DN80 geändert. 

Bitte ändert euren Durchflussmesser F1234“. Noch häufiger 

wird der Austausch per Tabellenkalkulations-Blatt 

sein: „An die PLT: Anbei erhalten Sie Version 15 der 

nochmals überarbeiteten PLT-Stellen-Bezeichnungen.“ 

Der Empfänger dieser Tabelle muss dann aus den Hunderten 

Zeilen die Änderungen heraussuchen und in seine 

Systeme eingeben. 

3.2 Magisches Projektdreieck 

Im Projektmanagement wird vom magischen Dreieck 

gesprochen, das aus Zeit, Qualität und Kosten besteht. 

Die Projektleitung ist dafür verantwortlich, das Projekt 

im vorgegebenen Budget, in den Terminen und mit 

dem vorgegebenen Umfang sowie in hoher Qualität 

abzuschließen. Der oben beschriebene Datentransport 

ist Teil des Projektaufwands und wirkt sich auf alle 

drei Kenngrößen aus: 

Datenexport und -import, die Konsolidierung von bestehenden 

und geänderten Daten, die Qualitätskontrolle 

der Daten und die Identifikation und Beseitigung von 

Fehlern kosten Zeit und verlängern die Projektdauer. 

Die gleichen Aktivitäten erhöhen auch die Projektkosten. 

Einerseits direkt als letztlich unproduktive Ingenieurstunden, 

andererseits auch indirekt durch Fehlerbeseitigung, 

Nachbesserungen, Dokumentenrevisionen 

und ähnliches. 

Jeder manuelle Transfer und jeder manuelle Abgleich 

von Daten ist – wie jede menschliche Arbeit – eine Fehlerquelle. 

Fehler können große Probleme bei der Inbetriebnahme 

bis hin zu Nachbesserungsprojekten schaffen. 

Um Fehler zu minimieren, müssen umfangreiche 

Qualitätssicherungsmaßnahmen wie beispielsweise das 

Vier-Augen-Prinzip eingesetzt werden. 

Der steigende wirtschaftliche Druck im globalen Wettbewerb 

erzwingt eine Verkleinerung des magischen Dreiecks, 

siehe Bild 2: Die Projektlaufzeit muss minimiert 

werden, die Kosten verringert – eine hohe Qualität wird 

trotzdem erwartet. Ein integriertes Engineering kann 

einen guten Beitrag in diesem Umfeld leisten. Selbst falls 

Werkzeuge für das integrierte Engineering teurer sind 

– der Wegfall des manuellen Datentransfers wird mindestens 

im gleichen Maß Kosten einsparen. Und die eingesparte 

Zeit sowie die Fehlervermeidung, durch die 

zusätzlich auch das Projektrisiko sinkt, sind große und 

vielleicht ausschlaggebende Vorteile des integrierten 

Engineerings. 

3.3 Schnittstellen 

Die Namur-Empfehlung NE 139 Informationsschnittstellen 

in der Prozessautomatisierung – Betriebliche Eigenschaften 

[2] zielt zwar auf Echtzeit-Schnittstellen für 

Prozessdaten, enthält aber einen Katalog von Anforderungen, 

die sich leicht auf die Schnittstellen für das integrierte 

Engineering übertragen lassen. 

Integrität: Keine ungewollten Veränderungen während 

der Datenübertragung; Security-Eigenschaften 

Nachhaltigkeit: Langjährige Pflege, Erweiterung und 

Modernisierung des Systems, unter anderem durch 

Aufwärtskompatibilität, hierarchische Strukturierung 

in unabhängige Layer- und Technologieunabhängigkeit 

Durchgängigkeit: Allgemeine Einsatzmöglichkeit 

über die Ebenen der Automatisierungspyramide 

(vgl. Abschnitt 2.1), Lebenszyklusphasen (vgl. Abschnitt 

2.2) und Gewerke (vgl. Abschnitt 2.3), unter 

anderem durch Konformität zu Standards und 

Marktverbreitung 

Handhabbarkeit: Einfache Planung, Wartung und 

Anwendung in der Praxis, unter anderem durch Installationsfreiheit, 

Projektierungsfreiheit und Plugand-play-Fähigkeit 

Betriebssicherheit: Beherrschung von Ausfällen und 

anderen Fehlern 


1-2 / 2013 

49


Eine weitere Anforderung ist, dass die Schnittstellen 

ein Management des Workflows ermöglichen müssen. 

Es muss eine klare Zuordnung der Daten zu Verantwortlichen 

(owner) geben, Änderungen müssen nachvollziehbar 

sein (wer hat wann was geändert?) und es 

müssen diverse Stati vergeben werden können (zum 

Beispiel freigegeben zum Detail Engineering oder as 

built). 

4. REALISIERUNGSANSÄTZE 

Zur Realisierung eines integrierten Engineerings gibt es 

zwei grundsätzliche Ansätze: 

Entweder Schnittstellen werden vermieden, indem 

man mit verschiedenen Werkzeugen oder Modulen 

auf derselben Datenbank arbeitet, 

oder es werden standardisierte Schnittstellen geschaffen, 

über die die verschiedenen Datenbanken 

der Werkzeuge Daten austauschen können. 

Vorteil des ersten Ansatzes ist, dass Schnittstellen gar 

nicht erst erforderlich sind. Die Integration leistet der 

Anbieter der Datenbank sowie der Module, die auf diese 

Datenbank zugreifen. Nachteil ist, dass man mit der 

Wahl der Datenbank auf die zugehörige Werkzeugsuite 

festgelegt ist. Wenn man zusätzliche Werkzeuge benötigt, 

sind diese wieder Inseln oder müssen individuell per 

Schnittstelle angedockt werden. 

Vorteil des zweiten Ansatzes ist, dass die standardisierten 

Schnittstellen eine grundsätzliche Offenheit 

ermöglichen, sodass man frei wählbare Engineering- 

Werkzeuge einsetzen kann – sofern sie den Schnittstellen-Standard 

verwenden. Nachteil ist, dass eine solche 

Standardisierung über alle Komponenten, Lebenszyklus-Phasen 

und Gewerke noch nicht vorhanden ist und 

einen hohen Aufwand erfordern wird. Außerdem müssen 

solche Standards über Jahrzehnte stabil oder aufwärtskompatibel 

sein, um die Anlagenlebensdauer 

abzudecken. 

Im Folgenden werden vier aktuelle Realisierungsansätze 

vorgestellt. Ein Anspruch auf Vollständigkeit wird 

nicht erhoben, der Autor ist dankbar für Hinweise auf 

andere Ideen. 

4.1 Werkzeugsuite mit zentraler Datenbank 

Das in Europa wohl am weitesten verbreitete Werkzeug 

mit zentraler Datenbank ist Comos von Siemens [3]. 

Basis ist eine relationale Datenbank mit einer objektorientierten 

Abstraktionsschicht, auf die verschiedene Module 

zugreifen. Diese Module decken die Prozessleittechnik 

und weite Teile der Verfahrenstechnik über den gesamten 

Lebenszyklus ab. Dadurch, dass alle Module auf 

dieselbe Datenbank zugreifen (siehe Bild 3), ist jederzeit 

die Konsistenz aller Daten gesichert. Wenn beispielsweise 

eine Messstelle umbenannt wird, ist sie im R&I-Schema, 

in der Messstellenliste, in der Ein-/Ausgangsliste des 

Prozessleitsystems und in den Stromlaufplänen geändert. 

Ein anderes Beispiel für ein Werkzeug mit zentraler 

Datenbank ist Cadison [4], das seinen Schwerpunkt mehr 

im Bereich der Verfahrenstechnik hat. 

4.2 Schnittstelle zwischen Comos und PCS 7 

Viele der für das PLS-Engineering erforderlichen Daten 

liegen durch die Feldplanung bereits vor: PLT-Stellen, 

Messbereiche und R&I-Fließbilder. Da liegt es nahe, die 

Softwareplanung für Prozessleitsysteme ebenfalls im 

PLT-Planungstool durchzuführen. Dieser Ansatz wurde 

in einem Pilotprojekt von Sanofi-Aventis Deutschland 

GmbH und Siemens AG verfolgt. Hierüber wurde bereits 

auf der Namur-Hauptsitzung 2011 in Bad Neuenahr berichtet 

(siehe Bild 4). Technische Basis ist der strukturierte 

Austausch der Daten über ein gemeinsames Datenmodell 

von Comos und PCS 7. 

Für die Software – speziell für Chargen-Produktion 

gemäß DIN EN 61512 – wurden in diesem Pilotprojekt 

folgende Objekte in Comos angelegt: 

Verriegelungspläne (Continuous Function Charts, 

CFCs) für Control Modules (Einzelsteuerebene). 

Die Funktionen wurden durch Sanofi-Aventis verbal 

beschrieben und von Siemens manuell für 

PCS 7 programmiert. In der Planung in Comos 

werden dann die Instanzen dieser Control-Module 

geplant und verdrahtet. Die Schnittstelle legt 

dann entsprechende Instanzen der Bausteine mit 

Verschaltungen und Verriegelung in PCS 7 an. 

Ablaufpläne (Sequential Function Charts, SFCs) für 

Equipment Modules. In diesen SFCs werden für jede 

Betriebsart die Abläufe der Equipment-Module neutral 

beschrieben. Der Compiler erzeugt die entsprechenden 

Equipment-Module in PCS 7. Wenn dann 

in Comos diese Equipment-Module für die konkrete 

Anlage instanziiert werden, legt die Schnittstelle 

entsprechende Instanzen dieser Equipment-Module 

in PCS 7 an. 

Zur Beschreibung der Equipment Module gehören 

nicht nur die Ablaufpläne, sondern auch noch Parameter. 

Im Prinzip wäre es möglich, auch die die Equipment- 

Module aufrufenden Rezepte in Comos zu planen 

und nach PCS 7 zu übertragen. Dies wurde im Pilotprojekt 

aber noch nicht realisiert. 

Die bisher im Pilotprojekt erstellten Schnittstellen-Funktionalitäten 

zwischen Comos und PCS 7 sind für den 

Bereich der Einzelsteuerebene bereits in den Produkten 

verfügbar und werden für die Equipment Module von 

Siemens demnächst als Marktprodukt freigegeben. 

4.3 NAMUR-DATENCONTAINER ZWISCHEN CAE UND PLS 

Die im vorigen Abschnitt beschriebene Schnittstelle 

zwischen Comos und PCS 7 ist naturgemäß herstellerspezifisch. 

Die Namur als Interessenverband aller PLT- 

Anwender arbeitet an Vorschlägen, eine solche Schnitt- 

50 


1-2 / 2013

stelle allgemeingültig zu beschreiben. Diese als Namur- 

Datencontainer bezeichnete Schnittstelle soll im Jahr 

2013 in einer Namur-Empfehlung veröffentlicht werden. 

Die Grundidee ist in Bild 5 dargestellt: Statt eine spezifische 

Schnittstelle von jedem CAE-System zu jedem 

Prozessleitsystem zu entwickeln, wird ein Namur-Datencontainer 

definiert, in den CAE-System und PLS Daten 

hineinschreiben und herauslesen können – wobei 

diese Schnittstelle auch bidirektional wirkt. Der Container 

selbst speichert keine Daten, sondern ermöglicht nur 

einen File-Transfer zwischen den Systemen. 

Die Herausforderung wird sein, diesen Container ausreichend 

detailliert zu beschreiben, damit die Schnittstellen 

zu CAE-Systemen und Prozessleitsystemen im 

Plug-and-play-Stil funktionieren. Andererseits muss 

diese Schnittstelle breite Akzeptanz finden (alle marktgängigen 

CAE-Systeme und PLS) und über Jahrzehnte 

hinaus unterstützt werden. 

4.4 Automation Service Bus 

BILD 3: Comos von Siemens als Beispiel 

eines CAE-Systems mit zentraler Datenbank 

Comos von Siemens 

Die bisher genannten Realisierungsansätze basieren entweder 

auf einer gemeinsamen Datenbank oder beziehen 

sich konkret auf die Schnittstelle zwischen CAE und 

PLS. Der Automation Service Bus zielt auf das Bereitstellen 

einer offenen Plattform zur Integration von heterogenen 

Software-Werkzeugen für die Entwicklung von Automatisierungssystemen 

[1]. An diese Plattform können 

verschiedene, spezifische Werkzeuge angeschlossen 

werden. Eine Engineering Data Base und eine Engineering 

Knowledge Base speichern die gemeinsam verwendeten 

Daten auf Projektebene. Bild 6 stellt die Grundstruktur 

des Automation Service Bus dar. 

Produktion 

Verfahrens-Ing. 

PLT-Ing. 

Comos PCS 7 

Compiler 

Betrieb 

5. RISIKEN UND CHANCEN 

Die Idee eines integrierten Engineerings ist nicht neu. 

Schon vor 20 Jahren gab es beispielsweise den Versuch, 

eine systemneutrale Konfiguration von Prozessleitsystemen 

zu entwickeln, die dann in jedes PLS hinuntergeladen 

werde könnte [5, 6]. Auch werden die Engineering- 

Tools mit zentralen objektorientierten Datenbanken und 

darauf zugreifende Werkzeuge seit mehr als zehn Jahren 

angeboten und ständig erweitert. Ein breit aufgestellter 

Entwurf für die Integration des Prozessentwurfs-, Engineering- 

und Betreuungsprozesses wurde bereits 2005 

veröffentlicht [7, 8]. Von einem integrierten Engineering, 

das die Herausforderungen von Abschnitt 2 und die Anforderungen 

von Abschnitt 3 erfüllt – und letztlich die 

eingangs gestellten Kernfragen bejaht – ist noch nicht 

viel zu sehen. 

5.1 Risiken für das integrierte Engineering 

Softwareplanung 

Softwareerstellung 

BILD 4: Schnittstelle zwischen Comos und PCS 7 

von Siemens für die Softwareerstellung 

Dieser Beitrag hat verdeutlicht, dass ein integriertes Engineering 

sinnvoll, der Weg dorthin jedoch nach wie vor 

herausfordernd ist. Die Breite der abzudeckenden Komponenten, 

Lebenszyklen und Gewerke, die Anforderungen 

und die relative Begrenztheit der Realisierungsansätze 

zeigen, wie groß die Aufgabe ist. Und der Blick auf 

andere Schnittstellen-Standardisierungen wie beispielsweise 

beim Feldbus zeigt, dass hier eine zähe gemeinsame 

Anstrengung vieler Beteiligter erforderlich ist, deren 

Interessen sich durchaus unterscheiden: 

Unmittelbarer Nutznießer eines integrierten Engineerings 

sind die Betreiberfirmen: Projekte sind billiger, 

schneller und besser (siehe Abschnitt 3.2), der Übergang 

von der Planungs- zur Betriebsphase erfordert keinen 

Dokumentationsaufwand und Obsoleszenzprobleme 

der Systeme (vergleiche [9]) lassen sich durch die geforderte 

Aufwärtskompatibilität beherrschen. Aber: Wer 

in den Betreiberfirmen kann und wird bei einem solchen 

Entwicklungsprojekt mitarbeiten? Die einzelnen 

Betriebe sicher nicht, die In-house-Engineering-Abteilungen 

wohl schon, aber nur, wenn dafür Entwick- 


1-2 / 2013 

51


Mapping 

Mapping 

Mapping 

Mapping 

Mapping 

BILD 5: „Namur-Datencontainer“ zwischen CAE-Systemen 

und Prozessleitsystemen. Quelle: Namur-Arbeitskreis 1.10 

Tablett-PC 

BILD 7: Anwendungsfall für Industrie 4.0 für den 

Austausch eines Ventils (Quelle: www.samson.de) 

BILD 6: Grundlegende Elemente einer 

Software-Werkzeugintegration mit dem 

Automation Service Bus. Quelle: [1] 

lungsgelder vom Konzern zur Verfügung gestellt werden. 

Einzelne Projekte werden den Entwicklungsaufwand 

nicht tragen können. 

Die Interessen von Engineering-Dienstleistern sind 

schon nicht mehr so eindeutig. Einerseits erlauben effiziente 

Entwicklungswerkzeuge eine günstige Projektabwicklung, 

aber offene Standards stehen auch den Mitbewerbern 

zur Verfügung und könnten Know-how-Vorsprünge 

relativieren. Und: Zumindest kurzfristig gesehen 

kann man auch mit dem Verkauf von Ingenieurstunden 

für Datentransfers Geld verdienen. 

Die Anbieter von CAE-Werkzeugen versuchen traditionell, 

möglichst viele Anwendungen im eigenen Haus 

anzubieten, sie tendieren also eher zu Systemen mit zentraler 

Datenbank (siehe Abschnitt 4.1). Eine Offenheit 

ermöglicht zwar die Ankopplung von spezialisierten 

Fremd-Engineering-Systemen, ist aber keine Einbahnstraße 

und ermöglicht auch anderen Anbietern, das eigene 

Werkzeug als Subsystem anzubinden. 

Die Anbieter von Systemen der Prozessleittechnik wie 

PLS, BDIS wollen durch auf ihre Systeme spezialisierte 

Engineering-Tools Vorteile vor den Mitbewerbern gewinnen: 

Wenn man PLS mitunter als Commodities bezeichnet, 

kann man durch effiziente Engineering-Tools punkten. 

Wie groß ist dann das Interesse, das PLS-Engineering 

einfach durch Compilierung der aus einem CAE-Werkzeug 

heruntergeladenen Funktionsplanung zu erzeugen? 

Bleiben die Verbände. Die Namur als Interessengemeinschaft 

Automatisierungstechnik der Prozessindustrie 

steht auf Seiten der Betreiber und treibt daher schon 

seit Jahren Elemente des integrierten Engineerings voran. 

Eigene Ressourcen für ein großes Entwicklungsprojekt 

hat sie jedoch nicht und hängt insofern vom Engagement 

ihrer Mitgliedsfirmen ab. Die VDI/VDE-Gesellschaft 

Mess- und Automatisierungstechnik (GMA) verbindet 

Hersteller, Betreiber und Universitäten und wäre daher 

ein mächtiger und willkommener Partner. 

Die Diskussion in den kommenden Monaten wird zeigen, 

welche Interessengruppen mit welchen Ressourcen 

das integrierte Engineering voranbringen. 

5.2 Motivation Industrie 4.0 

In Deutschland wird aktuell viel gesprochen von der 

vierten industriellen Revolution, kurz als Industrie 4.0 

bezeichnet [10]. Dieses Internet der Dinge und Dienste 

und die Cyber-Physical Production Systems streben eine 

Vernetzung von Prozessen, Produkten und Dienstleistungen 

an. Die Durchgängigkeit des Engineerings über 

den gesamten Lebenszyklus [10] wird dabei als kennzeichnendes 

Merkmal dieser Strategie bezeichnet. Im 

Folgenden sei ein einfacher Anwendungsfall von Industrie 

4.0 durchgespielt (siehe auch Bild 7): 

52 


1-2 / 2013

Ein Ventil fällt aus. 

Der Schichthandwerker holt aus dem Lager ein Ventil. 

Der Handwerker verbindet die CPU des Ventils 

drahtlos mit seinem Tablett-PC. 

Das Ventil fragt die PLT-Stellennummer ab, die es 

einnehmen soll. 

Das Ventil fragt die Spezifikation des technischen 

Platzes ab, vergleicht sie mit den eigenen Daten (Anschluss, 

Werkstoffe, Elektronik) und bestätigt, dass 

es zum Ersatz geeignet ist. 

Das Ventil übernimmt die Parameter des Vorgängers 

aus dem Feldgeräte-Engineering-System. 

Das Ventil lädt aus dem Internet die aktuelle Feldbusversion 

und parametriert sich entsprechend. 

Das Ventil führt einen Selbsttest durch und meldet: 

„alles ok“. 

Die Einbauanleitung wird von der Homepage des 

Herstellers auf den Tablett-PC geladen und die Liste 

der erforderlichen Werkzeuge wird angezeigt. 

Das Formular für die Kalibrierung wird gedruckt. 

Der Ersatz wird im W+I-System dokumentiert. 

Der Ingenieur erhält eine Mail und prüft Reparatur 

des alten Ventils oder Ersatzbeschaffung. 

Ein solcher, im Moment noch nach Science-Fiction klingender 

Anwendungsfall macht deutlich: Ohne ein 

durchgängiges, während der Anlagenlebensdauer zur 

Verfügung stehendes, eben integriertes Engineering 

wird Industrie 4.0 in der Prozessindustrie nicht realisierbar 

sein. 

6. ZUSAMMENFASSUNG UND AUSBLICK 

Dieser Beitrag ist ein Plädoyer für die Realisierung eines 

integrierten Engineerings. Dieser Begriff wird dabei 

relativ weit verstanden und auf die gesamte Planung 

und Dokumentation von Prozessanlagen bezogen. Die 

Integration soll alle Komponenten, alle Lebenszyklusphasen 

sowie alle Gewerke umfassen. Anforderungen 

an eine solche Integration wurden dargestellt und einzelne 

Realisierungsansätze vorgestellt. An einem Anwendungsfall 

gemäß der Methodik von Industrie 4.0 

wurde deutlich gezeigt, dass hierfür eine Integration 

der Engineering-Inseln zwingend erforderlich ist. 

Die Idee von Integration und Schnittstellen im Bereich 

von Prozessanlagen ist nicht neu. Es wird deutlich: Der 

Aufwand dafür ist hoch, viel Standardisierungsarbeit 

muss geleistet werden. Aber der Druck hin zu einer höheren 

Wirtschaftlichkeit erzwingt den Übergang vom 

manuellen zum industrialisierten Engineering-Prozess. 

Und die datentechnischen Grundlagen sind mit Schnittstellen 

wie XML und AutomationML gegeben. Es bleibt 

die Aussage: „Integriertes Engineering – wann, wenn 

nicht jetzt!“ 


03.01.2013 


AUTOR 

Dr.-Ing. THOMAS TAUCHNITZ 

(geb. 1957) studierte in 

Hannover Elektrotechnik 

und promovierte im Bereich 

der Regelungstechnik. Bei 

Sanofi-Aventis Deutschland 

leitet er die Engineering- 

Gruppe der Abteilung 

Technologie der Site Frankfurt 

Pharma. Er ist Vorstandsmitglied der 

Namur. Arbeitsschwerpunkte sind Prozess- und 

Betriebsleitsysteme, der Feldbus sowie Engineering-Systeme. 

Sanofi-Aventis Deutschland GmbH, 

SFP – H600, D-65926 Frankfurt am Main, 

Tel. +49 (0) 69 305 41 94, 

E-Mail: Thomas.Tauchnitz@Sanofi.com 

REFERENZEN 

[1] Biffl, S., Mordinyi, R., Moser, T.: Integriertes Engineering 

mit Automation Service Bus. atp edition – Automatisierungstechnische 

Praxis 54(12), S.36-43, 2012 

[2] NAMUR-Empfehlung NE 139 „Informationsschnittstellen 

in der Prozessautomatisierung – Betriebliche 

Eigenschaften“, März 2012. 

[3] Siemens: http://www.automation.siemens.com/mcms/ 

plant-engineering-software/de/Seiten/Default.aspx 

[4] it and factory: http://www.cadison.de/ 

[5] Kempny, H.-P., Maier, U.: Herstellerneutrale Konfigurierung 

von Prozessleitsystemen. atp - Automatisierungstechnische 

Praxis 32(11), S. 529-536, 1990 

[6] Scheiding, W.: Systemneutrale Konfiguration von 

Prozessleitsystemen. atp - Automatisierungstechnische 

Praxis 36(6), S. 55-61, 1994 

[7] Tauchnitz, T.: CIPE oder: Die Zeit ist reif für eine 

Integration des Prozessentwurfs- Engineering- und 

Betreuungs-Prozesses – Teil 1. atp – Automatisierungstechnische 

Praxis 47(10), S. 36-43, 2005 

[8] Tauchnitz, T.: CIPE oder: Die Zeit ist reif für eine 

Integration des Prozessentwurfs- Engineering- und 

Betreuungs-Prozesses – Teil 2. atp – Automatisierungstechnische 

Praxis 47(11), S. 56-63, 2005 

[9] NAMUR-Empfehlung NE 121 „Qualitätssicherung 

leittechnischer Systeme“, September 2008. 

[10] Umsetzungsempfehlungen für das Zukunftsprojekt 

Industrie 4.0 – Abschlussbericht des Arbeitskreises 

Industrie 4.0. Vorabversion, 02.10.2012. Herausgeber: 

Promotorengruppe Kommunikation der Forschungsunion 

Wirtschaft – Wissenschaft. 

www.forschungsunion.de 


1-2 / 2013 

53

Deutscher Industrieverlag GmbH | Arnulfstr. 124 | 80636 München

www.di-verlag.de 

Die neue Adresse für 

das Wissen der Industrie: 

Deutscher 

Industrieverlag 

Ein neues Kapitel beginnt: 

Aus Oldenbourg Industrieverlag wird Deutscher Industrieverlag 

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

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

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

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

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

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

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

Geschichte nahtlos mit der Zukunft. 

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

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

Namen Deutscher Industrieverlag Anspruch und Verpflichtung. 

WIssEn Für DIE 

ZuKunft

HAUPTBEITRAG 

Anforderungsprof il von 

Software wechseln 

Versagenswahrscheinlichkeit bei bekannter Betriebserfahrung 

Es ist möglich, aus der Erfahrung, die für Software mit der Abarbeitung bestimmter Anforderungen 

in betrieblichen Umgebungen vorliegt, auf deren späteres Versagensverhalten 

in anders gearteten Einsätzen zu schließen. Hierbei spielen die Pfade, in denen die Software 

abläuft, eine entscheidende Rolle. Sie bilden mit den Häufigkeiten ihrer Abläufe das 

jeweilige Anforderungsprofil. Sind das alte und das neue Anforderungsprofil bekannt, 

lässt sich auf die Versagenseigenschaften in der neuen Umgebung schließen. Die Schlüsse 

können auch die Ungenauigkeiten in den Kenntnissen der Profile berücksichtigen. 

Ungenauigkeiten über das neue Profil wiegen besonders schwer. Ist dieses aber genau 

bekannt und liegen entsprechend umfangreiche Betriebserfahrungen vor, lässt sich die 

Erfüllung auch hoher Zuverlässigkeits-Anforderungen zeigen. Ergänzende deterministische 

Verfikationsbemühungen sind immer nötig. 

SCHLAGWÖRTER Betriebserfahrung / Versagenswahrscheinlichkeit pro Anforderung / 

IEC 61508 / Pfadanalyse / Anforderungsprofilwechsel / Ungenauigkeiten 

Changing the demand profile of software – 

Failure probability and known operating experience 

From the eperience with software in a specific operation environment conclusions about 

its future behaviour in other environments can be drawn. In this regard the pathes that 

are executed play a decisive role. The frequencies of path traversals determine the demand 

profile. If both the old and the new demand profiles are known, the failure probabilities 

in the new environment can be derived. The conclusions can also consider inaccuracies 

in the knowledge of the demand profiles. Inaccuracies about the new profile weigh heavily. 

If this profile is well known, if other pre-requisites are fulfilled to the ideal way, and 

an extensive operating experience exists, it can be shown that even high reliability demands 

are met. Supplementary deterministic verification efforts are always required. 

KEYWORDS Operating experience / failure probability per demand / IEC 61508 / 

path analysis / change of demand profile / inaccuracies 

56 


1-2 / 2013

WOLFGANG EHRENBERGER, Hochschule Fulda 

Bei Wiederverwendung von Softwarekomponenten 

in neuer Umgebung kommt die Frage auf, 

mit welchen Versagenseigenschaften zu rechnen 

ist. Es geht um quantitative Aussagen, die 

sich aus Betriebserfahrung bekannter Art und 

Dauer herleiten lassen. Dabei wird angenommen, dass 

kein grundsätzlicher Unterschied zwischen durch Betriebserfahrung 

gesammelten Kenntnissen und durch 

Test oder Probebetrieb gewonnenen besteht; falls die 

jeweiligen Randbedingungen bekannt sind. 

Ausgangspunkt sind die Pfade durch ein Programm 

und deren Abläufe. Wir nehmen an, der jeweilige Pfad 

liefere einwandfreie Ergebnisse oder nicht, und dies sei 

nach jedem Ablauf beurteilbar. Bei nicht einwandfreien 

Ergebnissen sprechen wir von einem Versagen des jeweiligen 

Pfades und der zugehörigen Funktion. Die Betrachtungen 

sind keine reinen Blackbox-Betrachtungen: Es 

sind sogar recht genaue Kenntnisse über den Code der 

betroffenen Komponente erforderlich. Dieser Beitrag gibt 

einen probabilistischen Weg an, bei einfachen Software- 

Teilen, genauer Dokumentation alter Einsätze und klaren 

Vorstellungen über neue Einsätze das Einhalten von Anforderungen 

auch hoher Sicherheitsstufen (SILs) im Sinne 

der IEC 61508 [3] zu zeigen. Wird die zu beurteilende 

Software so umfangreich, dass sich ihre Pfade nicht 

mehr identifizieren lassen, sind mithilfe des Folgenden 

keine sinnvollen Aussagen möglich. 

Die Überlegungen sind hilfreich bei Software, die bereits 

lange Zeit zur besten Zufriedenheit ihrer Anwender 

gearbeitet hat, ohne einer formalen Verifikation unterzogen 

worden zu sein: etwa Software in Smart Sensors, 

CNC-Maschinensteuerungen, anderen Industrieausrüstungen 

oder sonstiger Software in eingebetteten Systemen. 

Interessant ist auch, ob, wann und wie aus dem 

konventionellen Bereich auf einen Sicherheitseinsatz 

geschlossen werden darf, also ob sich Verifikationskosten 

sparen lassen. Für hohe SILs kommt das Dargestellte 

in Betracht, falls die Software bereits für eine bestimmte 

Anwendung qualifiziert wurde, sie aber nun 

auch für eine andere verwendet werden soll, wie etwa 

in IEC 61508-3-Anhang D [3] vorgesehen. Das vorliegende 

Gebiet ist derzeit wichtig im Zusammenhang mit der 

Neufassung des Softwareteils der IEC 61508. 

Zunächst geht es hier um das in der Literatur Gefundene, 

dann um das Beurteilen monolithischer Programme. 

Die jeweils erforderlichen Randbedingungen werden 

genannt, obgleich sie in der Literatur, etwa bei [10], [11], 

[4], IEC 61508-7 [3] schon erwähnt worden sind. Behandelt 

werden nur Programme, die auf Anforderung arbeiten. 

Nicht behandelt wird Code, der gar nicht geschrieben 

wurde, wie etwa bei Ariane [12], sowie Fragen der 

Diversität, paralleler Prozesse oder von Zeitaspekten. 

1. IN DER LITERATUR VERTRETENE AUFFASSUNGEN 

Angesichts der Bedeutung der Schlussfolgerungen, die 

sich aus Betriebserfahrung ziehen oder nicht ziehen lassen, 

haben sich bereits mehrere Verfasser mit dem hier 

beschriebenen Sachverhalt befasst. Littlewood und Strigini 

[8] zitieren beifällig eine Auffassung der britischen 

Kernenergie-Genehmigungsbehörde, nach der es unmöglich 

sei, probabilistisch eine Versagenswahrscheinlichkeit 

von Software nachzuweisen, die kleiner ist als 10 -4 

pro Anforderung. Diese Auffassung betraf Reaktorschutzsysteme, 

die aufgabengemäß auf Anforderung arbeiten 

und nur selten angefordert werden. Die Meinung 

wurde nicht vertreten für häufig angeforderte Funktionen, 

etwa die Abspeicherfunktion eines Editors oder der 

computergesteuerten Startfunktion eines Pkws. 

Littewood [7] sowie Butler und Finelli [1] legen dar, 

dass sich niemals hohe Zuverlässigkeit von Software 

mithilfe probabilistischer Tests zeigen lasse. Sie gehen 

von einer reinen Blackbox-Betrachtung aus. Dem dort 

Ausgeführten wird gerne zugestimmt: Die mathematischen 

Grundlagen sind sorgfältig und korrekt wiedergegeben, 

ebenso die Schlüsse. Die folgenden Ausführungen 

stützen sich im Gegensatz dazu nicht auf eine reine 

Blackbox-Betrachtung, sondern nehmen bestimmte 

Kenntnisse über den Aufbau der jeweilige Software an: 

die Kenntnis ihrer Ablaufpfade. Soweit ich weiß, haben 

sich bisher nur wenige Informatiker mit dem inneren 


1-2 / 2013 

57

HAUPTBEITRAG 

Aufbau von probabilistisch zu beurteilender Software 

und den damit möglichen Schussfolgerungen beschäftigt. 

Zu diesen gehören Kuball, May, Hughes [6] und 

Söhnlein et al. [11]. Die von ihnen aufgeführten Einwände 

gegen die Möglichkeit des Nachweises hoher Zuverlässigkeiten 

per statistischem Test stützen sich in erster 

Linie auf die in praktischen Fällen unerreichbar hohe 

Anzahl erforderlicher Tests oder Testzeiten. 

Littlewood und Wright [9] stellen sehr gründlich dar, 

wie sich mithilfe statistischer Betrachtungen Zuverlässigkeitsaussagen 

von Software herleiten lassen Im Gegensatz 

zu diesem Beitrag betrachten sie auch den Fall, 

dass Versagensfälle aufgetreten sind. Besonders bemerkenswert 

ist in ihrem Aufsatz der Beweis der Äquivalenz 

Bayes‘scher und frequentistischer Ansätze. Ein solcher 

Nachweis findet sich auch in [11]. 

oberen Grenzwert, sein. Damit dies nachgewiesen 

werden kann, sind n Vorbetriebsfälle erforderlich. 

Dies führt zu: 

ln 

ln(1- ) a 

n = 

ln(1- ~ p) 

- ~ 

= p p~ ; p ln 

; (1) 

(1) n 

α heißt auch Signifikanzgrad. Die Formel (1) ist weithin 

bekannt. Ihr Beweis findet sich unter anderem in [8], [4] 

und [10]. Tabelle 1 enthält die Zusammenhänge nach (1) 

für die wichtigsten Aussagesicherheiten. 

Voraussetzung 7: Die Anforderungsbeschreibung 

(Funktionale Spezifikation) der zu beurteilenden Software 

ist vollständig, ausreichend detailliert und für alle 

Beteiligten unmissverständlich; und zwar für die Umgebung 

des Vorbetriebs und die neue Umgebung. 

2. VERSAGENSWAHRSCHEINLICHKEIT PRO ANFORDERUNG 

Zu beachten ist: Es gibt Versagensarten, die sich jeglicher 

probabilistischer Blackbox-Betrachtung entziehen. 

Wenn beispielsweise ein Programm für ein Verkehrsmittel 

enthält: 

Falls( (zukünftigesDatum == x) und (Zeit == y) ) 

verursache einen Unfall; 

sind auch riesige Anzahlen von Betriebsfällen der Vergangenheit 

wertlos. Hier hilft nur, sich den Code selbst 

anzusehen oder einen Überdeckungstest zu machen. 

Der Kürze wegen geht es im Weiteren stets um Vorbetrieb, 

auch wenn zugleich Testfälle, Probebetrieb oder 

Feldversuch gemeint sind. 

2.1 Monolithischer Fall und allgemeine Voraussetzungen 

Wir betrachten ein Programm, wie es Bild 1 darstellt. 

Voraussetzung 1: Reihenfolge und Anzahl der Aufrufe 

eines Programmteils haben keinen Einfluss auf das 

Ergebnis eines Einzelaufrufs (Unabhängigkeit der Wirkung 

der Abläufe voneinander). 

Voraussetzung 2: Während des Vorbetriebs kommt jede 

Eingangsdatenkombination mit der Wahrscheinlichkeit 

zum Zuge, mit der sie im schließlich zu beurteilenden 

Betrieb auftritt (Betriebstreue). 

Weiter unten wird behandelt werden, worauf zu schließen 

ist, wenn dies nicht gilt. 

Voraussetzung 3: Innerhalb der Vorgabe von Voraussetzung 

2 werden die einzelnen Eingabedatenkombinationen 

nach Zufallsgesichtspunkten unabhängig voneinander 

gewählt (Unabhängigkeit der Auswahl). 

Voraussetzung 4: Die Beobachtung des Vorbetriebs ist 

so gut, dass jedes Programm/Programmteil-Versagen bemerkt 

wird. 

Voraussetzung 5: Die Anzahl n der Vorbetriebs-Läufe 

ist groß, auch bei einfachen Systemen größer als 100. 

Voraussetzung 6: Es gibt keine Versagensfälle. 

Es werde verlangt: Mit der Aussagesicherheit β = 1 – α 

soll die Versagenswahrscheinlichkeit p ≤ , ihrem 

2.2 Pfade 

Das Folgende geht von den Pfaden durch ein Programm 

aus, so wie sie ein üblicher Kontrollfluss-Graph aufzeigt. 

Es gilt: 

Definition i: 

Ein Pfad besteht aus dem Code, der bei einem möglichen 

Ablauf eines Programms oder Programmteils durchlaufen 

wird; beginnend mit dessen Anfang, 

oder ab der Stelle, ab der alle vorher begonnenen Pfade 

zu Ende sind, bis zu seinem Ende, 

oder bis zu der Stelle, ab der alle bisher verarbeiteten 

Daten keine weitere Rolle spielen, 

oder ein neuer Pfad beginnt. 

Definition ii: 

Ein Pfad kann aus Pfad-Abschnitten bestehen (Bild 5). 

Ein Pfad an sich hat also keine Verzweigung; jede binäre 

Verzweigung verdoppelt vielmehr die Anzahl aller ohne 

sie bestehenden Pfade. Die Zahl der Pfade kann mit der 

Anzahl der Verzweigungen eines Programms exponentiell 

wachsen. 

Weiterhin wird fest gehalten: 

Voraussetzung 8: Die Pfade des zu beurteilenden Programms 

sind bekannt und etwaige Fehler können gefunden 

werden, wenn man seine Pfade ablaufen lässt. Jedes 

Programm oder Unterprogramm lässt sich somit grundsätzlich 

in der Form von Bild 2 darstellen. 

Die Äquivalenzklassen von Eingabedaten, von denen 

bei Testverfahren oft die Rede ist, lassen sich manchmal 

leicht auf die Pfade abbilden. Oft führt eine Äquivalenzklasse 

zu einem bestimmten Pfad oder Pfadabschnitt. 

Freilich lässt sich den Eingangsdaten eines Programms 

oft schlecht ansehen, welcher Äquivalenzklasse oder 

welchem Pfad sie zugehören. 

Das Anforderungsprofil eines Programms oder Unterprogramms 

wird mithilfe der alternativen Abläufe nach 

Bild 2 dargestellt. Für den Vorbetrieb ergibt sich folgende 

Rechnung: 

n 

i 

Anzahl der Abläufe des Pfades 

Für jeden Pfad gilt : 

~ 

p = 

i 

ln 

n 

i 

= 

i 

a 

n 

i 

(1a 

) 

(1a) 

58 


1-2 / 2013 

N 

n 

gesamte Anzahl aller Pfade 

= 

N 

n 

gesamte Anzahl aller Abläufe

Programm, 

Programmteil 

Bild Bild BILD 1: 1: 1: Programm oder oder Unterprogramm, von von links von links links 

Eingangsdaten erhaltend, nach nach rechts rechts die die die zugehörigen ni 

Anzahl 

Ergebnisse weitergebend. Ablauf 

Ablauf 

Datenbewegung 

Für jeden Pfad 

Bild 1: Programm oder Unterprogramm, von links 

Eingangsdaten erhaltend, nach rechts die zugehörigen 

Ergebnisse weitergebend. Ablauf 

Datenbewegung 

Pfad 1 

der Abläufe des Pfades i 

gilt : 

~ 

p = 

i 

ln 

n 

i 

= 

a 

n 

i 

Pfad 2 

(1a 

) 

Aussagesicherheit 

β 

Signifikanzgrad 

α 

0,999 0,001 6,9 6,9/p ~ 

0,99 0,01 4,6 4,6/p ~ 

0,95 0,05 3 3/p ~ 

0,90 0,1 2,3 2,3/p ~ 

0,63 0,37 1 1/p ~ 

a 

Somit gilt auch: 

TABELLE 1: Zusammenhang zwischen Aussagesicherheit 

Bild 2 

und Anzahl erforderlicher Vorbetriebsanforderungen, ~ a a 

pg 

= = 

falls unter idealen Bedingungen und bei n Anforderungen ng 

ng 

kein Versagensfall aufgetreten ist. 

ni 

Anzahl der Abläufe des Pfades i 

~ ln a 

Für jeden Pfad gilt : pi 

= = 

(1a 

) 

n n 

i 

i 

n 

N 

n 

g 

i 

1 = 


= 

N 

ni 

i= 

1 

ni 

= 

n 

g 

N 

i 

i= 

1 

= 

gesamte Anzahl aller Abläufe 

Pfad i 

relative Häufigkeit des Ablaufens des Pfades 

, weil die Pfade zueinander exklusiv Pfad ablaufen N 

i 

i 

= 

BILD 2: 2Exklusivität der einzelnen in 

ni 

ia 

a i 2 

einem = Programm = 

~ 

i pi 

ablaufenden Pfade, 

ning 

Auswahl, ni 

Flussdiagramm-Darstellung; 

die Verzweigung selbst sei fehlerfrei 

i 

N 

n 

g 

i 

1 = 


= 

N 

ni 

i= 

1 

ni 

= 

n 

N 

i= 

1 

g 

i 

= 

Somit gilt auch: 

~ a a i ni 

ia 

a i 2 

(2) 

p = = = = = 

~ 

g 

i pi 

n n n n n 

g 

gesamte Anzahl aller Abläufe 

relative Häufigkeit des Ablaufens des Pfades i 

, weil die Pfade zueinander exklusiv 

i 

g 

i 

g 

i 

2 

ablaufen 

Das Anforderungsprofil eines Programms charakterisiert 

die Gesamtheit der jeweiligen π i . Das zeigt, dass (2) 

nicht im Widerspruch zu (1) steht; es kommt bei der Gesamt-Versagens-Wahrscheinlichkeit 

p g nicht auf die Anzahl 

der Pfade an. Das lässt sich so veranschaulichen: 

Wenn es durch ein Programm mehrere Pfade gibt, verteilt 

sich der fiktive Versagensfall, der bei einem nur aus einem 

Pfad bestehenden Programm diesem einzigen Pfad zugeordnet 

ist, auf fiktive Teilversagensfälle der einzelnen 

Pfade, deren gewichtete Summe dann auf (2) führt. Eine 

Computersimulation mithilfe eines Zufallszahlengenerators 

bestätigt dies. 

mi 

ni 

mi 

p gv = = = i pi 

ng 

ng 

ni 

Gilt allerdings die Voraussetzung 6 nicht, gilt auch 

Formel (2) nicht; es ist vielmehr, wie die Theorie der 

geschichteten Stichproben, etwa wiedergegeben in [5], 

nahelegt: 

mi 

ni 

mi 

p gv = = = i pi(3) 

n 

(3) 

g ng 

ni 

p gv ist hierbei der Erwartungswert der Versagenswahrscheinlichkeit 

pro Anforderung des Programms, ohne 

Oberschranke, m i 

die Anzahl der Versagensfälle in Pfad 

i, π i und n g wie oben. 

(3) 

m 

p i 

i = , wie intuitiv zu vermuten. 

ni 

p i = 0 für versagensfreie Pfade, Summe wieder über 

alle Pfade. 

2.3 Änderung des Anforderungsprofils 

Falls sich die Anforderungen an ein Programm ändern, 

etwa weil es an anderer Stelle für andere Aufgaben eingesetzt 

p gwerden _ neu = soll, gilt 

~ 2 ~ 

i _ neu die pFormel i _ alt (2) sinngemäß; denn zu (4) 

ihrer Herleitung war keine Annahme über den Zeitpunkt 

der Programmabläufe erforderlich. Die 

~ ln 

p i _ haben max nach wie 

vor die im Vorbetrieb erhaltenen Werte, die π i ändern ni 

_ min 

= 

n 

i _ max_ neu 


1-2 / 2013 

n 

59 

ni 

ln 

i _ neu i _ max_ neu 

i _ min

HAUPTBEITRAG 

Bild 3 : 

sich aber aufgrund der neuen n i und des neuen n g . Die 2.4 Ungenaue Kenntnis der Pfadablauf-Zahlen 

Obergrenze 

~ 2 

p g _ neu = der Gesamt-Versagenswahrscheinlichkeit 

in der neuen Umgebung ergibt sich dann zu: Es kann sein, dass die Pfadablauf-Zahlen des Vorbetriebs 

~ 

i _ neu pi 

_ alt 

(4) 

und die des späteren Betriebs nur um δ 

~ 2 

p g _ neu = 

~ 

x ungenau bekannt 

i _ neu pi 

_ alt (4) ni 

Anzahl sind. (4) derEs Abläufe ist ratsam, des Pfades sich mit i den Wirkungen solcher Ungenauigkeiten 

auseinanderzusetzen, ähnlich wie mit der 

Dies gilt nur dann, wenn zutrifft: 

Ungenauigkeit ~ ln a 

Für jeden Pfad gilt : p physikalischer Messungen. Damit erhalten 

wir nach (1a) für nidie Versagenswahrscheinlichkeiten, 

ni 

fils lassen sich auf die N Pfade des alten Profils abbilden, die aus dem Betrieb ermittelt werden: 

i = = 

(1a 

) 

Voraussetzung 9: Alle Anforderungen des neuen Pro- 

die Abbildung wurde vorgenommen und die neuen N gesamte π i Anzahl ~ aller ln 

wurden ermittelt. 

~ p ln Pfade 

ln 

ln 

p i _ max 

= 

i _ max 

= 

ni 

_ min nn 

(5) 

i i _ i _ min n 

min 

i i _ min 

N 

Es ist ratsam, vorsichtig zu sein mit möglichen Versagens- 

oder Fehler-Maskierungen, siehe Bild 3. Falls sol- 

Wir nehmen ~ 

ln 

ng 

= ni 

gesamte Anzahl aller 

ln 

Abläufe 

i= 

1 

p beim neuen Profil für die π i das größtmögliche 

ln δ i und das kleinstmögliche n δ g an und schätzen: 

i _ max 

= 

che vorliegen, gilt (4) nicht mehr; ~ dann spielt lnmöglicher- 

weise auch die Reihenfolge 

p 

der i _ max Abläufe der Pfade eine 

n 

i _ min ni 

i _ min 

i 

(5) 

n 

neu 

n 

i = 

max_ 


i _ min n 

relative Häufigkeit des Ablaufens des Pfades i 

Rolle und nicht nur deren Anzahl. Eine visuelle Überprüfung 

des Codes sollte zeigen, dass kein solcher Ein- 

i _ max_ neu 

i _ max_ n i 

neu 

= i _ min = ni 

neu 

n 

g 

_ max_ 


ng 

_ min_ 

ng 

_ neu g _ min_ neu 

= = 

N 

n 

fluss vorliegt. 

g neu 

n2 

1 = 

_ min_ g _ neu g _ min_ neu 

i = i, 

weil n die Pfade zueinander 

i _ neu n exklusiv ablaufen 

i _ neu i _ max 2 

Eine besondere Gefahr besteht, falls im Ablauf des Programms 

eine Informationsreduktion stattfindet. 

i _ max_ nneu 

= = n n 

i= 

1 

ni 

_ max_ neu 

ni 

_ neu i _ max_ = neu* 

2 

i _ neu _ normal 2 

n 

g _ neu g _ min_ neu 

g _ neu 

i _ max_ neu 

n 

i _ neu 

ni 

_ neu i _ max 

i _ neu Somit i _ max_ giltneu 

auch: 

2 

ng 

_ min_ neu 

ng 


= * 

Falls die Programmstruktur i _ max_ neu 

= nach Bild 4 etwa = in einem 

2 

i _ neu _ norm 

Überwachungssystem enthalten nist, g _ min_ an dessen neu 

n 

n 

n 

Ende g _ neueine 

g neu 

g _ min_ 

einfache Oder-Entscheidung steht, zum Beispiel, dass 1 neu 

g _ neu g _ min_ 2 neu 2 _ 

~ a a i ni 

ian 

a i 

i _ 

= 

2 max_ 

i neu 

n 2 

p 

~ 

g = = = = _ = i _ neu i 

neu 

i pi 

_ max 2 

n 

= 

= * 

i neu normal 

aufgrund des einen oder des anderen Überwachungsergebnisses 

zu reagieren sei, mag das Ergebnis 2 von Pfadab- 

ni 

_ neu 

n g ng 

ning 

2 ni 

_ _ 

i _ neu i _ max 

g _ min_ neu 

1 n2 

n 

= * 

i _ neu _ normal 

n 

n 1 g _ neu g _ min_ neu 

g _ neu 


g _ neu 

i _ 

schnitt b oft unbeachtet bleiben, wenn fast immer gemäß 

= 

max_ neu 

Die drei letzten Gleichheiten = gelten, falls stets: 

Pfadabschnitt a reagiert wird und die Reaktion richtig g _ min_ neu 

1 

ist. Darauf hat meines Wissens zuerst Bishop [2] hingewiesen. 

1 = 

= 

1 i _ max_ neu 

i _ 

= 

max_ neu 

1 

= ~ 

g _ min_ 2 neu 

p g _ neu _ max = i _ neu _ max * p 

1 

i _ max 

g _ min_ neu 

Pfad 

Pfad 

~ 

2 

p Gemeinsam 

g = i _ neu _ max * p 

_ neu _ max 

Pfade, die über gemeinsame Daten verkoppelt sind 

i 

j 

benutzter 

Datenbereich 

BILD 3: Pfade, die über gemeinsame 

Daten verkoppelt sind 

( 

2 

* 

i _ max 


2 

ln 

( * 

~ 

p g _ neu _ max = 

p 

~ 

p g = 

p 

Pfad - 

Abschnitt _ neu 1 _ max 

mi 

p gv 2 

= ln = = 

) ( ng 

) ng 

ni 

n 

i 

i _ min_ alt 

2 

i _ neu _ normal ) ( ) 

n 

2 i i _ min_ alt 

i _ neu _ max * i _ max 

Pfad 2 

i _ neu 

- 

_ max * 

Pfad - 

Abschnitt 2 i _ max … 

2 

2 Abschnitt ln K 

( * i _ neu _ normal ) ( 

2 

2 ln 

( n * ) ( n 

i m~ 

… ln 

p i 

_ neu max _ normal 

i = i _) 

min_ alt 

i pni 

ni 

i_ min n 

i _ min_ alt (3) i 

BILD 5: Mehrere aufeinander folgende Pfadabschnitte, 

die jeweils zu gleichen Signifikanzgraden auf gleiche 

Bild 5 

ni 

neu 

n 

Versagenswahrscheinlichkeiten _ max_ 


i _ max_ neu 

= 

getestet worden 

= 

sind. 

Die Vorbetriebsanzahlen aller Abschnitte n sind 

g _ min_ neu 

n gleich. Die 


Versagensmöglichkeiten lassen sich zusammenfassen. 

n 

n 

n 

g _ neu 

i _ neu 

2 

g _ min_ neu 

i _ neu 

n 

) 

ln 

i _ min 

g _ neu 

2 

i _ max 

= 

2 

* 

Pfad-Abschnitt a 

Pfad-Abschnitt b 

Pfad-Abschnitt 

c, logisches 

Oder 

Δ 1,1 1,15 1 1,2 1,32 1,5 

i _ 

= 

max_ 2 3 5 

neu 

= 

Faktor 1,6 2 g _ 2,4 min_ neu5 7,51 

32 243 3125 

Bild 4 : 

BILD 4: Versagensmaskierung. Es kann sein, dass meistens 

nur die Ergebnisse von Pfadabschnitt a überprüft werden, 

und damit ein Versagen des Pfadabschnitts b unbemerkt 

bleibt oder nicht genügend oft überprüft wird. 

60 


1-2 / 2013 

TABELLE 2: Einfluss der Ungenauigkeiten der Kenntnis 

der verwendeten Ablaufzahlen auf das Endergebnis 

bei neuem Anforderungsprofil; Faktor der Vergrößerung 

von ~ 2 

p g _ neu zu = 

~ ~ 2 

p i 

neu p= 

i _ alt _ _ max * 

(4) 

g _ neu _ max nach (6). i neu pi 

_ max 

( 

2 

* 


2 

) ( 

n 

i 

ln 

i _ min_ alt 

)

i _ max_ neu 

= 

n 

i _ max_ neu 

g _ min_ neu 

= 

n 

i _ neu 

g _ neu 

i _ max_ neu 

g _ min_ neu 

n 

n 

g _ neu 

i _ neu 

2 

g _ min_ neu 

n 

i _ neu 

n 

g _ neu 

2 

i _ max 

= 

2 

* 


1 i _ max_ neu 

g _ min_ neu 

= 

1 

= 

a 

p k = pi 

ni 

Für den Neubetrieb erhalten wir mit (5): 

Kommen mehrere, den Voraussetzungen gemäß getestete 

~ 

2 

Pfadabschnitte hintereinander vor, dann sind deren einzelne 

Versagenswahrscheinlichkeiten pro Anforderung gemäß 

p g _ neu _ max = i _ neu _ max * pi 

_ max 

2 

2 ln 

Formel p g_verkettet_Pfad 1 beziehungsweise = p i, oder 1a zu ~ 

p gleichen a und ~ 

g _ verkettet _ Pfad = pi 

verifiziert 

worden, und die gesamte Anordnung hat (5a?) die Versa- 

~ 

( * i _ neu _ normal ) ( ) (5a) 

n ip g_verkettet_Pfad i _ min_ alt = p i, oder genswahrscheinlichkeit 

~ 

p 

= 

~ 

p 

p mit der Aussagesicherheit β. i 

Damit ist es möglich, den Einfluss der Ungenauigkeiten, 

die mit der Beobachtung der Vorbetriebsfälle und 

p g_verkettet_Pfad p = p i, oder ~ 

~ 

i pg 

_ verkettet _ Pfad = pi 

(7) 

der Abschätzung der Neubetriebsfälle verbunden psind, 

g_verkettet_Pfad = p i, oder ~ 

p 

~ 

g _ verkettet _ Pfad = pi 

zu berücksichtigen. Tabelle 2 gibt Beispiele. Es gilt: 2.6 Pfadabschnitte aus mehreren Anwendungen 

~ 2 

5 2 

p g _ neu _ max = ~ 

i _ neu _ max * pi 

_ max = * 

~ 

i _ neuWenn _ normalnicht * p (6) 

i _ alle normal Pfad-Versagenswahrscheinlichkeiten 

die gleiche Aussagesicherheit haben, sondern verschiedene, 

müssen ln(1- idiese ) 

~ 

5 2 

* p i _ max = * i _ neu _ normal * p 

i _ (6) 

= 

ln(1- nach j(1a) ) in die für das jeweils 

ins Auge gefasste - 

~ 

p System 

i - 

~ 

p festgelegte Aussagesicherheit 

j 

ln(1- i ) 

= 

ln(1- jumgerechnet ) 

werden. Da es auf die für den 

2.5 Mehrere aufeinander folgende Pfadabschnitte - 

~ 

p jeweiligen ~ 

i - p Pfad durchgeführte Anzahl von Testläufen 

j 

ankommt, gilt: 

ln(1- 

Werden mehrere Pfadabschnitte hintereinander zusammengefügt, 

etwa weil sie im Ablauf nacheinander fol- 

ln(1- - p 

~ 

i ) 

= 

ln(1- j ) 

~ 

i ) 

= 

ln(1i 

- j ) - p j 

(8) 

gend, ihre Ausgangsdaten jeweils an den folgenden - 

~ 

pi 

- 

~ 

p j 

übergeben, entsteht eine Verkettung, wie sie Bild 5 zeigt. 

Da ein Pfad ein möglicher Ablauf ist, geht er auch über Damit ergibt sich naturgemäß eine andere verifizierte 

Unterprogrammgrenzen hinweg. Die Aneinanderreihung Obergrenze für seine Versagenswahrscheinlichkeit. Ein 

der Pfad-Abschnitte ändert deren Versagenswahrscheinlichkeit 

Nachtest kann erforderlich sein, denn der gesamte Pfad 

nicht. Für jeden Abschnitt k des Pfades i gilt die versagt mit der Wahrscheinlichkeit, mit der sein schlech- 

Versagenswahrscheinlichkeit, die er aufgrund seiner Abtester 

Abschnitt versagt. 

= 2 ~ 

i _ neu _ max 

normal 

läufe hat, also p k = pi 

n a . Dies ist in Bild 5 mit den 

i 

Strichen unter den einzelnen Pfad-Abschnitten angedeutet. 

CoT21 

21 = 1/2 

n 21 

CoT11 

11 = 2/3 

n 11 

CoT22 

22 = 1/3 

n 22 

i _ max_ neu 

CoT12 

12 = 1/3 

n 12 

~ ln 

p i _ max 

= 

ni 

ni 

_ max_ neu 

n 23 

ng 

_ min_ neu 

ni 

_ neu 

BILD 6: Flussdiagramm-Darstellung. Unterprogramm, 

bestehend paus g_verkettet_Pfad fünf Codeteilen; 1 = p i, die i _ oder ~ 

max_ Ablaufhäufigkeiten 

neu 

= 

= pg 

_ verkettet _ 

nij jedes Codeteils wurden 

g _ min_ neugezählt. 1 Daraus ergaben 

verkettet_Pfad = psich i, oder die γ ij 

~ 

p= n ij /n g . Für die Obergrenze ~ 

g _ verkettet _ Pfad = p der Versagenswahrscheinlichkeit 

jedes Codeteils gilt gemäß (1a): 

a 

a 

i 

p 

~ a 

p 

11j 

j = mit a aus Tabelle 1. p 

~ a 

= 

p2 

2j 

j= = . . 

n1n 

1j 

j ~ 

nn 

2 22j 

j 

Für jede „Zeile“ gilt p g n_ 

neu gesamt _ max 

= i _ neu _ max * pi 

_ max 

= 

_ min 

CoT23 

23 = 1/6 

= 

2 

ng 


niZeile 

( 

2 

* 

ni 

ln 

ni 

_ neu i _ max_ neu 

ng 



i _ min 

2 

ni 

_ neu i _ max 

ng 

_ neu 

2 

) ( 

n 

ln 

= 

Pfad 

i i _ min_ alt 

) 

2 

* 

g _ verkettet _ Pfad 

~ 

i 

2.7 Verzweigungen und Schleifen, ergänzend erforderliche 

systematische Betrachtungen 

Verzweigungen und Schleifen können zu einer unübersehbar 

großen Zahl von Pfaden führen. Unübersehbar 

zahlreiche Pfade aber machen die vorgeschlagene Vorgehensweise 

unanwendbar, weil sich dann weder das alte, 

noch das neue Anforderungsprofil bestimmen lässt. Systematische 

Betrachtungen helfen dabei, die Verzweigungen 

herauszufiltern, die keinen Einfluss auf das Ergebnis 

(5) 

eines Programms haben und demnach nicht beachtet 

werden müssen. Im Allgemeinen ist, unabhängig von jeder 

probabilistischen Betrachtung, ein vollständiger 

Überdeckungstest nach mehreren der üblichen Kriterien 

erforderlich. Als minimal wird angesehen: Anweisungstest, 

Zweigtest, Test aller Prädikatenterme in logischen 

Ausdrücken, Crash-Test, Test aller Zeiger. 


3. BEISPIEL 

= Ein ~ 

p Unterprogramm bestehe aus den Codeteilen CoTij 

i 

gemäß Bild 6. 

3.1 Vorbetrieb 

Wird das Unterprogramm als ein Monolith betrachtet, 

so gilt gemäß (1) bei vorab ausgeführten n g = 30000 Betriebsfällen 

und a = 3 entsprechend einer Aussagesicher- 

(5a?) 

heit von 95 %: 

i ) 

= 

ln(1- 

- 

~ 

pi 

ln(1- 

- 

~ 

p j 

j ) 


1-2 / 2013 

61

HAUPTBEITRAG 

~ 

p i 

p g_verkettet_Pfad = p i, oder 

~ 

p 

~ 

p i 

p g_verkettet_Pfad = p i, oder 

= 

~ 

p 


i 

~ 

p 

~ 

p i 


= 

~ 

p 

i 

p k = 

pi 

a 

ni 

die dem Bild 6 entnehmbaren Pfade P1 bis P6 mit den 

in der Tabelle 3 angegebenen Ablaufhäufigkeiten ni verteilt. 

Die π i errechnen sich ln(1- zu n i /ni 

) 

g und = 

ln(1- die Einzel- j ) 

Pfad 

Ablaufzahl Ablaufhäufigkeit 

π i p ~ 

i zu 95% 

Obergrenze, 

Versagenswahrscheinlichkeiten ~ 

Code-Teile 

ln(1- i ) 

- p 

~ 

= 

ln(1- j ) 

i mit den -Obergren- 

zen - 

p 

P 

n j 

i 

~ 

pi 

gemäß (1a). - 

~ 

p j 

1 {CoT11,CoT21} 10 4 1/3 3*10 -4 

Mit den Zahlen der Tabelle 3 erhalten wir nach (1), (1a) 

~ 

und (2) auch 

p i 

2 {CoT11,CoT22} (2/3)*10 4 2/9 4,5*10 -4 

6 

~ 

4 2 ~ a 3 

p _ = 10 p 

g vor 

g_verkettet_Pfad = * = 

i p p 

i = i, oder ~ 

~ 

3 {CoT11,CoT23} (1/3)*10 4 1/9 9*10 -4 

6 = pg 

_ verkettet. . _ Pfad = pi 

(Formeln 

~ 

4 2n 

~ 30000 a 3 

p ~ a 

~ g _ vor = 

a 

p 

a 

p 

~ ~ 

i10 

= 1 = i * gpi 

= = . (F 

4 {CoT12,CoT21} (1/2)*10 4 1/6 6*10 -4 

a 

n 30000 

1 j = 1 j = 

i= 1 

g 

p 

p2 

j = . 

2 j = . 

5 {CoT12,CoT22} (1/3)*10 4 1/9 9*10n 

-4 

Sowohl die π i , als auch eventuell 6 die γ 

1 j 

n 

ij sind während 

~ 

42 

j 2 ~ a 3 

n 

des Vorbetriebs p 

1 j 

ng2 

_ j vor festzuhalten; = 10 = es gibt i * für pi 

den = allgemeinen = . (F 

6 {CoT12,CoT23} (1/6)*10 4 1/18 18*10 -4 

Fall kein einfaches Verfahren, die π i aus nden γ 30000 

i= 1 

g ij zu berechnen. 

~ a 

p 

~ 

6 

alle Alle 3*10 4 1 

1 j = 

~ a 

p2 

n 

~ 10 4 

j = a 

-4 

2 ~ a 3 

p g _ vor = 10. 

= 

p 

1 j 

1 j = 

i * pi 

= = 

n 

~ . a (Formelnummerie 

n 30000 

2 j i= 1 

g p2 

j = . 

n1 

j 

n 

TABELLE 3: Betriebserfahrung des Unterprogramms 

3.2 Neue Profile 2 j 

nach Bild 6 nach Pfaden (Vorbetrieb 

6 Falls in einem Betriebsfall ln(1- ein neues i ) 

= Anforderungsprofil 

ln(1- j ) 

~ 

4 2 ~ a 3 

p g _ vor = 10 = i * pi 

= vorliegt, = gibt . es neue π i , die (Formelnummerie 

- 

~ 

pi 

dagegen -bleiben ~ 

p j die alten 

n 30000 

i= 1 

g 

und nach (4) gilt beispielsweise: 

~ a 3 

1 betr 1 = 1/6 

~ 

4 

p 

1 

= 3*10 

-4 

1 betr 1 = 1/6 

~ p 

1 

= 3*10 

-4 

~ a p g _ vor3 

= = 4 = 10 

p g _ vor = = n 

. (Formelnummerierung?) 

= 10 30000 

n 

g . 2 betr 1 = 1/9 

~ 

(Formelnummerierung?) 

p 

2 = 4,5*10 

-4 

g 30000 

. 

2 betr 1 = 1/9 

~ p 

2 = 4,5*10 

-4 

3 betr 1 = 1/18 

~ p 

3 

= 9*10 

-4 

3 1/18 3 

9*10 1 betr 1 = 1/6 

~ p 

1 

= 3*10 

-4 

Die in Bild 6 eingetragenen Wahrscheinlichkeiten γ 

3 

ij 

4 

= = 10 geben 

. 

an, 

~ 

wie groß adie relative 3 (Formelnummerierung?) 

Häufigkeit 

4 

des Ablaufs 4 betr 1 = 1/3 

~ p 

4 = 6*10 

-4 

4 betr 1/3 4 

6*10 

-4 

1 betr 1 = 1/6 ~ p 

1 

= 3*10 

-4 

2 betr 1 = 1/9 

~ p 

2 = 4,5*10 

-4 

30000 eines der p gCodeteile _ vor = im = Vorbetrieb = 10 

2 1 

n 

= 1/9 war. ~ . Zunächst gelte, 

(Formelnummerierung?) 

30000 p 

die CoT2j seien unabhängig g 

5 betr 1 = 2/9 

~ p 

5 

= 9*10 

-4 

6 

5 betr 2/9 5 

-4 

2 = 4,5*10 

-4 

3 betr 1 = 1/18 

~ p 6 

3 

= 9*10 

-4 

~ 

2 

von den CoT1j zum Zuge 

p ~ 

2 ~ 

gekommen und es seien keine Variablenwerte von einem 6 betr 1 = 1/9 

~ g _ betr1p = i _ betr1 * p = 1,5* ~ 

i 

p 

6 = 18*10 

-4 

6 betr 1/9 g _ betr1 

= i _ betr1 * pi 

= 1 

3 betr 1 = 1/18 ~ p 

3 

= 9*10 

-4 

i= 

16 

6 

18*10 

-4 

4 betr 1 = 1/3 

~ p 

4 = 6*10 

-4 

i= 

16 

~ 

2 

der CoT1j weitergegeben worden. Man hätte also das Unterprogramm 

an der Stelle der zweiten Verzweigung 

i= 

i= 

1 

p 

~ 

2 ~ 

g _ betr 2 = i _ betr2 * p = 4, 

~ 

4 betr 1 1/3 4 

6*10 

-4 

p g _ betr 2 = i _ betr2 i 

* pi5 

5 betr 1 = 2/9 

~ p 

5 betr 1 2/9 5 

= 9*10 

-4 

6 

1 betr 1 = 1/6 ~ p 

1 

= 3*10 

-4 

~ 

2 

5 

9*10 

-4 

6 

p 

~ 

~ 

2 

4 

auseinanderschneiden, beide Zeilen getrennt ablaufen p 

~ 

lassen können und damit 6 betr keinen 1 1/9 g _ betr1 

= i _ betr1 * p = 1,5* 10 

6 betr 1 = 1/9 

~ g _ betr1 


= 1 

Einfluss 6 

auf 18*10 

-4 

p 

6 = i 18*10 

-4 

2 betr 1 = 1/9 ~ p 

2 = 4,5*10 

-4 

i= 

16 

i= 

16 

~ 

2 

sein Versagensverhalten 

ausgelöst. 

~ 

2 

1 betr 2 = 11/100 

~ p 

1 

3*10 

-4 

1 betr 2 = 11/100 

~ ~ 

4 

p 

~ 

p g _ betr 2 = i _ betr2 p = * p 

1 3*10 = 4,5* -4 10 g _ betr 2 = i _ betr2 * pi 

3 betr 1 = 1/18 ~ p 

3 

= 9*10 

-4 

In einem zweiten Betriebsfall i sei das Anforderungsprofil 

in anderer 

i= 

1 

i= 

1 

Es habe insgesamt n 4 g Vorbetriebsfälle 1 = 1/3 ~ p 

4gegeben. = 6*10 

-4 

Mit einem 

a aus Tabelle 1 und den γ ij aus Bild 6 gilt dann gemäß 2 betr 2 = 1/100 2 betr 2 = ~ Weise 

p 1/100 

~ 

2 = 4,5*10 p -4 

2 = 4,5*10 

geändert: -4 

5 betr 1 = 2/9 ~ p 

5 

= 9*10 

-4 

6 

~ 

2 

(2) bezüglich jeder der beiden „Zeilen“ dieses Bildes für 

3 betr 2 = 60/100 

3 60/100 ~ p = 

den Vorbetrieb: 

3 9*10 -4 

3 9*10 1 betr 2 11/100 1 

3*10 

-4 

1 betr 2 = 11/100 

~ p 

1 

= 3*10 

-4 

4 

p 

~ 

6 betr 1 = 1/9 ~ g _ betr1 


= 1,5* 10 

p 

6 = 18*10 

-4 

i= 

16 

2 

2 

3 

3 

~ 2 a 2 

a 

4 betr 2 3~ 

4 ~ betr 2 = 2/100 

~ 

3 

p a2/100 2 ~ ~ 

~ a p g _ vor = 2 = a 1 j * 2 

* 

* 

~ = 

1 j * p1 

j = 2pI 

= a 2 j * 

4 

6*10 4 

-4 6*10 

-4 

2 betr 2 = 1/100 ~ p 

2 = 4,5*10 

-4 

~ 

2 

2 betr 2 = 1/100 

~ p 

2 = 4,5*10 

-4 4 

p 

~ 

g _ betr 2 = i _ betr2 * pi 

= 4,5* 10 

i= 

1 

6 

2 

p * 

* 

~ = 

2 j * p2 

j = pII 

; 

6 

g _ vor = = 1 j ng 

1 j n1 

p1 

j 

I 

2 j 

2 j 2 p2 

II ; 

ng 

n j 1 j 

n 

= 

j = 1 

5 betr 2 = 

j 1 1 j 

n j = 10 ~ ~ 

2 ~ 

5 betr p 

0 ~ 

2 ~ 

5j 

= j = 9*10 5 -4 

-4 

3 betr 2 = 60/100 ~ p = 

p 

p 

1 

g _ betr 2 = _ betr 2 = 3 9*10 

-4 

3 betr 2 = 60/100 

~ p 

3 

= 9*10 

-4 

g i 

i _ betr2 *_ betr2 p 

* 

i = 4, 

p 

5 

i = 1 

i 

= 

j = 

4 betr 2 2/100 4 

j = 6*10 

-4 

1 

j j = 1 

i = 1 (Formelnum 

6 betr 26/100 (Formelnummerierung? 

2 

3 

3 

a 

2 

* 

~ ~ 2 2 

2 

~ 

= 1~ 

j p1 

j = p~ ~ 

6 betr 2 = 26/100 

~ p 

6 = 18*10 

6 

-4 18*10 

-4 

4 betr 2 = 2/100 

~ 

6 

5 betr 2 0 ~ 

2 

p 

4 = 6*10 

-4 

1 betr 2 = 11/100 ~ p ~ 

4 

6 

1 

= 3*10 

-4 

5 

9*10 

-4 p g _ betr 2 = i _ betr2 * pi 

= 4,5* 

10 

5 betr 2 = 0 

~ ~ 

2 ~ 

2 

3 

3 i = 1 p 

5 

= 9*10 

-4 p _ betr 2 = g i _ betr2 * p 

2 betr 2 = 1/100 ~ p 

a 

~ 4 * ; 

~ ~ pI 

2 j2 

a6 betr 2 26/100 

g _ ~ vor = pI 

4= 

pII 

2 2 

j 

. 

2 j = ~ pII 

2 a 

2 

~ 

n p * 

1 j g _ vor = = 1 j 

* 

* 

* ; 

j = 1 pg 

_ vor = pI 

= pj 

II 

= 1 = 10 . 

2 j = 1 j 

6 

18*10 

-4 

i = 1 

i 

2 = 4,5*10 

-4 

1 j = pI 

= 2 j 6 betr 2 = 26/100 

~ 

2 j p p6 

2 = j = 18*10 

-4 

3 betr 2 = 60/100 ~ p 

3 

= 9*10 

-4 

pII 

ng 

n1 

j = 1 

j 1 j 

n 

= 

j = 1 

j = 1 2 j j = 1 

4 betr 2 = 2/100 ~ p (Formelnummerierung?) 

4 = 6*10 

-4 

6 

das ergibt mit den obigen und den in Bild 6 angegebenen 

(Formelnummerie 

Zahlen: 

5 betr 2 = 0 ~ ~ 

2 ~ 

4 

p 

5 

= 9*10 

-4 p g _ betr 2 = i _ betr2 * pi 

= 4,5* 

10 

~ 

p g _ betr1 

> 

~ 

p ges _ vor 

~ 

=10 4 p i = 1 

 

. 

6 betr 2 = 

~ ~ ~ 4 

26/100 ~ p 

g _ betr1 

> 

~ 

p 

6 = 18*10 

-4 ges _ vor 

~ 

p g _ betr1 

> 

~ 

~ 

p ges _ vor 

pg 

_ vor = pI 

= pII 

= 10 . 

~ 

 

Wie 

p 

ersichtlich, 

> ~ 

g _ betr2 

p gilt gessowohl _ vor p g _ betr1 

> 

~ 

~ 

p ges _ vor als 

p > ~ 

~ 

g _ betr2 

p 

auch p g _ betr2 

> ~ 

ges _ vor 

p ges _ vor; und dies bei gleichbleibender 

Anforderungszahl, ~ p g _ betr2 

> ~ 

Hängen dagegen die Berechnungen der zweiten Zeile 

p ges _ vor allein aufgrund der Änderung 

~ 

von denen der ersten ab, weil sie Ergebniswerte von ihr des Anforderungsprofils. p 

~ 

g _ betr2 

p 

~ 

ist sogar größer als 

~ 

verwenden, muss das Unterprogramm als Ganzes betrachtet 

werden mit nicht mehr 2 beziehungsweise 3 

8 ~ 

p 

~ 

g8 

_ betr2 

p 

~ I + pII 

~ 

p 

~ I + p 

g _ betr2 

p 

~ I + pII 

, obgleich beide Zeilen von Bild 6 die gleiche II 

p 

~ 

g _ betr2 

p 

~ 

Anforderungsanzahl erhalten haben, wie im Vorbetrieb! 

I + pII 

getrennten Pfaden, sondern 6, mit den entsprechenden 

Ablaufhäufigkeiten und Versagenswahrscheinlichkeiten. 

Die gesammelte Betriebserfahrung habe sich auf trachten sei, lässt sich aufgrund der Kenntnis des 

Die Frage, wie das Unterprogramm von außen zu be- 

Un- 

62 


1-2 / 2013 

8 

8

vor 

~ 

p g _ betr1 

> 

~ 

p ges _ vor 

~ 

p g _ betr2 

p I pII 

~ p g _ betr2 

> ~ 

p ges _ vor 

~ + 

~ 

terprogramms allein nicht beantworten. Die Antwort 

hängt vielmehr davon ab, wie es in das oder die 

aufrufende(n) Programm(e) eingebettet ist. Wird es etwa 

an 5 anderen Stellen aufgerufen und da jeweils in 4 

verschiedenen Pfaden, so sind insgesamt 5*4*6 = 120 

Pfade zu betrachten. 

3.3 Berücksichtigung von Ungenauigkeiten 

Die Darlegungen des Beitrags können unter den angegebenen 

Voraussetzungen dazu beitragen, Genehmigungsverfahren 

zu beschleunigen. Für Einsätze mit andersartigem 

Anforderungsprofil gestatten sie eine genauere 

quantitative Aussage über das Versagensverhalten von 

Software, als viele bisher bekannte Verfahren. Sie sind 

aber nur anwendbar, wenn die Pfade durch die zu beurteilende 

Software durch eine Analyse festgestellt worden 

sind. Dies dürfte viele Programme von der Anwendung 

der dargestellten Qualifikationsmethode ausschließen; 

denn nur eine ungenau bekannte Anzahl von Pfaden 

oder Zahl von Pfadabläufen führen zu einer erheblichen 

Vergrößerung der für eine bestimmte neue Anwendung 

vorauszusetzenden Betriebserfahrung oder schließen 

dieses Verfahren gänzlich aus. 

Die erforderliche Erfahrung ist für hohe SILs unter Umständen 

nicht mehr zu erbringen. Kleine Programme oder 

Programme, die zwar umfangreich sind, aber aus vielen 

kurzen Pfaden bestehen, lassen sich, wie hier beschrieben, 

mit geringerem Aufwand qualifizieren als große oder solche 

mit vielen langen verschlungenen Pfaden. Es kann 

sein, das dies bei kleinen Programmen zu einer Kosteneinsparung 

in Genehmigungsverfahren führt, beispielsweise 

um von SIL2 ausgehend SIL3 nachzuweisen 

Für hohe SILs kommt das Verfahren vor allem dann in 

Betracht, wenn ein bereits sicherheitsqualifiziertes Programm 

für eine neue Aufgabe eingesetzt werden soll, 

etwa gemäß 61508-3-D. 

Unter ungünstigen Bedingungen können die verlangten 

Analysen und Nachweise über Vorbetriebszeiten so 

arbeitsintensiv werden, dass die probabilistische Verifikation 

nicht empfehlenswert ist und das zu beurteilende 

Programm eher mit deterministischen Mitteln verifiziert 

wird. Angesichts der zahlreichen und sehr einschränkenden 

Voraussetzungen, die für die Anwendung des 

Dargestellten eingehalten werden müssen, ist es für große 

und komplizierte Programme nicht einsetzbar. 

Nach meiner Auffassung besteht keine Gefahr, die hier 

beschriebene Vorgehensweise könnte Beweise oder analysebasierte 

Tests überflüssig machen; sie kann sie aber 

ergänzen und zu einer zahlenmäßigen Erfassung von 

Zuverlässigkeitseigenschaften von Software beitragen, 

ähnlich der bei Hardware üblichen. 

~ 

p g _ betr1 

> 

~ 

p ges _ vor 

~ + 

~ 

~ 

p g _ betr2 

p I pII 

Weiteren Untersuchungen bleibt vorbehalten, unter 

welchen Umständen es sinnvoll ist, mit Äquivalenzklassen 

statt mit Pfaden zu arbeiten, und wann sich eine 

Verknüpfung der Betrachtung von Datenströmen mit der 

von Ablauf-Pfaden anbietet. 


07.04.2012 

REFERENZEN 

AUTOR 


Wären die beteiligten Ablaufhäufigkeiten nur ungenau 

bekannt, wie bei der Herleitung von (6) angenommen, [1] Butler, R.W., Finelli, G.B.: The Infeasibility of Quantifying the Reliability of 

ergäbe sich für den Betriebsfall 2 bei einem =1,1: 

~ 

p g _ betr 2 = Life-Critical 7,2*10 -4 Real-Time Software; IEEE Transactions on Software Engineering 

=1,1: 

~ 

p g _ betr 2 = 7,2*10 -4 statt des obigen Werts. 

9(1), S. 3-12, 1993 

[2] Bishop, P.G., Esp, D.G., Pullen, F.D., Barnes, M., Humphreys, P., Dahll, G., Bjarlan, 

B., Lahti, J., Valisuo, H.: STEM – A Project on Software Test and Evaluation Methods. 

FAZIT 

In: Proceedings Safety and Reliability Symposium SARS 87, S. 100-117. 1987 

[3] DIN/ISO/IEC 61508: Functional Safety of electrical/electronic/ programmable 

electronic safety-related systems, 7 parts, 2010 

[4] Ehrenberger, W.: Software-Verifikation – Verfahren für den Zuverlässigkeitsnachweis 

von Software, Hanser Verlag, 2002 

[5] Heinhold, J., Gaede, K.-W.: Ingenieurstatistik, S. 324-334. Oldenbourg Verlag, 1972. 

[6] Kuball, S., May, J., Hughes, G.: Structural Software Reliability Estimation. 

In Proceedings Safecomp 99, S. 336-349. Springer, 1999. 

[7] Littlewood, B.: Eingeladener Vortrag Safecomp 85, Como/Italy, persönliche 

Mitteilung 

[8] Littlewood, B., Strigini, L.: Validation of Ultra-high Dependability for Softwarebased 

Systems. Communications of the ACM, 36(11), 69-80, 1993 

[9] Littlewood, B., Wright, D.: Some Conservative Stopping Rules for the Operational 

Testing of Safety-Critical Software. IEEE Transactions on Software Engieering 

23(11), 673-683,1997 

[10] Söhnlein, S.: Quantitative Bewertung der Softwarezuverlässigkeit komponentenbasierter 

Systeme durch statisische Auswertung der Betriebserfahrung. Dissertation 

Friedrich-Alexander-Universität Erlangen Nürnberg, Oktober 2010 

[11] Söhnlein, S., Saglietti, F., Meitner, M., Bitzer, F.: Auswertung der Betriebserfahrung 

zum Zuverlässigkeitsnachweis von Softwaresystemen am Beispiel einer Getriebesteuerung. 

atp edition - Automatisierungstechnische Praxis 52(6), 32-39, 2010 

[12] Weyand, C.: Ariane 5 - Luftfahrt, Berühmt–berüchtigte Software–Fehler 

http://formal.iti.kit.edu/~beckert/teaching/Seminar-Softwarefehler-SS03/ 

weyand.pdf, 2003 

Professor e.m. Dr.-Ing. WOLFGANG 

EHRENBERGER (geb. 1941) hat an der Hochschule 

Fulda Software Engineering gelehrt 

und an der DIN/ISO/IEC 61508 mitgearbeitet; 

er kommt ursprünglich von der Gesellschaft 

für Reaktorsicherheit. 

Hochschule Fulda, 

Angewandte Informatik, 

D-36039 Fulda, Tel. +49 (0) 661 964 03 25, 

E-Mail: 

wolfgang.d.ehrenberger@informatik.hs-fulda.de 


1-2 / 2013 

63

HAUPTBEITRAG 

OPC UA and ISA 95 

Interoperability for MES by implementing ISA 95 with OPC UA 

ISA 95 bietet ein Informationsmodell, das Materialien, Personal, Equipment, technische 

Anlagen, und andere Information auf der Ebene des Produktionsprozessmanagements 

repräsentiert. OPC UA offeriert eine verlässliche Kommunikationsinfrastruktur. Die Fähigkeiten 

zur Informationsmodellierung von OPC UA ermöglichen die generische und 

konfigurierbare Repräsentation der ISA 95-Information und den schnellen synchronen 

Datenaustausch, wie er für Produktionsabläufe erforderlich ist. Dieser Artikel beschreibt 

einen Ansatz zur Abbildung von ISA 95 nach OPC UA, der den interoperablen Informationsaustausch 

ermöglicht. 

SCHLAGWÖRTER ISA 95 / OPC UA / Interoperabilität / Informationsmodellierung / MES 

OPC UA and ISA 95 – 

Interoperability for MES by implementing ISA 95 with OPC UAh 

ISA 95 provides an information model representing materials, personnel, equipment, 

physical assets and other information on the level of Manufacturing Operations Management. 

OPC UA offers a robust and reliable communication infrastructure. OPC UA’s rich 

information modeling capabilities can be used to represent ISA 95 information in a generic 

and configurable way that allows for high-speed synchronous data exchanges required 

for manufacturing workflows. This paper introduces an approach mapping ISA 95 information 

into OPC UA allowing an interoperable manner of information exchange. 

KEYWORDS ISA 95 / OPC UA / Interoperability / Information Modeling / MES 

64 


1-2 / 2013

DENNIS BRANDL, BR&L Consulting 

PAUL HUNKAR, DSInteroperability 

WOLFGANG MAHNKE, ABB 

TOSHIO ONO, Yokogawa 

Automation does not end with equipment control; 

it also includes higher levels of control 

that manage personnel, equipment, and materials 

across production areas. Effectiveness in 

manufacturing companies is not based solely 

on equipment control capability. Manufacturing companies 

must also be efficient at coordinating and controlling 

personnel, materials, and equipment across different 

control systems in order to reach their maximum potential. 

This coordination and control must occur in at least 

four different parts of an organization; production, quality 

tests and test labs, warehousing and inventory management, 

and maintenance. 

This coordination and control is often supported 

by Manufacturing Execution Systems (MES) for management 

of production operations, Laboratory Information 

Management Systems (LIMS) for quality 

tests and test lab management, Warehouse Management 

Systems (WMS) or Tank Farm Management 

systems for management of inventory operations, and 

Asset Management or Computerized Maintenance 

Management Systems (CMMS) for maintenance operations. 

These systems together are collectively 

called Manufacturing Operations Management 

(MOM) systems. MOM defines a diverse set of functions 

that operate above automation control systems, 

reside below the level of enterprise business systems 

and are local to a site or area. 

1. OVERVIEW ON TECHNOLOGIES 

1.1 ISA 95 

The ANSI/ISA 95 Enterprise/Control System Integration 

standard [1], also released as IEC 62264 [2], defines five 

levels of activities in a manufacturing organization. Generally, 

automation and control support Levels 1 and 2, 

MOM systems support Level 3, and business Enterprise 

Resource Planning (ERP) systems support Level 4 activities. 

The ISA 95 levels are shown in Figure 1. 

Level 0 defines the actual physical processes. 

Level 1 elements are the sensors and actuators attached 

to the control functions in automation systems. 

Level 2 automation and control systems have realtime 

responses measured in sub-seconds and are 

typically implemented on Programmable Logic Controllers 

(PLC), Distributed Control Systems (DCS), 

and Open Control Systems (OCS). 

Level 3 typically operates on time frames of days, 

shifts, hours, minutes, and seconds. Level 3 functions 

also include maintenance functions, quality 

assurance and laboratory functions, and inventory 

movement functions, and are collectively called Manufacturing 

Operations Management. A wide variety 

of systems support the Level 3 activities, including 

SCADA (Supervisory Control and Data Acquisition) 

systems for monitoring the process and providing 

operator control, batch control systems for 

execution of recipes, data historians for the collection 

and preservation of time based data from Level 

2 systems, recipe and document management systems 

for managing recipes and workflow instructions, 

detailed scheduling, campaign management 

or work dispatching, and work or product tracking. 

Level 4 is called Business Planning and Logistics. 

Level 4 typically operates on time frames of months, 

weeks, and days. Enterprise Resource Planning 

(ERP) logistics systems are used to automate Level 4 

functions. 

It is important to remember that each level has some form 

of control and each level has its own definition for realtime. 

Level 3 systems consider real-time to mean information 

available a few seconds after shop floor events 

occur. Level 4 systems consider real-time to mean that 

logistics and material information is available daily or 

within a few hours after the end of a shift. 

This paper deals with information exchange across Level 

3 systems or between Level 2 and Level 3 systems. 

Specifically this would involve information exchange 


1-2 / 2013 

65

HAUPTBEITRAG 

between MES, WMS, LIMS, AM, PLC and DCS systems. 

This information exchange in real-time, often requiring 

transaction times measured in seconds or subseconds, in 

order to allow workflows and recipes to execute in a timely 

manner. ISA 95 defines four primary types of information 

that often must be exchanged among MOM systems 

and between ERP systems and MOM systems, these types 

are; information about material and the properties of materials, 

information about equipment as it pertains to the 

operations being performed, information about the physical 

assets that make up the equipment, and information 

about personnel and their roles and qualifications. 

Material Class, Material Definition, Material Lot, Material 

Sublot, and Material Test Information – This is the 

definition of the lots, sublots, material definitions, and 

material classes involved in production. This information 

allows Level 3 and Level 4 systems to unambiguously 

identify material specified in production schedules 

and consumed or produced in actual production. 

Equipment Class, Equipment, and Capability Test Information 

– This is the definition of the roles that equipment 

and equipment classes perform in production, inventory 

management, and quality test labs. This information 

may be used to associate production with specific 

equipment as part of a production record, or with 

equipment classes to schedule production and allocate 

costs. 

Physical Assets, Physical Asset Classes, and Physical 

Asset Capability test information – This is an identification 

of the specific physical asset (by serial number or 

asset ID) used in manufacturing operations. It also includes 

the make and model information that identifies the 

type of physical asset and its properties. 

Personnel Class, Person, and Qualification Test Information 

– This is the definition of the persons and personnel 

classes (roles) involved in production. This information 

may be used to associate production with specific 

persons as part of a production record, or with personnel 

classes to allocate production costs. 

1.2 OPC UA 

Classic OPC – the predecessor of OPC UA – is used to 

provide interoperable data exchange in automation between 

components of potentially different vendors. It is 

focusing on the second level defined by ISA 95 (see Figure 

1). With over 15.000 OPC products on the market 

from more than 2.500 companies [3] it is very well accepted 

and applied and almost every system targeting industrial 

automation implements classic OPC. With its 

flavors OPC DA (data access), A&E (alarms and events) 

and HDA (historical data access) it allows exchanging 

current, real-time related data and their history, as well 

as alarms and events between automation components 

like controllers and HMI (human machine interface) 

running on a Windows based PC. 

OPC UA (unified architecture, [4]) unifies these specifications 

and brings them to state-of-the-art technology 

with a service-oriented architecture (SOA). By switching 

the technology foundation from Microsoft’s COM/DCOM 

to web service technology OPC UA becomes platformindependent 

and can be applied in scenarios where classic 

OPC cannot be used. OPC UA can directly be deployed 

to controllers and intelligent devices without the 

need for a Windows-based PC to expose the data, as in 

classic OPC. It can also be seamlessly integrated into 

MOM and ERP systems running on UNIX / Linux. It still 

fits very well in the Windows-based environment where 

classic OPC lives today. 

Level 4 

Business Planning 

& Logistics 

Plant Production Scheduling, 

Operational Management, etc 

4 - Establishing the basic plant schedule - 

production, material use, delivery, and shipping. 

Determining inventory levels. 

Time Frame 

Months, weeks, days, shifts 

FIGURE 1: ISA 95 Activity 

Levels in a Manufacturing 

organization 

Level 3 

Manufacturing 

Operations Management 

Dispatching Production, Detailed Production 

Scheduling, Reliability Assurance, ... 

3 - Work flow / recipe control to produce the 

desired end products. Maintaining records and 

optimizing the production process. 

Time Frame 

Shifts, hours, minutes, seconds 

Level 2 

Level 1 

Manufacturing Control 

Basic Control, Supervisory Control, 

Process Sensing, Process Manipulation,… 

2 - Monitoring, supervisory control and automated 

control of the production process 

1 - Sensing the production process, manipulating 

the production process 

Level 0 

Production Process 

0 - The physical production process 

66 


1-2 / 2013

OPC UA provides a robust and reliable communication 

infrastructure having mechanisms for handling lost 

messages, failover, heartbeat, etc. With its binary encoded 

data it offers a high-performing data exchange 

solution. Security is built into OPC UA as security requirements 

become more and more important especially 

since environments are connected to the office network 

or the internet and attackers are starting to focus on automation 

systems [5]. 

In addition, OPC UA provides powerful information 

modeling capabilities. Unlike classic OPC with a very 

basic model, OPC UA provides the ability to define types 

and add semantic information to the data exchanged. 

With these capabilities OPC UA offers a high potential 

for becoming the standardized communication infrastructure 

for various information models. Several information 

models are already defined based on OPC UA 

making use of the generic and powerful meta model of 

OPC UA. This includes models for: 

the IEC 61131-3 programming model [6] used to 

program control applications; 

a model for analyzer devices [7]; 

a base model used by FDI (field device integration), 

OPC UA has built-in support allowing several 

different standardized information models to be 

hosted in one OPC UA server [8]. 

OPC UA is easily scalable. It can be applied on embedded 

devices with limited hardware resources as well as on 

very powerful machines like mainframes. Of course, an 

application running on limited hardware can only provide 

a limited set of data to a limited set of partners 

whereas an application running on high-end hardware 

can provide a large amount of data with several decades 

of history for thousands of clients. The information modeling 

capabilities also scale. An OPC UA server might 

provide a very simple model or a very complex model 

depending on the application needs. An OPC UA client 

can make use of the model or only access the data it needs 

and ignore the meta data accessible on the server. 

2. MOTIVATION 

MOM systems must often share definitions about resources: 

personnel, equipment, materials, and physical 

assets. This is needed to uniquely identify the resource 

and to verify that it is qualified or appropriate for the 

task to be performed, such as a material status that indicates 

that a material has been released for use in production. 

ISA 95 provides a standard framework to describe 

this information model for exchange, but ISA 95 

does not define a mechanism to exchange this information. 

MESA International defined B2MML [9] as a transport 

for exchanging ISA 95 based information, but this 

information exchange is for periodic Level 3/Level 4 

exchanges, not for sub-second based data exchange. 

OPC UA provides an infrastructure for defining information 

models in a standard manner and for exchanging 

the data associated with the information model in a 

secure reliable real-time manner. OPC’s typical applications 

are for integrating Level 2 and Level 3. By adapting 

the ISA 95 Information model to OPC UA, the 

ISA 95 information model can be extended to Level 2. 

In addition it allows the information represented by ISA 

95 models to be exchanged using OPC UA on Level 3. It 

provides services to query, browse, and update this information 

in a controlled manner in a highly efficient 

communication protocol. 

The following subsections summarize the information 

that needs to be exchanged. 

Sharing Material Information 

Manufacturing requires materials. It is not surprising 

that manufacturing systems have a requirement to identify 

and track materials because the main purpose of 

manufacturing is to convert materials in one form into 

materials of another form. An important part of MOM 

integration is maintaining and exchanging material 

identification and information. 

MES identify materials and their suitability for use, 

batch management systems confirm that the correct 

materials are used as specified in the recipes, 

tracking and tracking systems (bar-code scanners 

and RFID readers), 

LIMS confirm that the correct materials are tested 

and the correct materials are used in testing, 

WMS identify materials in their storage locations. 

Shared material information can be divided into 

three main categories; 

material class information identifies the materials 

without regard to the source of the material, 

material definition information identifies material 

from specific vendors or sources, 

material lot information identifies actual material, 

its location and quantity. 

Sharing Equipment Information 

One important element of managed information is the 

correct identification of the equipment used for manufacturing. 

Equipment identification is used for: 

scheduling, 

tracking and tracing, 

maintenance, 

troubleshooting, 

visualization (HMI), 

capacity tracking, 

OEE (Overall Equipment Effectiveness) calculations. 

Unfortunately, it is not uncommon for a manufacturing 

company to have multiple identifications for a single piece 

of equipment. Therefore, a critical aspect of equipment 

information management is managing different 

equipment ID’s across multiple vendor systems and applications. 

Sharing Physical Asset Information 

Identification of a unique physical asset, irrespective of 

the role the equipment is performing is vital for: 


1-2 / 2013 

67

HAUPTBEITRAG 

maintenance, 

equipment qualification and regulatory compliance, 

financial asset tracking 

Each physical asset has a vendor serial number that is 

needed for financial tracking and maintenance contracts. 

Vendor serial numbers are not unique, so each 

physical asset is usually given a unique company-specified 

financial asset tag number. The financial asset tag 

number is maintained in a financial system and may not 

be compatible with maintenance system identifications. 

Usually differences are in the number of characters or 

numbers used and the naming rules required by the applications. 

Therefore, maintenance systems often have a 

separate maintenance tag that is added to the physical 

asset. In the case of small equipment, the three separate 

identification tags and vendor make and model information 

can cover most of the equipment’s surface area. All 

of these different identifications often require that a system 

can quickly determine if a physical asset is qualified 

for production, and to obtain the physical asset identification 

for any regulatory records. 

Sharing Personnel Information 

Multiple regulatory rules, laws, and internal procedures 

require that personnel who perform shop floor actions are 

unequivocally identified, are authorized to perform the 

actions, and have valid training or qualifications to perform 

the actions. Because personnel information is usually 

maintained in multiple IT and control systems, it is a key 

area of exchanged information. Specific uses in different 

systems that require coordination and sharing include: 

MES Personnel qualification to be checked before 

someone is allowed to take an action 

LIMS Identification of approved personnel to perform 

tests and handle materials, often based on their 

training qualifications, 

AM Certification information about personnel performing 

maintenance activities to ensure that they 

have the proper training required by the activity, 

WMS Certification that personnel are trained and 

qualified to handle material movement systems, 

such as fork trucks or crane systems. 

3.1 Modeling Approach of ISA 95 

The ISA 95 modeling approach to information is based 

on a “Property” model. The ISA 95 models define a 

minimum set of industry-independent information as 

attributes. Industry specific, application specific, and 

company specific information are represented as property 

objects. For example, the personnel class property 

would be used to define application or industry 

specific attributes for personnel classes, and person 

property would be used to contain instance values for 

the properties. 

In the ISA 95 resource models there are “Classes” 

and “Instances”. The word “Class” used as part of an 

object definition name should be considered as a category, 

not as a “Class” in the official UML Modeling 

definition. For example: “Personnel Class” should be 

considered a “Personnel Category”, because it is used 

to distinguish between the kinds of personnel in the 

real world and to define properties that would be common 

to personnel within the same category. The Figure 

2, from ANSI/ISA 95.00.02, is the Personnel object 

model. Each instance of the Personnel Class defines a 

role that a person can perform, such as a Draftsman. 

Each role may have specific properties, such as a Drafting 

License Number and a License Expiration Date. 

Each Person can be associated to one or more Personnel 

Class Roles. If the person is Draftsman, then the Person 

Properties define the values for the Drafting License 

Number and License Expiration Date for that person. 

The Qualification Test Specification identifies a test 

that may be associated with determining the value for 

a property (such as a test for Draftsman used to obtain 

a Drafting License Number.) The information obtained 

from taking the test can be modeled in the Qualification 

Test Result. 

This modeling approach for ISA 95 means that properties 

must be able to be dynamically queried and browsed. 

The properties available for individual objects will be 

different, for example in Figure 3, Joe Smith has a Drafting 

License Number, but Sally Jones does not. The OPC 

UA modeling approach provides the flexibility to have 

the dynamic data discovery required for Level 3 communications. 

3. MAPPING ISA 95 TO OPC UA 

After relating the benefitis of implementing the ISA 95 

model with OPC UA and describing the information to 

be exchanged this section focuses on how the mapping 

can be done. To generate a mapping of the ISA 95 information 

model to an OPC UA information model, first the 

information model available in ISA 95 has to be understood. 

This is described in section 3.1. The information 

modeling capabilities of OPC UA as base of the mapping 

are described in section 3.2. The mapping approach is 

defined in section 3.3, and details as well as examples 

given in sections 3.4 and 3.5. Section 4 describes an implementation 

of the mapping in order to verify the efficiency 

of the proposed mapping. 

3.2 Modeling Approach of OPC UA 

The basic information modeling principles of OPC UA 

are (taken from [3]): 

Using object-oriented techniques including type hierarchies 

and inheritance. Typed instances allow 

clients to handle all instances of the same type in 

the same way. Type hierarchies allow clients to work 

with base types and to ignore more specialized information. 

Type information is exposed and can be accessed 

the same way as instances. The type information is 

provided by the OPC UA server and can be accessed 

with the same mechanisms used to access instances. 

68 


1-2 / 2013

FIGURE 2: Class 

Diagram of ISA 95 

[from ANSI/ISA 

95.00.02] 

FIGURE 3: Example 

of a personnel class 

instances and 

person instances 

BaseNode 

+NodeId : NodeId 

+NodeClass : NodeClass 

+BrowseName : QualifiedName 

+DisplayName : LocalizedText 

+Description : LocalizedText 

FIGURE 4: Modeling concepts of 

OPC UA – the OPC UA meta model 

Object 

+EventNotifier : Byte 

Variable 

+Value 

+DataType : NodeId 

+ValueRank : Int32 

+ArrayDimensions : Int32 

+AccessLevel : Byte 

+UserAccessLevel : Byte 

+MinimumSampleInterval : Int32 

+Historizing : Boolean 

Method 

+Executable : Boolean 

+UserExecutable : Boolean 

View 

+ContainsNoLoops : Boolean 

+EventNotifier : Byte 

ObjectType 

+IsAbstract : Boolean 

ReferenceType 


+Symmetric : Boolean 

+InverseName : LocalizedText 

VariableType 

+Value 

+DataType : NodeId 

+ArraySize : Int32 


DataType 



1-2 / 2013 

69

HAUPTBEITRAG 

Full meshed network of nodes allowing information 

to be connected in various ways. OPC UA allows 

supporting various hierarchies exposing different 

semantics and references between nodes of those 

hierarchies. The same information can be exposed 

in multiple ways depending on the use case. 

Extensibility regarding the type hierarchies as well 

as the types of references between nodes. OPC UA is 

extensible in several ways regarding the modeling 

of information. In addition to the definition of subtypes 

of nodes it allows the definition of additional 

types of references between nodes and the definition 

of methods extending the functionality of OPC UA. 

No limitation on how to model information in order 

to allow an appropriate model for the provided data. 

OPC UA servers targeting a system that already contains 

a rich information model can expose that model 

“natively” in OPC UA instead of mapping the 

model to a different model. 

OPC UA information modeling is always done on the 

server-side. OPC UA information models always 

exist on OPC UA servers, not on the client. They can 

be accessed and modified from OPC UA clients. An 

OPC UA client is not required to have an integrated 

OPC UA information model and it does not have to 

provide such information to an OPC UA server. 

Those principles support very basic as well as very complex 

and powerful information models such as ISA 95. 

In Figure 4, the base concepts of OPC UA – the meta 

model – are summarized. There are different node classes 

for different purposes. Nodes are connected by references. 

Node classes represent objects for structuring 

the address space, methods, and variables containing 

data. Node class attributes are described in the figure. 

OPC UA defines a UML-like notation for modeling 

OPC UA address spaces. Figure 5, illustrates the modeling 

notation and concepts. The notation illustrates the 

object, variable and data type symbols as well as object 

type, variable type and reference type. The example 

shows one object type called MyType inheriting from 

the OPC UA defined BaseObjectType. It uses the Has- 

PersonType 

Personnel Class Type 

Notation 

Supervisor 

Professional Engineer 

Operator 

Object 

ObjectType 

HasComponent 

BelongsTo Personnel Class 

BelongsTo Personnel Class 

BelongsToPersonnel Class 

HasProperty 

Sally Jones 

Variable 

VariableType 

HasSubtype 

DataType 

ReferenceType 

 

HasTypeDefinition 

Other Reference Types 

(name written on it) 

FIGURE 6: Mapping of ISA 95 to OPC UA 

Classes and Instances (Alternative One) 

Example 

BaseObjectType 

BaseDataVariableType 

MyInstance 

MyType 

MyCounter 

MyCounter 

PersonType 

Personnel Class Type 

FIGURE 5: Example and 

Notation of OPC UA modeling 

Sally Jones SupervisorType Professional EngineerType Operator Type 

Personal 

Class Folder 

Supervisor 

Professional Engineer 

Operator 

FIGURE 7: Mapping of ISA 95 to OPC UA 

Classes and Instances (Alternative Two) 

70 


1-2 / 2013

Subtype reference. MyType contains a variable called 

MyCounter, referenced by a HasComponent reference. 

Variables, objects and methods on types are called instance 

declarations and define the structure of the types. 

That means that instances of MyType also have a variable 

called MyCounter. As variables are typed as well, 

they reference to the OPC UA defined BaseDataVariableType. 

Variables have data types assigned to them defining 

the data type of the value of the variable. This can 

be built-in data types like Int16 or Boolean but also userdefined 

data types. 

Those concepts allow the definition of object types 

with a specific structure and semantic, as well as reference 

types with specific semantic. 

3.3 Mapping Approach 

When mapping the ISA 95 model to OPC UA typically 

the same mapping rules should be applied when mapping 

similar ISA 95 structures. However, sometimes the- 

re are several useful mapping alternatives and it is more 

effective to have different mappings depending on the 

expected use of the models. 

In the following, the rules and potentially alternatives 

are described. 

ISA 95 Properties 

ISA 95 properties are mapped to OPC UA variables. That 

means that for each UML class representing Properties 

(e.g. Person Property in Figure 2) an OPC UA variable 

type is created (inheriting from a variable type ISA95PropertyType). 

Instances of the ISA 95 properties are instances 

of the specific type, referenced by a HasISA95Property 

reference. 

ISA 95 Classes 

As described in section 1.1, ISA 95 classes are used for 

categorization rather than in the object-oriented sense 

of class and instance. That means each class has some 

ISA 95 properties assigned to it and each instance assigned 

to the class contains at least the properties in 

ISA-95 Base Information Model 

ISA95Asset 

AssignmentType 

ISA95 

ClassPropertyType 

ISA95 

PropertyType 

ISA95 

TestResultType 

FIGURE 8: OPC UA ISA95 

Architecture Sample 

:: 

ISA95ClasspropertyType 

HasISA95 

ClassProperty 

TestResult 

HasISA95 

Property 

:: 

ISA95PropertyType 

ISA95ClassType 

ISA95Test 

SpecificationType 

ISA95ObjectType 

HasISA95 

ClassProperty 

 

 

HasISA95 

Property 

ISA-95 Common Object Model Example 

EquipmentClassType 

EquipmentCapabilityTestSp 

ecificationType 

EquipmentType 

AssetAssignment:: 

ISA95AssetAssignmentType 

:: 

EquipmentType 

MadeUpOf 

Third Party Model Example 

HeatingReactor 

ClassType 

ThirdPartyEquipmentTestSp 

ecificationType 

ReactorType 

HasISA95 

ClassProperty 

HeatingTime:: 

ISA95ClassPropertyType 

BelongsTo 



HasISA95 

Property 

Third Party Instance Example 

HeatingReactorClass 

BelongsTo 

HR1001 

HasISA95 

ClassProperty 


ISA95ClassPropertyType 



HasISA95 

Property 

MadeUpOf 

FIGURE 9: OPC UA ISA 95 Server Address Space 

TestSpecifications:: 

BaseObjectType 

ConformsTo 

ReactorHeatingTimeTest:: 

ThirdPartyEquipmentTestSpecificationType 

OtherTestSpecifications:: 

ThirdPartyEquipmentTestSpecificationType 

TS1001:: 

EquipmentType 

EquipmentOf 

TS#1234:: 

PhysicalAssetType 


1-2 / 2013 

71

HAUPTBEITRAG 

the class. An instance can have several classes and thus 

all their properties. 

Each ISA 95 concept representing a class (e.g. Personnel 

Class in Figure 2) is mapped to an OPC UA object type. 

There are two alternatives how to map the concrete class 

(i.e. instances of Personal Class). 

Map them to OPC UA objects (see Figure 6) 

Map them to OPC UA object types and objects (see 

Figure 7) 

The first approach is the direct mapping from the ISA 95 

model. Each instance fulfilling the class would reference 

the object and clients aware of the ISA 95 model would 

be able to interpret it. However, it does not make use of 

the OPC UA type model and it would be hard for generic 

clients to interpret and program against (e.g. it would 

require a specific user interface that understood all of 

the Operator properties for a person). A more generic 

approach is shown in Figure 7, which defines subtypes 

of the object type containing all properties and the instances 

contain instances of the subtypes. Both alternatives 

can make sense, depending on the expected use. 

ISA 95 Objects 

The ISA 95 Objects are mapped to OPC UA object 

types and object instances. Therefore each UML class 

modeling instances (e.g. Person in Figure 2) is mapped 

to an OPC UA object type and the instances are 

instances of that type. Depending on the mapping of 

the ISA 95 class it either references the object or contains 

an instance of the object type. In both cases it 

contains all properties of the classification (see Figure 

6 and Figure 7). 

ISA 95 Relations 

ISA 95 relations (e.g. from Person to Qualification Test 

Specification) are mapped to OPC UA references. In oder 

to expose the specific semantic new OPC UA reference 

types need to be defined. However, this is a fixed set of 

new reference types. 

Implementation of the Mapping 

The overall architecture of the model has been completed 

and is illustrated in Figure 8. It includes the physical 

asset and equipment models, their interactions with test 

specification and personal models. The equivalent material 

handling models are not shown. 

REFERENZEN 

AUTOREN 

[1] ANSI/ISA-95.00.01: Enterprise-Control System 

Integration - Part 1: Models and Terminology, 2010 

[2] IEC 62264-1: Enterprise-control system integration 

– Part 1: Models and terminology, Edition 1.0, 

March 2003 

[3] Mahnke, W., Leitner, S.-H., Damm, M.: OPC Unified 

Architecture, Springer, 2009 

[4] IEC 62541-1: OPC Unified Architecture - Part 1: 

Overview and Concepts, February 2010 

[5] Greenfield, D.: The Stuxnet Effect on Cyber Security, 

Automation World, March 2012 

[6] PLCopen and OPC Foundation: OPC UA Information 

Model for IEC 61131-3, Version 1.00, March 2010 

[7] OPC Foundation: OPC Unified Architecture Companion 

Specification for Analyser Devices, Version 1.00, 

October 2009 

[8] OPC Foundation: OPC Unified Architecture for 

Devices (DI), Version 1.00, December 2009 

[9] WBF: Business To Manufacturing Markup Language 

- B2MML , Version 0500, March 2011 

DENNIS BRANDL (born in 1951) is the founder and 

chief consultant for BR&L Consulting, specializing 

in Manufacturing IT applications, including 

Business-to-Manufacturing Integration, MES 

solutions, General and Site Recipe implementations, 

and automation system security. He has 

been involved in automation system design and 

implementation in a wide range of applications 

over the past 25 years. Dennis has been an active 

member of the ISA 95 Enterprise/Control System 

Integration committee for the past 15 years and is 

editor of the set of standards. He is a USA expert 

on batch control to IEC, is the former chairman of 

the ISA SP88 Batch System control standard, and 

is the chairman of the IEC and ISO Joint Working 

Group on Enterprise/Control Integration. 

Mr. Brandl has written numerous papers and 

articles on business to manufacturing integration 

and flexible manufacturing solutions and has a 

regular column in Control Engineering. Dennis 

has a BS in Physics and an MS in Measurement 

and Control from Carnegie-Mellon University, 

and a MS in Computer Science from California 

State University. 

BR&L Consulting, 

208 Townsend Ct, Suite 200 Cary, NC 27518 – USA, 

Tel. +1 (0) 919 852 53 22, 

E-Mail: dnbrandl@brlconsulting.com 

72 


1-2 / 2013

A prototype of the information model is maintained as 

part of the OPC UA ISA 95 working group, which is developing 

the information model. The prototype includes 

a fully functional version of the information model. The 

information model includes samples of typical extensions 

that a company may generate to adapt the generic 

ISA95 information model to a company or deployment 

specific information model. 

The address space shown in Figure 9 illustrate sample 

properties and objects such as an ISA 95 based 

temperature sensor or larger ISA 95 based model of a 

boiler, which include the aggregation of other equipment 

items. 

SUMMARY 

This paper describes the union of two widely accepted 

technologies – ISA 95 and OPC UA – that expands on 

the strengths of both. The ISA 95 model is widely used 

to define the information required for system integration. 

It provides a set of abstract UML models that can 

be used to represent exchanged information about materials, 

personnel, equipment, physical assets and 

other information. The OPC UA standard is an integration 

technology that is based on web service technology, 

is platform independent, and can be deployed 

from small embedded systems up to large scale plantwide 

systems. OPC UA provides a robust and reliable 

communication infrastructure having mechanisms for 

handling lost messages, failover, heartbeat, and a binary 

encoding for high performance data exchanges. 

OPC UA’s open data model can be used to represent 

ISA 95 information in a generic and configurable method 

that allows for high-speed synchronous data exchanges 

required for manufacturing workflows. 

The resulting union provides a robust high speed communication 

system for widely accepted common MOM 

information model. It also allows the ISA 95 model to be 

extended down to the level 1-2 systems without custom 

interfaces. It also allows ERP system to obtain select information 

directly from level 1-2 systems. It is expected that 

the OPC UA ISA 95 working group will finalize a mapping 

specification by the end of 2012 and it will be made available 

via the OPC Foundation. 


21.05.2012 


PAUL HUNKAR (born in 1961) is president of 

DS Interoperability, independent consulting 

firm, specializing in design and development 

of software systems. He has been running DS 

Inter operability for 3 years, his client list includes 

Yokogawa, ABB, Unified Automation, 

Rovosys and the OPC Foundation. Paul is member 

of the Technical Advisory Council of the 

OPC Foundation. He is editor for the Profiles 

and Alarm & Condition parts of the OPC UA 

Specification. He was the Director of Certification 

for the OPC Foundation and the chair of 

the OPC Foundation Compliance Working 

Group. He had previously worked for major 

Process Automation vendors for more than 25 

years in a variety of engineering roles including 

designing, constructing and managing 

development of advanced control application, 

operator interface systems, historical systems 

and investigating new technologies. Paul has a 

Bachelors Degree in Computer Engineering 

from the University of Michigan and a Masters 

Degree in Computer Engineering from Case 

Western Reserve University. 

DSInteroperability, 

4012 Deacon Ct, 44236 Hudson, Ohio, 

Tel. +1 (0) 440 337 41 61, 

E-Mail: paul.hunkar@dsinteroperability.com 

Dr.-Ing. WOLFGANG MAHNKE (born in 1971) works at the ABB Corporate 

Research Center in Germany in the field of Industrial Software Systems. He 

is editor of the Address Space Model and the Information Model parts of the 

OPC UA specification and author of the first book on OPC UA. Wolfgang is 

member of the Technical Advisory Council of the OPC Foundation and the 

OPC Europe Advisory Board. He holds a Diploma in Computer Science from 

the University of Stuttgart. During his work at the University of Kaiserslautern 

he gained his Ph.D. in the area of Databases and Information Systems. 

ABB AG, Industrial Software Systems, 

Wallstadter Straße 59, D-68526 Ladenburg, 

Tel. +49 (0) 6203 71 62 55, 

E-Mail: wolfgang.mahnke@de.abb.com 

THOSHIO ONO (born in 1968) graduated in 1990 as a control engineer. 

He has worked for Yokogawa Electric Corporation for more than 

20 years and has been involved in automation system design and 

implementation in SCADA, DCS, and NCS systems. He had been an 

active member of technical committee in OPC Japan for the past 10 years. 

He was nominated in 2009 as one of the three Japanese delegates to the 

IEC SC65E WG8 as an OPC UA specialist. Today, he works for Yokogawa 

Corporation of America as principal system architect and evangelizes 

the OPC UA standard within Yokogawa. 

Yokogawa Electric Corporation, 

2-9-32 Nakacho, Musashino-shi, 

Tokyo, Japan 180-8750, Tel. +81 (0) 972 417 27 50, 

E-Mail: toshio.ono@us.yokogawa.com 


1-2 / 2013 

73

HAUPTBEITRAG 

Cloud Computing im Kontext 

eines Prozessleitsystems 

IT-Einfluss auf Architektur der Prozessautomatisierung 

Die Informationstechnik hat wesentlichen Einfluss auf die Architektur von Prozessleitsystemen 

genommen. Das belegen unterschiedliche Bussysteme sowie Anzeige- und Bedienansätze. 

So hat die im ersten Beitragsteil beschriebene IT-Technologie Virtualisierung 

bereits heute Einzug in die Praxis gehalten. Cloud Computing ist hingegen nicht übliche 

Praxis im Kontext der Architektur eines Prozessleitsystems. Im Rahmen entsprechender 

Vorfeldarbeiten fokussiert dieser zweite Beitragsteil auf das häufig kontrovers diskutierte 

Cloud Computing hinsichtlich der Prozessleitsystem-Architektur. 

SCHLAGWÖRTER PLS / Virtualisierung / Cloud Computing 

Cloud Computing in the context of a Distributed Control System – 

IT influence on the architecture of process automation 

IT has significant influence on the architecture of distributed control systems. This influence 

is overlaid by various technologies regarding communication, visualization and 

operating systems. Virtualization is such a technology that was described in the first part 

of this paper. Virtualization is used in practice and thus has already influence on the 

architecture of a distributed control system. Cloud computing, however, is not common 

practice so far. This second part of the paper focuses on the often controversial discussed 

topic cloud computing regarding the distributed control system architecture. 

KEYWORDS DCS / virtualization / cloud computing 

74 


1-2 / 2013

MARTIN SCHNEIDER, STEFAN RUNDE, MARTIN GLASER, STEFAN GERACH, Siemens AG 

Ein mögliches Mittel für die ständige Anforderung 

Kostenreduzierung ist gegebenenfalls der 

Einsatz neuester Technologien. Diese allgemeine 

Tatsache beeinflusst auch die Architektur 

eines Prozessleitsystems (PLS). Dabei stammen 

die Technologien häufig aus der IT, wie im Beitrag „Virtualisierung 

im Kontext eines Prozessleitsystems" bereits 

dargestellt. Virtualisierung wird schon in der Praxis 

angewendet und hat Einfluss auf die Architektur 

eines PLS genommen [3]. Der Begriff Cloud Computing 

wird einerseits für die dahinterstehenden Technologien 

(Cloud-Plattform) und andererseits für die angebotenen 

Services auf Basis der Cloud Computing Technologien 

(Geschäftsmodell) verwendet – die Technologien sind 

der Enabler für das Geschäftsmodell. Eine der Basistechnologien 

einer Cloud-Computing-Plattform ist Virtualisierung 

[2]. Der Einsatz von Cloud Computing ist im 

Kontext eines PLS keine übliche Praxis. Veröffentlichungen 

im Zusammenhang von Cloud Computing und 

der Automatisierungstechnik im Allgemeinen sowie der 

Architektur eines PLS im Speziellen sind rar [8] [9]. 

Dadurch, dass in der Community nicht unterschieden 

wird zwischen den Technologien und dem Geschäftsmodell, 

entsteht häufig der Eindruck, es könne „nichts“ 

mit Hilfe von Cloud Comuting besser werden, da es in 

Grundzügen bereits angewendet wird, oder es könne 

„alles“ Bestehende und Neue verbessert werden. Das folgende 

Zitat bezüglich Services – ein wesentliches Element 

des Cloud Computing – belegt diese Aussage eindrucksvoll: 

„Sprach man zuerst von Software-as-a-Service 

und Infrastructure-as-a-Service, so kamen weitere 

Angebote [...] hinzu. Inzwischen gibt es sogar seltsam 

anmutende Auswüchse wie Human-as-a-Service. Wegen 

des gemeinsamen Suffix fasst man alle Arten von Cloud 

Services gerne unter dem Begriff Anything-as-a-Service 

(XaaS) zusammen. Zwar sind viele dieser Service-Bezeichner 

durchaus sinnvoll [...], aber die Vielfalt trägt 

nicht unbedingt zum Verständnis bei.“ [6] 

Die Grundlagenbeschreibung (1) hinsichtlich des 

Cloud Computings bildet einen Schwerpunkt dieses Beitrags. 

Auf der Basis entsprechender Literatur, meist aus 

dem IT-Umfeld, wurden die wesentlichen Charakteristika 

in den Kontext der Automatisierungstechnik (AT) 

gestellt. Ein weiterer Schwerpunkt ist die Darstellung 

hinsichtlich der Realisierung eines PLS in der Cloud im 

Kontext der Vorfeldentwicklung (3). 

1. GRUNDLAGEN DES CLOUD COMPUTINGS 

1.1 Einordnung 

Cloud Computing ist im Grundsatz nicht neu. Es basiert 

auf verschiedenen Ansätzen, die sich in den letzten Jahrzehnten 

entwickelt haben, wie in Bild 1 dargestellt. 

Grundsätzlich lassen sich diese Ansätze in die beiden 

Kategorien Infrastruktur-Bereitstellung und Applikations-Bereitstellung 

einteilen [6]. 

1. Kategorie: Infrastruktur-Bereitstellung: 

Bereits Ende der 80er-Jahre wurden verteilte Rechen- und 

Speicherressourcen zu einem Cluster virtueller Supercomputer 

zusammengefasst, um rechenintensive Anwendungen 

aus Gebieten wie beispielsweise der Physik, Biologie, 

Meteorologie durchzuführen. Diese Anwendung tauchte 

erstmals um das Jahr 2002 im wissenschaftlichen Kontext 

unter dem Begriff Grid Computing auf. Virtualisierung 

umfasst Methoden, die es erlauben, Rechen- und Speicher- 

Ressourcen, die im Grid Computing zu einem Cluster zusammengefasst 

werden, effizient zu verwenden (unter 

anderem Konsolidierung, anwendungsorientierte Partitionierung). 

Für detaillierte Informationen zum Thema Virtualisierung 

sei auf Teil 1 des Beitrags verwiesen [3]. Auf 

der Basis der beiden zuvor genannten Technologien sieht 

das Utility Computing eine flexible Bereitstellung von IT- 

Infrastruktur mit dem Ziel vollständiger Kostenkontrolle, 

flexibler Kostenverrechnung und aktivem Management 

des Service Level Agreement (SLA) vor. Ein SLA ist eine 

Vereinbarung zwischen Auftraggeber und Dienstleister 

für wiederkehrende Dienstleistungen. Die Vereinbarung 

beinhaltet beispielsweise Regelungen zu Quality of Service 

(QoS) – Bandbreite, Latenz, Jitter und Verfügbarkeit. 


1-2 / 2013 

75

HAUPTBEITRAG 

2. Kategorie: Applikations-Bereitstellung: 

Das Application Service Providing ermöglicht es einem 

Provider (Anbieter), Applikationen zentral bereitzustellen, 

die ein Anwender über das Intranet oder Internet 

nutzt. Dieser Ende der 90er-Jahre verfolgte Ansatz basiert 

auf der Idee, IT-Investitionen durch gemietete Software 

(SW) zu verringern. Weiterhin ermöglicht es aufgrund 

der zentralen Bereitstellung eine einfachere Pflege und 

Wartung der jeweiligen Software. Application Service 

Providing (ASP) war der erste Schritt zur gemieteten SW. 

Software-as-a-Service (SaaS) ist die Weiterentwicklung 

des Gechäftsmodells in Richtung Self Service. Der große 

Unterschied ist, dass im ASP Anwendungen gezielt für 

Kunden angepasst wurden beziehungsweise bereitgestellt 

wurden, bei SaaS hingegen Anwendungen für 

Kunden-Zielgruppen vorab bereitgestellt werden und die 

Kunden sich je nach Bedarf bedienen. 

1.2 BEGRIFFSBESTIMMUNG 

Ausgehend von den beiden zuvor beschriebenen Technologien 

und Kategorien adressiert Cloud Computing 

somit die Bereitstellung von Infrastruktur und Applikationen. 

Es existieren zahlreiche Definitionen des Begriffs 

Cloud Computing – eine einheitliche Definition gibt es 

nicht. Eine viel zitierte Definition vom National Institute 

of Standards and Technology (NIST) beschreibt Cloud 

Computing wie folgt: 

«Cloud computing is a model for enabling ubiquitous, 

convenient, on-demand network access to a shared pool 

of configurable computing resources (e.g., networks, 

servers, storage, applications, and services) that can be 

rapidly provisioned and released with minimal management 

effort or service provider interaction.» [5] 

Der überwiegende Teil der Cloud-Computing-Beschreibungen, 

unter anderem vom European Network 

and Informations Security Agency (ENISA), vom Bundesamt 

für Sicherheit in der Informationstechnik 

(BSI), sowie Bundesverband Informationswirtschaft, 

Telekommunikation und neue Medien e.V. (Bitkom), 

greifen die oben genannte Definition inhaltlich auf. 

Nachfolgend sind die wesentlichen Merkmale kurz 

beschrieben: 

Ubiquitous, convenient, on-demand network access: Der 

Cloud-Nutzer kann bei Bedarf (on-demand) überall (ubiquitous) 

selbstständig auf die Cloud-Services (geeignet) zugreifen. 

Durch den Einsatz aktueller Web-Technologien kann 

der Zugriff über das Intranet, das Internet oder ein Virtual 

Private Network von einem beliebigen Ort aus erfolgen. 

Shared pool of configurable computing ressources: Der 

Bereitstellende einer Cloud hält einen Pool an mehrmandantenfähigen 

Ressourcen vor, die gebündelt einem oder 

mehreren Benutzern zur Verfügung gestellt werden können 

– der Benutzer hat keine Information darüber, welche 

Ressourcen gerade verwendet werden und wo sich 

diese befinden. 

Rapidly provisioned: Die Ressourcen bieten eine gute Skalierbarkeit 

und weisen demnach eine entsprechende Elastizität 

auf. Aus Sicht des Cloud-Nutzers steht eine unbegrenzte 

Kapazität an Ressourcen zur Verfügung. Den Prinzipien 

des Utility-Computings (1.2) folgend werden die 

Cloud-Services mittels definierter Metriken überwacht 

(engl: metered-by-use), um einerseits die Service-Qualität 

zu garantieren und andererseits eine verbrauchsabhängige 

Abrechnung (pay-per-use) zu ermöglichen. 

Minimal management effort: Cloud Computing zeichnet 

sich durch einen hohen Grad an Automatisierung aus. 

Dadurch können die Ressourcen mit minimalem Verwaltungsaufwand 

durch den Cloud- und Service-Provider 

automatisiert bereitgestellt werden. 

1.3 SPI-Ordnungsrahmen 

Der vom NIST [5] definierte und allgemein etablierte Software/Platform/Infrastructure-Ordnungsrahmen 

(SPI-Ordnungsrahmen) 

dient der allgemeinen Klassifizierung von 

Dienst-Modellen, siehe Bild 2. Die Dienstmodelle lau-ten 

Infrastructure-as-a-Service (IaaS), Platform-as-a-Service 

(PaaS) sowie Software-as-a-Service (SaaS). Als gemeinsame 

Eigenschaft besitzen alle drei Modelle die Bereitstellung 

einer Dienstleistung als „as a Service“ (1.2). 

Bei IaaS stellt ein Cloud-Provider die IT-Basisinfrastruktur 

zur Verfügung. Zu dieser IT-Basisinfrastruktur 

zählen zum Beispiel Rechen- und Speicher-Ressourcen 

oder Netzinfrastruktur. Diese Basisinfrastruktur nutzt 

Virtualisierungstechniken, die die Grundlage dafür bereitstellen, 

die Ressourcen dynamisch und zeitnah bereitzustellen 

(1.2). 

Bei PaaS wird eine Anwendungsplattform zur Entwicklung 

und zum Betrieb eigens entwickelter Anwendungen 

zur Verfügung gestellt. Zu dieser Anwendungsplattform 

zählen neben einem Betriebssystem zudem 

entsprechende Laufzeitumgebungen. Diese beinhalten 

unter anderem Frameworks (zum Beispiel für Runtime), 

Message Queuing, Load Balancing oder Datenbanken, 

die abhängig von den aktuellen Anforderungen skalierbar 

sind – und/oder Entwicklungsumgebungen, Applikations- 

und Web-Server sowie Bibliotheken. 

SaaS hat seinen Ursprung im Application Service Providing 

(1.1). Hierbei werden Anwendungen in einer 

Cloud zur externen Nutzung zur Verfügung gestellt. Der 

Zugriff erfolgt zumeist ohne zusätzliche Installation 

über einen herkömmlichen Web-Browser. Die Verwendung 

von Web-Techniken ermöglicht, dass der jeweilige 

Kunde unabhängig von bestimmten Betriebssystemen 

die entsprechende Anwendung nutzen kann. Die Abrechnung 

bezüglich der Verwendung der jeweiligen Anwendung 

erfolgt oftmals in Form von pay-per-use (1.2). 

1.4 Zugangsmodelle 

Ein wesentliches Unterscheidungsmerkmal der Zugangsmodelle 

ist der autorisierte Kreis zur Benutzung bereitgestellter 

Dienste bei IaaS, PaaS und SaaS. Die Zugangsmodelle 

stehen orthogonal zu diesen Modellen des SPI- 

Ordnungsrahmens. Somit lassen sich prinzipiell alle in 

Bild 2 dargestellten Kombinationsmöglichkeiten auf der 

Basis der nachfolgend beschriebenen Zugangsmodelle 

realisieren. 

76 


1-2 / 2013

Public Cloud: Bei dieser auch als External bezeichneten 

Cloud stehen die verschiedenen angebotenen Cloud- 

Dienste öffentlich zur Verfügung. Die (End-)Kunden 

teilen sich die durch einen unabhängigen Cloud-Provider 

öffentlich bereitgestellte Infrastruktur inklusive der 

Dienste. 

Private Cloud: Diese Cloud, die auch als Internal Cloud 

bezeichnet wird, hat als Cloud-(End-)Kunden ausschließlich 

eine einzige Interessengemeinschaft (zum Beispiel 

im Rahmen des Engineerings [7]) aus einer Organisation 

(beispielsweise einem Unternehmen). Die Infrastruktur 

wird durch die Organisation bereitgestellt. Wird der Betrieb 

dieser Cloud durch einen externen Dienstleister sichergestellt, 

so wird der Begriff Managed Private Cloud 

verwendet – Cloud-Provider ist weiterhin die Interessengemeinschaft, 

wobei die Verantwortung des ordnungsgemäßen 

Betriebs auf der Basis von SLA jedoch beim externen 

Dienstleister liegt. Stellt der externe Dienstleister 

zudem die Infrastruktur in seinem eigenen Rechenzentrum 

bereit, so wird diese Lösung auch als Outsourced 

Private Cloud bezeichnet – entsprechende SLAs sind 

ebenfalls selbstverständlich. 

Community Cloud: Diese Cloud ist eng verwandt mit der 

Private Cloud, die ebenfalls als Vertical (Application) 

Cloud bezeichnet wird. Sie steht ebenfalls lediglich einer 

Interessengemeinschaft zur Verfügung, unterscheidet 

sich jedoch von der Private Cloud dadurch, dass mehrere 

Organisationen (zum Beispiel zwei Unternehmen) 

Zugriff haben. 

Hybrid Cloud: Im Gegensatz zur Public Cloud gewährt 

die Hybrid Cloud wie die Private Cloud oder Community 

Cloud ebenfalls einer Interessengemeinschaft den 

Zugriff. Jedoch wird der Ansatz der Private Cloud/Community 

Cloud dahin gehend erweitert, dass im Bedarfsfall 

(zum Beispiel bei Lastspitzen) die Standardinfrastruktur 

durch Infrastruktur aus der Public Cloud ergänzt 

wird. 

Dies setzt jedoch eine sorgfältige Planung der Schwellen 

voraus. Vor allem die Provisionierung muss bedacht 

werden. Bei komplexen Systemen kann dies mehrere 

Stunden in Anspruch nehmen, bis die externen Ressourcen 

tatsächlich genutzt werden können. 

Neben den genannten Zugangsmodellen existieren weitere 

Derivate (beispielsweise Virtual Private Cloud), die 

jedoch hier im Rahmen der Grundlagen nicht skizziert 

wurden. Weiterhin wurde auf eine Diskussion der Vorund 

Nachteile der beschriebenen Modelle verzichtet. 

Hinsichtlich der Zugangsmodelle kann zwischen dem 

Consumer- und Industriegeschäft unterschieden werden. 

Aufgrund der gegebenen Randbedinungen (unter 

anderem Zertifizierung) im Industriegeschäft erlaubt 

eine Private Cloud eine einfachere Umsetzung, welche 

aber zu Lasten der Ressourceneffizienz geht – dies ist 

jedoch insbesondere der Vorteil einer Hybrid Cloud und 

Public Cloud. Bei den folgenden Ausführungen wird auf 

die Unterscheidung zwischen Private Cloud und Community 

Cloud verzichtet. Der Einfachheit halber wird 

lediglich der Begriff Private Cloud verwendet. 

1.5 Use Cases 

Im Automatisierungstechnik(AT)-Umfeld kann aus Sicht 

eines AT-Herstellers weiterhin zwischen einem AT-Kunden 

BILD 1: Cloud Computing vereint IT-Basistechnologien 

mit Geschäftsmodellen. 

BILD 3: Cloud Computing Use Cases 

BILD 2: Übersicht Cloud Stack 


1-2 / 2013 

77

HAUPTBEITRAG 

und einem IT-Dienstleister unterschieden werden. 

Beim Cloud Computing kann zwischen dem Cloud- 

Provider, dem Cloud-Kunden sowie dem Cloud- 

Endanwender unterschieden werden. Ein wichtiger 

Punkt ist die Tatsache, dass sich aufgrund der Philosophie 

von Cloud Computing vielfältige Use Cases in 

der Anwendung dieser Technologie ergeben. So können 

die genannten Rollen aus dem Umfeld der Automatisierungstechnik 

auf verschiedene Weise mit den 

Rollen aus dem Umfeld des Cloud Computing kombiniert 

werden. 

Nachfolgend sind der Use Case 4 sowie der Use Case 5 

in einer Ausprägung (etwa realisierte Private Cloud unter 

Verwendung von IaaS) erläutert, um die zuvor beschriebenen 

Grundlagen zu verdeutlichen. 

Use Case 4 – Cloud für die interne Entwicklung eines 

AT-Herstellers: Eine Ausprägung des Use Cases (Bild 3) 

ist die Realisierung als Private Cloud (1.4) in der in Bild 2 

dargestellten Kombination 1, Realisierung von IaaS. 

So kann der AT-Hersteller beispielsweise ein eigenes 

Betriebssystem auf der Basis seiner ausgewählten IaaS- 

Dienstleistungen – bereitgestellt von einem IT-Dienstleister 

– installieren und seine Anwendungen für interne 

Aufgaben bereitstellen. In diesem Fall ist der AT-Hersteller 

auch für die Wartung (wie Update des Betriebssystems) 

verantwortlich, wohingegen die Verantwortung 

bezüglich der bereitgestellten IT-Basisinfrastruktur in 

der Verantwortung des IT-Dienstleisters liegt. 

Use Case 5 – Cloud für den Kunden-Service eines AT- 

Herstellers: Eine Ausprägung dieses Use Cases 5 

(Bild 3) ist die Realisierung als Community Cloud (1.4) 

in der Kombination 5 (Bild 2) – Realisierung von PaaS 

und SaaS. 

Diese Ausprägung ermöglicht, dass der AT-Hersteller 

und -Entwickler eine PaaS-Anwendungsplattform 

(engl.: managed) auf der Basis eigener IT-Basisinfrastruktur 

zur Verfügung gestellt bekommt. Sofern es 

sich um eine konventionelle Anwendungsumgebung 

handeln würde, könnten konventionelle, auf einem 

Rechner beim AT-Kunden zu installierende Anwendungen 

entwickelt werden. Bei diesem Use Case handelt 

es sich jedoch bei der bereitgestellten PaaS-Anwendungsplattform 

um eine Entwicklungsumgebung zur 

Erstellung Web-Browser-geeigneter Software, um entsprechend 

SaaS-Anwendungen für die AT-Kunden 

bereitzustellen. Der Kunde kann sich ausschließlich 

auf die Nutzung der bereitgestellten Anwendung konzentrieren; 

unter anderem wird Wartung und Pflege 

zentral vom AT-Hersteller durchgeführt. 

2. PLS IN EINER PRIVATE CLOUD 

Aufgrund der notwendigen Randbedinungen erlaubt 

eine Privat Cloud eine einfachere Umsetzung, welche 

aber zulasten der Ressourceneffizienz geht. Dies ist jedoch 

der Vorteil einer Public Cloud. Die folgenden Abschnitte 

fokussieren auf die einfachere Realisierung 

eines PLS in der Private Cloud anstelle einer Realisierung 

in einer Hybrid Cloud oder Public Cloud (1.4). Die 

Beschreibungen erfolgen exemplarisch anhand der Engineering 

Station des PLS Simatic PCS 7. 

2.1 Überführungsvarianten 

Unabhängig von den beschriebenen Modellen des SPI- 

Ordnungsrahmens (1.3) sowie dem Zugangsmodell (1.4) 

bestehen die folgenden Migrationskonzepte, um eine existierende 

Anwendung in einer Cloud zu betreiben. 

Überführungsvariante 1: Diese Variante (Kapselung) 

setzt lediglich eine virtualisierte Infrastruktur voraus. 

Das Betriebssystem sowie die Anwendung(en) werden 

in eine virtuelle Maschine portiert. Diese virtuelle Maschine 

lässt sich auf einer kompatiblen IaaS-Cloud betreiben 

– vergleiche Kombination 1 (1.3). Der Zugriff auf 

diese erfolgt über Standardprotokolle (zum Beispiel TCP/ 

IP, HTTP, RDP). Mittels geeigneter Software ist es möglich, 

diese Software entsprechend zu transformieren, 

womit diese in einem Web-Browser nutzbar ist. Diese 

Realisierungsvariante kann der Kombination 4 beziehungsweise 

Kombination 6 (1.3) zugeordnet werden. 

Überführungsvariante 2: Eine weitere Variante (Integration) 

ist, dass die jeweilige bestehende, konventionelle 

Anwendung – auf einem Rechner installiert - 

Dienste aus der Cloud nutzt (zum Beispiel Speicher 

für Backups, Big-Data-Anwendungen). Hinsichtlich 

dieser Migrationsstrategie sind alle Kombinationen 

(1.3) realisierbar. 

Überführungsvariante 3: Bei dieser Variante (Migration) 

können bestehende Applikationen nicht portiert 

werden. Es können lediglich die Konzepte (zum Beispiel 

Prozesse, Verfahren, Algorithmen) wiederverwendet 

werden. Ausgehend von diesen Konzepten sowie 

basierend auf der bereitgestellten Anwendungsplattform 

(PaaS) sind dann die Anwendungen (SaaS) neu zu 

entwickeln. Aufgrund der notwendigen PaaS-Anwendungsplattform 

sind lediglich Kombinationen realisierbar, 

welche PaaS und SaaS vorsehen – Kombination 5, 

Kombination 6 und Kombination 7 (1.3). 

Die Überführungsvariante 3 ermöglicht, den maximalen 

Nutzen zu erzielen, den eine Cloud bietet. Es ist jedoch 

notwendig, die entsprechende/n PLS-Anwendung/en auf 

Basis von PaaS nahezu neu zu entwickeln, um sie darauf 

aufbauend als SaaS bereitzustellen – der Aufwand ist in 

Relation zu Variante 2 höher. So ermöglicht die Variante 

2 ein höheres Maß an Wiederverwendung, indem gegebenenfalls 

bestehende (Cloud-)Anwendungen um reale PaaSund/oder 

IaaS-Dienste erweitert werden. Darüber hinaus 

ist so eine Anpassung der bestehenden (Cloud-)Anwendungen 

möglich. Ist eine Erweiterung/Anpassung nicht 

notwendig, so liegt der Schluss nahe, Überführungsvariante 

1 zu verfolgen. Damit verbunden sind relativ geringer 

Aufwand mit einem verhältnismäßig guten Nutzen. 

Nicht zuletzt aus diesem Grund wurde daher die letztgenannte 

Überführungsvariante zur exemplarischen 

Umsetzung der Simatic PCS 7 Engineering Station (ES) 

in eine Private Cloud gewählt. 

2.2 Realisierungsplattform 

In Bild 5 ist eine Übersicht der aktuell gängigen Lösungen 

im Umfeld des Cloud Computings dargestellt. SaaS- 

78 


1-2 / 2013

Lösungen und -Produkte sind individuell und basieren 

gegebenenfalls auf IaaS sowie PaaS (1.3). Bekannte SaaS- 

Produkte sind Anwendungen wie Google Docs, Windows 

Live Services oder das Strato HiDrive. Für Privatanwender 

sind diese Angebote meist kostenlos und werden 

über Werbenetzwerke finanziert. Auf Anwender in Unternehmen 

zielen gewerbliche Anwendungen wie Google 

Apps for Business, Microsoft Office 365 oder die CRM- 

Anwendungen von Salesforce. 

Die überwiegende Zahl der Kunden in der Prozessautomatisierung 

setzt zur Virtualisierung – eine Basis-Technologie 

von Cloud Computing – ihres PLS den 

Hypervisor VMware ESXi ein. Daher wurden zur exemplarischen 

Überführung von Simatic PCS 7 in eine Private 

Cloud vorerst VMware-Produkte ausgewählt – weitere 

Cloud-Plattformen, wie beispielsweise Microsoft 

Azure, sind ebenfalls denkbar. Für Grundlagen hinsichtlich 

der Architektur eines PLS sei auf den ersten Teil 

dieses Beitrags zum Thema Virtualisierung verwiesen [1]. 

Nachfolgend sind die wesentlichen Komponenten der 

Realisierung mit VMware vCloud [4] beschrieben (Bild 5): 

Private Cloud Resource Pools / Public Cloud Resource: 

Die Grundlage für den Aufbau einer Private Cloud ist ein 

Pool von physikalischen Ressourcen an Server-, Netzwerk- 

und Storage-Komponenten, der Cloud Resource 

Pool. Ergänzt werden kann dieser Pool durch Ressourcen 

einer Public-Cloud, die dann auch als Hybrid-Cloud bezeichnet 

wird (1.4). 

Als Virtualisierungsschicht dient der vSphere-Hypervisor 

(auf ESXi-Basis). Diese Schicht ist die Grundlage 

für die weiteren VMware-Produkte, die zum Aufbau einer 

Private Cloud benötigt werden [1]. 

Die sogenannte Automatisierungsschicht wurde realisiert 

durch VMware vCenter Server. Es organisiert die 

von der VMware vSphere Virtualization Platform abstrahierten 

Cloud Ressourcen. 

Die sogenannte Self-Service-Automation-Schicht ermöglicht 

dem Cloud-(End-)Kunden die Verwaltung der 

Cloud-Ressourcen mittels eines Self-Service-Portals. 

Diese Schicht wurde hier mit dem VMware vCloud Director 

implementiert. Mit Hilfe des VMware vCloud Directors 

greift der Cloud Provider auf die vom vCenter 

Server bereitgestellten Ressourcen zu und stellt diese 

entsprechend organisiert in virtuellen Rechenzentren 

bereit. Der Cloud-Kunde kann dieses von ihm angeforderte 

virtuelle Rechenzentrum nutzen. 

Auf der Basis dieser Schichten ist es möglich, die drei 

in Abschnitt 2.1 genannten Überführungsvarianten zu 

realisieren. Dazu werden weitere entsprechende Komponenten 

bereitgestellt. 

Die Realisierung erfolgte exemplarisch auf Basis der 

genannten VMware vCloud-Lösung. 

Ausgehend von der dritten Variante (2.1) ist die Engineering 

Station (ES) von Simatic PCS 7 in eine Private 

Cloud überführt worden. Es handelt sich um die 

Kombination 6 (1.3) und den Use Case 2 (1.5). 

2.3 Umsetzung 

Die ES wurde zur Darstellung in diesem Beitrag ausgewählt, 

da sie als möglicher Kandidat beispielhaft für die 

Vorteile einer Anwendung in der Cloud steht. So wird 

eine ES beispielsweise während der zeitlich relativ kurzen 

Engineering Phase genutzt – in der verhältnis mäßig 

langen Betriebsphase einer Anlage in der Prozessindustrie 

eher weniger. 

In Bild 6 ist die Umsetzung der Überführung der ES 

von Simatic PCS 7 basierend auf VMware skizziert – die 

OS und MS werden lediglich als weitere PLS-Komponenten 

aufgeführt. Als Private Cloud Resource Pool 

stand die Hardware der SmartAutomation Karlsruhe 

BILD 4: Cloud-Dienste 

BILD 5: 

Simatic PCS 7 auf 

der Basis der 

VMware vCloud- 

Lösung 


1-2 / 2013 

79

HAUPTBEITRAG 

(SmA Khe) zur Verfügung. Dabei handelt es sich um einen 

Fujitsu Server TX300 S6 (1 Intel Xeon X5660 mit 

sechs Kernen à 2,8 GHz, 32 GB RAM) [1]. Auch wenn ein 

Server im eigentlichen Sinne noch keine Cloud bildet, 

ist dies hinsichtlich der prinzipiellen Funktionstests 

zunächst ausreichend. Die von der VMware vSphere Virtualization 

Platform abstrahierten Cloud Ressourcen 

wurden mittels VMware vCloud Director entsprechend 

bei VMware vCenter Server bestellt und von dort bereitgestellt. 

Diese Schichten bilden die Grundlage für die 

VM. Eine VM repräsentiert die ES. Ausgehend von der 

gewählten Überführungsvariante 1 (2.1) wurde die bestehende 

ES-Anwendung in eine VM transformiert. 

2.4 Retrospektive 

Grundsätzlich kann, wie auch im Umfeld der IT, für die 

(Prozess-)Automatisierung als Vorteil aufgeführt werden, 

dass es mithilfe von Cloud Computing möglich ist, ausgewählte 

Investitionskosten auf die Betriebs- beziehungsweise 

Anlagenlaufzeit abzuschreiben – eine Umverteilung 

von Investitions- zu Betriebskosten. So können 

beispielsweise zu Beginn eines Projektes die Kosten für 

gewisse Werkzeuge entfallen, da sie bei Bedarf angefordert 

und wie im SLA vereinbart verrechnet werden. Weiterhin 

ist aufzuführen, dass für den jeweiligen Cloud- 

Endanwender, siehe Bild 3, in der (Prozess-)Automatisierung 

geringere Aufwände für Pflege und Wartung der 

Infrastruktur anfallen können; zum Beispiel aufgrund 

von zentral ausgeführten Updates und Upgrades. Dieser 

grundsätzliche Fakt kann bereits aufgrund der gemachten 

Erfahrungen im Rahmen der praktischen Umsetzung bestätigt 

werden – notwendige Updates konnten zentral 

eingespielt werden und standen jedem, im Rahmen der 

Vorfeldtests jedem fiktiven AT-Endkunden, sofort zur 

Verfügung. Als weiterer Fakt ist zu nennen, dass gewonnene 

Erkenntnisse bei der Überführung von bestehenden 

PLS-Komponenten in virtueller Umgebung im Allgemeinen 

wertvoll waren; im Speziellen hinsichtlich der virtuellen 

Umgebung von VMware – beispielsweise hinsichtlich 

der Konfiguration der Kommunikationsbeziehungen 

in virtueller Umgebung. Prinzipiell ist zu sagen, 

dass es keine grundsätzlichen Einschnitte bezüglich der 

ES-Funktionalität (zum Beispiel Projektierung, Offline- 

Planung) gab hinsichtlich Simatic PCS 7 in einer Private 

Cloud basierend auf VMware vCloud. 

Gesamtheitlich kann der vielfach genannte Nutzen im 

Kontext des Cloud Computings jedoch noch nicht bestätigt 

werden, da Langzeiterfahrungen fehlen. Tatsache ist 

zudem, dass noch keine belastbaren Aussagen zu wesentlichen 

Anforderungen in der (Prozess-)Automatisierung 

wie beispielsweise Zuverlässigkeit und Performanz getroffen 

werden können. 

ZUSAMMENFASSUNG UND AUSBLICK 

Im Kontext von Cloud Computing stehende, bereits existierende 

Ansätze (zum Beispiel Application Service 

Providing, Grid Computing, Virtualisierung) erwecken 

den Eindruck, dass Cloud Computing nichts Neues zu 

sein scheint. Abstrakt betrachtet resultiert aus der Kombination 

der Ansätze das Cloud Computing. Aus der 

Kombination heraus scheint jedoch „Alles“ – zumindest 

doch „Vieles“, möglich zu sein. So existieren drei 

Dimensionen: SPI-Ordnungsrahmen, Zugangsmodelle 

und Use Cases. Grundsätzlich sieht der SPI-Ordnungsrahmen 

die drei individuell kombinierbaren Modelle 

Infrastructure-as-a-Service (IaaS), Platform-as-a-Service 

(PaaS) und Software-as-a-Service (SaaS) vor. Eine weitere 

Dimension bilden die vier Zugangsmodelle Public 

Cloud, Private Cloud, Community Cloud und Hybrid 

Cloud. Zuletzt ist die Dimension Use Case entscheidend. 

Ein triviales Beispiel für einen Use Case ist, dass ein 

AT-Hersteller sowohl als Cloud-Provider, Cloud-Kunde 

und Cloud-Endkunde auftreten kann. Alle drei Dimensionen 

bilden einen Lösungsraum mit Nullstellen. Werden 

die verschiedenen Punkte der drei Dimensionen 

geschickt miteinander kombiniert, so kann einerseits 

vielfältiger Nutzen daraus resultieren – flexiblere und 

individuellere Bereitstellung von Software. Andererseits 

resultieren daraus auch Herausforderungen – wie 

Sicherstellung der notwendigen Performanz (beispielsweise 

Bandbreite, Rechen- und Speicherressourcen). 

Grundsätzlich kann bei den Zugangsmodellen zwischen 

dem Consumer- und Industriegeschäft unterschieden 

werden. Aufgrund der gegebenen Randbedinungen 

(unter anderem Zertifizierung) im Industriegschäft erlaubt 

eine Private Cloud eine einfachere Umsetzung. 

REFERENZEN 

[1] Runde, S.; Schneider, M.; Glaser, S., Thieme, S.: IT im Kontext 

der Prozessleittechnik – Teil 1: Virtualisierung. atp edition – 

Automatisierungstechnische Praxis 55(1), S. 28-36, 2013.. 

[2] Käfer, G.: Cloud Computing Architecture. Verfügbar unter: 

http://www.sei.cmu.edu/saturn/2010/, zuletzt geprüft am: 

20.01.2013. 

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

Automatisierungstechnische Architektur in der Prozessindustrie 

mit Leitsystem in virtueller Umgebung. In: 

Tagungsband Automation 2011, S. 28-35. VDI, 2011. 

[4] VMware. Verfügbar unter: http://www.vmware.com/de/. 

Zuletzt geprüft am: 14.01.2013. 

[5] National Institute of Standards and Technology (NIST): 

The NIST Definition of Cloud Computing. Verfügbar unter: 

http://csrc.nist.gov/publications/nistpubs/800-145/ 

SP800-145.pdf, zuletzt geprüft am: 14.01.2013. 

[6] Vossen, G., Haselmann, T., Hoeren T.: Cloud-Computing für 

Unternehmen. Technische, wirtschaftliche, rechtliche und 

organisatorische Aspekte. dpunkt-Verl., Heidelberg, 2012. 

[7] Runde, S: Wissensbasierte Engineeringunterstützung in 

der Automatisierungstechnik am Beispiel der Gebäudeautomation. 

Fortschritt-Berichte VDI Reihe 20 Nr. 434: 

Rechnergestützte Verfahren. Düsseldorf: VDI Verlag 2011. 

[8] Schlesinger, D.: Automatisieren in der Wolke? Automatisierung 

& Messtechnik - Sonderheft 2012, S. 8–9. 2012 

[9] Inductive Automation: Cloud-Based SCADA Systems – 

the Benefits & Risks. Is Moving Your SCADA System to the 

Cloud Right For Your Company? Verfügbar unter: 

http://files.inductiveautomation.com/whitepapers/ 

WhitePaper-Cloud-Based-SCADA-Systems.pdf, zuletzt 

geprüft am: 14.01.2013 

80 


1-2 / 2013

Diese einfacherer Umsetzung geht aber zu Lasten der 

Ressourceneffizienz, die insbesondere der Vorteil einer 

Hybrid Cloud und Public Cloud ist. Ausgehend von dieser 

Situation wurde für einen prinzipiellen Funktionstest 

die Engineering Station von Simatic PCS 7 in eine 

Private Cloud überführt. Bei der Anwendung dieser Simatic 

PCS 7-Komponente konnten keine grundsätzlichen 

Einschnitte bezüglich Funktionalität (zum Beispiel Projektierung, 

Offline-Planung) festgestellt werden. Gesamtheitlich 

kann der suggerierte Nutzen noch nicht bestätigt 

werden, da Langzeiterfahrungen fehlen. Der Nutzen 

hinsichtlich einer vereinfachten Durchführung von Updates, 

Upgrades etc. zeigte sich jedoch. 

In Zukunft sind weitere PLS-Komponenten wie MS, 

OS in der Cloud zu realisieren, um technische und 

nichttechnische Aspekte besser bewerten zu können. Es 

sind noch viele offene Punkte zu klären, um belastbare 

Aussagen zu wichtigen Anforderungen in der (Prozess-) 

Automatisierung, wie etwa Zuverlässigkeit und Performanz, 

treffen zu können. Exemplarisch seien zudem die 

Aspekte Security und Compliance genannt. In einer 

Cloud können große Mengen verschiedener, teilweise 

sensibler Daten und Informationen gespeichert werden. 

So werden Cloud-Plattformen zu einem interessanten 

Ziel für interne und/oder externe Angreifer. Cloud-spezifische 

Security-Aspekte (Verfügbarkeit, Integrität, Vertraulichkeit, 

Authentizität und Verbindlichkeit) sind 

mit Bezug zu der jeweiligen Organisationsform/Bereitstellungsmodell 

(1.4) zu berücksichtigen. Mit dem Thema 

Security geht der Komplex Compliance einher. Zur 

Compliance gehören die Einhaltung der gesetzlichen, 

unternehmensinternen und vertraglichen Regelungen, 

der Datenschutz, das Risiko-Management, der rechtliche 

Rahmen und die Governance. 

Werden Cloud-Dienste verwendet, insbesondere in der 

Public Cloud, so ist die Einhaltung der Compliance eine 

weitere Herausforderung. 

DANKSAGUNG 


18.09.2012 


Die Autoren danken dem Experten für Cloud Computing 

Herrn Dr. Gerald Käfer für das Reviewen des 

Beitrags. Er untersucht die Relevanz und Auswirkung 

von „Software as a Service“ und Cloud Computing für 

das zukünftige Produkt- und Servicegeschäft. Sein 

Themenfeld der letzten Jahre war schwerpunktmäßig 

Cloud Computing im Enterprise-IT-Umfeld. 

AUTOREN 

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

absolvierte ein Informa tik-Studium an der Hochschule 

Karlsruhe. Er ist in der Vorfeldentwicklung 

als Teilprojektleiter im Projekt „Future DCS Architectures“ 

zuständig für das Thema Integration von 

IT-Trends in der Prozessautomatisierung, wie zum 

Beispiel Virtualisierung oder Cloud Computing. 

Siemens AG, Sector Industry, 

Advanced Technologies and Standards, 

Östliche Rheinbrückenstrasse 50, 


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

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

Vorfeldentwicklung Projektleiter für das Thema 

„Future DCS Architecture“ und Programm Manager 

für das Themenfeld „PC-based Architecture“. Nach 

der Ausbildung zum Energieelektroniker, studierte 

er Elektro- und Informationstechnik an der FH 

Hannover und promovierte an der Helmut-Schmidt- 

Universität Hamburg. Aktuelle Schwerpunkte seiner 

Arbeit sind die Verbesserung von Engineering und 

Architekturen im Umfeld von SCADA und PLS. 

Siemens AG, 

Sector Industry, Advanced Technologies and Standards, 



E-Mail: stefan.runde@siemens.com 

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

im Simatic PCS 7-Produktmanagement die 

Gruppe „Software & Innovation“ und ist als 

Projekt familienleiter „DCS SW-Products“ tätig. 

Er studierte Elektrotechnik an der TH Karlsruhe 

und beschäftigt sich seit vielen Jahren 

mit der Entwicklung von PLS, insbesondere 

mit dem Fokus auf neue Technologien für die 

Innovation von PLS. 

Siemens AG, 

Sector Industry, Industry Automation, 



E-Mail: martin.glaser@siemens.com 

M. Sc. STEFAN GERACH (geb. 1983) studierte 

nach der Ausbildung zum Fachinformatiker – 

Fachrichtung Systemintegration Informatik 

an der HS Karlsruhe. Seine Masterarbeit 

(„Cloud Computing im Kontext der Prozess 

automatisierung“) schrieb er in der Abteilung 

Advanced Technologies and Standards des 

Sektors Industry der Siemens AG. 

Siemens AG, 

Industry Sector, Customer Services Division, 

Siemensallee 84, 


E-Mail: stefan.gerach@siemens.com 


1-2 / 2013 

81

IMPRESSUM / VORSCHAU 

IMPRESSUM 

VORSCHAU 

Verlag: 

DIV Deutscher Industrieverlag GmbH 

Arnulfstraße 124, 80636 München 

Telefon + 49 89 203 53 66-0 

Telefax + 49 89 203 53 66-99 

www.di-verlag.de 

Geschäftsführer: 

Carsten Augsburger, Jürgen Franke 

Spartenleiterin: 

Anne Hütter 

Herausgeber: 

Dr.-Ing. Thomas Albers 

Dr. Gunther Kegel 

Dipl.-Ing. Georg Kumpfmüller 

Dr.rer.nat. Norbert Kuschnerus 

Beirat: 

Dr.-Ing. Kurt Dirk Bettenhausen 

Prof. Dr.-Ing. Christian Diedrich 

Prof. Dr.-Ing. Ulrich Epple 

Prof. Dr.-Ing. Alexander Fay 

Prof. Dr.-Ing. Michael Felleisen 

Prof. Dr.-Ing. Georg Frey 

Prof. Dr.-Ing. Peter Göhner 

Dipl.-Ing. Thomas Grein 

Prof. Dr.-Ing. Hartmut Haehnel 

Dr.-Ing. Jörg Kiesbauer 

Dipl.-Ing. Rolf Marten 

Dipl.-Ing. Gerald Mayr 

Dr. Jörg Nothdurft 

Dr.-Ing. Josef Papenfort 

Dr. Andreas Wernsdörfer 

Dipl.-Ing. Dieter Westerkamp 

Dr.rer.nat. Christian Zeidler 

Organschaft: 

Organ der GMA 

(VDI/VDE-Gesell schaft Messund 

Automatisierungs technik) 

und der NAMUR 

(Interessen gemeinschaft 

Automatisierungs technik der 

Prozessindustrie). 

Redaktion: 

Anne Hütter (ahü) 

(verantwortlich) 

Telefon + 49 89 203 53 66-58 

Telefax + 49 89 203 53 66-99 

E-Mail: huetter@di-verlag.de 

Gerd Scholz (gz) 

Einreichung von Hauptbeiträgen: 

Prof. Dr.-Ing. Leon Urbas 

(Chefredakteur, verantwortlich 

für die Hauptbeiträge) 

Technische Universität Dresden 

Fakultät Elektrotechnik 

und Informationstechnik 

Professur für Prozessleittechnik 

01062 Dresden 

Telefon +49 351 46 33 96 14 

E-Mail: urbas@di-verlag.de 

Fachredaktion: 

Dr.-Ing. Michael Blum 

Dipl.-Ing. Heinrich Engelhard 

Prof. Dr.-Ing. Jürgen Jasperneite 

Dr.-Ing. Bernhard Kausler 

Dr.-Ing. Niels Kiupel 

Dr.-Ing. Gerrit Meixner 

Dr.-Ing. Jörg Neidig 

Dipl.-Ing. Ingo Rolle 

Dr.-Ing. Stefan Runde 

Prof. Dr.-Ing. Frank Schiller 

Bezugsbedingungen: 

„atp edition – Automatisierungstechnische 

Praxis“ erscheint 

monatlich mit Doppelausgaben im 

Januar/Februar und Juli/August. 

Bezugspreise: 

Abonnement jährlich: € 468,– + € 30,–/ 

€ 35,- Versand (Deutschland/Ausland); 

Heft-Abbonnement + Online-Archiv: 

€ 638,40; ePaper (PDF): € 468,–; 

ePaper + Online-Archiv: € 608,40; 

Einzelheft: € 55,– + Versand; 

Die Preise enthalten bei Lieferung 

in EU-Staaten die Mehrwertsteuer, 

für alle übrigen Länder sind es 

Nettopreise. Mitglieder der GMA: 30% 

Ermäßigung auf den Heftbezugspreis. 

Bestellungen sind jederzeit über den 

Leserservice oder jede Buchhandlung 

möglich. 

Die Kündigungsfrist für Abonnementaufträge 

beträgt 8 Wochen zum Bezugsjahresende. 

Abonnement-/ 

Einzelheftbestellung: 

Leserservice atp 

Postfach 91 61, 97091 Würzburg 

Telefon + 49 931 41 70-4 94 

Telefax + 49 931 41 70-4 92 

E-Mail: leserservice@di-verlag.de 

Verantwortlich für 

den Anzeigenteil: 

Inge Matos Feliz 

Telefon + 49 89 203 53 66-22 

Telefax + 49 89 203 53 66-99 

E-Mail: matos.feliz@di-verlag.de 

Es gelten die Preise der Mediadaten 2013 

Anzeigenverwaltung: 

Brigitte Krawczyk 

Telefon + 49 89 2 03 53 66-12 

Telefax + 49 89 2 03 53 66-99 

E-Mail: krawczyk@di-verlag.de 

Art Direction / Layout: 

deivis aronaitis design | dad | 

Druck: 

Druckerei Chmielorz GmbH 

Ostring 13, 

65205 Wiesbaden-Nordenstadt 

Gedruckt auf chlor- und 

säurefreiem Papier. 

Die atp wurde 1959 als „Regelungstechnische 

Praxis – rtp“ gegründet. 

DIV Deutscher Industrieverlag 

GmbH München 

Die Zeitschrift und alle in ihr enthaltenen 

Beiträge und Abbildungen sind urheberrechtlich 

geschützt. Mit Ausnahme der 

gesetzlich zugelassenen Fälle ist eine 

Verwertung ohne Ein willigung des Verlages 

strafbar. 

Gemäß unserer Verpflichtung nach § 8 

Abs. 3 PresseG i. V. m. Art. 2 Abs. 1c DVO 

zum BayPresseG geben wir die Inhaber 

und Beteiligungsverhältnisse am Verlag 

wie folgt an: 

DIV Deutscher Industrieverlag GmbH, 

Arnulfstraße 124, 80636 München 

Alleiniger Gesellschafter des Verlages 

ist die ACM-Unternehmensgruppe, 

Ostring 13, 

65205 Wiesbaden-Nordenstadt 

ISSN 2190-4111 

DIE AUSGABE 3 / 2013 DER 

ERSCHEINT AM 04.03.2013 

MIT DEM SCHWERPUNKT „APPS, SMARTPHONES 

UND TABLETS IM INDUSTRIELLEN EINSATZ“ 

Gamification in kollaborativen 

Produktionsnetzwerken – 

Chancen und Risiken 

Das Smartphone als 

universelles Diagnosegerät – 

Benutzerfreundliches Konzept 

zur Fehlerdiagnose 

Smartphones und Tablets in der 

industriellen Produktion – 

Nutzerfreundliche Bedienung 

von Feldgeräten 

Kontextsensitive UIs für die 

Fabrik von morgen 

App-Orchestrierung – Vernetzte 

Apps für komplexe Aufgaben 

Aus aktuellem Anlass können sich die Themen 

kurzfristig verändern. 

LESERSERVICE 

E-MAIL: 

leserservice@di-verlag.de 

TELEFON: 

+ 49 931 41 70-4 94 

82 


1-2 / 2013

Erreichen Sie die Top-Entscheider 

der Automatisierungstechnik. 

Sprechen Sie uns an wegen Anzeigenbuchungen 

und Fragen zu Ihrer Planung. 

Inge Matos Feliz: Tel. +49 89 203 53 66-22 

E-Mail: matos.feliz@di-verlag.de

atp kompakt 

Methoden Verfahren Konzepte 

Sonderpreise 

für 

Abonnenten 

der atp edition 

Die Automatisierungstechnik wird durch neue Forschungen und Entwicklungen bestimmt. Damit Ingenieure 

fit für ihren Job sind und die entscheidenden Trends in der Automatisierungstechnik schnell zur Hand haben, 

legt die Fachpublikation atp edition die Buchreihe atp kompakt auf. Alle darin enthaltenen Beiträge haben 

ein wissenschaftliches Gutachterverfahren durchlaufen. 

Herausgeber Prof. Dr.-Ing. Frank Schiller leitet am Lehrstuhl für Informationstechnik im Maschinenwesen der 

TU München das Fachgebiet Automatisierungstechnik. 

atp kompakt Band 1 

Erfolgreiches Engineering – Die wichtigsten Methoden 

Diese Ausgabe befasst sich mit den Methoden, Verfahren und Standards, die Sie in den nächsten Jahren im Engineering beschäftigen 

werden. Wichtige Kriterien sind die einfache Wiederverwendbarkeit von Komponenten, die Unterstützung durch geeignete Werkzeuge, 

die Erhöhung der Flexibilität von Anlagen sowie geeignete Modellierungs- und Gerätebeschreibungssprachen. 

1. Auflage 2010, 138 Seiten mit CD-ROM, Broschur, € 79,- • ISBN: 978-3-8356-3210-3 

Für Abonnenten 

€ 74,- 


Effiziente Kommunikation – Die bedeutendsten Verfahren 

Sie bekommen Einblick in die wachsende Bedeutung der industriellen Kommunikation und dem Wandel in der Gerätekommunikation. 

Einen Schwerpunkt bildet die Kommunikationstechnik in der Prozessautomatisierung mit deren besonderen Rahmenbedingungen wie 

dem Explosionsschutz. Die bedeutendsten Verfahren und Methoden der modernen Kommunikation werden praxisnah veranschaulicht. 



€ 54,- 


Praktische Messtechnik – Die besten Konzepte 

Dieser Band vermittelt wertvolles Know-how zu allen Aspekten der praktischen Messtechnik und fokussiert besonders die Prozessmesstechnik. 

Lernen Sie die Fortschritte in der Sensortechnik entlang der Technologie-Roadmap kennen und profitieren Sie von erstklassigen 

Konzepten zu kostengünstigen und effizienten Lösungen. 



€ 54,- 

atp kompakt Kollektion (Bände 1-3) 

Erfolgreiches Engineering Effiziente Kommunikation Praktische Messtechnik 

Mit dieser dreibändigen Kollektion zu den Themen Engineering, Kommunikation und Messtechnik erhalten Sie ein nützliches, 

kompakt und praxisnah aufbereitetes Kompendium zu den Kernthemen der Automatisierungstechnik. Die wertvolle Grundlage 

für Ihre tägliche und zukünftige Arbeit. 

1. Auflage 2010, ca. 282 Seiten mit CD-ROM, Broschur • € 179,- • ISBN: 978-3-8356-3221-9 


€ 169,- 

Sofortanforderung im Online-Shop www.di-verlag.de 

oder telefonisch +49 (0)201 / 82002-14

atp edition Automatisierung im Life Cycle modularer Anlagen (Vorschau)

Erfolgreiche ePaper selbst erstellen