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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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-

atp edition

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

atp edition

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.

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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.

atp edition

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

atp edition

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-

atp edition

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

atp edition

1-2 / 2013

27

atp edition

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

atp edition

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

atp edition

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.

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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.

MANUSKRIPTEINGANG

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

Temperatur [K]

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

atp edition

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.

Temperatur [K]

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

Standardabweichung

σ 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

Standardabweichung

σ N

ı

2

2

Standardabweichung σ N


Signal x

Signal y i

σ 2

y 2

N

i TPF 1

Standardabweichung

σ 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

Standardabweichung

σ N,1

Konst.1

Standardabweichung


Standardabweichung

Konst.2

σ N,2

σ NS,1

σ NS,2

Standard -

abweichung

σ NS

Trend

BILD 5: Rekursives Tiefpassfilter und Differenzierer

42

atp edition

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

Standardabweichung

Konst.1 σ NS,1

0 1000 2000 3000 4000 5000

Rausch-

Standardabweichung

Signal y i,2

HPF


Standardabweichung

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

Temperatur [K]

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

MANUSKRIPTEINGANG

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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-

atp edition

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

atp edition

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!“

MANUSKRIPTEINGANG

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

=


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


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

atp edition

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

_ neu g _ min_ neu

= *

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

i _ neu _ normal

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

atp edition

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

*

i _ neu _ normal

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

*

i _ neu _ normal

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

_ neu g _ min_ neu

niZeile

(

2

*

ni

ln

ni

_ neu i _ max_ neu

ng

_ neu g _ min_ neu

i _ neu _ normal

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.

i _ neu _ normal

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 )

atp edition

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

= i _ betr1 * pi

= 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

= i _ betr1 * pi

= 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

atp edition

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.

MANUSKRIPTEINGANG

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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:

atp edition

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

atp edition

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


atp edition

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

atp edition

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

HeatingTime::

ISA95PropertyType

HasISA95

Property

Third Party Instance Example

HeatingReactorClass

BelongsTo

HR1001

HasISA95

ClassProperty

HeatingTime::

ISA95ClassPropertyType

HeatingTime::

ISA95PropertyType

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

atp edition

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

atp edition

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.

MANUSKRIPTEINGANG

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

atp edition

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

atp edition

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.

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

atp edition

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

MANUSKRIPTEINGANG

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,

D-76187 Karlsruhe, Tel. +49 (0) 721 595 61 13,

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,


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

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,


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

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,

D-76187 Karlsruhe, Tel. +49 (0) 721 595 15 39,

E-Mail: stefan.gerach@siemens.com

atp edition

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

atp edition

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.


Für Abonnenten

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


Für Abonnenten

€ 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

Für Abonnenten

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

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

Template löschen?

Als Template speichern?