atp edition Betriebliche Mitbenutzung von SIS-Komponenten (Vorschau)
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
7-8 / 2012<br />
54. Jahrgang B3654<br />
Oldenbourg Industrieverlag<br />
Automatisierungstechnische Praxis<br />
<strong>Betriebliche</strong> <strong>Mitbenutzung</strong> <strong>von</strong><br />
<strong>SIS</strong>-<strong>Komponenten</strong> | 26<br />
Überwachung <strong>von</strong> Prozessen<br />
mit kleiner Losgröße | 34<br />
Kernmodelle für die<br />
Systembeschreibung | 40<br />
Vorgehensmodellierung im<br />
Anlagen-Engineering | 50<br />
Modellbasierte<br />
Software-Entwicklung | 60<br />
Automatische Wertebereichsanalyse | 68<br />
Mensch-Maschine-Schnittstelle<br />
im demografischen Wandel | 76
Print wirkt<br />
„<strong>atp</strong> <strong>edition</strong>“ ist ein Printtitel auf höchster<br />
Qualitätsstufe und mit Nachhaltigkeit im<br />
Sinne wiederkehrender Nutzung. Der Titel<br />
erfüllt den selbstgestellten Anspruch eines<br />
anspruchsvollen und seriösen Magazins für<br />
Top-Entscheider zwischen Wissenschaft<br />
und Praxis konsequent.<br />
Entsprechend der journalistischen Konzeption<br />
ist Online hintenangestellt. Die Jury<br />
sah hier „die beispielhafte Umsetzung einer<br />
wissenschaftlich ausgerichteten Fachzeitschrift<br />
mit Magazincharakter“.
editorial<br />
Industrie 4.0 = Automation<br />
Made in Germany<br />
Deutschland hat bei der derzeit proklamierten vierten industriellen Revolution<br />
„Industrie 4.0“ ausgezeichnete Voraussetzungen. Warum? Weil wir<br />
seit langem die Möglichkeiten der industriellen Kommunikations- und Informationstechnologie<br />
(IKT) für die Anwendung in der Automatisierungstechnik<br />
konsequent und systematisch entwickeln und nutzen. Die derzeitige Entwicklung<br />
im Hinblick auf Vernetzung und Allgegenwärtigkeit jeglicher Information<br />
wird der Automation einen Schub geben und neue Möglichkeiten eröffnen.<br />
Das Ziel der Automatisierung ist und bleibt der wunschgemäße, sichere,<br />
zuverlässige und effiziente Betrieb <strong>von</strong> Anlagen, etwa in der Produktion, der<br />
Energieerzeugung, der Medizin-, Verkehrs- und Umwelttechnik. Die Nutzung<br />
zusätzlicher Informationen, die zukünftig über weitere Sensoren, eingebettete<br />
Systeme und zugehörige Vernetzung zur Verfügung stehen, dient diesem<br />
Ziel und eröffnet neue Möglichkeiten.<br />
Daher unterstützen wir die Initiative „Industrie 4.0“ im Rahmen der Hightech-Strategie<br />
der Bundesregierung. „Industrie 4.0“ bedeutet konsequente Automation.<br />
Wir werden die aktuellen Trends aus der IKT nutzen und gezielt für<br />
die industrielle Automation weiterentwickeln. Darunter fallen unter anderem<br />
der Ausbau <strong>von</strong> Sensor- und Kommunikationsnetzen, die Vernetzung <strong>von</strong><br />
Anlagen, die Verfügbarkeit, Transparenz und Sicherheit <strong>von</strong> Daten, die übersichtliche<br />
Visualisierung <strong>von</strong> Anlagenzuständen sowie die einfache und intuitive<br />
Bedienung <strong>von</strong> Anlagen.<br />
Eines jedoch muss uns klar sein: Die Anlagen der „Industrie 4.0“ mit den<br />
oben beschriebenen Eigenschaften werden komplexer sein als die Anlagen,<br />
die wir heute kennen und nutzen.<br />
„Komplexität beherrschen – Zukunft sichern“ war das Motto des diesjährigen<br />
Kongresses Automation 2012 (13. und 14. Juni in Baden-Baden). Wir haben<br />
die GMA-Mitglieder befragt, wie sie Komplexität wahrnehmen und wie sie<br />
damit umgehen. Über 600 Mitglieder haben sich daran beteiligt. Die Antworten<br />
ergaben, dass Komplexität für uns Automatisierer ein aktuelles Thema ist,<br />
dass Komplexität stetig zunimmt und dass Ingenieure in Deutschland darauf<br />
gut vorbereitet sind.<br />
Auf der anderen Seite haben wir ermittelt, dass 48 Prozent der Befragten<br />
Komplexität als Problemstellung wahrnehmen. Fast 36 Prozent gaben an, Komplexität<br />
als Belastung zu empfinden – das, liebe Leser, kann auf Dauer nicht<br />
gut sein. Dies bedeutet für die Hersteller und Integratoren, Geräte, Systeme<br />
und Anlagen entsprechend zu planen und zu errichten sowie sich auf anerkannte<br />
Standards zu verständigen und diese konsequent anzuwenden. „Weniger<br />
ist mehr“ lautet hier die Forderung und es gilt das Richtige richtig zu<br />
tun! Nicht das zusätzliche Funktionsmerkmal sondern die anwenderfreundliche<br />
Bedienung mit zuverlässiger Funktion muss das Designziel für „Industrie<br />
4.0“ und damit „Automation Made in Germany“ sein.<br />
In der vorliegenden Ausgabe der <strong>atp</strong> <strong>edition</strong> finden Sie ausgewählte Beiträge<br />
unseres Kongresses Automation 2012 – ich wünsche Ihnen viele Anregungen<br />
und neue Ideen beim Lesen. Bitte notieren Sie sich schon heute den Termin für<br />
den nächsten Kongress Automation am 25. und 26. Juni 2013 in Baden-Baden.<br />
Dr.-Ing. Kurt D.<br />
Bettenhausen<br />
Vorsitzender der VDI/VDE-<br />
Gesellschaft Mess- und Automatisierungstechnik<br />
(GMA)<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012<br />
3
Inhalt 7-8 / 2012<br />
Forschung<br />
6 | TU Dresden entwickelt weltweit ersten chemischen Mikroprozessor<br />
Fraunhofer investiert Millionen in<br />
Forschungszentrale für Informationssicherheit<br />
7 | Nanokomposites: Auf dem Weg zum flexiblen Bildschirm<br />
Verband<br />
Modulation <strong>von</strong> Plattformen für optimalen Produktlebenszyklus<br />
8 | Integrierte Digitale Anlagenplanung:<br />
Wissenschaftliche Beiträge für Symposium gesucht<br />
Teigeler ist neuer DKE-Geschäftsführer<br />
China will zum globalen Technologieführer werden<br />
9 | Namur-Arbeitsblatt NA 140 berät zur Steigerung <strong>von</strong><br />
Energieeffizienz in Chemieanlagen<br />
branche<br />
10 | Europäische Schuldenkrise verunsichert<br />
deutsche Elektroindustrie im ersten Halbjahr<br />
VDI-Konferenz: Prozessmesstechnik an Biogasanlagen<br />
aus Theorie und Praxis<br />
75. Namur-Hauptversammlung dreht sich um Anfänge und<br />
Zukunftspotenzial <strong>von</strong> Aktorik<br />
11 | <strong>atp</strong> <strong>edition</strong> ist bestes Fachmedium 2012<br />
12 | Automation 2012: Komplexität beherrschen und<br />
Ingenieur-Nachwuchs praxisorientiert vorbereiten<br />
16 | FDI-Projekt für einheitliche Geräteintegration<br />
geht in die nächste Runde<br />
rubriken<br />
3 | Editorial<br />
82 | Impressum, <strong>Vorschau</strong><br />
4<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012
Praxis<br />
18 | Effiziente Erfassung und Übertragung <strong>von</strong><br />
Testdaten ermöglicht umgehende Reaktionen<br />
20 | Prozesssteuerung erfüllt strenge Pharma-Regeln<br />
und lässt sich individuell konfigurieren<br />
22 | Datenerfassungssystem macht die Produktion in<br />
Stanz- und Biegemaschinenanlage effizienter<br />
24 | Intensiv genutzte Datennetzwerke benötigen<br />
nicht erst seit Stuxnet leistungsfähige und<br />
sichere <strong>Komponenten</strong><br />
Hauptbeiträge<br />
26 | <strong>Betriebliche</strong> <strong>Mitbenutzung</strong> <strong>von</strong><br />
<strong>SIS</strong>-<strong>Komponenten</strong><br />
T. Gabriel, G. Versteegen und B. Schrörs<br />
34 | Überwachung <strong>von</strong> Prozessen<br />
mit kleiner Losgröße<br />
M. Kaupp und J. Neher<br />
40 | Kernmodelle für die Systembeschreibung<br />
D. Kampert und U. ePPle<br />
50 | Vorgehensmodellierung im<br />
Anlagen-Engineering<br />
S. Sokolov, H.- P. Fichtner, Z. Cihlar, M. Kaiser und C. Diedrich<br />
60 | Modellbasierte Software-Entwicklung<br />
D. Kuschnerus, M. Gerding, A. Bilgic und T. Musch<br />
68 | Automatische Wertebereichsanalyse<br />
S. Biallas, S. Kowalewsk und B. Schlich
forschung<br />
TU Dresden entwickelt weltweit<br />
ersten chemischen Mikroprozessor<br />
An der Technischen Universität Dresden ist erstmals<br />
die Entwicklung eines chemischen Mikroprozessors<br />
gelungen. Im Gegensatz zum bekannten Mikroprozessor,<br />
der elektronische Information verarbeitet, regelt der chemische<br />
Mikroprozessor Materieflüsse. Das Schaltkreis-<br />
Konzept ähnelt dem der mikroelektronischen Prozessoren.<br />
Die chemischen Schaltkreise bestehen aus übereinander<br />
gestapelten dünnen Schichten aktiver Materialien.<br />
Allerdings kommen nicht dotierte aktive<br />
elektronische Halbleitermaterialien wie Silizium zum<br />
Einsatz, sondern besondere Polymere, die aber ebenfalls<br />
die Basis für transistorähnliche Bauelemente bilden, die<br />
zu tausenden in den Chip integriert sind. Die chemischen<br />
Mikrochips sind die ersten echten Lab-on-a-Chip-Mikroprozessoren,<br />
eine Art Labor auf dem Mikrochip. Sie benötigen<br />
keine externe Steuerung, da sie vollautomatisch<br />
arbeiten und mit chemischer Energie betrieben werden.<br />
Die Wissenschaftler um Teamleiter Prof. Andreas Richter<br />
hoffen, dass ihr Konzept eine Entwicklung anstößt,<br />
die vergleichbar mit jener der elektronischen Mikroprozessoren<br />
ist, deren Einführung Anfang der siebziger Jahre<br />
den Siegeszug der Mikroelektronik einleitete.<br />
Die Zukunft ihrer chemischen Mikroprozessoren sehen<br />
die Wissenschaftler im Bereich Medizin, Umwelt,<br />
Prozesstechnik und anderen Wissenschaftsbereichen.<br />
Dort basieren viele, vielleicht die meisten Prozesse auf<br />
der Verarbeitung <strong>von</strong> Materialien. Das Team <strong>von</strong> Prof.<br />
Andreas Richter arbeitet mit in dem als Exzellenzcluster<br />
bewilligten „Center for Advancing Electronics Dresden“<br />
(cfAED). Ziel des cfAED ist die Erschließung neuer Wege<br />
für die Mikroelektronik der Zukunft. Der chemische<br />
Mikroprozessor wurde auf der 4. International Conference<br />
„Smart Materials, Structures and Systems“ in<br />
Montecatini Terme, Italien, präsentiert.<br />
ahü<br />
Technische Universität Dresden,<br />
Mommsenstr. 9, D-01069 Dresden,<br />
Tel. +49 (0) 351 46 30,<br />
Internet: www.tu-dresden.de<br />
Chemischer<br />
Mikroprozessor<br />
Bild: Rinaldo<br />
Greiner/TU Dresden<br />
6<br />
Fraunhofer investiert Millionen in<br />
Forschungszentrale für Informationssicherheit<br />
Das Thema IT-Sicherheit ist in aller Munde. Das<br />
Fraunhofer-Institut für Sichere Informationstechnologie<br />
(SIT) hat erste Konsequenzen gezogen. Anfang Juli<br />
feierten rund 100 Gäste aus Politik, Wissenschaft und<br />
Spatenstich am Fraunhofer SIT (v.l.n.r.): Staatssekretär im<br />
Hessischen Ministerium für Wissenschaft und Kunst Ingmar Jung,<br />
Fraunhofer-Vorstand Dr. Alexander Kurz, Institutsleiter des Fraunhofer<br />
SIT Prof. Michael Waidner, Oberbürgermeister der Stadt Darmstadt<br />
Jochen Partsch und Architekt Xaver Egger. Bild: Fraunhofer<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012<br />
Forschung den Beginn der Erweiterungsbauarbeiten am<br />
SIT in Darmstadt. Insgesamt werden 18 Millionen Euro<br />
in den Ausbau der hessischen Forschungseinrichtung<br />
fließen. Ab Sommer 2014 sollen neben dem neuen Gebäude<br />
auf etwa 3000 Quadratmeter Nutzfläche 170 Wissenschaftlerinnen<br />
und Wissenschaftler zu Datenschutz<br />
und Informationssicherheit forschen. Finanziert wird<br />
der Neubau vom Land Hessen im Rahmen des Förderprogramms<br />
LOEWE (Landes-Offensive zur Entwicklung<br />
wissenschaftlich-ökonomischer Exzellenz) mit 9,1 Millionen<br />
Euro und dem Bundesministerium für Bildung<br />
und Forschung (BMBF).<br />
Dr. Alexander Kurz, Vorstand der Fraunhofer-Gesellschaft<br />
für Personal und Recht: „Sicherheit ist eines der<br />
zentralen Forschungsthemen für die Fraunhofer-Gesellschaft.<br />
Es ist daher nur konsequent, dass wir massiv in<br />
den Ausbau unserer Forschungskapazitäten am Fraunhofer<br />
SIT investieren.<br />
Erst durch den neuen Erweiterungsbau kann das Fraunhofer<br />
SIT wie geplant wachsen und dabei seinen Mitarbeiterinnen<br />
und Mitarbeitern dauerhaft hochqualitative<br />
Arbeitsplätze zur Verfügung stellen.“<br />
ahü<br />
Fraunhofer-Institut<br />
für sIchere Informationstechnologie (SIT),<br />
Rheinstr. 75, D-64295 Darmstadt, Tel. +49 (0) 61 51 86 90,<br />
Internet: www.sit.fraunhofer.de
Nanokomposites: Auf dem Weg<br />
zum flexiblen Bildschirm<br />
Der Schutz hochempfindlicher technischer Bauteile könnte zukünftig durch<br />
sogenannte Nanokomposites realisiert werden. Forschern unter der Leitung<br />
<strong>von</strong> Prof. Dr. Josef Breu an der Universität Bayreuth (Lehrstuhl Anorganische<br />
Chemie I) ist es gelungen, eine Schutzschicht aus Silikatscheiben und kettenförmigen<br />
Kunststoffen herzustellen. Sie besteht aus vielen übereinanderliegenden<br />
Ebenen. Jede Ebene setzt sich aus winzigen Bausteinen zusammen,<br />
die wenige Nanometer hoch sind und sich in ihrem dreistufigen Aufbau gleichen.<br />
Die Mitte bilden künstlich erzeugte scheibenförmige Schichtsilikate,<br />
deren Oberfläche zehn Mal größer ist als <strong>von</strong> Schichtsilikaten, die in der<br />
Natur vorkommen. An den Silikatscheiben sind kettenförmige Kunststoffmoleküle<br />
verankert, die zur Anwendung in einer luftdichten Schutzschicht optimiert<br />
wurden. Die so hergestellte Schutzschicht gehört zu den sogenannten<br />
Nanokomposites, einer Materialklasse. Die beschrieben Ebenen im Schichtsilikat<br />
verhindern das Eindringen <strong>von</strong> Wasser und Sauerstoff. Außerdem ist<br />
die Schicht flexibel und kann sich Verformungen beliebig anpassen. Kombiniert<br />
man das Nanokomposit mit einer Polymer-Matrix, kann es zukünftig<br />
herkömmliche starre Schutzschichten aus Glas ablösen. Die Forscher hoffen,<br />
dass sie dem langfristigen Ziel, nämlich der Herstellung biegsamer Displays,<br />
damit ein Stück näher gerückt sind. Das kosteneffiziente Herstellungsverfahren<br />
wurde nun zum Patent angemeldet. Nachlesbar ist die Forschungsarbeit<br />
unter dem Titel „UV-Cured, Flexible, and Transparent Nanocomposite Coating<br />
with Remarkable Oxygen Barrier“ in: Advanced Materials, Volume 24, Issue<br />
16, pp. 2142-2147 DOI: 10.1002/adma.201104781. ahü<br />
TEchnoLogIE<br />
schaFFT<br />
ForTschrITT<br />
DarT FELDbus<br />
Universität Bayreuth, Lehrstuhl für Anorganische Chemie I,<br />
Universitätsstr. 30, D-95447 Bayreuth, Tel. +49 (0) 921 550,<br />
Internet: www.sfb840.uni-bayreuth.de<br />
Modulation <strong>von</strong> Plattformen für<br />
optimalen Produktlebenszyklus<br />
Das Bundesministerium für Bildung und Forschung (BMBF) unterstützt die<br />
Initiative „RePlaMo“ am Zentrum für Mechatronik und Automatisierungstechnik<br />
(Zema) in Saarbrücken mit fünf Millionen Euro über die nächsten<br />
drei Jahre. „RePlaMo“ steht für „Wandlungsfähigkeit durch rekonfigurierbare<br />
Plattformkonzepte für die Montage“. Das Forschungsprojekt unter der Leitung<br />
<strong>von</strong> Prof. Dr.-Ing. Rainer Müller soll eine Antwort auf den <strong>von</strong> der Industrie<br />
geforderten schnellen Produktlebenszyklus in der Montage geben. Automatisierungslösungen<br />
sind zwar unumgänglich aber teuer in der Anschaffung.<br />
Abhilfe sollen hier rekonfigurierbare Montageanlagen schaffen. Müller fordert<br />
daher, dass zukünftige Montagesysteme mit geringem Aufwand und zeiteffektiv<br />
an neue Anforderungen angepasst und vom Produktlebenszyklus entkoppelt<br />
werden.<br />
An „RePlaMo“ beteiligen sich zahlreiche Montagesystemhersteller- und<br />
anwender, um rekonfigurierbare und wirtschaftliche Montagekonzepte<br />
zu entwickeln. Dazu gehört etwa die Modularisierung. Das Baukastenprinzip<br />
ermöglicht eine variable Stückzahlbandbreite und einen skalierbaren<br />
Produktvariantenmix mit geringem Aufwand. Die Modularisierung<br />
zerlegt die Montagestationen in einzelne verständliche Funktionsgruppen.<br />
Da<strong>von</strong> wird abgeleitet, welche Systemelemente (Basis-, Zuführ-, Transport<br />
oder das eigentliche Montageprozessmodul) die technische Anpassungsfähigkeit<br />
begrenzen und optimiert werden müssen.<br />
ahü<br />
Zentrum für Mechatronik und Automatisierungstechnik<br />
gemeinnützige GmbH,<br />
Gewerbepark Eschberger Weg, Geb. 9, D-66121 Saarbrücken,<br />
Tel. +49 (0) 68 18 57 87 15, Internet: www.mechatronikzentrum.de<br />
Eigensicherheit ohne Leistungsgrenzen:<br />
Die nächste Innovation<br />
<strong>von</strong> Pepperl+Fuchs<br />
n High Power Trunk + Eigensicherheit<br />
erstmals kombiniert in einem<br />
innovativen System für maximale<br />
Sicherheit<br />
n Hohe Leistung ermöglicht größere<br />
Segmente mit langen Kabelwegen<br />
n Hohe Betriebssicherheit und<br />
Verfügbarkeit garantieren ein<br />
Höchstmaß an Effizienz<br />
Erfahren Sie mehr unter:<br />
www.dart-feldbus.de<br />
Pepperl+Fuchs<br />
Vertrieb Deutschland GmbH<br />
Lilienthalstraße 200 · 68307 Mannheim<br />
Tel. +49 621 776-2222 · Fax +49 621 776-272222<br />
pa-info@de.pepperl-fuchs.com<br />
www.pepperl-fuchs.de<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012<br />
7
Verband<br />
Integrierte Digitale Anlagenplanung:<br />
Wissenschaftliche Beiträge für Symposium gesucht<br />
Das „ProcessNet/Namur-Symposium IDA 2013 – Integrierte<br />
Digitale Anlagenplanung und -führung“ findet am<br />
21. und 22. März 2013 in Frankfurt am Main statt. Es richtet<br />
sich an Hersteller, Anwender und Entwickler moderner Informationstechnologien<br />
in der Prozesstechnik und in der<br />
Prozessleittechnik. Der Expertentreff wird <strong>von</strong> ProcessNet<br />
mit Unterstützung der Namur (Verband der Anwender <strong>von</strong><br />
Automatisierungstechnik der Prozessindustrie) organisiert.<br />
Mit Vorträgen aus Hochschule und Praxis, Softwaredemonstrationen<br />
sowie einer begleitenden Ausstellung bietet<br />
das Symposium eine Plattform, um aktuelle Anforderungen<br />
an „digitale“ Anlagen und Produkte in Verfahrens- und<br />
Automatisierungstechnik und notwendige informationstechnische<br />
Methoden und Werkzeuge zu diskutieren. Die<br />
Schwerpunktthemen der IDA 2013 lauten: Smart-Scale-<br />
Anlagen: Modularisierung, Scale Up/Number Up, Anlagenkonzepte<br />
für weltweit verteilte Einsatzstoffe und Märkte,<br />
Informationsmodelle für die Digitale Anlagenplanung und<br />
-führung, Einsatz <strong>von</strong> Standards für den Datenaustausch<br />
(beispielsweise ISO 15926, IEC 62424 plantXML, Onto-<br />
CAPE) im Engineering und für die Prozessführung (beispielsweise<br />
IEC 61850, OPC UA), Assistenzsysteme: Modell-<br />
gestützte Unterstützungssysteme für das Engineering, Lebenszykluskostenmodelle<br />
für Anlagen, Risiko- und Investitionsmanagement<br />
und Integriertes Workflow Management.<br />
Interessierte sind eingeladen, wissenschaftliche Beiträge<br />
für Vorträge oder Poster bis zum 14. September 2012 online<br />
unter www.processnet.org/ida2013 einzureichen. Dort liegt<br />
eine entsprechende Vorlage (Muster) für die Erstellung einer<br />
Kurzfassung bereit. Prof. Dr.-Ing. Leon Urbas, Vorsitzender<br />
des Vorbereitungskomitees und Chefredakteur der<br />
<strong>atp</strong> <strong>edition</strong>, behält sich vor, Beiträge zur Veröffentlichung<br />
im Fachmagazin <strong>atp</strong> <strong>edition</strong> auszuwählen. Diese Aufsätze<br />
werden in einem Themenheft zur digitalen Anlage erscheinen.<br />
Absolventen sind aufgefordert, ihre in 2011/12 erstellten<br />
Abschlussarbeiten einzureichen und mit einem Poster<br />
vorzustellen. Die ProcessNet-Fachgemeinschaft PAAT hat<br />
einen Preis <strong>von</strong> 1000 Euro für die beste Qualifikationsarbeit<br />
ausgelobt und unterstützt studentische Teilnehmer mit<br />
zehn Reisestipendien à 400 Euro.<br />
ahü<br />
ProcessNet (Initiative <strong>von</strong> Dechema und VDI-GVC),<br />
Theodor-Heuss-Allee 25, D-60486 Frankfurt am Main,<br />
Tel. +49 (0) 69 756 42 49, Internet: www.processnet.org<br />
Teigeler ist neuer DKE-Geschäftsführer<br />
Seit 1. Juli 2012 ist Michael Teigeler (45) neuer Geschäftsführer<br />
der DKE Deutsche Kommission Elektrotechnik<br />
Elektronik Informationstechnik im DIN und VDE<br />
(VDE|DKE). Er folgt auf Dr. Gerhard Dreger, der nach fünf<br />
Jahren als Mitglied der Geschäftsleitung in den Ruhestand<br />
geht. Sprecher der Geschäftsführung bleibt Dr. Bernhard<br />
Thies. Michael Teigeler ist seit 2008 Leiter der Abteilung<br />
Internationale Zusammenarbeit der VDE|DKE und hat die<br />
Normungsaktivitäten mit Brasilien, Russland, Indien, China<br />
und Südkorea vertieft. Künftig soll die Normungsarbeit<br />
in Bereichen wie Elektromobilität und Intelligente Netze<br />
auf internationaler Ebene weiter ausgebaut werden. Michael<br />
Teigeler hat an der Hochschule Darmstadt Elektrotechnik<br />
mit der Fachrichtung Automatisierungstechnik studiert.<br />
Seine berufliche Laufbahn startete er<br />
1992 als Vertriebs- und Entwicklungsingenieur<br />
bei der Redar Nahortungstechnik<br />
GmbH in Darmstadt. Im Jahr<br />
1993 wurde er Application Manager<br />
Automotive bei der Baumer Ident<br />
GmbH und wechselte 1995 zur VDE-<br />
Normungsorganisation DKE. ahü<br />
Michael<br />
Teigeler<br />
Bild: VDE.<br />
DKE Deutsche Kommission<br />
ElektrotechNIK ElektroNIK<br />
InformationstechNIK im DIN und VDE,<br />
Stresemannallee 15, D-60596 Frankfurt am Main,<br />
Tel. +49 (0) 69 630 80, Internet: www.dke.de<br />
China will zum globalen Technologieführer werden<br />
Zum Innovationsführer will China unter anderem in<br />
Thermoprozesstechnik, Verfahrenstechnik, Fluidtechnik,<br />
bei Präzisionswerkzeugen, Werkzeugmaschinen<br />
oder Formenbau werden. Dies stellte VDMA-Präsident<br />
Dr. Thomas Lindner bei der Vorstellung der Studie<br />
„Implications of the 12th Five-Year-Plan for German<br />
Machinery Manufacturers“ klar. Die Studie wurde im<br />
Auftrag der Impuls-Stiftung des VDMA <strong>von</strong> der Droege<br />
Group China durchgeführt. Vor fünf Jahren stand China<br />
noch auf Platz vier unter den weltgrößten Maschinenbauländern.<br />
Im Jahre 2011 hat China sich mit 563 Mrd.<br />
Euro Umsatz die Spitzenposition gesichert. Bis 2015, so<br />
versichern die VDMA-Experten, liefert China nicht mehr<br />
im Niedrigpreis-Segment sondern bietet State-of-the-art-<br />
Technologie an, zum Nachteil deutscher Hersteller. Bis<br />
2015 will China seine sieben strategische Bereiche mit<br />
F&E-Investitionen <strong>von</strong> 1,2 Billionen Euro fördern, um<br />
globale Technologieführerschaft zu erreichen: umweltfreundliche<br />
Fahrzeuge, neue Energiequellen, Highend-<br />
Equipment, Energieeffizienz, neue Materialien, Bio-<br />
Technologie und neue Informationstechnologie. ahü<br />
Verband deutscher Maschinenund<br />
Anlagenbau,<br />
Lyoner Str. 18, D-60528 Frankfurt am Main,<br />
Tel. +49 (0) 69 66 03 14 11, Internet: www.vdma.org<br />
8<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012
QR code generated on http://qrcode.littleidiot.be<br />
Namur-Arbeitsblatt NA 140 berät zur Steigerung<br />
<strong>von</strong> Energieeffizienz in Chemieanlagen<br />
Das Namur-Arbeitsblatt NA 140 informiert über die Ermittlung<br />
<strong>von</strong> Energiesparpotenzial in der Chemieindustrie.<br />
Die vom Namur-Arbeitskreis 4.17 „Energieeffizienz“<br />
vorgestellte Vorgehensweise zur Analyse der Einsparmöglichkeiten<br />
durch den gezielten Einsatz <strong>von</strong> Automatisierungstechnik<br />
ist allgemeingültig und wird<br />
durch Praxisbeispiele aus der Automatisierungstechnik<br />
ergänzt. Das Arbeitsblatt NA 140 verfolgt die Ziele:<br />
Darstellung einer allgemeingültigen Vorgehensweise<br />
zur Ermittlung <strong>von</strong> Potenzialen und Maßnahmen<br />
zur Steigerung der Energieeffizienz mit dem gezielten<br />
Einsatz <strong>von</strong> Automatisierungstechnik,<br />
Hilfestellung bei der Identifikation und Quantifizierung<br />
der Energieeffizienzpotenziale anhand <strong>von</strong><br />
Checklisten,<br />
Veranschaulichung durch konkrete Lösungsvorschläge<br />
und praktische Beispiele für typische Prozesseinheiten<br />
in der chemischen Industrie,<br />
Verweise auf weiterführende Informationen für den<br />
Praktiker.<br />
Unentdeckte Potenziale: Anwenderverband<br />
Namur veröffentlicht Empfehlung zur Energieeffizienz in<br />
Anlagen. Bild: pixelio.de/Rike<br />
Das Arbeitsblatt richtet sich an Mitarbeiter und Mitarbeiterinnen<br />
<strong>von</strong> Unternehmen der Prozessindustrie mit<br />
einem technischen Hintergrund. Sie können das Arbeitsblatt<br />
nutzen, um Maßnahmen zur Verbesserung der Energieeffizienz<br />
umzusetzen und weiterzuentwickeln.<br />
Auch die chemische Industrie steht vor der wichtigen<br />
Aufgabe, den spezifischen Energieeinsatz ständig weiter<br />
zu reduzieren. Dazu gehören sicherlich verfahrenstechnische<br />
Maßnahmen, wie etwa Wärmeintegration und<br />
Wirkungsgrad-Verbesserungen. Komplexere Prozesse<br />
und Wärme- sowie Stoffverkopplungen zwischen mehreren<br />
Anlagen stellen jedoch weitere Anforderungen an<br />
die Automatisierungstechnik. Interdisziplinäre Ansätze<br />
können verbleibende Potenziale identifizieren und umsetzen.<br />
Die Automatisierungstechnik kann ungenutztes<br />
Potenzial erschließen. Anregungen und Hilfestellung<br />
bietett das Namur-Arbeitsblatt, dass auf der Internetseite<br />
des Verbands <strong>von</strong> Anwendern der Automatisierungstechnik<br />
in der Prozessindustrie (Namur) heruntergeladen<br />
werden kann. <br />
ahü<br />
Namur-Geschäftsstelle c/o<br />
Bayer Technology Services GmbH,<br />
Gebäude K 9, D-51368 Leverkusen,<br />
Tel. +49 (0) 214 307 10 34, Internet: www.namur.de<br />
Automation &<br />
Power Tour<br />
Innovation trifft<br />
Tradition 2012<br />
Erleben Sie Prozessautomatisierung<br />
und Energietechnik mit informativen<br />
Fachvorträgen, innovativen Produkten<br />
sowie der Möglichkeit zum Dialog mit<br />
Experten, an traditionsreichen Orten<br />
in Ihrer Nähe. Details finden Sie unter:<br />
www.abb.de/automationtour<br />
ABB Automation Products GmbH<br />
Tel.: 0800 111 44 11<br />
Fax: 0800 111 44 22<br />
E-Mail: vertrieb.messtechnik-produkte@de.abb.com<br />
JUNI_<strong>atp</strong>EDITION_PA_APT_2012_1_3.indd 1 14.06.12 13:12<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012<br />
9
anche<br />
Europäische Schuldenkrise verunsichert<br />
deutsche Elektroindustrie im ersten Halbjahr<br />
Von wachsenden Unsicherheiten geprägt“ – so beschreibt<br />
der Chefvolkswirt des ZVEI (Zentralverband<br />
Elektrotechnik- und Elektroindustrie e. V.), Dr. Andreas<br />
Gontermann, die Auftragseingänge für die deutsche<br />
Elektroindustrie im ersten Halbjahr. Grund dieser Unsicherheiten<br />
sei die europäische Schuldenkrise, so erläutert<br />
der Experte in einer ZVEI-Mitteilung. Die Bestellungen<br />
sind im Mai deutlich (34 Prozent) hinter dem<br />
Vorjahresstand zurück geblieben. Inlands- und Auslandsaufträge<br />
verfehlten das Niveau <strong>von</strong> 2011 um 50<br />
beziehungsweise fünf Prozent. Von Januar bis Mai 2012<br />
gingen die Bestellungen um zwölf Prozent gegenüber<br />
dem Vorjahr zurück. Inlandskunden orderten 19 und<br />
Auslandskunden fünf Prozent weniger.<br />
Der Umsatz mit elektrotechnischen und elektronischen<br />
Produkten und Systemen lag im Mai dieses Jahres<br />
bei 14,2 Mrd. Euro und damit acht Prozent niedriger als<br />
vor einem Jahr. „Es war der dritte rückläufige Monat in<br />
Folge“, so Dr. Gontermann. Die Erlöse mit inländischen<br />
Kunden nahmen im Mai um zehn Prozent auf 7,4 Mrd.<br />
Euro ab, die mit ausländischen Kunden um sieben Pro-<br />
Praxisberichte und Forschungsergebnisse zu „Intelligenten<br />
Biogasanlagen“ stellt die 2. VDI-Konferenz<br />
„Prozessmesstechnik an Biogasanlagen“ am 9. und 10.<br />
Oktober 2012 in Fulda vor. Durch steigenden Kostendruck<br />
und sich ändernde Betriebsanforderungen gewinnt<br />
die Prozessoptimierung an Bedeutung. Auf der Konferenz<br />
unter der Leitung <strong>von</strong> Dr.-Ing. Jan Liebetrau, Bereichsleiter<br />
Biochemische Konversion am Deutschen Biomasseforschungszentrum<br />
(DBFZ) in Leipzig, diskutieren Experten<br />
den Einsatz <strong>von</strong> Messtechnik sowie aktuelle Entwicklungen<br />
und Praxisreife <strong>von</strong> Sensoren und Messverzent<br />
auf 6,8 Mrd. Euro. Von Januar bis Mai 2012 summierte<br />
sich der Branchenumsatz auf 70,2 Mrd. Euro – ein<br />
Minus <strong>von</strong> rund eineinhalb Prozent gegenüber Vorjahr.<br />
Die preisbereinigte Produktion der Elektroindustrie<br />
lag im Mai 2012 sieben Prozent niedriger als vor einem<br />
Jahr. Im Zeitraum <strong>von</strong> Januar bis Mai dieses Jahres ist sie<br />
noch um knapp ein Prozent gegenüber Vorjahr gewachsen.<br />
Ihre Produktionspläne haben die Elektrofirmen im<br />
Juni dieses Jahres – wie schon im Mai – leicht herabgesetzt.<br />
„Per Saldo bleiben diese aber positiv: 16 Prozent<br />
der Branchenunternehmen wollen in den nächsten drei<br />
Monaten mehr produzieren“, sagte Dr. Gontermann. 73<br />
Prozent der Firmen planen, ihr gegenwärtiges Output-<br />
Niveau beizubehalten.<br />
ahü<br />
ZVEI – Zentralverband Elektrotechnik- und<br />
Elektronikindustrie e. V.,<br />
Lyoner Str. 9, D-60528 Frankfurt am Main,<br />
Tel. +49 (0) 69 630 22 55,<br />
Internet: www.zvei.org<br />
VDI-Konferenz: Prozessmesstechnik an<br />
Biogasanlagen aus Theorie und Praxis<br />
fahren. Mess-, Regelungs- und Automationskonzepte sind<br />
ebenso Thema wie Praxisberichte zu Mindestanforderungen<br />
an Messtechnik aus Sicht eines Umweltgutachters<br />
und die Umsetzung eines Prozessmonitorings bei einer<br />
Biogasanlage in Güstrow. <br />
ahü<br />
VDI Wissensforum GmbH,<br />
VDI-Platz 1, D-40468 Düsseldorf,<br />
Tel. +49 (0) 211 621 46 41,<br />
Internet: www.vdi.de<br />
10<br />
75. Namur-Hauptversammlung dreht sich um<br />
Anfänge und Zukunftspotenzial <strong>von</strong> Aktorik<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012<br />
Am 8. und 9. November findet in Bad Neuenahr die<br />
75. Namur-Hauptversammlung statt. Der Verband <strong>von</strong><br />
Automatisierungsanwendern in der Prozessindustrie<br />
(Namur) wählte in diesem Jahr den Schwerpunkt Aktorik.<br />
Stellgeräte sind nicht mehr rein manuelle Bediengeräte.<br />
Sie bilden heute eine ausbalancierte Kombination<br />
aus Mechanik und intelligenter Funktion, bestehend aus<br />
optimierten <strong>Komponenten</strong> und smarten Stellungsreglern.<br />
Die Namur-Hauptsitzung wird in Vorträgen und Workshops<br />
die Anfänge der Aktorik und ihr Zukunftspotenzial<br />
beleuchten. Dabei werden der Feldgeräteintegrationsstandard<br />
FDI, Wireless-Anwendungen, das Energiemonitoring<br />
und die Energieeffizienz behandelt. Am Freitagvormittag<br />
steht dann das Thema "Integriertes Engineering"<br />
auf dem Veranstaltungsplan. Hauptsponsor der 75. Namur-Hauptversammlung<br />
ist der Stellgeräte-Hersteller<br />
Samson. Dr.-Ing. Jörg Kiesbauer, im Vorstand der Samson<br />
AG für Forschung und Entwicklung verantwortlich, geht<br />
in seinem Plenarvortrag auf die historische Entwicklung<br />
der Stellgeräte ein. <br />
ahü<br />
Namur Geschäftsstelle,<br />
c/o Bayer tEchnology sErvices,<br />
Gebäude K9, D-51568 Leverkusen,<br />
Tel. +49 (0) 214 307 10 34,<br />
Internet: www.namur.de
<strong>atp</strong> <strong>edition</strong> ist bestes<br />
Fachmedium 2012<br />
Als Fachmedium des Jahres 2012 ist <strong>atp</strong> <strong>edition</strong> <strong>von</strong><br />
der Deutschen Fachpresse ausgezeichnet worden.<br />
Das Magazin setzte sich am 14. Juni 2012 anlässlich<br />
des Kongresses der Deutschen Fachpresse in Essen<br />
in der Kategorie „Konstruktion/Produktion/Industrie<br />
allgemein“ durch. In der Begründung der Jury heißt<br />
es: „<strong>atp</strong> <strong>edition</strong> ist ein Printtitel auf höchster Qualitätsstufe<br />
und mit Nachhaltigkeit im Sinne wiederkehrender<br />
Nutzung. Der Titel erfüllt den selbstgestellten<br />
Anspruch eines anspruchsvollen und seriösen<br />
Magazins für Top-Entscheider zwischen Wissenschaft<br />
und Praxis konsequent. Entsprechend der<br />
journalistischen Konzeption ist Online hintenangestellt.“<br />
Die Jury sah hier „die beispielhafte Umsetzung<br />
einer wissenschaftlich ausgerichteten Fachzeitschrift<br />
mit Magazincharakter“.<br />
Die Deutsche Fachpresse ist ein Zusammenschluss<br />
des Börsenvereins des Deutschen Buchhandels, des<br />
Verbands deutscher Zeitschriftenverleger (VDZ), der<br />
world wide magazine media association (FIPP), der<br />
Akademie des deutschen Buchhandels und der VDZ<br />
Akademie. Der Verbund vereint hochrangige Interessensvertreter<br />
deutscher Fachmedien. Die Awards der<br />
deutschen Fachpresse zeichnen die besten deutschen<br />
Fachmedien aus. Die Deutsche Fachpresse würdigt<br />
– eigenen Angaben zufolge – „Publikationen, die beispielhaft<br />
für die vielen hochwertigen gedruckten und<br />
digitalen Informationsangebote aus Fachmedienhäusern<br />
in Deutschland stehen. Zugleich stellt sie mit<br />
dem Award heraus, welchen Beitrag Fachmedien als<br />
Gattung für die Gesellschaft leisten: Ihre seriöse Information<br />
und vorausschauende Themenwahl sind<br />
Grundlage für wirtschaftlichen Erfolg.“ ahü<br />
Oldenbourg IndustrIEVErlag GmbH,<br />
Redaktion <strong>atp</strong>, Rosenheimer Str. 145, D-81617 München,<br />
Tel. +49 (0) 89 45 05 14 18<br />
Internet: www.<strong>atp</strong>-<strong>edition</strong>.de<br />
Auszeichung:<br />
Preis der<br />
Deutschen<br />
Fachpresse<br />
Mit Sicherheit<br />
kompetent<br />
SIL<br />
SIL SIL<br />
Mit den Stellventilen Typ 3241 <strong>von</strong><br />
SAMSON sind Sie immer auf der<br />
sicheren Seite. Dank ihrer hohen<br />
MTBF brauchen Sie sich um einen<br />
Ausfall nicht zu sorgen.<br />
Noch mehr Sicherheit garantieren die<br />
Stellungsregler der Bauarten 3730<br />
und 3731. Mit ihrem zertifizierten<br />
Magnetventil und dem induktiven<br />
Grenzkontakt führen sie die Sprungantworttests<br />
automatisch durch und<br />
dokumentieren die Ergebnisse.<br />
Gehen Sie auf Nummer sicher mit<br />
SAMSON.<br />
A01039DE<br />
SAMSON AG · MESS- UND REGELTECHNIK<br />
Weismüllerstraße 3 · 60314 Frankfurt am Main<br />
Telefon: 069 4009-0 · Telefax: 069 4009-1507<br />
E-Mail: samson@samson.de · www.samson.de<br />
SAMSON GROUP · www.samsongroup.de<br />
<strong>atp</strong> <strong>edition</strong><br />
6 / 2012<br />
11
anche | Automation 2012<br />
Automation 2012: Komplexität beherrschen und<br />
Ingenieur-Nachwuchs praxisorientiert vorbereiten<br />
Automation 2012: <strong>atp</strong> award 2011 vergeben/GMA-Umfrage zum Thema Komplexität<br />
Siemens-Vorstandsmitglied Prof. Siegried Russwurm<br />
sprach das Grußwort bei der Automation 2012.<br />
Kongressleiter Prof. Ulrich Jumar<br />
begrüßte zur Eröffnung rund 500 Teilnehmer.<br />
Problemlösungskompetenz und praktische Erfahrung<br />
erleichtern dem deutschen Ingenieur die Arbeit und<br />
machen deutsche Automation so erfolgreich – dies ist<br />
das Fazit der 13. Automation in Baden-Baden. Die VDI-<br />
Veranstaltung, die am 13. und 14. Juni etwa 460 Automatisierer<br />
in das Kongresshaus der Kurstadt lockte,<br />
stand unter dem Titel „Komplexität beherrschen – Zukunft<br />
sichern“.<br />
Im Anschluss an den Eröffnungsvortrag <strong>von</strong> Dr.-Ing.<br />
Kurt D. Bettenhausen (GMA-Vorsitzender) und Kongressleiter<br />
Prof. Dr.-Ing. Ulrich Jumar, richtete Prof.<br />
Dr.-Ing. Siegfried Russwurm, Vorstandsmitglied der<br />
Siemens AG, ein unterhaltsames Grußwort an die Veranstaltungsteilnehmer.<br />
Sein Beitrag „Produktion im<br />
Wandel – Wege zur nachhaltigen Sicherung der Wettbewerbsfähigkeit“<br />
entlockte manchem Zuhörer das ein<br />
oder andere bestätigende Kopfnicken. Komplexität und<br />
entsprechende Lösungsansätze bildeten in seinem Vortrag<br />
das zentrale Thema.<br />
Zum Thema Komplexität hatte die GMA (VDI/VDE-<br />
Gesellschaft Mess- und Automatisierungstechnik) im<br />
Vorfeld des Kongresses 600 Mitglieder befragt. Die Gesellschaft<br />
wollte wissen, in welcher Form und wie häufig<br />
Komplexität auftritt, wie die Ingenieure ihre persönliche<br />
Lösungskompetenz einschätzen und wie sie mit<br />
besonderen Situationen im Alltag umgehen. Fast die<br />
Hälfte aller Befragten (45,5 Prozent) gab an, dass sie<br />
täglich mit dem Problem Komplexität konfrontiert seien.<br />
Komplexität definierten dabei 76,3 Prozent als gegenseitige<br />
Abhängigkeit <strong>von</strong> Fragestellungen sowie die<br />
Beurteilung der zugehörigen Konsequenzen. Und: Komplexität<br />
am Arbeitsplatz nimmt zu. Dies bestätigte eine<br />
Mehrheit <strong>von</strong> rund 84 Prozent der GMA-Befragten.<br />
Doch fast genauso viele sind zuversichtlich. Von<br />
den Befragten gaben etwa 87 Prozent an, dass sie auf<br />
Komplexität vorbereitet sind. „Man darf nicht vergessen,<br />
dass es sich um die subjektive Einschätzung<br />
jedes Befragten handelt“, so GMA-Geschäftsführer<br />
Dieter Westerkamp. Demnach zählten fast 90 Prozent<br />
aller Befragten den Umgang mit Problemen als ihre<br />
persönliche Stärke. Nur 36 Prozent empfänden Komplexität<br />
als Belastung.<br />
Ingenieuren kommen nach eigenen Angaben bei der<br />
Lösung herausfordernder Arbeitssituationen zwei Dinge<br />
zugute: Die eigene Erfahrung und die praktische<br />
Ausbildung. Ein Alarmsignal bei zunehmender Komplizität<br />
technischer Lösungen, so Bettenhausen. „Bei<br />
der Ausbildung appellieren wir daran, den Schwerpunkt<br />
mehr auf methodische Fähigkeiten zu legen. Da<br />
waren wir in Deutschland bei der Ausbildung unserer<br />
Ingenieure schon einmal deutlich besser“, betont er.<br />
Praktische Ausbildung und Kreativität vermissen die<br />
12<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012
Automatisierer schon längst. Dies bekundet auch Dr.<br />
Wilhelm Otten, Vorsitzender der Namur (Interessensgemeinschaft<br />
der Anwender <strong>von</strong> Automatisierungstechnik<br />
in der Prozessindustrie), im <strong>atp</strong> <strong>edition</strong>-Interview:<br />
„Es fehlt die klassische Problemlösungskompetenz.“<br />
Dies bestätigt auch sein Vorgänger Dr. Norbert Kuschnerus:<br />
„Man gewinnt heute den Eindruck, es wird nur<br />
noch auswendig gelernt.“<br />
Umso wichtiger ist es für die Automatisierungsbranche,<br />
herausragende Leistungen <strong>von</strong> Nachwuchsingenieuren<br />
hervorzuheben. Auch dazu wurde die Automation<br />
2012 in Baden-Baden genutzt. <strong>atp</strong>-<strong>edition</strong>-Chefredakteur<br />
Prof. Dr.-Ing. Leon Urbas zeichnete im Rahmen<br />
der Eröffnungsveranstaltung Dr.-Ing. Annika<br />
Kufner und Dr.-Ing. Michael Wedel mit dem <strong>atp</strong> award<br />
2011 aus.<br />
Annika Kufner, die derzeit für die Bosch AG in Singapur<br />
arbeitet und deshalb nicht anwesend war, bekam<br />
die Auszeichnung in der Kategorie „Industrie“ für den<br />
Beitrag „Fortschritt bei Simulation <strong>von</strong> Montagemaschinen“.<br />
Die Arbeit wurde in der Ausgabe 9/2011 <strong>von</strong> <strong>atp</strong><br />
Programm<br />
SIL<br />
Sprechstunde<br />
Moderation: Jürgen George,<br />
Pepperl+Fuchs GmbH<br />
4. SIL-Sprechstunde<br />
Funktionale Sicherheit<br />
18. + 19.9.2012, Mannheim, Pepperl+Fuchs GmbH<br />
www.sil-sprechstunde.de<br />
Wann und Wo?<br />
<strong>edition</strong> als Hauptbeitrag veröffentlicht. Kufners Aufsatz,<br />
den sie mit Dr.-Ing. Philipp Dreiss und Prof. Dr.-<br />
Ing. Peter Klemm geschrieben hatte, befasst sich mit der<br />
automatisierten Erstellung <strong>von</strong> Verhaltensmodellen für<br />
die Hardware-in-the-Loop-Simulation der Maschinen.<br />
In der Kategorie „Hochschule“ machte Dr.-Ing. Michael<br />
Wedel das Rennen. Sein Beitrag „Zuverlässigkeitsbewertung<br />
in frühen Entwicklungsphasen“ erschien in<br />
der Ausgabe 10/2011 <strong>von</strong> <strong>atp</strong> <strong>edition</strong>. Der Autor stellte<br />
einen Ansatz vor, der Rückrufe und Stillstände <strong>von</strong> Anlagen<br />
vermeiden soll. Die Lösung basiert auf rigide definierten<br />
Softwarekomponenten.<br />
<strong>atp</strong> <strong>edition</strong> vergibt traditionell auf dem VDI-Kongress<br />
„Automation“ in Baden-Baden den Nachwuchsförderpreis<br />
<strong>atp</strong> award. Ausgezeichnet werden zwei Preisträger<br />
jeweils in der Kategorie „Industrie“ und „Hochschule“,<br />
die im vorangegangenen Jahr in <strong>atp</strong> <strong>edition</strong> veröffentlicht<br />
haben.<br />
Die <strong>atp</strong>-Chefredaktion sowie Fachredaktion, Herausgeber<br />
und Beiräte wählen die Preisträger aus. Potenzielle<br />
Kandidaten dürfen zum Zeitpunkt der Veröffentli-<br />
PLT-Schutzeinrichtung<br />
Prinzip der SIL-Bewertung<br />
Parameter der SIL-Bewertung<br />
Vermeidung systematischer Fehler<br />
Bewertung zufälliger Fehler<br />
Gerätequalifikation aufgrund „früherer Verwendung“<br />
Referenten<br />
Dirk Hablawetz, BASF SE<br />
Dr. Andreas Hildebrandt, Gerhard Jung, Pepperl+Fuchs GmbH<br />
Udo Hug, BImSchG § 29a Sachverständiger<br />
Dr. Thomas Karte, Samson AG<br />
Dr. Gerold Klotz-Engmann, Endress+Hauser Messtechnik GmbH + Co. KG<br />
Josef Kuboth, Landesamt für Natur, Umwelt und Verbraucherschutz NRW<br />
Bernd Schroers, Bayer Technology Services<br />
Heiko Schween, HIMA Paul Hildebrandt GmbH + Co KG<br />
Johann Ströbl, TÜV Süd Industrie Service GmbH<br />
Weitere Informationen und Online-Anmeldung unter www.sil-sprechstunde.de<br />
Termin<br />
Dienstag, 18.09.2012<br />
Veranstaltung (11:30 – 16:30 Uhr)<br />
„Get-Together“ mit Abendessen (ab 17:30 Uhr)<br />
Mittwoch, 19.09.2012<br />
Veranstaltung (9:00 – 15:00 Uhr)<br />
Ort<br />
Mannheim, Pepperl+Fuchs GmbH<br />
Thema<br />
SIL – Qualifizierung <strong>von</strong> PLT-Schutzeinrichtungen<br />
Teilnahmegebühr<br />
<strong>atp</strong> <strong>edition</strong>-Abonnenten 540 € zzgl. MwSt<br />
Firmenempfehlung 590 € zzgl. MwSt<br />
reguläre Teilnahmegebühr 690 € zzgl. MwSt<br />
Im Preis enthalten sind die Tagungsunterlagen<br />
sowie das Catering (Kaffee, 2x Mittagsimbiss,<br />
„Get-Together“ mit Abendessen).<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012<br />
13
anche | Automation 2012<br />
Prof. Leon Urbas, Chefredakteur der <strong>atp</strong> <strong>edition</strong>, vergab<br />
anlässlich des Automationskongresses den <strong>atp</strong> award an Dr. Annika<br />
Kufner in der Kategorie "Industrie".<br />
Dieter Westerkamp und<br />
Dr. Kurt D. Bettenhausen<br />
stellten die Ergebnisse der<br />
GMA-Umfrage „Komplexität“ vor.<br />
Dr. Michael Wedel (l.) nahm seinen <strong>atp</strong> award 2011<br />
in der Kategorie „Hochschule“ <strong>von</strong> Prof. Leon Urbas<br />
entgegen. <br />
Bilder: Anne Hütter<br />
chung nicht älter als 35 Jahre sein. Wenn es sich um<br />
einen Beitrag mit mehreren Autoren handelt, erhält der<br />
jüngste Verfasser stellvertretend für alle Autoren den<br />
Preis und das Preisgeld in Höhe <strong>von</strong> 2 000 Euro.<br />
Die über 70 Fachbeiträge und mehr als 20 Posterpräsentationen<br />
sowie die Ausstellung <strong>von</strong> Industriepartnern<br />
auf der Automation 2012 bewiesen erneut, dass<br />
Deutschlands Ingenieure führend sind in der Automatisierung.<br />
In der vorliegenden Ausgabe <strong>von</strong> <strong>atp</strong> <strong>edition</strong><br />
stellt der Hauptbeitragsteil (ab S.26) eine Auswahl der<br />
Beiträge der Automation 2012 vor. Im Editorial (S.3) dieser<br />
Aus-gabe betont der GMA-Vorsitzende Bettenhausen,<br />
dass Deutschland den Anschluss an den internationalen<br />
Wettbewerb nicht verlieren dürfe. Gerade mit der Industrie<br />
4.0 stehen die Zeichen für einen Standortvorteil der<br />
Bundesrepublik nicht schlecht. Es müsse jedoch jederzeit<br />
die Anwenderfreundlichkeit der Funktion im Mittelpunkt<br />
des Entwicklungsprozesses stehen.<br />
Autorin<br />
Anne Hütter<br />
Redaktion <strong>atp</strong><br />
Oldenbourg Industrieverlag GmbH,<br />
Rosenheimer Straße 145, D-81671 München,<br />
Tel. + 49 (0) 89 45 05 14 18,<br />
E-Mail: huetter@oiv.de<br />
14<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012
E20001-F160-M117<br />
Gewinne optimiert man nicht über<br />
Nacht. Aber Tag für Tag.<br />
Realisieren auch Sie das Potenzial energieeffizienter Lösungen<br />
Knapper werdende Ressourcen, steigende Energiekosten<br />
sowie immer strengere Umweltauflagen verschärfen den<br />
Druck auf die Industrie, effizienter als bisher mit Energie<br />
umzugehen. Und das Potenzial ist riesig. Bis zu 70 % der<br />
eingesetzten Energie in Industriebetrieben werden allein<br />
durch elektrische Antriebe und Motoren verbraucht.<br />
Ob moderne Energiesparmotoren oder innovative Software-Anwendungen<br />
– wir bieten Ihnen ein umfangreiches<br />
Portfolio an energieeffizienten Produkten und Lösungen<br />
sowie umfassendes Energy Consulting. Damit erzielen<br />
Sie auf Dauer Effizienzgewinne, die Sie immer wieder<br />
machen. Tag für Tag.<br />
siemens.de/energieeffizienz
anche<br />
FDI-Projekt für einheitliche Geräteintegration<br />
geht in die nächste Runde<br />
Field Device Integration macht sich auf den Weg zur Standardisierung<br />
Demonstrator:<br />
Der Herstellerübergreifende<br />
FDI-Demonstrator.<br />
Bild: ABB<br />
Mit der Gründung der FDI Corporation, LLC (Limited<br />
Liability Company amerikanischen Rechts), haben<br />
die Interessenverbände FDT Group, Fieldbus Foundation,<br />
Hart Communication Foundation, OPC Foundation und<br />
Profibus&Profinet International einen weiteren Schritt in<br />
Richtung Marktreife des geplanten, einheitlichen Industriestandards<br />
für die Geräteintegration gemacht. Die neue<br />
Organisation soll den Standardisierungsprozess sowie<br />
die Entwicklung des Toolkits für die Field Device Integration<br />
(FDI) Technology weiter vorantreiben.<br />
Anlässlich der Hauptversammlung der Namur (Verband<br />
<strong>von</strong> Automatisierungsanwendern in der Prozessindustrie)<br />
präsentierte die FDI Cooperation typische Anwendungsfälle<br />
an einem Hersteller-übergreifenden Demonstrator.<br />
Dieser Prototyp wurde unter Führung <strong>von</strong> ABB gemeinsam<br />
mit anderen am FDI-Projekt beteiligten Firmen erstellt.<br />
Der Demonstrator zeigt, wie sich in Zukunft Inbetriebnahme,<br />
Diagnose und Gerätetausch realisieren lassen.<br />
Eigenen Angaben zufolge ermöglicht FDI Anwendern<br />
und Herstellern <strong>von</strong> Feldgeräten eine einheitliche und<br />
beherrschbare Geräteintegration in Systeme, Asset Management-<br />
und Gerätekonfigurationslösungen. Die Vorteile<br />
<strong>von</strong> FDI bestünden insbesondere in der Möglichkeit,<br />
Lebenszykluskosten nachhaltig zu senken. Zudem ließen<br />
sich damit die technischen Risiken minimieren und das<br />
Handling vereinfachen.<br />
Anforderung und Leistung<br />
Bisher gab es im Bereich der Geräteintegration zwei Richtungen<br />
– die EDDL (Electronic Device Description Language)<br />
und die FDT/DTM (Field Device Tool/Device Type<br />
Manager). Anwender und Lieferanten mussten sich in der<br />
Regel für eine Seite entscheiden, denn die Entwicklung,<br />
Bereitstellung und Wartung <strong>von</strong> Gerätebeschreibungen<br />
ist für die Hersteller mit hohen Kosten verbunden.<br />
Ziel der Technologie ist es, die komplette Gerätefunktionalität<br />
in einem Device Package abzubilden. Dieses ist<br />
skalierbar, für einfache Geräte ist der EDD-Anteil ausreichend.<br />
Durch die Verwendung <strong>von</strong> EDDL und OPC UA ist<br />
die Technologie plattformunabhängig. Gekapselte Ausführungsumgebungen<br />
für EDDL und UIP sorgen für Robustheit.<br />
Darüber hinaus ist keine Softwareinstallation<br />
(Registry) nötig. Die Technologie ist protokollunabhängig.<br />
Namur und WIB (International Instrument User’s Association)<br />
sind mit gemeinsam abgeleiteten Forderungen<br />
an der Entwicklung des Standards beteiligt. Im Wesentlichen<br />
wird Folgendes gefordert und <strong>von</strong> der FDI-Technologie<br />
erfüllt:<br />
Innerhalb FDI (etwa in den Device Packages) muss<br />
die harmonisierte EDDL verwendet werden.<br />
Durchgängiger Einsatz der FDI-Standard-<strong>Komponenten</strong><br />
"Common Host Components“ (EDD Engine, UID<br />
Renderer, UIP Hosting Component…), als Standardschnittstelle<br />
für Device Packages in allen FDI-Systemen<br />
(Server, FDT (2.0) …).<br />
Die EDD-Blöcke „Device Definition“, „Business Logic"<br />
und „User Interface Description“ müssen für<br />
die Inbetriebnahme in allen Device Packages vorhanden<br />
sein.<br />
16<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012
FDI muss eine flexible Integration und Aktivierung<br />
<strong>von</strong> Device Packages ermöglichen. Eine aktive Geräteintegration<br />
erfolgt wahlweise mit UID (User Interface<br />
Description) und UIP (User Interface Plugin)<br />
oder alternativ nur mit UID.<br />
Migrationslösungen müssen den Weiterbetrieb der<br />
installierten Geräte innerhalb neuer FDI-Systeme<br />
sicherstellen.<br />
Für jedes Gerät darf es nur ein Device Package geben.<br />
Die Auswahl mehrerer Device Packages für ein Gerät,<br />
etwa durch unterschiedliche Funktionalitäten<br />
innerhalb der Device Packages, ist nicht zulässig.<br />
Nicht nur die Implementierung, sondern auch das<br />
Vorhandensein verschiedener Device Packages für<br />
ein Gerät ist nicht zulässig.<br />
Wie der Standard funktioniert<br />
In der Client-Server-Architektur <strong>von</strong> FDI bietet ein FDI-<br />
Server den Zugriff auf das sogenannte Informationsmodell.<br />
Es bildet die Kommunikationstopologie des Automatisierungssystems<br />
ab, in dem die gesamte Kommunikationsinfrastruktur<br />
sowie die Feldgeräte als Objekte<br />
repräsentiert sind. Konkret bedeutet dies, dass die Daten,<br />
Funktionen und die Bedienoberfläche <strong>von</strong> Feldgeräten<br />
Teil des Informationsmodells sind.<br />
FDI-Clients greifen dann über den FDI-Server auf das<br />
Informationsmodell zu, um beispielsweise die Bedienoberfläche<br />
des Feldgerätes zu laden und Client-seitig<br />
zur Anzeige zu bringen. Verändert der Bediener über die<br />
Bedienoberfläche Parameter des Feldgeräts, werden diese<br />
vom Client zurück in das Informationsmodell übertragen.<br />
Daneben können FDI Clients auch ohne gerätespezifische<br />
Bedienoberfläche auf die Geräteparameter im Informationsmodell<br />
zugreifen, etwa für Condition Monitoring.<br />
Welche Daten, Funktionen und Bedienoberflächen der<br />
FDI-Server im Informationsmodell repräsentieren muss,<br />
definiert der Gerätehersteller über das FDI Device Package<br />
mit den Inhalten Device Definition, Business Logic,<br />
User Interface Descriptions und User Interface Plug-ins.<br />
Die Device Definition beschreibt die Daten des Feldgerätes<br />
sowie die interne Struktur, wie beispielsweise Blöcke.<br />
Die Business Logic stellt sicher, dass die Konsistenz der<br />
Geräte-Daten gewahrt bleibt. User Interface Descriptions<br />
und User Interface Plug-ins definieren die Bedienoberflächen<br />
des Feldgerätes. Device Definition, Business Logic<br />
und User Interface Description basieren auf EDDL (IEC<br />
61804-3). Das User Interface Plug-in bietet eine frei programmierbare<br />
Bedienoberflächen. Weitere FDT-Konzepte<br />
sind Nested Communication, also die offene Einbindung<br />
<strong>von</strong> Netzübergängen sowie die Integration <strong>von</strong><br />
Kommunikationstreibern über sogenannte Communication<br />
Server. EDD- und DTM-Lösungen lassen sich in<br />
den FDI Device Packages wiederverwenden.<br />
Der Hintergrund des Projekts<br />
Das im Jahr 2007 im Rahmen des ECT (EDDL Cooperation<br />
Team) gestartete FDI-Projekt basiert auf einer Kooperation<br />
der genannten Interessenverbände. Im Jahr 2009<br />
wurde mit Unterstützung der Hersteller ABB, Emerson,<br />
Endress + Hauser, Honeywell, Invensys, Siemens und<br />
Yokogawa das Projekt um die Entwicklung eines protokollübergreifenden<br />
FDI Tool Kits und gemeinsamen EDD<br />
Interpreters erweitert. Namur und WIB, die in den Niederlanden<br />
beheimatete International Instrument Users‘<br />
Association, haben Anforderungen der Endanwender<br />
eingebracht und verfolgen weiterhin deren Umsetzung.<br />
Mit der Gründung der FDI Cooperation, LLC wurde ein<br />
weiterer wichtiger Zwischenschritt erreicht. Die Gesellschaft<br />
mit Sitz in Delaware, Austin, Texas, USA, ersetzt<br />
das EDDL-Cooperation-Team. Eigentümer der Gesellschaft<br />
sind die Interessenverbände. Im Management sitzen<br />
Vertreter der Hersteller und Interessenverbände.<br />
Hans-Georg Kumpfmüller <strong>von</strong> Siemens übernimmt die<br />
Position des Vorstandsvorsitzenden, Achim Laubenstein<br />
<strong>von</strong> ABB wurde zum Geschäftsführer ernannt.<br />
Die Hauptaufgabe wird es auch weiterhin sein, die<br />
Standardisierung <strong>von</strong> FDI in der IEC weiter voranzutreiben.<br />
Dies gilt ebenso für Wartung und Pflege der FDIsowie<br />
der EDDL Spezifikation sowie für das Bereitstellen<br />
und das Pflegen der Tool Kits und der Standard Host<br />
<strong>Komponenten</strong>, beispielsweise des EDD Interpreters. Die<br />
Vermarktung <strong>von</strong> FDI soll weiterhin über die Interessenverbände<br />
laufen.<br />
Die Ziele sind klar definiert. So soll es eine standardisierte<br />
Integration <strong>von</strong> Feldgeräten auf der Basis der<br />
EDDL- und der FDT-Technologie geben, wofür unter anderem<br />
die EDDL für Hart, Profibus und FF weitgehend<br />
harmonisiert werden. Die Technologie soll für einfache<br />
und komplexe Feldgeräte geeignet sein und mit bereits<br />
installierten Geräten kombiniert werden können.<br />
Autor<br />
Dipl.-Ing. Achim<br />
Laubenstein ist bei ABB<br />
in der Division Process<br />
Automation zuständig für<br />
Feldbusstandardisierung.<br />
Er ist Executive Director der<br />
FDI Cooperation, Mitglied<br />
im Executive Committee der<br />
FDT Group und der Fieldbus<br />
Foundation sowie im Beirat der Profibus<br />
Nutzerorganisation.<br />
ABB Automation GmbH,<br />
Schillerstr. 72, D-32425 Minden,<br />
Tel. +49 (0) 571 830 18 47,<br />
E-Mail: achim.laubenstein(at)de.abb.com<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012<br />
17
PRAXIS<br />
Effiziente Erfassung und Übertragung <strong>von</strong><br />
Testdaten ermöglicht umgehende Reaktionen<br />
Progress Energy überwacht <strong>von</strong> der Zentrale aus Leistungstests in 30 Kraftwerken in Echtzeit<br />
Der OPC Excel<br />
RePOrter ist ein<br />
OPC-Client, der<br />
Excel in eine<br />
Reporting-Lösung<br />
für Prozess- und<br />
Anlagendaten<br />
verwandelt.<br />
Bild: MatrikonOPC<br />
In 30 Elektrizitätswerken, hier das<br />
Kohlekraftwerk „Crystal River“ in Citrus County<br />
(Florida), führt Progress Energy kontinuierlich<br />
Tests durch, deren Resultate nun mit Hilfe des<br />
OPC Excel Reporter sofort zentral erfasst und<br />
ausgewertet werden können. Bild: Progress Energy<br />
Progress Energy führt in seinen 30 Kraftwerken im<br />
Südosten der USA kontinuierlich Tests zur Sicherstellung<br />
der Leistungsfähigkeit durch. Musste der leitende<br />
Ingenieur früher zu jedem Test anreisen oder<br />
lange auf die Ergebnisse warten, so kann er nun die<br />
Prüfungen ohne Zeitverzögerung <strong>von</strong> seinem Büro in<br />
der Unternehmenszentrale aus verfolgen, auswerten –<br />
und gegebenenfalls sofort eingreifen. Ermöglicht wird<br />
das durch den OPC Excel Reporter <strong>von</strong> Matrikon OPC.<br />
Der Energieversorger zählt zu den Fortune-500-Energieunternehmen<br />
mit einem Jahresumsatz <strong>von</strong> rund zehn<br />
Milliarden US-Dollar. Das Unternehmen ist für die Deckung<br />
des Strombedarfs <strong>von</strong> rund 3,1 Millionen Kunden<br />
in North und South Carolina sowie in Florida zuständig<br />
und verfügt über eine Erzeugungskapazität <strong>von</strong><br />
23 000 Megawatt. Um dieses hohe Leistungsniveau zu<br />
halten, muss der Energiekonzern laufend Anlagentests<br />
durchführen. Die Verteilung seiner 30 Kraftwerke auf<br />
den ganzen Südosten der USA stellt Progress Energy<br />
hierbei vor große Herausforderungen.<br />
18<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012
Resultate FLIesseN direkt INS FIRMENNETzWERK<br />
Dick Fletcher, leitender Ingenieur bei Progress Energy,<br />
und sein Team sind für viele der Praxistests des Unternehmens<br />
zuständig. Jahrelang musste Fletcher daher<br />
stets zum jeweiligen Kraftwerk reisen, um die Ergebnisse<br />
dieser Überprüfungen einsehen zu können. Alternativ<br />
musste er warten, bis die Testdaten gesammelt<br />
und ihm auf einem USB-Laufwerk oder per E-Mail zugeschickt<br />
wurden.<br />
Das Unternehmen suchte daher eine schnelle und unkomplizierte<br />
Methode, um unternehmenskritische Prozess-<br />
und Anlagedaten aus den zahlreichen Leistungsund<br />
Abnahmeprüfungen in seinen Kraftwerken zu sammeln,<br />
zu übertragen sowie zu analysieren.<br />
Als Progress Energy sein Vor-Ort-Erfassungssystem<br />
aufrüstete, entschied sich das Unternehmen daher für<br />
eine effizientere und einfachere Möglichkeit, um die<br />
Anlagentestdaten in das Unternehmensnetzwerk zu<br />
übertragen und nach Eingang im Netzwerk diese Echtzeitdaten<br />
anzuzeigen sowie angepasste Berichte auf<br />
deren Grundlagen zu erstellen. Insgesamt sollte die Lösung<br />
kostengünstig und leicht zu implementieren sein<br />
sowie problemlos an die vorhandene Architektur des<br />
Unternehmens angepasst werden können.<br />
EFFIZIENT UND leICHT ERWEITERBAR<br />
Zur Umsetzung des Projekts entschied sich Progress<br />
Energy, den OPC Excel Reporter <strong>von</strong> Matrikon OPC für<br />
die Erfassung und Übertragung <strong>von</strong> Daten aus dem Feld<br />
zu nutzen, da diese Lösung die gewünschte Effizienz<br />
und Skalierbarkeit bietet.<br />
Der OPC Excel Reporter ist ein OPC-Client, der Excel<br />
in eine Reporting-Lösung für Prozess- und Anlagendaten<br />
verwandelt. So ist eine Verbindung mit jeder Echtzeit-<br />
(OPC DA) oder historischen (OPC HDA) Datenquelle<br />
möglich. Musterberichte erleichtern den Einstieg und<br />
helfen dabei, problemlos Produktions-, Qualitäts- und<br />
Leistungsberichte in der benutzerfreundlichen Excel-<br />
Umgebung zu erstellen.<br />
Zudem bietet der OPC Excel Reporter eine OPC-<br />
Schnittstelle für die automatisierte Datenübertragung<br />
<strong>von</strong> verschiedenen Standorten an eine zentrale Stelle.<br />
Dank dieser Methode kann Dick Fletcher nun Echtzeit-<br />
Testdaten aus den Kraftwerken in Florida und South<br />
Carolina <strong>von</strong> seinem Büro in North Carolina aus analysieren<br />
und Automatisierungsabläufe überwachen.<br />
Statt wie in der Vergangenheit zu jedem Teststandort<br />
fliegen zu müssen, lässt Fletcher lokale Techniker die<br />
Testgeräte installieren.<br />
FEHLER ENtdeCKT – UND SOFORT BEHOBEN<br />
Einmal, so berichtet Fletcher, sei es sogar gelungen, Probleme,<br />
auf die man während eines Anlagentests stieß,<br />
auf der Stelle zu beheben. Er betont: „Früher konnte ein<br />
solcher Vorgang Tage dauern. Jetzt kümmern wir uns in<br />
Echtzeit darum.“ Denn durch die Integration des OPC<br />
Excel Reporter in die Architektur des Unternehmens ist<br />
es jedem dafür qualifizierten und autorisierten Nutzer<br />
möglich, sofort auf die Daten zuzugreifen, wenn diese<br />
im Firmennetzwerk eintreffen. Der Excel Reporter ermöglichte<br />
dem verantwortlichen Ingenieurteam den<br />
direkten Einsatz der Lösung innerhalb weniger Minuten.<br />
Fletcher betont, dass es für ihn und sein Team sehr<br />
einfach war, Excel Reporter zu implementieren und<br />
herauszufinden, wie sich die Daten innerhalb der Lösung<br />
bearbeiten lassen. „Dank der einfachen Plug-and-<br />
Play-Installation dauert es fünf oder zehn Minuten,<br />
um Excel Reporter zu starten, wenn man sich mit Excel<br />
auskennt“, so Fletcher. „Die Anwendung ist sehr<br />
Menü-orientiert und wirklich unkompliziert zu nutzen.“<br />
Zu den weiteren Vorteilen des Systems zählt auch<br />
die problemlose Skalierbarkeit im Falle einer Systemergänzung<br />
durch zusätzliche Geräte.<br />
REISEZEIT UND KOsteN GESPART<br />
Die Lösung <strong>von</strong> Matrikon OPC erfüllt alle Anforderungen<br />
des Energieunternehmens. So werden die automatisierten<br />
Abläufe in den verschiedenen Standorten anhand<br />
<strong>von</strong> Anlagen- sowie Prozessdaten in Echtzeit<br />
überwacht, um eine gleichbleibend hohe Leistung der<br />
Kraftwerke zu garantieren. Statt wie bisher zeit- und<br />
kostenintensiv Testergebnisse vor Ort einsehen zu müssen,<br />
können die gewonnenen Daten jetzt <strong>von</strong> einer zentralen<br />
Stelle aus verwaltet und auf diese Weise für die<br />
Mitarbeiter schneller verfügbar gemacht werden. Aufgrund<br />
des bisherigen Erfolgs beabsichtigt Progress<br />
Energy nun, die Nutzung des OPC Excel Reporter auf<br />
weitere Geschäftseinheiten auszuweiten.<br />
Autor<br />
Jason Fletcher ist<br />
Regional Manager für<br />
EMEA (Europe, Middle East<br />
und Africa) bei Matrikon<br />
OPC.<br />
Matrikon Deutschland AG,<br />
Venloer Straße 25, D-50672 Köln,<br />
Tel. +49 (0) 221 969 77 19,<br />
E-Mail: jason.fletcher@matrikonopc.com<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012<br />
19
PRAXIS<br />
Prozesssteuerung erfüllt strenge Pharma-Regeln<br />
und lässt sich individuell konfigurieren<br />
Zenon erlaubt Anlagen <strong>von</strong> Bosch Packaging die Kommunikation mit verschiedenen Steuerungen<br />
Hohe Anforderungen<br />
Die Anordnung „21 CFR Part 11“ ...<br />
... der amerikanischen Lebensmittel- und Gesundheitsbehörde fdA (Food and<br />
Drug Administration) gibt strenge Richtlinien für den sicheren Umgang mit<br />
elektronischen Daten vor. Diese umfassen die Speicherung und den Abruf <strong>von</strong><br />
elektronischen Informationen, den Zugriffsschutz, elektronische Signaturen,<br />
Audit Trails sowie die Archivierung <strong>von</strong> Informationen. Jeder Datenzugriff<br />
muss gemäß dieser Verordnung unveränderbar und personalisiert protokolliert<br />
werden. Unternehmen der Industriezweige Pharma und Kosmetik,<br />
Chemie und Genussmittel müssen garantieren, dass ihre eingesetzten<br />
IT-Lösungen diesen Vorgaben entsprechen.<br />
GMP – „Good Manufacturing Practice“ ...<br />
... ist eine Initiative, die Richtlinien für die Qualitätssicherung in der Produktion<br />
<strong>von</strong> Arzneien, Wirkstoffen sowie Lebens- und Futtermitteln geschaffen hat.<br />
Setzt ein produzierendes Unternehmen ein GMP-konformes Qualitätsmanagement<br />
ein, ist zum einen die Qualität der Produkte gesichert, zum anderen<br />
erlauben die Gesundheitsbehörden die Vermarktung dieser Produkte.<br />
GAMP 5 – "Good Automated Manufacturing Practice" ...<br />
... ist ein detaillierter Leitfaden für die Validierung automatisierter Anlagen<br />
und Systeme in der Pharmaindustrie. Es handelt sich dabei nicht um ein<br />
gesetzliches Regelwerk, dennoch hat sich dieser Leitfaden in den vergangenen<br />
Jahren zum Standard entwickelt.<br />
Bosch Packaging Systems AG, ...<br />
... Tochterunternehmen der internationalen Bosch Packaging Technology, mit<br />
Sitz im Schweizer Beringen, ist eines der weltweit führenden Unternehmen im<br />
Bereich Entwicklung, Herstellung und Verkauf <strong>von</strong> Verpackungs- und<br />
Handlingsystemen. Dazu gehören flexible Lösungen auf Roboterbasis für<br />
verschiedenste Produkte wie Nahrungsmittel, Tierfutter, Gesundheits- und<br />
Hygieneartikel oder Pharmazeutika. Als Systemlieferant für komplette<br />
Verpackungslinien, bislang vor allem im Nahrungsmittelbereich tätig, liefert<br />
Bosch Packaging Systems seine Anlagen nun auch verstärkt in die Pharmazeutische<br />
Industrie und bietet professionelles System-Engineering für<br />
Pharma-Großprojekte an<br />
Für seine zunehmenden Aktivitäten im pharmazeutischen<br />
Umfeld suchte der Maschinenhersteller Bosch<br />
Packaging Systems AG nach einer neuen Lösung für die<br />
Prozessleittechnik und Visualisierung seiner Verpackungsanlagen.<br />
Mit Zenon <strong>von</strong> Copa-Data kann das Unternehmen<br />
seinen Kunden nun Anlagen liefern, die mit den verschiedensten<br />
Steuerungen zuverlässig Daten austauschen können<br />
und alle behördlichen Anforderungen erfüllen, auch<br />
die strenge Vorschrift 21 CRF Part 11 der amerikanischen<br />
Lebensmittel- und Gesundheitsbehörde FDA.<br />
Für Anwendungen in der Nahrungs- und Genussmittelindustrie<br />
war das bestehende HMI-System bei Bosch<br />
Packaging Systems bislang zufriedenstellend. Aus der<br />
strategischen Entscheidung, sich künftig intensiver mit<br />
Großprojekten der pharmazeutischen Industrie auseinanderzusetzen,<br />
entstand der Bedarf für eine neue Lösung,<br />
die den strengen behördlichen Richtlinien der Pharma-<br />
Branche entspricht. Die neue Prozesssteuerung und Visualisierung<br />
musste die Vorschrift 21 CRF Part 11 der<br />
amerikanischen Lebensmittel- und Gesundheitsbehörde<br />
FDA erfüllen sowie konform zu GMP und GAMP sein.<br />
SCHNITTSTELLEN FÜR FLEXIBLE KOMMUNIKATION<br />
Das existierende System auf Basis <strong>von</strong> WinCE konnte<br />
diesen Vorgaben nicht gerecht werden. Für die Suche<br />
nach einer Alternative wurden hohe Erwartungen formuliert:<br />
Einerseits erhoffte sich Bosch Packaging Systems,<br />
direkten Einfluss auf die Produktentwicklung<br />
nehmen zu können, andererseits sollten Kosteneinsparungen<br />
im zweistelligen Prozentbereich erzielt werden.<br />
Die Möglichkeit einfacher und schneller Projektierung<br />
für die jeweiligen Kundenprojekte und vielfältiger Handlungsspielraum<br />
waren zusätzliche Entscheidungskriterien.<br />
Mehr als 20 Softwaresysteme renommierter internationaler<br />
Hersteller wurden im Rahmen der Evaluation<br />
begutachtet und bewertet. Die Entscheidung fiel auf Zenon<br />
<strong>von</strong> Copa-Data.<br />
Pascal Witprächtiger, Leiter Software-Entwicklung<br />
und Konstruktion bei der Bosch Packaging Systems AG,<br />
begründet die Wahl: „Wir haben uns für Zenon entschieden,<br />
weil es ein offenes System ist, das alle nötigen<br />
Schnittstellen für die Zukunft bietet. Unsere Kunden<br />
suchen nach Gesamtlösungen, die sich individuell anpassen<br />
lassen. Als unabhängiges System wird Zenon<br />
diesem Anspruch gerecht. Es kann mit anderen <strong>Komponenten</strong><br />
problemlos kommunizieren und schließt damit<br />
offene Lücken im Linienmanagement.“<br />
FREIE HARDWARE-WAHL SENKT DIE KOSTEN<br />
Witprächtiger hebt ein weiteres Argument hervor: „Durch<br />
das einfache Konfigurieren <strong>von</strong> Zenon können wir auch<br />
spezielle Kundenanforderungen erfüllen. Je nach Bedarf<br />
werden zusätzliche Module lizenziert und Funktionalitäten<br />
erweitert. So bleiben die Anwendungen flexibel und<br />
die Entscheidungen beim Kunden. Auch unsere Erwartungen<br />
hinsichtlich Kosteneinsparungen haben sich<br />
weitgehend erfüllt.“ Dazu habe zum einen das neue System<br />
selbst mit seinem Optimierungspotenzial beigetragen.<br />
Andererseits habe sich die Hardwareunabhängigkeit<br />
<strong>von</strong> Zenon positiv ausgewirkt: „Dadurch, dass Zenon<br />
nicht auf bestimmte Hardwarekomponenten angewiesen<br />
ist, konnten wir bei den Panelherstellern einen Wettbewerb<br />
eröffnen, der die Kostensituation begünstigte.“<br />
PARAMETRIEREN STATT PROGRAMMIEREN<br />
Wichtig sei für Bosch Packaging Systems auch gewesen,<br />
dass Copa-Data über internationale Ableger und eine<br />
mehr als 20-jährige Firmengeschichte verfügt. „Das“, so<br />
Witprächtiger, „gibt uns Sicherheit und das Vertrauen,<br />
in eine stabile und langfristige Geschäftsbeziehung zu<br />
investieren.“ Mit seiner Produktphilosophie „parametrieren<br />
statt programmieren“ und seinen Kernwerten<br />
Durchgängigkeit, Unabhängigkeit und Kompatibilität<br />
20<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012
Bei Bosch Packaging<br />
Systems wird Zenon primär<br />
in zwei Geschäftsbereichen<br />
eingesetzt: einerseits bei<br />
horizontalen Schlauchpackmaschinen,<br />
Speicherlösungen<br />
und Verteilsystemen, andererseits<br />
im Bereich Toploading,<br />
Kartonierung und Delta<br />
Robotik.<br />
Die ProduktionsAnzeige (linkes<br />
Bild) informiert die Bediener bei Bosch<br />
Packaging Systems über alle relevanten<br />
Parameter. Über Karteireiter ist ein<br />
schneller Wechsel zwischen dem<br />
Produktionsbild, den Heizungseinstellungen<br />
und der Produktionsstatistik<br />
inklusive Schicht-Konfiguration<br />
möglich. Im Menü „Project Management“<br />
(rechtes Bild) werden die<br />
Haupteinstellungen für das aktuelle<br />
Projekt vorgenommen.<br />
Bilder: Bosch Packaging Systems<br />
verfolgt Zenon seit Beginn der Entwicklung einen eher<br />
unkonventionellen Weg. Ein modularer Aufbau, einfache<br />
Konfigurierbarkeit, die offene Kommunikation über<br />
mehr als 300 eigene Kommunikationsprotokolle und die<br />
Einhaltung internationaler Standards garantieren ein<br />
hohes Maß an Freiheit und Sicherheit.<br />
zuvERLäSSIGER UND SICHERER DATENAUSTAUSCH<br />
Lars Krause, Software-Ingenieur bei Bosch Packaging<br />
Systems erläutert: „Die Anwendungen beim Endkunden<br />
sind trotz ähnlicher branchenbedingter Anforderungen<br />
meistens sehr unterschiedlich und individuell. Beim<br />
einen finden wir Steuerungen <strong>von</strong> Allen Bradley vor,<br />
beim anderen Siemens Simotion oder Bosch Rexroth.<br />
Meistens jedoch trifft man auf einen Mix verschiedenster<br />
Geräte unterschiedlicher Hersteller, <strong>von</strong> den Steuerungen<br />
über die PCs bis hin zu den Bedien-Panels. Die<br />
größte Herausforderung dabei ist es, zuverlässigen und<br />
sicheren Datenaustausch zwischen all diesen Geräten<br />
herzustellen. Mit Zenon können wir unseren Kunden<br />
nun ein Produkt liefern, das diese Herausforderung bewältigt<br />
und alle gesetzlichen Grundlagen erfüllt.“<br />
Zenon wird bei Bosch Packaging Systems primär in<br />
zwei Geschäftsbereichen eingesetzt: einerseits bei horizontalen<br />
Schlauchpackmaschinen, Speicherlösungen<br />
und Verteilsystemen, andererseits im Bereich Toploading,<br />
Kartonierung und Delta Robotik. Pascal Witprächtiger<br />
resümiert: „Copa-Data hat sich als starker Partner<br />
unserer Wünsche angenommen, etliche Neuentwicklungen<br />
in sein Produkt integriert und in der jüngsten<br />
Zenon-Version fertiggestellt. Für uns ist es besonders<br />
wichtig, dass wir gemeinsam mit unseren Partnern<br />
auch das Produkt weiterentwickeln können, ohne dabei<br />
Sonderlösungen zu generieren.“<br />
Autor<br />
Bernhard Ebert<br />
ist International Sales<br />
Consultant bei der<br />
Copa-Data GmbH.<br />
Copa-Data GmbH,<br />
Haidgraben 2, D-85521 Ottobrunn,<br />
Tel. +43 (0) 662 431 00 22 01,<br />
E-Mail: bernharde@copadata.com<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012<br />
21
PRAXIS<br />
Datenerfassungssystem macht die Produktion in<br />
Stanz- und Biegemaschinenanlage effizienter<br />
Betriebsdaten-Erfassungssystem bei Phoenix Feinbau für transparenten Informationsfluss eingesetzt<br />
Werden neue Fertigungsanlagen errichtet, legen die<br />
Betreiber einen immer größeren Schwerpunkt auf<br />
den Informationsfluss. Dabei spielt die durchgängige<br />
Datenübertragung <strong>von</strong> der Produktionshalle bis in die<br />
Unternehmensleitebene und das Internet eine wesentliche<br />
Rolle. So planen die Anwender nicht nur die Maschinen<br />
und Anlagen, sondern auch die zugehörige Infrastruktur<br />
sowie die Hard- und Software für die Betriebsdatenerfassung.<br />
Als Ergebnis erhalten sie eine<br />
vernetzte Fertigungslinie mit transparenten Informationen<br />
an allen relevanten Produktionsorten.<br />
Die Phoenix Feinbau GmbH & Co. KG, ein Tochterunternehmen<br />
der Phoenix-Contact-Gruppe, folgt dem<br />
Trend: Die neue Produktionshalle ist auf einen nahtlosen<br />
Informationsfluss ohne Systembrüche ausgerichtet. Um<br />
die Produktivität der Stanz- und Biegemaschinen zu erhöhen,<br />
wird beispielsweise ein neues Betriebsdaten-Erfassungssystem<br />
(BDE) genutzt, das Teil einer Automatisierungslösung<br />
ist.<br />
VIELFÄLTIGE MONTAGEMÖGLICHKEITEN<br />
Das BDE-System Hydra läuft auf einem Panel-PC der Produktlinie<br />
Valueline, an den Rolf Perner, Mitarbeiter im<br />
Bereich Manufacturing Execution System (MES) im unternehmenseigenen<br />
Maschinenbau <strong>von</strong> Phoenix Contact,<br />
besondere Anforderungen stellt: „Neben der Leistungsfähigkeit<br />
waren uns Faktoren wie der kompakte Aufbau<br />
des Panel-PCs, eine geringe Leistungsaufnahme sowie<br />
die langfristige Verfügbarkeit des Geräts wichtig. Umfangreiche<br />
Untersuchungen haben ergeben, dass sich der<br />
Panel-PC aus unserem eigenen Industrie-PC-Programm<br />
am besten für die umzusetzenden Aufgaben eignet. Die<br />
gesamte Einheit, die in ein Gehäuse mit farblich abgestimmten<br />
Konturen eingebaut ist, wird in die bestehenden<br />
Anlagen integriert.“ Aufgrund verschiedener Montagemöglichkeiten<br />
wie einem Tragarmsystem <strong>von</strong> Rittal<br />
oder Halterungen gemäß Vesa-Standard lassen sich die<br />
Valueline-PCs an nahezu jedem Ort in der Maschine oder<br />
Anlage installieren. Ein weiterer Vorteil des Panel-PCs<br />
liegt in den vielen Konfigurationsmöglichkeiten. Dadurch<br />
hat der Bediener freie Sicht auf andere Anzeigeund<br />
Bedieneinheiten in der jeweiligen Maschine.<br />
IndIVIduELLE KONFIGurATION<br />
Die Produktfamilie Valueline besteht aus drei Modulen.<br />
Die CPU (Central Processing Unit) umfasst alle wichtigen<br />
Schnittstellen eines Industrie-PCs. Sie kann wahlweise<br />
mit Festplatten, CF-Karten (Compact Flash) oder<br />
leistungsfähigen Solid-State-Platten konfiguriert werden.<br />
Zudem stehen verschiedene Prozessortypen zur<br />
Verfügung. Für einfache Anwendungen bietet sich der<br />
Intel-Atom-Prozessor an, während der Core2Duo-Prozessor<br />
umfangreiche Aufgaben abarbeitet. Sämtliche<br />
Prozessortypen sind verlustleistungsarm und benötigen<br />
keinen Lüfter zur Kühlung. Die passive Kühlung der<br />
Panel-PCs ermöglicht einen Betrieb ohne rotierende<br />
Teile, was die Verfügbarkeit der Maschinen und Anlagen<br />
deutlich erhöht. Komplettiert wird der Valueline-<br />
Bild 1: Die Produktionshalle <strong>von</strong> Phoenix Feinbau umfasst<br />
zahlreiche Stanz- und Biegemaschinen.<br />
Baukasten durch ein Display-Modul in den Abmessungen<br />
12 bis 24 Zoll, das mit der CPU zum klassischen<br />
Panel-PC kombiniert wird, sowie ein Erweiterungsmodul<br />
für ein bis zwei PCI-Karten.<br />
Aus den drei Modulen kann der Anwender seinen individuellen<br />
Industrie-PC zusammenstellen – als Box-PC<br />
für die Hutschiene, als Thien Client zur kostenoptimierten<br />
Nutzung oder als Panel-PC. Jedes Gerät weist also für<br />
die jeweilige Applikation geeignete Leistungsmerkmale<br />
und Speichersysteme auf. Die <strong>Komponenten</strong> sind längere<br />
Zeit verfügbar. Dieser Ansatz stellt sicher, dass ein<br />
funktionskompatibler Industrie-PC über einen Zeitraum<br />
<strong>von</strong> mehreren Jahren geliefert werden kann. Das permanente<br />
Anpassen der Software aufgrund einer veränderten<br />
Ausstattung des Industrie-PCs entfällt.<br />
TransparENTEr ProduKTIONsprozess<br />
In der neuen Produktionshalle <strong>von</strong> Phoenix Feinbau<br />
wird die MES-Software Hydra zur maschinennahen Datenerfassung<br />
eingesetzt. Phoenix Contact nutzt derzeit<br />
die Hydra-Module ADE/HLS (Auftragsdaten-Erfassung/<br />
Leitstand), MDE (Maschinendaten-Erfassung) und WRM<br />
(Werkzeug- und Ressourcen-Management). Im nächsten<br />
Schritt wird die Lösung um das Modul QMS (Qualitätsmanagement)<br />
ergänzt. Die Kleinsteuerung ILC 150 ETH<br />
erfasst die Maschinensignale (Mengen, Status), wertet<br />
sie aus und überträgt alle relevanten Daten über eine<br />
standardisierte OPC-Schnittstelle der Maschinensteuerung<br />
via lokales TCP/IP-Netzwerk an den Panel-PC. Die<br />
Terminal-Software visualisiert die aktuellen Zähler, Zu-<br />
22<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012
Bild 2: Die Industrie-PCs der Produktlinie Valueline<br />
werden zur maschinennahen Visualisierung eingesetzt.<br />
Bild 3: Der Panel-PC lässt sich aufgrund variabler<br />
Montagemöglichkeiten direkt im Fertigungsprozess<br />
installieren. <br />
Bilder: Phoenix Contact<br />
stände, Zeiten sowie Prozess- und Auftragsdaten mit<br />
Bezug zum entsprechenden Auftrag und der jeweiligen<br />
Maschine auf dem Display des Panel-PCs. Dem Bediener<br />
werden nicht nur Informationen angezeigt: Er kann<br />
selbst Daten wie den Zählerstand oder einen Status über<br />
den Touchscreen oder die in den Panel-PC integrierte<br />
Software-Tastatur eingeben. Darüber hinaus ist ein Zugriff<br />
auf verschiedene Datenbanken möglich, um beispielsweise<br />
Zeichnungen und Dokumente zum Fertigungsauftrag<br />
einzusehen.<br />
Der Valueline-PC schreibt sämtliche Eingaben und Werte<br />
über das Netzwerk in die Hydra-Datenbank. Im Hydra-<br />
Leitstand HLS wird der Feinplan unter Berücksichtigung<br />
der Kapazität der verschiedenen Produktionsmittel erstellt<br />
und der aktuelle Produktionsfortschritt online abgebildet.<br />
Der Bediener kann somit jederzeit kompetent Auskunft<br />
geben und im Fall einer Störung schnell die richtige Entscheidung<br />
treffen. Die Industrie-PCs unterstützen laut<br />
Herstellerangaben einen transparenten Produktionsprozess,<br />
denn auf Basis aktueller Kennzahlen lassen sich<br />
Durchlaufzeiten verkürzen und Kosten reduzieren.<br />
HOHE BETRIEBSSICHERHEIT<br />
Jeder Käufer erwartet qualitativ hochwertige Produkte<br />
zu einem adäquaten Preis. Die innovative Hardware, die<br />
leistungsfähige Software und die durchgängige Vernetzung<br />
der komplexen Maschinen und Anlagen sind hier<br />
nur Mittel zum Zweck. Mit der richtigen Technik lassen<br />
sich allerdings Ausstoß und Verfügbarkeit verbessern<br />
und die Produktivität erhöhen, was wiederum zu günstigeren<br />
Preisen führt. Bestes Beispiel sind die vielen<br />
tausend Stanz- und Biegeteile, die die Produktionshalle<br />
<strong>von</strong> Phoenix Feinbau täglich in hoher Qualität verlassen.<br />
Die Panel-PCs der Produktlinie Valueline sorgen dafür,<br />
dass die vielfältigen Funktionen des BDE-Systems<br />
Hy-dra direkt an den Stanz- und Biegemaschinen genutzt<br />
werden können. Die Geräte lassen sich nicht nur<br />
einfach installieren, sie erfüllen auch die besonderen<br />
Anforderungen an die Betriebssicherheit, die sich aus<br />
der starken Vibration der Anwendungen sowie der hohen<br />
Umgebungstemperatur ergeben. Durch neue Technologien<br />
verfügen die Panel-PCs über Prozessoren, die<br />
deutlich weniger Energie als die bislang verwendeten<br />
Varianten benötigen.<br />
Autor<br />
Dipl.-Ing. Dietmar Knecht ist im Produktmarketing<br />
IPC/HMI bei der Phoenix Contact<br />
Electronics GmbH tätig.<br />
Phoenix Contact Electronics GmbH,<br />
Dringenauer Straße 30, D-31812 Bad Pyrmont,<br />
Tel. +49 (0) 5281 94 60,<br />
E-Mail: dknecht@phoenixcontact.com<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012<br />
23
PRAXIS<br />
Intensiv genutzte Datennetzwerke benötigen nicht erst<br />
seit Stuxnet leistungsfähige und sichere <strong>Komponenten</strong><br />
Scalance sichert zuverlässige Datenübertragung im komplexer werdenden Industrie-Netzwerk<br />
Die Wireless-LAN-<strong>Komponenten</strong> (WLAN) mit dem Standard IEEE 802.11n bieten eine Datenrate <strong>von</strong> bis zu<br />
450 Megabit/s und sind auch für raue Industrieumgebungen geeignet. Bild: Siemens<br />
Es gibt vielfältige Anwendungen für die Datenvernetzung<br />
in industriellen und industrienahen Umgebungen.<br />
Neben den üblichen Steuerungs- und Informationsdaten<br />
werden über die Netzwerkinfrastrukturen auch<br />
Sprachdaten (beispielsweise Voice over IP) sowie hochauflösende<br />
HD-Videos (High Definition) verarbeitet.<br />
Einsatzbereiche finden sich in der Stahl- und Automobilindustrie,<br />
an Öl- und Erdgasfeldern, in Minenbetrieben,<br />
Häfen oder Versorgungs- und Verkehrseinrichtungen.<br />
Kommunale und städtische Einrichtungen<br />
verwenden drahtlose Datentechnik für öffentliche Sicherheitsanwendungen<br />
wie Videoüberwachung, mobile<br />
Datenübertragung und Katastrophenschutz. Intelligente,<br />
industrietaugliche und leistungsfähige Switches,<br />
Router sowie WLAN-<strong>Komponenten</strong> ermöglichen dafür<br />
den Aufbau <strong>von</strong> robusten, störungssicheren und zuverlässigen<br />
Ethernet-Netzwerken für die dauerhafte Übertragung<br />
sehr hoher Datenkapazitäten.<br />
Sichere WLAN-Lösungen für die iNdustrie<br />
Mit dem Einsatz <strong>von</strong> ethernetbasierten Netzen in der<br />
Automatisierung gewinnt das Thema Datensicherheit in<br />
Industrienetzwerken an Bedeutung. Bis vor wenigen Jahren<br />
wurden Schlagworte wie Virenscanner und Firewalls<br />
nur in Verbindung mit Heim IT oder Office IT verwendet.<br />
Nicht allein Stuxnet machte jedoch auf die Gefahren für<br />
die Automatisierung aufmerksam.<br />
Für spezielle Anforderungen in der Industrie sowie in<br />
öffentlichen Bereichen bieten Hersteller wie Siemens aber<br />
individualisierte IT-Security-Lösungen. Damit lassen<br />
sich gerade anspruchsvolle Applikationen wie HD-Videoübertragungen<br />
per Funk realisieren. Über weit verteilte<br />
Anlagen, etwa in kilometerlangen Tunneln, ist<br />
durch den Einsatz <strong>von</strong> intelligenten Funknetzwerken<br />
mit Hilfe <strong>von</strong> vielen Access Points und Wireless-LAN-<br />
Controllern eine lückenlose Funkabdeckung möglich.<br />
Häufig spielt der Faktor Flexibilität eine wichtige Rolle,<br />
24<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012
wenn Unternehmen sich entscheiden, ihre Daten per<br />
Funk zu übertragen. Darüber hinaus lassen sich störanfällige<br />
Technologien ersetzen, wie wartungsintensive<br />
Schleifleiter, die häufig bei Kränen oder Hängebahnen<br />
vorkommen. Ein weiterer Einsatzgrund ist die Vermeidung<br />
kostspieliger und schwer zu realisierender Verkabelungen.<br />
Das Verlegen <strong>von</strong> Kabeln im Freien ist häufig<br />
technisch anspruchsvoll, teuer und bei zahlreichen, weit<br />
verteilten <strong>Komponenten</strong> nur dann sinnvoll, wenn sie<br />
dauerhaft am selben Platz verbleiben. Zudem gefährden<br />
Beschädigungen durch Personen oder Umwelteinflüsse<br />
die Funktionalität der Anlagen.<br />
Heute betreiben zahlreiche Firmen Funknetzwerke,<br />
über die neben beweglichen Anlagen (beispielsweise<br />
Berg- und Tagebau, Krane) auch sicherheitsrelevante<br />
Funktionen („Not-Aus“) gesteuert werden. Eine robuste<br />
Technik mit speziellen Eigenschaften für industrielle<br />
Anwendungen (iFeatures <strong>von</strong> Siemens) sichert dabei die<br />
störungsfreie Funktion.<br />
Die Geräte bieten Redundanzmechanismen (Wechsel<br />
zwischen 2,4 und 5 GHz), iPCF (Industrial Point Coordination<br />
Function) und Hopping (Frequenzsprünge, bei<br />
Siemens iHOP) zur Sicherung der Verbindung. Durch<br />
einen professionellen Aufbau lässt sich die häufig diskutierte<br />
Datensicherheit in Funknetzen auf das hohe<br />
Niveau <strong>von</strong> kabelgebundenen Anlagen heben.<br />
Aktive <strong>Komponenten</strong> für industrie-Netzwerke<br />
Für ein leistungsfähiges Datennetzwerk unter rauen Bedingungen<br />
sind neben den passiven Hardware-<strong>Komponenten</strong><br />
wie Antennen oder eine Verkabelung mit Leitungen,<br />
Steckern und Anschlussdosen auch aktive <strong>Komponenten</strong><br />
notwendig. Dazu gehören neben den Access<br />
Points aus Funknetzen leistungsfähige Switches und<br />
Router, die einen kollisionsfreien, zielgerichteten Datenaustausch<br />
ermöglichen.<br />
Siemens bietet Layer-3-fähige Geräte für den Einsatz in<br />
Gigabit- und sogar 10-Gigabit-Netzwerken an. Die in der<br />
Industrie verwendeten sprach- und bildgebenden Verfahren<br />
machen es nötig, komplexe Netze zu strukturieren.<br />
So lassen sich in Netzwerken mit Layer-3-Switches durch<br />
Routerfunktionen virtuelle LANs (VLAN) für solche Applikationen<br />
segmentieren. Voice over IP bekommt sein<br />
eigenes virtuelles Netzwerk, obwohl es physikalisch über<br />
das Gesamtnetz läuft. Die Switches der Produktreihe<br />
Scalance XR-500 <strong>von</strong> Siemens übernehmen diese Aufgabe.<br />
Die Produktfamilie Scalance besteht aus aufeinander<br />
abgestimmten Netzkomponenten. Sie sind für die raue<br />
Industrieumgebung konzipiert und ermöglichen den<br />
durchgängigen, flexiblen und sicheren Aufbau eines leistungsfähigen<br />
Netzwerks.<br />
Scalance X bildet ein abgestuftes Portfolio <strong>von</strong> Industrial<br />
Ethernet Switching Components inklusive Kommunikationsprozessoren<br />
mit integriertem Switch. Die Produkte<br />
sind geeignet für Switching-Aufgaben – nicht nur<br />
im rauen Industrieumfeld. Scalance W, also <strong>Komponenten</strong><br />
für Industrial Wireless LAN (IWLAN), sorgen für<br />
drahtlose, fehlersichere Kommunikation im Rahmen <strong>von</strong><br />
Personen- und Maschinensicherheit. Sie bilden die zentrale<br />
Komponente zur Strukturierung großer Automatisierungsnetze<br />
und dienen der Verbindung <strong>von</strong> Industrial<br />
IT und Office IT zu einer gemeinsamen Unternehmens<br />
IT. Finanziell ergibt sich, über den gesamten Lebenszyklus<br />
betrachtet, für solche industriellen Switches eine<br />
positive Bilanz gegenüber Office-Geräten.<br />
Der modulare Aufbau dieser Switches macht sie flexibel<br />
und individuell anpassbar. Der Kunde kann also sein<br />
Netzwerk durch das nachträgliche Erweitern <strong>von</strong> Switch-<br />
Ports, den zusätzlichen Ausbau mit Lichtwellenleitern<br />
(LWL) oder Power over Ethernet (PoE) sowie durch höhere<br />
Übertragungsraten jederzeit ausbauen, ohne die Geräte<br />
komplett austauschen zu müssen. Dies macht sich im<br />
Fehlerfall bezahlt. Stillstandszeiten werden auf ein Minimum<br />
reduziert, da ein defektes Modul im laufenden<br />
Betrieb schnell gewechselt werden kann (Hot Swappable).<br />
Anlagenverfügbarkeit und Laufzeit steigern<br />
Der Einsatz <strong>von</strong> Industrie-Hardware steigert zum einen<br />
die Verfügbarkeit einer Anlage. Zum anderen ergeben<br />
sich durch längere Laufzeiten und geringeren Energieverbrauch<br />
Kosteneinsparungen gegenüber Office-Hardware.<br />
Robustheit und Zuverlässigkeit sind genauso gefordert<br />
wie hohe Leistungsfähigkeit der Netzwerke, auch<br />
in rauen Umgebungen. Mit Datenraten, wie sie bisher nur<br />
<strong>von</strong> leistungsfähigen Office-IT-Anlagen bekannt waren,<br />
ist es auch in rauen Umgebungen möglich, anspruchsvolle<br />
Applikationen wie HD-Video zu betreiben und Anlagen<br />
für kommende Anforderungen zu rüsten.<br />
Autor<br />
Dipl.-Betriebswirt Gert<br />
Mikuta ist Marketing<br />
Promotion Manager in der<br />
Division Industry Auto -<br />
mation im Industry Sector<br />
der Siemens AG.<br />
Siemens AG,<br />
I IA SC S MK&P 2,<br />
Gleiwitzer Str. 555, D-90475 Nürnberg,<br />
Tel. +49 (0) 911 895 29 05,<br />
E-Mail: gert.mikuta@siemens.com<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012<br />
25
Hauptbeitrag | Automation 2012<br />
<strong>Betriebliche</strong> <strong>Mitbenutzung</strong><br />
<strong>von</strong> <strong>SIS</strong>-<strong>Komponenten</strong><br />
Fallbeispiel: SIL 3-Überdruck-Schutzeinrichtung<br />
IEC 61511 – der technische Standard für funktionale Sicherheit in der Prozessindustrie –<br />
empfiehlt eine strikte Trennung <strong>von</strong> sicherheitstechnischer und betriebstechnischer Funktionalität.<br />
Vielfältige Vorteile ergeben sich jedoch aus einem betrieblichen Zugriff auf<br />
<strong>Komponenten</strong> des Sicherheitssystems. Für derartige Szenarien verlangt der Standard eine<br />
zusätzliche Risikobetrachtung mit dem Ziel, die Sicherheits-Integrität des Gesamtsystems<br />
zu bewerten. In diesem Beitrag wird am Beispiel einer SIL 3-Überdruckabsicherung mit<br />
Mitteln der Prozessleittechnik eine einfache und generische Methode präsentiert, wie<br />
sich diese Risikobetrachtung durchführen lässt.<br />
SCHLAGWÖRTER Funktionale Sicherheit / <strong>Mitbenutzung</strong> / Risikobetrachtung /<br />
Sicherheits-Integrität<br />
Operational Access to <strong>SIS</strong> Components –<br />
Case Study: SIL 3 Safety Instrumented Function<br />
IEC 61511, the technical standard for functional safety in the process industry sector,<br />
recommends a strict separation of safety-related and operational functionality. However,<br />
providing operational access to components of the safety instrumented system can offer<br />
advantages. For such scenarios, the standard demands an additional risk assessment in<br />
order to evaluate the overall safety integrity. Using the example of an SIL 3 overpressure<br />
protection by means of process control technology, a simple generic method is presented<br />
for such an evaluation.<br />
KEYWORDS Functional safety / shared components / risk assessment / safety integrity<br />
26<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
Thomas Gabriel, Bayer Technology Services<br />
Gerhard VERSTEEGEn, Bayer MaterialScience<br />
Bernd Schrörs, Bayer Technology Services<br />
Process and plant safety with means of process<br />
control technology (PCT) is currently broadly<br />
applied in accordance with IEC 61511 [1]. The<br />
international standard is supplemented by a<br />
variety of national norms (e.g. VDI/VDE 2180<br />
[2]), and recommendations (e.g. Namur NEs 93 [3], 126<br />
[4], 130 [5]). Together, they form a very detailed framework,<br />
describing the entire lifecycle of a safety instrumented<br />
function (SIF) from identification, specification,<br />
and design, to commissioning, management of change,<br />
and finally decommissioning.<br />
A central recommendation of the standard is to separate<br />
safety related and operational functionality. The<br />
intention behind this is to reduce the risk for a common<br />
mode failure of the two different protection layers as far<br />
as possible. However, providing operational access to<br />
components of the safety instrumented system (<strong>SIS</strong>)<br />
yields advantages in various ways. For such scenarios<br />
IEC 61511 demands an additional risk assessment in order<br />
to evaluate the overall safety integrity.<br />
A possibility for conducting said evaluation is presented<br />
in this article. A SIL 3 overpressure protection<br />
serves as case study. Background and additional description<br />
of said system are covered by section 1. Section<br />
2 contains the chain of arguments enabling for a<br />
qualified decision on whether sharing components<br />
among safety and operational layer is allowed for<br />
the case study. The derivations are held very straightforward,<br />
such that an adaptation to similar scenarios<br />
is easily possible. In section 3 and 4, a recapitulation<br />
of the most important aspects and utilized conservatisms<br />
is provided.<br />
1. Case Study<br />
1.1 Process Hazard Analysis<br />
Basis for all considerations provided with this article<br />
is a process hazard analysis, i.e. an analysis of potential<br />
dangers arising from unintended deviations within the<br />
process. The aim of such interdisciplinary activity is to<br />
identify risks and define appropriate measures for<br />
preventing the occurrence and/or<br />
mitigating the consequences<br />
of said hazards – with the final result of having all process<br />
risks reduced to a tolerable level. Following the current<br />
mathematical definition of risk as provided by e.g.<br />
IEC 61511, any process risk R P can be written as<br />
R P = F I ∙ E(S), (1)<br />
i.e. the product of the frequency of occurrence of the<br />
initiating event F I , leading to the related process hazard<br />
(e.g. control system failure, external impacts, faulty operator<br />
behavior), and the expected value of consequences<br />
E(S), resulting from the discussed hazard in case of<br />
having no protective measures in place. As long as no<br />
additional protective measures are defined, the frequency<br />
of the initiating event equals the frequency of the<br />
undesired event.<br />
This definition of risk is the underyling principle for<br />
almost all commonly applied risk assessment tools, such<br />
as risk matrices or risk graphs. All considerations presented<br />
in this article can thus be applied independently<br />
from the actually utilized tool.<br />
A very common risk is the consideration of the deviation<br />
“pressure high” for a vessel, caused by a control<br />
equipment failure, e.g. failure of the pressure control. As<br />
the resulting consequence is bursting of the vessel, including<br />
release of contained medium, the potential for<br />
causing serious damage to people and environment, is<br />
very high.<br />
IEC 61511-1, 8.2.2 yields an initiating event frequency of<br />
F BPCS = F I = 10 -5 h -1 ~ 1/10 y -1 (2)<br />
related to arbitrary BPCS (Basic Process Control System)<br />
failures. As many possible process hazards can be caused<br />
by some kind of control equipment failure, this regula-<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
27
Hauptbeitrag | Automation 2012<br />
tion from IEC 61511 heavily impacts on current risk assessments<br />
in the process industry: an initiating event<br />
frequency of one event per ten years is very dominant<br />
compared to other realistic hazard causes.<br />
In order to describe our case study, we will refer to<br />
subsequent risk analysis with related protective safety<br />
measure (see figure 1 for the bare process automation<br />
instrumentation – without the SIF to be designed; notice:<br />
unimportant parts of the process with respect to<br />
the discussed topics, such as vessel outlets, are left out<br />
in all figures):<br />
Deviation: Pressure high in vessel BA001<br />
Considered initiating event: failure of control<br />
equiment (e.g. stuck open failure of Y0002 or drift<br />
of sensor P0003)<br />
Risk class: Very high<br />
Assigned risk reduction measure: PCT SIF U0002,<br />
“Overpressure Protection”, SIL 3 quality<br />
Description of SIF:<br />
Pressure measurement in BA001; if the related trip<br />
limit is exceeded, the vessel’s inlet is to be shut in<br />
order to separate it from pressure sources<br />
The assigned safety instrumented function U0002 is<br />
supposed to reduce the process risk R P to a tolerable<br />
residual risk R R .<br />
1.2 Implementation<br />
Figure 2 illustrates a possible implementation for the<br />
specified overpressure protection in SIL 3 quality, following<br />
plain theory of IEC 61511. Outlined in green is<br />
the pressure control loop U0001, comprising of a pressure<br />
transmitter P0003 impacting on the flow to vessel<br />
BA001 via valve Y0002 with attached positioner. The<br />
safety instrumented system is outlined in blue. It comprises<br />
of a single safety instrumented function (SIF)<br />
U0002, following the specification from the risk analysis.<br />
Two pressure transmitters (P0001 and P0002) impact on<br />
two ball (open/close) valves (Y0001 and Y0003) via suitable<br />
solenoids. The safety programmable logic controller<br />
(SPLC) performs a 1oo2 voting among the two sensors<br />
and thus triggers both associated final elements in case<br />
of any of the two sensors exceeding its related trip limit.<br />
The design satisfies the SIL 3 architectural requirements<br />
from IEC 61511, as in the process industry sector typically<br />
IEC 61508 certified SPLCs in combination with<br />
prior-use field devices (see [5]) are utilized. With commonly<br />
utilized components, the standard’s requirements<br />
regarding availability can also be easily satisfied.<br />
In the process industry, a design according to figure 3<br />
is also common. Here, one pressure sensor (P0002) and<br />
the control valve are shared among <strong>SIS</strong> and the basic<br />
process control system (BPCS, the operational decentralized<br />
control system). A more signal-oriented view is provided<br />
in figure 4. This solution will be the subject of<br />
further considerations and represents our case study.<br />
On sensor side, the 4-20mA signal from P0001 is fed<br />
immediately to the SPLC. P0002’s signal is looped<br />
through a signal replicator where the current signal is<br />
duplicated and fed to the operational PLC of the BPCS,<br />
as well as to the SPLC. The voting algorithm on the SPLC<br />
performs a 1oo2 voting and triggers the solenoids of<br />
Y0001 and Y0002 in case of a demand. While Y0001 is a<br />
pure safety valve, Y0002 is additionally equipped with<br />
a positioner and can thus be accessed via BPCS.<br />
1.3 IEC 61511 Requirements<br />
A very basic requirement is to have all PCT devices utilized<br />
in the SIF selected in accordance with section 11.5<br />
of IEC 61511 (“Requirements for selection of components<br />
and subsystems”). The primary focus thus lies on the<br />
components’ safety-related-functionality – not the operational<br />
aspects. For instance, the shared control valve<br />
shall primarily provide sufficiently low leakage rate and<br />
travel time, rather than optimal control performance. Of<br />
course, an optimal design optimizes both – safety-related<br />
as well as operational requirements.<br />
IEC 61511 provides explicit implementory aspects regarding<br />
the utilization of safety components for operational<br />
purposes. The design as depicted in figures 3 and<br />
4 is in accordance with these requirements. Most relevant<br />
concern of the standard is the evaluation of the<br />
resulting independency of <strong>SIS</strong> and BPCS. A failure in<br />
the BPCS shall not result in a loss of the safety function<br />
(IEC 61511-1, 11.2.4). This is achieved by electrically decoupling<br />
BPCS and <strong>SIS</strong> sensor loops after the signal<br />
replicator. These components ensure that e.g. shortcircuits<br />
in the PLC loop do not affect the safety path<br />
from the pressure sensor P0002 to the SPLC. On final<br />
element side, this principle is implemented by the<br />
mounting position of the solenoid for Y0002 between the<br />
valve’s actuator and the outlet of the positioner. In case<br />
of a demand to the SIF, the <strong>SIS</strong> trips the solenoid and<br />
de-aerates the actuator independently from the behavior<br />
of the operational positioner. Overriding of the safety<br />
function is not possible.<br />
IEC 61511-2, 11.2.4ff even list several advantages arising<br />
from the installation according to figures 3 and 4:<br />
replicating the sensor signal to the BPCS allows for<br />
enhanced diagnostic measures; comparing the sensor<br />
value with correlated signals from operationally<br />
used components enables for e.g. sensor drift<br />
detection<br />
comparing the sensor value as received by the<br />
SPLC with the one received by the PLC allows for<br />
enhanced diagnosis of intermediate components<br />
(such as e.g. ex-barriers) and the input peripherals<br />
of the SPLC<br />
granting operational access to a safety-related valve<br />
allows for enhanced online diagnostic measures:<br />
as the final element is operated frequently by the<br />
related controller (control valves) or batch sequence<br />
(ball valves), an evaluation of e.g. travel time or friction<br />
curve (as provided by modern positioners) allows<br />
for the early detection of wear-out, plugging,<br />
and corrosion effects<br />
28<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
SIL PFD avg RRF<br />
Table 1: SIL requirements (excerpt from IEC 61511-1:2003,<br />
table 3)<br />
2 $ 10 -3 to < 10 -2 >100 to #1,000<br />
3 $ 10 -4 to < 10 -3 >1,000 to #10,000<br />
FiguRE 1: Piping and instrumentation diagram of case<br />
study vessel BA001 with related pressure control<br />
equipment<br />
Figure 4: Signal-oriented overview of the case study SIF<br />
design<br />
Figure 2: Piping and instrumentation diagram of a valid<br />
SIL 3 overpressure SIF design according to IEC 61511<br />
Figure 5: SIF remainder after the occurrence of scenario<br />
1 according to section 2.1<br />
Figure 3: Piping and instrumentation diagram of the<br />
case study SIF design<br />
FiguRE 6: SIF remainder after the occurrence of scenario<br />
2 according to section 2.1<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
29
Hauptbeitrag | Automation 2012<br />
On the downside, it is to be clearly pointed out that<br />
shared components alter the already mentioned independency<br />
of BPCS and <strong>SIS</strong> in a functional way:<br />
IEC 61511-1, 11.2.10 stresses a specific type of scenario,<br />
where a failure of a shared component causes a demand<br />
to the exact SIF said component is part of.<br />
In figure 3 or 4, this corresponds to e.g. a stuck signal<br />
failure of the pressure transmitter P0002. Due to the failure<br />
(signal freezes below the trip point of the related SIF),<br />
the control loop fails and opens the control valve Y0002<br />
as wide as possible. As a direct result, pressure in BA001<br />
rises until the dangerous state is reached (the failure of<br />
the shared component causes a demand to the related<br />
SIF). For this scenario, the safety related availability of<br />
the SIF’s sensor part depends on the remaining sensor<br />
P0001, only. A similar scenario can easily be constructed<br />
for the shared control valve.<br />
Consequently, IEC 61511 demands an evaluation of the<br />
overall safety integrity of the coupled systems. The subsequent<br />
sections of this article introduce a very simple<br />
and generic approach towards that requirement.<br />
2. evaluation of Safety Integrity<br />
2.1 Preparations<br />
PCT related preventive safety measures impact on the<br />
initiating event frequency F I of a process risk R P by<br />
reducing it by a factor RRF. This risk reduction factor<br />
is directly related to the safety loop’s safety-related unavailability<br />
and thus its average probability of failure<br />
on demand (PFDavg). Hence, the frequency of occurrence<br />
F R of the undesired event in case of having one<br />
single preventive PCT safety measure in place can be<br />
written as<br />
F R = F I / RRF = F I ∙ PFD avg .(3)<br />
Table 1 is an excerpt from IEC 61511 and denotes PFDavg<br />
as well as related RRF for PCT safety loops of SIL 2 and<br />
SIL 3 quality.<br />
For the case study, the frequency of the relevant initiating<br />
event F BPCS = 1/10 y -1 as found in section 1.1 can be<br />
splitted into two fractions with related individual failure<br />
scenario:<br />
1 | Dangerous failure of shared sensor P0002 or control<br />
valve Y0002 due to e.g. sensor value drift or stuck<br />
valve position, simultaneously causing a demand to<br />
the SIF. The corresponding failure frequencies equal<br />
the shared components’ failure rates m P0002 and<br />
m Y0002 , to be retrieved e.g. from the respective safety<br />
manuals. Hence, the overall frequency for the initiating<br />
event originating from the shared components<br />
equals<br />
F P+Y = m P0002 + m Y0002 .(4)<br />
F P+Y can be estimated by referring to slightly adjusted<br />
generic (and thus conservative) equipment data,<br />
raised in the German process industry and provided<br />
by the Namur [5] (see source for applicability<br />
requirements):<br />
m P0002 + m Y0002 =<br />
1000 FIT + 400 FIT ( – 250FIT) = 1150 FIT,(5)<br />
where 1 FIT (Failures In Time) equals one failure per<br />
10 9 hours. The provided failure rates are the respective<br />
dangerous failure rates of pressure sensor channel<br />
and valve channel, and are only applicable for<br />
prior-use channel components. However, this requirement<br />
has been the basis for the chosen implementation<br />
of the case study (see section 1.2). The<br />
NAMUR failure rates are channel related and thus<br />
include the failure rates of all intermediate components,<br />
such as transmitter power supply, solenoid<br />
valves, etc.. These have to be excluded from the relevant<br />
frequency F P+Y . A generic combined contribution<br />
of 250 FIT for these devices is assumed and<br />
consequently removed from the original failure<br />
rates, yielding 1150 FIT, i.e. 1 event per 99 years.<br />
2 | Any arbitrary BPCS failure not related to the shared<br />
components P0002 and Y0002 is also assumed to<br />
create a demand to the SIF. Examples are operator<br />
or positioner failures, programming errors, etc. The<br />
related frequency is F otherBPCS = F BPCS – F P+Y , i.e. the<br />
initiating event’s total frequency 1/10 y -1 minus F P+Y .<br />
For reasons of simplicity and conservatism, we<br />
will set<br />
F otherBPCS = 1/10 y -1 .(6)<br />
Both scenarios can be combined, as they are related to<br />
the same process hazard and the underlying stochastic<br />
processes are independent from each other (see [6] for<br />
a more detailed derivation of the probabilistic background).<br />
The residual frequency of the undesired event<br />
under consideration of the two contributing scenarios is<br />
F R = (F P+Y ∙ PFD avg,1oo1 ) + (F otherBPCS ∙ PFD avg,1oo2 ).(7)<br />
In (7), PFD avg,1oo1 is the average safety related unavailability<br />
of the remaining parts of the original SIF, given the<br />
occurrence of scenario 1, i.e. demand caused by a dangerous<br />
failure of shared component P0002 or Y0002. A very<br />
conservative approach is to assume that both components<br />
are simultaneously not available, rendering an<br />
entire channel of the overpressure protection unavailable.<br />
However, failed components P0002 and Y0002 do<br />
not prevent the remainder of the SIF from correct execution.<br />
Therefore, for scenario 1, a contribution to risk reduction<br />
PFD avg,1oo1 is still provided by the single channel<br />
SIF remainder, consisting of sensor P0001, the SPLC, and<br />
ball valve Y0001 as denoted in fig. 5.<br />
A similar consideration can be made for PFD avg,1oo2 in<br />
(7). Given the occurrence of scenario 2, i.e. an arbitrary<br />
BPCS failure without impact on the shared components,<br />
the complete SIF contributes with the related PFD avg to<br />
risk reduction (see figure 6).<br />
30<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
2.2 Calculations<br />
From table 1 it can be concluded that the case study SIL<br />
3 measure is supposed to reduce the initiating event by<br />
a RRF > 1,000. In combination with equations (2), (3), and<br />
(7), this yields<br />
F R = F BPCS / 1,000 > (F P+Y ∙ PFD avg,1oo1 ) + (F otherBPCS ∙ PFD avg,1oo2 ).<br />
(8)<br />
The inequality expresses that with the actual implementation<br />
a risk reduction beyond the minimum RRF (see<br />
table 1) for SIL 3 SIFs is targeted.<br />
In [2], part 4, table 3, a set of equations enables for<br />
expressing the PFDavg of a 1oo2 redundant SIF by the<br />
PFDavg of a simplex 1oo1 SIF. This equation shall be<br />
applied here in order to proceed with the investigation.<br />
With<br />
PFD avg,1oo2 = 4/3∙PFD avg,1oo1 ² + b∙PFD avg,1oo1 (9)<br />
from [2], part 4, where b is the common-cause factor,<br />
equation (8) can be rewritten as<br />
F BPCS / 1,000 ><br />
(F P+Y ∙ PFD avg,1oo1 ) + (F otherBPCS ∙ (4/3∙PFD avg,1oo1 ² + b∙PFD avg,1oo1 )).<br />
(10)<br />
Setting<br />
F BPCS = 1/10 y-1 (see (2)),<br />
F P+Y = 1/99 y-1 (see (5)),<br />
F otherBPCS = 1/10 y-1 (see (6)),<br />
b = 0.05 (worst case value according to [2], part 4)<br />
in equation (10), yields<br />
1/10 y -1 / 1,000 ≥ (1/99 y -1 ∙ PFD avg,1oo1 ) +<br />
(1/10 y -1 ∙ (4/3∙PFD avg,1oo1 ² + 0.05∙PFD avg,1oo1 )).(11)<br />
For an actual SIF, PFD avg,1oo1 can now be calculated, e.g.<br />
based on the manufacturers’ failure rates which are usually<br />
provided with the safety manuals. As equation (9)<br />
only holds for homogeneously instrumented systems,<br />
for both, sensor and final element part, the worse channel<br />
failure rate shall be utilized for the evaluation of<br />
inequation (11).<br />
Abbreviation<br />
BPCS<br />
F BPCS<br />
F I<br />
F otherBPCS<br />
F P+Y<br />
F R<br />
MooN (e.g. 1oo2, 2oo3)<br />
PCT<br />
PFD avg<br />
PLC<br />
RRF<br />
SIF<br />
SIL<br />
<strong>SIS</strong><br />
SPLC<br />
Meaning<br />
Basic Process Control System<br />
frequency of a demand caused by an arbitrary BPCS failure<br />
frequency of the initiating event<br />
frequency of a demand caused by an arbitrary BPCS failure without relation to any<br />
shared component<br />
frequency of a demand caused by shared components (related to the shared components’<br />
failure rates)<br />
residual frequency of the occurrence of the undesired event after the application<br />
of one or multiple safety measures<br />
M-out-of-N<br />
Process Control Technology<br />
average Probability of Failure on Demand<br />
Programmable Logic Controller<br />
Risk Reduction Factor<br />
Safety Instrumented Function<br />
Safety Integrity Level<br />
Safety Instrumented System<br />
Safety related Programmable Logic Controller<br />
Table 2: List of abbreviations<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
31
Hauptbeitrag | Automation 2012<br />
In order to demonstrate that even in cases of strong<br />
conservatism (11) still applies and in order to provide<br />
an approach as generic as possible, the NAMUR data [5]<br />
shall be utilized again for the calculation of PFD avg,1oo1 .<br />
With the simplified equation<br />
PFD avg,1oo1 = ½ ∙ m DU ∙ T I ,(12)<br />
from [2], part 4, the combined average probability of<br />
failure for sensor part and final element part can be<br />
calculated. As parameters serve the channel failure<br />
rates as introduced in (5) (now without the exclusion<br />
of intermediate devices), and a standard proof test interval<br />
T I of one year. After finally neglecting the SPLCs<br />
contribution to the system’s unavailability (which is<br />
typically one to two magnitudes below the channels’<br />
contributions),<br />
PFD avg,1oo1 = ½ ∙ 1400 FIT ∙ 8760 h = 6.13 ∙ 10 -3 (13)<br />
Referenzen<br />
[1] IEC 61511: Functional safety – Safety instrumented<br />
systems for the process industry sector –. Part 1-3, 2003<br />
[2] VDI/VDE 2180: Sicherung <strong>von</strong> Anlagen der Verfahrenstechnik<br />
mit Mitteln der Prozessleittechnik (PLT). Part<br />
1-5, 2007-2010<br />
[3] ne 93: Verification of the Safety-Related Reliability of<br />
PCT Safety Instruments. 2003<br />
[4] ne 126: Provisions to Safeguard Existing Standards for<br />
Process Control System Safety Equipment. 2009<br />
[5] ne 130: “Proven-in-use”-Devices for Safety Instrumented<br />
Systems and simplified SIL Calculation. 2010<br />
[6] gabriel, T., Litz, L., Schroers, B.: Nutzung <strong>von</strong><br />
<strong>SIS</strong>-Armaturen für Leitsystemfunktionen. <strong>atp</strong> <strong>edition</strong><br />
– Automatisierungstechnische Praxis 53(03),<br />
S. 20-29. 2010<br />
follows. (13) in (11) yields 1.00 ∙ 10-4 > 9.76 ∙ 10-5. Even<br />
with entirely generic and thus conservative data, this<br />
article proves that the case study design according to<br />
figs. 3 and 4 meets the desired SIL 3 requirements.<br />
3 Annotations<br />
The case study has been introduced along with an exemplary<br />
implementation, that fully satisfies the standard’s<br />
implementational requirements.<br />
For the additional risk assessment, a chain of arguments<br />
has been constructed that heavily focuses on<br />
applying multiple conservatisms wherever possible:<br />
The application of generic and thus conservative<br />
NAMUR failure rate data instead of much better<br />
manufacturer data<br />
Equations are simplified in a conservative way, see<br />
e.g. (6)<br />
The relevant event’s frequency is set equal to the<br />
combined failure rates of pressure sensor and control<br />
valve, see equation (4). Actually, the two components<br />
will not fail simultaneously. This generally allows<br />
for a seperated consideration of two scenarios with<br />
1. the pressure sensor failing, and<br />
2. the control valve failing.<br />
In contrast to the approach provided in this article,<br />
this seperation would result in less truncated SIF<br />
remainders. For instance, given the occurrence of<br />
scenario 1, the shared pressure sensor is not available,<br />
while the remaining SIF still consists of the<br />
other sensor, and a redundant pair of valves in the<br />
final element part. Notice the difference to the conservative<br />
approach used in this article, where always<br />
both shared components are assumed to be simultaneously<br />
unavailable. Seperated consideration of the<br />
two scenarios would result in a significantly better<br />
PFD avg,1oo1 .<br />
Although several possible benefits from sharing<br />
components have been outlined in section 1.3<br />
Autoren<br />
Dr.-Ing. Thomas Gabriel (geb. 1980) arbeitet im<br />
Bereich Functional Safety bei Bayer Technology<br />
Services. Arbeitsschwerpunkte: Process Safety,<br />
Safety System Design, Quantitative Evaluation of<br />
the Safety related Availability.<br />
Bayer Technology Services GmbH,<br />
Geb. B407,<br />
D-51368 Leverkusen,<br />
Tel. +49 (0) 214 304 36 92,<br />
E-Mail: thomas.gabriel@bayer.com<br />
Dipl.-Ing. GERHARD VERSTEEGEn (geb. 1958)<br />
arbeitet im Bereich der Verfahrens- und Anlagensicherheit<br />
bei Bayer MaterialScience.<br />
Arbeitsschwer punkte: Erstellung und Überprüfung<br />
verfahrens technischer Sicherheits konzepte.<br />
Bayer MaterialScience AG,<br />
Geb. K12,<br />
D-51368 Leverkusen,<br />
Tel. +49 (0) 214 307 21 97,<br />
E-Mail: gerhard.versteegen@bayer.com<br />
32<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
(which impact on all PFD avg to be calculated in the<br />
course of our chain of arguments), no credit has been<br />
taken for these.<br />
It should be mentioned that by resolving all conservatisms<br />
by e.g. providing specific device-individual failure<br />
rate data, and by use of extended PFD avg calculation models,<br />
a significantly better overall RRF can be achieved.<br />
Conclusion<br />
The intention of this article was to provide a simple<br />
method for evaluating the overall safety integrity for a<br />
specific case study, a SIL 3 overpressure protection, in<br />
case of sharing a sensor and a final element among <strong>SIS</strong><br />
and BPCS.<br />
The result indicates, that – as long as the application<br />
of NAMUR data is valid – sharing components among<br />
<strong>SIS</strong> and BPCS does not lower the overall risk reduction<br />
of the safety loop to an inacceptable value. It has been<br />
shown that the minimum target risk reduction factor<br />
1,000 is achieved with arbitrary prior-use sensors and<br />
final elements according to NE 130.<br />
The approach as provided here might serve as a basis<br />
for suitable analysis of deviating SIF structures, i.e. 2oo3<br />
sensor redundancy or multiple final element groups.<br />
Die Referenzklasse für die<br />
Automatisierungstechnik<br />
Erfahren Sie auf höchstem inhaltlichem Niveau,<br />
was die Automatisierungsbranche bewegt. Alle<br />
Hauptbeiträge werden im Peer-Review-Verfahren<br />
begutachtet, um Ihnen maximale inhaltliche<br />
Qualität zu garantieren.<br />
Genießen Sie ein einzigartiges Lektüreerlebnis,<br />
das ausgezeichnete Layout und die exklusive<br />
Produktausstattung.<br />
Manuskripteingang<br />
21.03.2012<br />
Im Peer-Review-Verfahren begutachtet<br />
Dr.-Ing. Bernd SCHRÖRS (geb. 1954) leitet den<br />
Bereich Functional Safety bei Bayer Technology<br />
Services. Arbeitsschwerpunkte: Process Safety,<br />
Safety System Design, Quantitative Evaluation of<br />
the Safety related Availability.<br />
Bayer Technology Services GmbH,<br />
Geb. B407,<br />
D-51368 Leverkusen,<br />
Tel. +49 (0) 214 307 44 39,<br />
E-Mail: bernd.schroers@bayer.com<br />
Wählen Sie einfach das Bezugsangebot,<br />
das Ihnen zusagt!<br />
· Das Heft als gedrucktes, zeitlos-klassisches Fachmagazin<br />
· Das e-Paper als modernes, digitales Informationsmedium<br />
für Computer, Tablet oder Smartphone<br />
· Das Heft + e-Paper als clevere Abo-plus-Kombination<br />
ideal zum Archivieren<br />
Alle Bezugsangebote und Direktanforderung<br />
finden Sie im Online-Shop unter<br />
www.<strong>atp</strong>-online.de<br />
Oldenbourg Industrieverlag<br />
www.<strong>atp</strong>-online.de<br />
<strong>atp</strong> <strong>edition</strong><br />
<strong>atp</strong> <strong>edition</strong> erscheint in der Oldenbourg Industrieverlag GmbH, Rosenheimer Str. 145,<br />
7-<br />
81671<br />
8 / 2012<br />
München<br />
33
Hauptbeitrag | Automation 2012<br />
Überwachung <strong>von</strong> Prozessen<br />
mit kleiner Losgröße<br />
Active Learning in der Prozessüberwachung<br />
Für die automatisierte Fertigung werden zuverlässige Überwachungssysteme benötigt,<br />
um im Falle ungünstiger Prozesszustände rechtzeitig regelnd eingreifen zu können. Die<br />
derzeit verfügbaren modellbasierten Überwachungssysteme haben den Nachteil, dass sie<br />
mit großem Aufwand auf den zu überwachenden Fertigungsprozess zugeschnitten werden<br />
müssen. Dieser Beitrag beschreibt ein neuartiges Überwachungssystem, das sich mit minimalem<br />
Aufwand an den zu überwachenden Prozess anpassen lässt. Dieser Aufwand<br />
rechnet sich selbst für Fertigungsprozesse mit kleiner Losgröße.<br />
SCHLAGWÖRTER Prozessüberwachung / Klassifikation / Active Learning<br />
Monitoring small batch production processes –<br />
Active learning in process monitoring<br />
Automated production processes require reliable monitoring systems so that timely intervention<br />
is possible if things go wrong. However, adapting model-based monitoring<br />
systems to a specific production process is only viable for processes with large batch sizes.<br />
A new approach to monitoring systems is described that reduces the initial adaptation to<br />
a minimum, so that it is suitable even for small batch production processes.<br />
KEYWORDS process monitoring / classification / active learning<br />
34<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
Markus Kaupp, Joachim NEHER, Fraunhofer-Institut für Produktionstechnik und Automatisierung (ipa)<br />
Fertigungsbetriebe können in Hochlohnländern<br />
nur dann bestehen, wenn sie sich durch Flexibilität,<br />
Termintreue und Qualität vom globalen<br />
Wettbewerb abheben. Daher müssen Fertigungsstätten<br />
an solchen Standorten in der Lage sein,<br />
qualitativ hochwertige Teile kostengünstig, schnell und<br />
zuverlässig herzustellen [1, 2]. Die Hauptvoraussetzung<br />
hierfür sind optimal geführte Fertigungsprozesse. Eine<br />
optimale Prozessführung bedingt wiederum das schnelle<br />
Erkennen ungünstiger Prozesszustände. Insbesondere<br />
muss es möglich sein, die Qualität der gefertigten Teile<br />
umfassend und zeitnah zu bestimmen. Ziel ist es, in<br />
solchen Fällen korrigierend in die Prozesse eingreifen<br />
zu können, noch bevor Schlechtteile entstehen [3, 4].<br />
Derzeit wird die Qualität der gefertigten Teile meist mit<br />
den Einrichtungen der zentralen Qualitätsprüfung ermittelt.<br />
Selbst mit modernen Prüfmethoden betragen die<br />
Prüfzeiten dabei aber oft deutlich mehr als das Hundertfache<br />
der Produktionszeit. Eine Vollprüfung der Teile ist<br />
daher aus wirtschaftlicher Sicht in der Regel nicht mehr<br />
möglich. Dies ist einer der Hauptgründe für die große<br />
Verbreitung der statistischen Prüfung (SPC), die auf<br />
Stichproben basiert. Bei kurzen Fertigungszeiten und<br />
gleichzeitig langen Prüfzeiten stoßen stichprobenbasierte<br />
Verfahren allerdings an die Grenzen ihrer Leistungsfähigkeit.<br />
Dies gilt insbesondere dann, wenn die Fehler<br />
zufällig auftreten. Eine weitere Schwäche der SPC ist,<br />
dass sie Fehler nicht erkennen kann, die durch die Wechselwirkung<br />
mehrerer Signalquellen entstehen [4, 5].<br />
Die zuvor genannten Schwächen der SPC und die gestiegenen<br />
Anforderungen an die fertigungsbegleitende<br />
Dokumentation führen dazu, dass Unternehmen zunehmend<br />
prozessnahe Überwachungssysteme einführen,<br />
um so eine hundertprozentige Qualitätsüberwachung zu<br />
erreichen [6]. Solch eine Einhundertprozent-Prüfung<br />
wird oft mit dem Prozess nachgeschalteten, automatischen<br />
Prüfstationen realisiert. Diese Prüfstationen untersuchen<br />
üblicherweise roboterunterstützt oder unter<br />
Verwendung industrieller Bildverarbeitung geometrische<br />
oder optische Eigenschaften aller gefertigten Teile<br />
[7, 8]. Innere Produkteigenschaften, wie beispielsweise<br />
Formschluss oder Festigkeit, sind mit derartigen Prüfsystemen<br />
jedoch nicht zu erfassen. Ein raues Prüfumfeld,<br />
hohe Fertigungstaktraten, hohe Anforderungen an die<br />
Prüfgenauigkeit oder stark strukturierte Teilegeometrien<br />
begrenzen ebenso den wirtschaftlichen Einsatz dieser<br />
Prüftechniken innerhalb <strong>von</strong> Fertigungslinien [4]. Aus<br />
diesem Grund gibt es schon seit Jahren Forschungs- und<br />
Entwicklungsarbeiten, die mittels Sensorintegration und<br />
unterschiedlicher Überwachungsmethoden eine qualitätsbezogene<br />
Inline-Überwachung <strong>von</strong> Produktionsprozessen<br />
verfolgen [3, 9]. In der Spritzgießtechnologie ist<br />
eine laufende und dokumentierte Prozessdatenerfassung<br />
bereits seit langem Stand der Technik und wird oft vom<br />
Kunden als Qualitätsdokumentation gefordert [6].<br />
Als leistungsfähigste Verfahren zur sensordatenbasierten<br />
Prozessüberwachung gelten die modellbasierten Überwachungssysteme.<br />
Diese Systeme modellieren die Fertigungsprozesse<br />
mit Verfahren aus dem Bereich des überwachten<br />
maschinellen Lernens. Dadurch sind sie in der<br />
Lage, auch die komplexen Zusammenhänge stark wechselwirkungsbehafteter<br />
Fertigungsprozesse abzubilden. Ein<br />
großer Nachteil der derzeit eingesetzten modellbasierten<br />
Überwachungssysteme ist allerdings, dass sie mit sehr<br />
großem Aufwand an den zu überwachenden Fertigungsprozess<br />
angepasst werden müssen [10–12]. Dieser Aufwand<br />
rechnet sich nur für Prozesse mit großen Stückzahlen [4].<br />
Um künftig auch Fertigungsprozesse mit kleinen und<br />
mittleren Losgrößen effizient überwachen zu können,<br />
wurde am Fraunhofer-Institut für Produktionstechnik<br />
und Automatisierung daher ein neuartiges Überwachungssystem<br />
entwickelt. Dieses System lässt sich mit<br />
minimalem Aufwand an den zu überwachenden Prozess<br />
anpassen. Bei Bedarf kann der aktive Lernalgorithmus<br />
noch zusätzliche Anpassungen vornehmen. Diese Anpassungen<br />
können aber erfolgen, während der Prozess<br />
bereits überwacht wird.<br />
In diesem Beitrag wird der beschriebene Ansatz zur<br />
Prozessüberwachung ausführlich vorgestellt. Zudem<br />
wird dessen Funktionsumfang und Leistungsfähigkeit<br />
anhand eines realen Produktionsprozesses aus dem Bereich<br />
der Kunststoffverarbeitung demonstriert.<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
35
Hauptbeitrag | Automation 2012<br />
1. Modellbasierte Prozessüberwachung<br />
Das Grundproblem des überwachten maschinellen Lernens<br />
ist die Vorhersage der Ausgabe einer unbekannten<br />
Funktion. In anderen Worten: Seien X und Y nichtleere<br />
Mengen, und sei f:X Y eine unbekannte Funktion.<br />
Dann ist es die Aufgabe des überwachten maschinellen<br />
Lernens, für jeden möglichen Eingabewert xεX den zugehörigen<br />
Funktionswert f(x) vorherzusagen. Ist die Ausgabemenge<br />
Y diskret, dann nennt man die Vorhersageaufgabe<br />
Klassifikation, andernfalls wird die Aufgabe<br />
Regression genannt [13].<br />
Überwachte Lernverfahren bewältigen diese Vorhersageaufgabe<br />
mithilfe eines Vorhersagemodells. Die entsprechenden<br />
Vorhersagemodelle erstellen diese Verfahren<br />
auf der Basis vorgegebener Beispieldatensätze. Jeder<br />
dieser Beispieldatensätze sεX×Y enthält dabei einen<br />
möglichen Eingabewert zusammen mit dem zugehörigen<br />
Sollausgabewert. Wenn die vorgegebenen Beispieldatensätze<br />
das zugrundeliegende Problem ausreichend gut<br />
beschreiben, kann der Algorithmus mit dem daraus erstellten<br />
Vorhersagemodell auch die Funktionswerte für<br />
bisher ungesehene Eingabewerte vorhersagen [13].<br />
Modellbasierte Prozessüberwachungssysteme nutzen<br />
überwachte maschinelle Lernverfahren für die Prognose<br />
des aktuellen Prozesszustandes. Solche Systeme haben<br />
üblicherweise den gleichen Grundaufbau (siehe Bild 1).<br />
Nach diesem Aufbauschema werden zunächst physikalische<br />
Größen des überwachten Prozesses sensorisch<br />
erfasst. Die so gewonnenen Rohsignale werden anschließend<br />
mit Verfahren der digitalen Signalverarbeitung<br />
aufbereitet. Aus den aufbereiteten Signalen werden im<br />
Rahmen der Kenngrößenbildung wiederum die relevanten<br />
Informationen extrahiert und durch numerische<br />
Werte beschrieben. Diese numerischen Werte werden<br />
Kenngrößen genannt. Die Kenngrößenselektion wählt<br />
aus den verfügbaren Kenngrößen die aussagekräftigsten<br />
aus. Dadurch lassen sich Güte und Robustheit der späteren<br />
Prognose verbessern. Die ausgewählten Kenngrößen<br />
werden an ein Prozessmodell übergeben. Grundlage dieses<br />
Prozessmodells ist ein überwachtes maschinelles<br />
Lernverfahren, das mit Beispieldatensätzen an den zu<br />
überwachenden Prozess angepasst wurde [12].<br />
Die für die Modellanpassung benötigten Beispieldatensätze<br />
müssen so beschaffen sein, dass sie den Prozess<br />
ausreichend gut beschreiben. Daher werden diese Datensätze<br />
unter Verwendung eines detaillierten Versuchsplans<br />
(DoE) erzeugt. Die Ausarbeitung eines Versuchsplanes<br />
und die Ausführung der notwendigen Experimente im<br />
Fertigungsprozess sind bei diesen klassischen Überwachungssystemen<br />
sehr zeitaufwendig und teuer [10, 12].<br />
2. Der neue Ansatz<br />
Active Learning erweitert den Ansatz des überwachten<br />
maschinellen Lernens. Wie das klassische überwachte<br />
Lernen verwendet auch das Active Learning Beispielda-<br />
Bild 1: Allgemeiner Aufbau <strong>von</strong> Prozessüberwachungssystemen<br />
Bild 2: Ablauf der Prozessüberwachung mit<br />
Active Learning<br />
36<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
tensätze für die Anpassung an ein konkretes Problem.<br />
Das spezielle Merkmal <strong>von</strong> Active-Lerning-Algorithmen<br />
ist deren Fähigkeit, die Prognosegüte auch nach Ende<br />
der initialen Anpassungsphase noch weiter verbessern<br />
zu können. Diese Verbesserung lässt sich erreichen, indem<br />
der Algorithmus während der laufenden Klassifikation<br />
hochinformative Eingabedatensätze ausfindig<br />
machen kann. Diese hochinformativen Datensätze lassen<br />
sich vom Anwender manuell klassifizieren und an den<br />
Lernalgorithmus zurückgeben. Die manuell klassifizierten<br />
Datensätze werden innerhalb des Algorithmus dann<br />
den anderen Beispieldatensätzen hinzugefügt und verbessern<br />
so das Prognosemodell [14–17].<br />
Wird das Konzept des Active Learning in der Prozessüberwachung<br />
angewandt, so ergibt sich der in Bild 2<br />
dargestellte Aufbau. In diesem Aufbau übernimmt das<br />
Prozessüberwachungssystem im laufenden Betrieb Sensordaten<br />
aus dem aktuell überwachten Prozess. Die übernommenen<br />
Signale werden aufbereitet und an den Active-Learning-Algorithmus<br />
weitergegeben. Dieser Algorithmus<br />
ist nun in der Lage zu erkennen, ober er den<br />
aktuellen Datensatz überhaupt zuverlässig klassifizieren<br />
kann. Wenn dies möglich ist, so wird der entsprechende<br />
Prozesszustand als Resultat ausgegeben. Kommt der Algorithmus<br />
aber zu dem Ergebnis, dass keine zuverlässige<br />
Klassifikation möglich ist, so werden die aktuellen Signaldaten<br />
als hochinformativ gekennzeichnet und an einer<br />
geeigneten Stelle abgespeichert. Gleichzeitig wird das<br />
im entsprechenden Zyklus produzierte Werkstück aus<br />
Bild 3: Codebookvektoren mit ihren konvexen Hüllen<br />
dem Fertigungsprozess ausgeschleust. Das ausgeschleuste<br />
Werkstück kann nun einer manuellen Qualitätsprüfung<br />
unterzogen werden. Das Ergebnis dieser Qualitätsprüfung<br />
wird zusammen mit den zugehörigen Sensordaten<br />
an das Überwachungssystem übergeben und dort zur<br />
Verbesserung des Prognosemodells verwendet [18, 19].<br />
Für das System wurde ein neuer Active-Learning-Algorithmus<br />
entwickelt, der auf der Learning-Vector-Quantization<br />
(LVQ) [20] basiert. LVQ hat sich als robustes<br />
Klassifikationsverfahren in der Prozessüberwachung<br />
bewährt [21]. Das LVQ-Verfahren arbeitet auf Basis <strong>von</strong><br />
Codebookvektoren. Diese Codebookvektoren werden im<br />
Rahmen der Modellanpassung im Kenngrößenraum positioniert.<br />
Nach erfolgter Positionierung der Codebookvektoren<br />
werden alle vorhandenen Beispieldaten dem<br />
jeweils nächstliegenden Codebookvektor zugeordnet.<br />
Abschließend wird jedem der Codebookvektoren die<br />
Klasse zugewiesen, die in den ihm zugeordneten Beispieldatensätzen<br />
am häufigsten vorkommt. Soll nach<br />
Abschluss der Anpassungsphase ein Datensatz klassifiziert<br />
werden, so wird zunächst der Codebookvektor ermittelt,<br />
der im Kenngrößenraum den geringsten Abstand<br />
zum zu klassifizierenden Datensatz hat. Als Ergebnis der<br />
Klassifikation wird dann die Klasse zurückgegeben, die<br />
dem entsprechenden Codebookvektor zugeordnet ist [20].<br />
Im Rahmen der beschriebenen Arbeiten wurde der<br />
ursprüngliche LVQ-Algorithmus zu einem Active-Learning-Algorithmus<br />
erweitert, indem die „Unbekannt-<br />
Klassifikation“ integriert wurde. Die Unbekannt-Klassifikation<br />
versetzt den Algorithmus in die Lage, zu<br />
unterscheiden, welche Datensätze er sicher klassifizieren<br />
kann. Datensätze, die nicht sicher klassifiziert werden<br />
können, werden als unbekannt gekennzeichnet.<br />
Diese unbekannten Datensätze gelten als hochinformativ<br />
und werden zur manuellen Klassifikation an den<br />
Benutzer weitergereicht.<br />
Zur Integration der Unbekannt-Klassifikation in den<br />
bestehenden LVQ-Algorithmus wurde ein neuartiger<br />
Ansatz verfolgt. Dieser Ansatz verwendet eine anisotrope<br />
räumliche Form für die Unbekannt-Klassifikation.<br />
Nach erfolgtem Training ordnet das Verfahren jedem<br />
Kenngrößensatz aus den verwendeten Trainingsdaten<br />
den nächstgelegenen Codebookvektor zu. Anschließend<br />
werden die Codebookvektoren und die zugeordneten<br />
Kenngrößensätze in die Ebene projiziert. In dieser Projektion<br />
wird für jeden Codebookvektor die konvexe Hülle<br />
um die zugeordneten Kenngrößensätze bestimmt.<br />
Diese konvexen Hüllen bilden später die Grenzen für die<br />
Unbekannt-Klassifikation. Wann immer die 2-dimensionale<br />
Projektion eines Kenngrößensatzes in eine dieser<br />
konvexen Hüllen fällt, gilt das Datenmuster als bekannt.<br />
Andernfalls wird es als unbekannt klassifiziert. Bild 3<br />
zeigt die Verteilung der Codebookvektoren und die zugeordneten<br />
Kenngrößensätze anhand <strong>von</strong> Sensordaten<br />
aus einem realen Fertigungsprozess. Die konvexen Hüllen,<br />
die den einzelnen Codebookvektoren zugeordnet<br />
wurden, sind dabei mit farbigen Linien markiert.<br />
Durch Integration der zuvor beschriebenen Methode<br />
konnte das ursprüngliche LVQ-Verfahren um die Fähigkeit<br />
zur Unbekannt-Klassifikation erweitert werden. Es<br />
zeigte sich, dass mit diesem Verfahren eine sehr rigide<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
37
Hauptbeitrag | Automation 2012<br />
Bild 4: Temperaturen im Formnest über alle Zyklen<br />
Bild 5: Ergebnisse der Unbekannt-Klassifikation bei<br />
verstellter Heißkanaltemperatur<br />
Trennung zwischen bekannten und potenziell unbekannten<br />
Datensätzen erzielt wird.<br />
3. Ergebnisse und Diskussion<br />
Zur Verifikation wurde das im Beitrag vorgestellte Prozessüberwachungssystem<br />
in mehreren Fertigungsprozessen<br />
prototypisch eingesetzt. Einer dieser überwachten<br />
Prozesse war ein Spritzgießprozess mit Achtfach-<br />
Werkzeug, mit dem Präzisionsteile mit Sicherheitsanforderung<br />
für den Automotive-Bereich gefertigt werden. Bei<br />
einer Zykluszeit <strong>von</strong> unter 10 Sekunden werden etwa 50<br />
Teile pro Minute gefertigt. Mit herkömmlichen Methoden<br />
ist eine Einhundertprozent-Überwachung dabei nicht<br />
möglich. Daher ist eine prozessintegrierte Überwachung<br />
auf Basis <strong>von</strong> Sensorsignalen zwingend notwendig.<br />
Das Werkzeug wurde mit acht Temperatursensoren<br />
und einem Drucksensor ausgerüstet und die Daten wiederum<br />
über ein eDAQ-System der Firma Priamus erfasst.<br />
Während der Versuchsreihe wurde zum einen die laufende<br />
Produktion über einige Zeit mitgeschrieben. Andererseits<br />
wurden auch qualitätsrelevante Prozessparameter<br />
wie Nachdruck, Einspritzgeschwindigkeit und<br />
Temperatur <strong>von</strong> Werkzeug und Heißkanal gezielt variiert,<br />
wobei der ursprüngliche Arbeitspunkt wiederholt<br />
angefahren wurde. Der Prozess ist mit einem Handling<br />
zur formnestgetrennten Ablage ausgerüstet, über den<br />
auch Ausschuss- und Versuchsteile in separate Ablagen<br />
abgelegt werden. Das Ausschleusen zu prüfender Bauteile<br />
ist somit einfach möglich.<br />
Der Verlauf <strong>von</strong> Start- und Maximaltemperatur eines<br />
Werkzeugtemperatursignals über alle Zyklen der parametervariierten<br />
Versuchsreihe ist in Bild 4 dargestellt.<br />
Auch hierbei zeigen sich wieder die Auswirkungen <strong>von</strong><br />
Prozessvariationen und Störeinflüssen auf das thermische<br />
Gleichgewicht des Prozesses. So waren nach der<br />
Absenkung der Werkzeugtemperatur fast 200 Produktionszyklen<br />
notwendig, bis wieder ein stabiles Gleichgewicht<br />
erreicht wurde. Auch längere Handlingswege<br />
aufgrund der Teileablage in der Versuchs- oder Ausschussrutsche<br />
führen direkt zu einer geringfügigen Zykluszeitverlängerung<br />
und damit einer Störung des thermischen<br />
Gleichgewichts. Eine Zykluszeitverlängerung<br />
<strong>von</strong> zirka 0,8 Sekunden bei der Ablage der Versuchsteile<br />
bei 10 aufeinanderfolgenden Zyklen ist durch signifikante<br />
Einbrüche der Temperaturen zu erkennen.<br />
Aus den aufgezeichneten Signalen wurden Kenngrößenvektoren<br />
zur Beschreibung des Produktionszyklus<br />
abgeleitet. Anhand der Versuchsdaten wurde mit den im<br />
Projekt erarbeiteten Methoden ein Prozessmodell erstellt.<br />
Die Anwendung auf die gesamten Versuchszyklen,<br />
also inklusive der Zyklen mit Übergängen <strong>von</strong> einer Prozesseinstellung<br />
zur anderen, zeigte, dass die Einstellung<br />
vom Prozessmodell mit sehr hoher Sicherheit richtig<br />
zugeordnet werden konnte. Ferner wurden die Übergangszyklen<br />
größtenteils als unbekannt ausgeschleust.<br />
Einzig im direkten Umfeld der Einstellungen – also direkt<br />
nach einer Parametervariation oder vor Erreichen<br />
des neuen stationären Zustands – war die Zuordnung<br />
nicht immer eindeutig. Insgesamt konnten die Klassifikationsmethoden<br />
jedoch ihre hohe Güte auch an realen<br />
Bauteilen beweisen.<br />
Abschließend wurde während der Produktion noch<br />
die Heißkanaltemperatur (im Bereich <strong>von</strong> 300 °C) nur um<br />
5 °C variiert, um eine Prozessstörung zu simulieren. Eine<br />
Variation der Heißkanaltemperatur war bei den Daten<br />
für das Modelltraining nicht enthalten. Wie aus Bild 5<br />
ersichtlich, wurde der geänderte Prozesszustand zeitnah<br />
erkannt und alle Produktionszyklen als „unbekannt“<br />
klassifiziert. Der Anwender ist somit in der Lage, Prozessstörungen<br />
frühzeitig erkennen und somit zeitnah<br />
darauf reagieren zu können [22].<br />
Zusammenfassung<br />
Dieser Beitrag beschreibt ein neuartiges Prozessüberwachungssystem,<br />
das am Fraunhofer-Institut für Produktionstechnik<br />
und Automatisierung entwickelt wurde.<br />
Das Prozessüberwachungssystem arbeitet auf Basis <strong>von</strong><br />
Algorithmen aus dem Bereich des Active Learning. Die<br />
Verwendung dieser Algorithmen versetzt das System in<br />
die Lage, mit geringem initialen Adaptionsaufwand eine<br />
sichere Überwachung zu gewährleisten. Die Leistungsfähigkeit<br />
des Systems wurde anhand eines realen Fertigungsprozesses<br />
bestätigt. Für die Anpassung des Überwachungssystems<br />
an den Fertigungsprozess wurde ein<br />
Versuchsplan gefahren, der weniger als eine halbe Stunde<br />
der Maschinenzeit in Anspruch nahm. Dieser geringe<br />
38<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
Versuchsaufwand zeigt, dass sich das erarbeitete Überwachungssystem<br />
schnell und einfach einrichten lässt.<br />
Förderhinweis<br />
Autoren<br />
Manuskripteingang<br />
09.05.2012<br />
Im Peer-Review-Verfahren begutachtet<br />
Das IGF-Vorhaben 16138N der Forschungsvereinigung<br />
Forschungsgemeinschaft Qualität e.V. (FQS), August-<br />
Schanz-Straße 21A, 60433 Frankfurt am Main, wurde<br />
über die AiF im Rahmen des Programms zur Förderung<br />
der industriellen Gemeinschaftsforschung und<br />
-entwicklung (IGF) vom Bundesministerium für Wirtschaft<br />
und Technologie aufgrund eines Beschlusses<br />
des Deutschen Bundestages gefördert.<br />
Dipl.-Ing. (BA) Dipl.-Inform.<br />
MARKus Kaupp (geb. 1975)<br />
studierte Informationstechnik<br />
und Informatik und<br />
arbeitete mehrere Jahre als<br />
Entwicklungsingenieur auf<br />
dem Gebiet der digitalen Signalanalyse<br />
(unter anderem<br />
bei Philips). Seit 2009<br />
erforscht er am Fraunhofer-IPA Methoden der<br />
künstlichen Intelligenz zur Klassifikation <strong>von</strong><br />
Sensorsignalen.<br />
Fraunhofer-IPA, Bild- und Signalverarbeitung,<br />
Nobelstr. 12, D-70569 Stuttgart,<br />
Tel. +49 (0) 711 970 18 33,<br />
E-Mail: Markus.Kaupp@ipa.fraunhofer.de<br />
Dipl.-Ing. JOACHim NEHER<br />
(geb. 1976) studierte Technische<br />
Kybernetik an der<br />
Universität Stuttgart. Seit<br />
2002 ist er wissenschaftlicher<br />
Mitarbeiter am IFF der<br />
Universität Stuttgart und am<br />
Fraunhofer-IPA. Er promovierte<br />
zum Thema der<br />
Prozessüberwachung mit Neuro-Fuzzy-Modellen.<br />
Seine Forschungsschwerpunkte liegen auf<br />
den Gebieten der Prozessüberwachung, dem<br />
Energiemonitoring in der Fertigung sowie der<br />
Energieeffizienz insbesondere in der Kunststoffverarbeitung.<br />
Fraunhofer-IPA, Bild- und Signalverarbeitung,<br />
Nobelstr. 12, D-70569 Stuttgart,<br />
Tel. +49 (0) 711 970 18 16,<br />
E-Mail: Joachim.Neher@ipa.fraunhofer.de<br />
Internet: www.ipa.fraunhofer.de<br />
Referenzen<br />
[1] Westkämper E. (Hrsg.): Wandlungsfähige Unternehmensstrukturen.<br />
Das Stuttgarter Unternehmensmodell. Springer, Berlin 2005<br />
[2] Wiendahl, H.-P.; Gerst, D.; Keunecke, L. (Hrsg.): Variantenbeherrschung<br />
in der Montage. Konzept und Praxis der flexiblen Produktionsendstufe.<br />
Springer, Berlin 2004<br />
[3] Liang, S.Y., Hecker, R.L., Landers, R. G.: Machining Process Monitoring<br />
and Control: The State-of-the-Art. Journal of Manufacturing Science<br />
and Engineering 126 (2), S. 297–310, 2004<br />
[4] Schmidberger, E., Neher, J. Leitfaden für die Qualitätssicherung und<br />
-überwachung <strong>von</strong> LowRunner-Prozessen (QSLR). Forschungsgemeinschaft<br />
Qualität e.V., Frankfurt am Main 2008<br />
[5] neher, J., Schmidberger, E.: Was das Werkzeug weiß. Inline-Qualitätsüberwachung<br />
auch für kleine Losgrößen. Qualität und Zuverlässigkeit<br />
QZ 53 (9), S. 94–95, 2008<br />
[6] Wurm, H.: 100 % Qualitätskontrolle. Plastverarbeiter 13, S. 82, 2006<br />
[7] modrich, K.-U.: Industrielle Bildverarbeitung für automatisierte<br />
Produktionen. Optik & Photonik 2 (3), S. 25–31, 2007<br />
[8] breuer, T.: Wirtschaftlich bei kleinen Losgrößen. Plastverarbeiter 14<br />
(2007), S. 14–16<br />
[9] König, E.: Dynamische Temperaturmessung als Ausschussphrophylaxe.<br />
Kunststoffe 97, S. 56–60, 2007<br />
[10] teti, R.; Jemielniak, K.; O’Donnell, G.; Dornfeld, D.: Advanced monitoring<br />
of machining operations. Cirp Annals - Manufacturing Technology<br />
59 (2), S. 717–39, 2010<br />
[11] ribeiro, B.: Support Vector Machines for Quality Monitoring in a Plastic<br />
Injection Molding Process. ieee Transactions on Systems, Man and<br />
Cybernetics, Part C (Applications and Reviews) 35 (3), S. 401–10, 2005<br />
[12] abellan-Nebot, J. V.; Romero Subirón, F.: A review of machining<br />
monitoring systems based on artificial intelligence process models.<br />
The International Journal of Advanced Manufacturing Technology 47<br />
(1-4), S. 237–57, 2010<br />
[13] bishop, C. M.: Pattern Recognition and Machine Learning. Verlag<br />
Springer Science + Business Media LLC, New York, NY 2008<br />
[14] Salibian-Barrera, M.; van Aelst, S.: Robust model selection using fast<br />
and robust bootstrap. Computational Statistics & Data Analysis 52 (12),<br />
S. 5121–35, 2008<br />
[15] Cohn, D, Atlas, L.; Ladner, R.: Improving Generalization with Active<br />
Learning. Machine Learning 15 (2), S. 201–21, 1994<br />
[16] Jain, P.; Kapoor; Ashish: Active Learning for Large Multi-class<br />
Problems. In: ieee Conference on Computer Vision and Pattern<br />
Recognition S. 762–769. ieee, Los Alamitos, California 2009<br />
[17] Schleif, F. M.; Hammer, B.; Villmann, T.: Margin-based active learning<br />
for LVQ networks. In: Verleysen, M. (Hrsg.): Advances in computational<br />
intelligence and learning. 14th European Symposium on Artificial<br />
Neural Networks, S. 1215–1224. d-side, Evere, Belgium 2006<br />
[18] Kaupp, M., Neher, J.: A new Approach for Quality Monitoring in Small<br />
Batch Processes. In: Terje K. Lien (Hrsg.): Responsive, customer<br />
demand driven, adaptive assembly. Proceedings of the 3rd Cirp<br />
Conference on Assembly Technologies and Systems. S. 205–208. Tapir<br />
Academic Press, Trondheim 2010<br />
[19] Kaupp, M.; Neher, J.: Active Learning Based Process Monitoring – An<br />
Application Report. In: Spath, D.; Ilg, R. (Hrsg.): Innovation in product<br />
and production. 21th International Conference on Production Research,<br />
Fraunhofer-Verlag, Stuttgart 2011<br />
[20] Kohonen, T.: The self-organizing map. Proceedings of the ieee 78 (9),<br />
S. 1464–1480, 1990<br />
[21] Khushaba, R. N., Al-Ani, A., Al-Jumaily, A.: Feature Subset Selection<br />
Using Differential Evolution and a Statistical Repair Mechanism. Expert<br />
Systems with Applications 38 (9), S. 11515–11526. 2011<br />
[22] Kaupp, M.; Neher, J.: Schlussbericht zum Forschungsvorhaben<br />
„Adaptive Klassifikation“ 2012<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
39
Hauptbeitrag | Automation 2012<br />
Kernmodelle für die<br />
Systembeschreibung<br />
Ein Konzept zur Vereinfachung<br />
Durch komplexer und abstrakter werdende Technologien nehmen auch Umfang und Komplexität<br />
ihrer Beschreibungen zu. Während Spezifikationen konkreter Technologien direkt<br />
referenziert und damit ausgegliedert werden können, ist dies für die allgemeinen und<br />
grundlegenden Konzepte und Strukturen hinter den Technologien wegen fehlender Referenzen<br />
nicht möglich. Entsprechend müssen sie in jedem Anwendungsfall erneut definiert<br />
werden. Insbesondere für Anwendungsnormen, in denen eine vollständige und<br />
unmissverständliche Beschreibung angestrebt wird, führt dies zu extrem komplexen und<br />
umfangreichen Spezifikationen, die häufig nur noch <strong>von</strong> wenigen Experten vollständig<br />
erfasst werden können. Der DKE-Arbeitskreis 931.0.4 hat es sich daher zum Ziel gesetzt,<br />
grundlegende Konzepte und Strukturen in Modellform zu spezifizieren und als referenzierbare<br />
„Kernmodelle“ zu veröffentlichen.<br />
SCHLAGWÖRTER Modellierung / Kernmodelle / Normung / Entitätenmodell /<br />
prozessmodell / Lebenszyklusmodell<br />
Core models for system documentation –<br />
A proposal for simplification<br />
As technologies become more complex and abstract, the complexity of their documentation<br />
also increases. While it is possible to directly reference specifications for certain<br />
technologies and thus decouple them from a document, this is not possible for the general<br />
underlying concepts and structures, for which no reference documents are available.<br />
Accordingly, it is necessary to define these for each application. In particular in standards,<br />
the result is frequently that only a limited group of experts are able to understand the<br />
document in full. DKE working group 931.0.4 has set itself the goal of publishing these<br />
basic concepts and structures as referenceable “core models”.<br />
KEYWORDS modelling / core models / standardisation / entity-model /<br />
process-model / lifecycle-model<br />
40<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
David KampERT, UlriCH Epple, RWTH Aachen<br />
Zur Spezifikation <strong>von</strong> technischen Systemkonzepten<br />
ist heute die Verwendung einer Vielzahl<br />
<strong>von</strong> abstrakten Begriffen, Zusammenhängen,<br />
technologischen Konzepten und grundlegenden<br />
Modellierungskonzepten erforderlich. Wenn<br />
eine Spezifikation so exakt sein soll, dass keine Missverständnisse<br />
entstehen können, wächst der Umfang der<br />
Beschreibung rapide an. Dies ist ein Problem der aktuellen<br />
Normung und führt in vielen Fällen so weit, dass<br />
Normen häufig nur noch <strong>von</strong> wenigen Experten, die das<br />
gesamte Werk und seine Begriffswelt kennen, vollständig<br />
verstanden werden. Natürlich ist es unumgänglich,<br />
dass eine Norm mit der Komplexität ihres Inhalts<br />
wächst. Es sollte jedoch möglich sein, sich in einer Norm<br />
auf das Kernthema zu konzentrieren und nicht zusätzlich<br />
alle vorausgesetzten Begriffe und verwendeten Konzepte<br />
mit spezifizieren zu müssen, um eine vollständige<br />
Beschreibung zu erzielen.<br />
Diese grundlegende Anforderung wird nicht erfüllt.<br />
Dafür lassen sich zahlreiche Beispiele anführen. So enthält<br />
DIN EN 61360 [6] ein merkmalbasiertes Klassifikationsschema<br />
für (ganz allgemeine) Objekte, obwohl die<br />
Norm sich eigentlich speziell mit der Beschreibung elektrischer<br />
Bauteile befasst. Ein anderes Beispiel ist die als<br />
Batch-Norm bekannte DIN EN 61512 [7], in der unter anderem<br />
der hierarchische Aufbau <strong>von</strong> industriellen Anlagen<br />
spezifiziert wird. Es soll an dieser Stelle nicht<br />
kritisiert werden, dass dies im Einzelfall so ist, sondern<br />
vielmehr hinterfragt werden, warum es eigentlich notwendig<br />
ist. Schließlich wird eine merkmalbasierte Klassifikation<br />
für viele Arten <strong>von</strong> Objekten angewendet, und<br />
Industrieanlagen haben auch ohne Batch-Prozesse einen<br />
hierarchischen Aufbau.<br />
In jedem Fall ist klar, dass in Folge dieser Situation<br />
der Umfang einzelner Normen drastisch ansteigt und<br />
sich eine eigene Begriffswelt bildet, die trotz einer<br />
scheinbaren Allgemeingültigkeit doch aus einer eher<br />
speziellen Perspektive stammt. Da verwundert es<br />
nicht, wenn außerhalb dieser Perspektive niemand diese<br />
Begriffswelt übernimmt, sondern sie lieber nach<br />
eigenen Vorstellungen neu definiert. Verständnisprobleme<br />
durch Begriffskonfusion sind damit vorprogrammiert.<br />
Auslöser des Dilemmas ist, dass allgemeingültige<br />
und grundlegende Konzepte verwendet werden,<br />
die jedoch an keiner Stelle unabhängig vom Anwendungsbereich<br />
festgelegt sind. Wird nun ein solches<br />
Konzept im Rahmen einer Spezifikation benötigt, bleibt<br />
nichts anderes übrig, als es im Rahmen der Spezifikation<br />
vollständig neu zu beschreiben. Deshalb drängt<br />
sich die Frage auf, weshalb es für die betroffenen Spezifikationen<br />
nicht möglich ist, vorhandene Quellen zu<br />
referenzieren – schließlich wird das zum Teil sogar<br />
explizit gefordert [3].<br />
Sofern es um die Beschreibung konkreter Technologien<br />
geht, für die an anderer Stelle bereits eine Spezifikation<br />
existiert, ist das natürlich möglich und wird<br />
auch so getan. Doch anders als konkrete Technologien<br />
haben die hier angesprochenen Konzepte keine selbstständige<br />
Anwendung, sondern sind Modelle, die einer<br />
Sichtweise auf Systeme entsprechen. Beispielsweise<br />
kann für einen Produktionsprozess festgelegt werden,<br />
dass er mithilfe einer bestimmten Technologie umgesetzt<br />
wird. Dieser Aspekt wird somit eindeutig und<br />
unabhängig. Die Modellvorstellung hinter dem Begriff<br />
„Produktionsprozess“ als Spezialfall eines Prozesses<br />
wird aber durch den konkreten Produktionsprozess<br />
geprägt und ist dadurch nicht problemlos auf andere<br />
konkrete Produktionsprozesse übertragbar. Für Modelle<br />
dieser Art offenbart sich die Notwendigkeit zur Spezifikation<br />
erst dann, wenn sie auch eine Anwendung<br />
haben. Typischerweise gibt es daher keine referenzierbare<br />
Quelle, die sie unabhängig als vollständiges Modell<br />
definiert.<br />
Der Ausweg aus der Situation ist leicht zu erkennen.<br />
Wenn verbreitete Konzepte, die als allgemein bekannt<br />
gelten, in allgemeingültiger Form einmalig festgelegt<br />
werden, lassen sie sich in speziellen Anwendungsfällen<br />
ohne eine erneute grundlegende Beschreibung verwenden.<br />
Dazu ist es wichtig, eine sinnvolle Auswahl an<br />
Konzepten zu treffen und diese in einem geeigneten<br />
Detailgrad anwendungs- und technologieunabhängig zu<br />
beschreiben. Der DKE-Arbeitskreis 931.0.4 „Kernmodel-<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
41
Hauptbeitrag | Automation 2012<br />
le“ hat sich zum Ziel gesetzt, derartige Konzepte zu<br />
identifizieren und als Kernmodelle zu beschreiben.<br />
1. Kernmodelle<br />
Der Begriff Kernmodell bezeichnet eine spezielle Art <strong>von</strong><br />
Modellen. Kernmodelle besitzen folgende Eigenschaften:<br />
Kernmodelle sind Beschreibungen <strong>von</strong> grundlegenden<br />
Konzepten und Zusammenhängen, die<br />
einen bestimmten Aspekt eines Systems betreffen.<br />
Kernmodelle sind allgemein, technologie- und<br />
anwendungsneutral in allen Fällen anwendbar, in<br />
denen der relevante Aspekt eine Rolle spielt.<br />
Kernmodelle sind einfach und übersichtlich.<br />
Kernmodelle besitzen einen formalen Kern.<br />
Kernmodelle können sich gegenseitig nutzen, sind<br />
aber weitgehend in sich selbst verständlich.<br />
Definition Kernmodell<br />
Einfache modellmäßige Beschreibung <strong>von</strong> grundlegenden<br />
Konzepten und Zusammenhängen, die einen allgemeinen<br />
Aspekt <strong>von</strong> Systemen betreffen.<br />
Einordnung<br />
Konzepte, die dem des Kernmodells ähneln, sind in vielen<br />
wissenschaftlichen und technischen Bereichen verbreitet.<br />
Eine exakte Entsprechung existiert jedoch nicht.<br />
Beispielsweise verbindet Geschäftsmodelle in der Betriebswirtschaftslehre<br />
[2], Entwurfsmuster in der Architektur<br />
[1] und Softwareentwicklung [8] mit den Kernmodellen,<br />
dass durch sie abstrakte Ideen formuliert<br />
werden, die praktisch ganz unterschiedlich ausgeprägt<br />
sein können. Im Falle der Softwareentwicklung wurde<br />
ein Katalog <strong>von</strong> Entwurfsmustern etabliert, in dem sie<br />
explizit und strukturiert beschrieben werden [8]. Dies<br />
ist ebenfalls eine Zielsetzung für Kernmodelle. Eine<br />
klare Abgrenzung gegenüber den Entwurfsmustern der<br />
Softwareentwicklung ist, dass Kernmodelle nicht den<br />
Anspruch der unmittelbaren Umsetzung erheben. Sie<br />
sind nicht Entwurfsgrundlage sondern ein Aspekt eines<br />
entworfenen Systems. In dieser Hinsicht sind Kernmodelle<br />
eher mit Geschäftsmodellen vergleichbar, die sich<br />
an keiner konkreten Stelle eines Unternehmens manifestieren,<br />
sondern einer Sichtweise auf ein Unternehmen<br />
entsprechen. Eine anerkannte, eindeutige Definition<br />
des Begriffs „Geschäftsmodell“ sowie eine strukturierte<br />
Beschreibungsform, an der man sich bei der Definition<br />
der Kernmodelle anlehnen könnte, existieren<br />
jedoch nicht [2].<br />
Anwendungsspektrum<br />
Kernmodelle dienen der Modellierung <strong>von</strong> Systemen,<br />
Systeminteraktionen und Verwaltung <strong>von</strong> Systemen sowie<br />
der Modellierung weiterer mehr domänenspezifischer<br />
Aspekte. Die vom AK931.0.4 betrachteten Kernmodelle<br />
lassen sich in die folgenden Kategorien einteilen:<br />
Einteilung <strong>von</strong> Informationswelt und realer Welt<br />
Strukturierung und Beschreibung <strong>von</strong> Systemen<br />
Funktionalität technischer Systeme<br />
Prozesse und Prozessführung<br />
Abschnitt 3 enthält drei Beispiele für Kernmodelle, die<br />
zur Beschreibung <strong>von</strong> technischen Prozessen herangezogen<br />
werden können.<br />
Normung<br />
In der aktuellen Normung werden zur Vereinfachung<br />
und zur Wahrung <strong>von</strong> Konsistenz häufig Begriffsdefinitionen<br />
oder vollständige Modelle referenziert und übernommen.<br />
Beispielsweise verwendet die DIN EN 61360<br />
ein in ISO 13584-42 [10] definiertes Informationsmodell.<br />
Kernmodelle sind im Vergleich weniger konkret ausgeprägt<br />
als derartige Spezifikationen, sie beinhalten andererseits<br />
aber mehr Semantik als durch eine einfache<br />
Begriffsdefinition erfassbar wäre. Daher reichen die Methoden,<br />
die Normung (beispielsweise [4,5]) oder Wissenschaft<br />
(beispielsweise [11,12]) zur Begriffsbildung und<br />
-verwendung vorsehen, nicht aus, sondern müssen durch<br />
zusätzliche Beschreibungskonzepte ergänzt werden. Die<br />
richtige Positionierung <strong>von</strong> Kernmodellen wäre innerhalb<br />
einer Querschnittsnorm wie der IEC 60050, dem<br />
internationalen elektrotechnischen Wörterbuch. Grundsätzlich<br />
verbergen sich hinter den dort normierten<br />
Grundbegriffen bereits Konzepte, die jedoch weniger<br />
umfangreich und als erkennbare Modelle beschrieben<br />
sind, als es bei Kernmodellen der Fall ist. Die Definition<br />
<strong>von</strong> Kernmodellen an dieser Stelle wäre daher eine sinnvolle<br />
Erweiterung, die dort genutzt werden kann, wo die<br />
Referenz einer Begriffsdefinition keine ausreichende<br />
Semantik liefert.<br />
2. Nutzen <strong>von</strong> Kernmodellen<br />
Ein wesentliches Ziel der Kernmodelle ist die Vereinfachung<br />
der Beschreibung <strong>von</strong> komplexen Systemzusammenhängen,<br />
insbesondere in Standards und Normen. Ein<br />
erster Schritt dazu ist die einfache Verständlichkeit der<br />
Kernmodelle selbst. Kernmodelle werden prinzipiell einfach<br />
und in sich verständlich gehalten. Zur einheitlichen<br />
Beschreibung <strong>von</strong> Kernmodellen hat der AK 931.0.4 ein<br />
Beschreibungsmuster entworfen. Das Muster ist maximal<br />
vier Seiten lang und enthält sowohl informelle als auch<br />
formale Beschreibungsteile. Auch wenn sich einige Kernmodelle<br />
gegenseitig referenzieren und aufeinander aufbauen,<br />
ist doch jedes Modell für sich verständlich. Bei<br />
der Modellierung ist es Ziel, Kernmodelle so festzulegen,<br />
dass ihre Begriffe und Strukturen ein in sich geschlossenes<br />
wiederverwendbares Modell ergeben, das im Anwendungsfall<br />
ohne Veränderung seiner Struktur um spezifische<br />
Ausprägungen ergänzt werden kann. Es ist nicht die<br />
Absicht, dadurch eine Vereinheitlichung zu erzwingen,<br />
die allgemein auch gar nicht realisierbar wäre, sondern<br />
die Möglichkeit zur Referenzierung einer Grundidee zu<br />
geben. Kernmodelle sind deshalb so formuliert, dass sie<br />
in den Punkten, in denen ein Konsens verschiedener Anwendungsbereiche<br />
gegeben ist, diese genau beschreiben.<br />
Andere Aspekte bleiben dagegen bewusst offen, um die<br />
Anwendbarkeit nicht einzuschränken.<br />
42<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
In einem zweiten Schritt können Kernmodelle helfen,<br />
die Spezifikation <strong>von</strong> technischen Systemkonzepten zu<br />
vereinfachen. Aufgrund der allgemeinen Gültigkeit kann<br />
bei der Beschreibung bestimmter Systemaspekte direkt<br />
auf das entsprechende Kernmodell verwiesen werden,<br />
anstatt dieses neu zu spezifizieren (in den zuvor genannten<br />
Normen beispielsweise auf das Merkmalmodell oder<br />
das Anlagenhierarchiemodell). Durch diese Verweismöglichkeit<br />
auf bekannte Kernmodelle wird der Umfang<br />
<strong>von</strong> Normen reduziert. Darüber hinaus wird die Kommunikation<br />
durch vereinheitlichte Grundbegriffe und<br />
wiederkehrende Konzepte vereinfacht.<br />
Nutzung als semisemantische Plattform<br />
Die Semantik der Kernmodelle ist sehr einfach und wenig<br />
ausgeprägt. Es handelt sich jedoch um grundsätzliche<br />
Konzepte und dies führt dazu, dass sich eine Vielzahl <strong>von</strong><br />
grundsätzlichen technischen Aufgabenstellungen schon<br />
allein auf dieser Ebene, ohne Kenntnis weiterer Spezifika<br />
der Anwendungssemantik, lösen lässt. Ein Problem ist<br />
das Erkennen eines Kernmodells innerhalb einer speziellen<br />
Implementierung. Kernmodelle sind in den Systemen<br />
typischerweise als implizite Strukturen in den Anwendungen<br />
hinterlegt. Um auf sie zugreifen zu können, müssen<br />
explizit gewisse Schnittstellen angelegt werden, die<br />
nach außen die Funktionalität des Kernmodells repräsentieren<br />
und die konkrete Realisierung verbergen. Die Definition<br />
der Schnittstelle eines Kernmodells folgt direkt aus<br />
der Definition des Modells und wird als nachfolgender<br />
Schritt vorgenommen. Durch die Gesamtheit der realisierten<br />
Schnittstellen eines Systems wird die Gesamtfunktionalität<br />
der implementierten Kernmodelle repräsentiert<br />
und kann als eine semisemantische Plattform<br />
angesehen werden. Eine solche Architektur eröffnet eine<br />
mächtige Möglichkeit zum Einsatz <strong>von</strong> allgemeinen Funktionen<br />
zur Automatisierung und Verifikation.<br />
3. Beispiele für Kernmodelle<br />
Als Beispiele werden im Folgenden drei Kernmodelle vorgestellt:<br />
das Entitätenmodell, das Prozessmodell und das<br />
Lebenszyklusmodell. Die Beschreibung lehnt sich an die<br />
Struktur des vom AK 931.0.4 vorgegebenen Musters an.<br />
3.1 Entitätenmodell<br />
Der Begriff Entität steht für eine gedankliche oder physische<br />
Einheit. Diese wird in ihrem Organisationsumfeld<br />
nicht nur als Stück einer Menge gesehen, sondern als<br />
Individuum verwaltet und in ihrem Lebenszyklus verfolgt.<br />
Entitäten bilden das gedankliche und physische<br />
Inventar einer Organisationseinheit.<br />
Einordnung/Anwendungsbereich<br />
In der Philosophie versteht man unter einer Entität allgemein<br />
einen Gegenstand in seinem individuellen Dasein.<br />
Dabei kann es sich um einen physischen oder einen<br />
gedanklichen Gegenstand handeln. Gegenstände besitzen<br />
eine Existenzphase, in der sie ununterbrochen vorhanden<br />
(da) sind, sie existieren an sich und unabhängig<br />
<strong>von</strong> einem Betrachter. Gegenstände können entweder<br />
eine bestimmte endliche Zeit oder unendlich lange existieren.<br />
In Anlehnung an den Lebenslauf <strong>von</strong> Lebewesen<br />
haben auch Gegenstände einen Lebenszyklus, dem sie<br />
unterworfen sind.<br />
In dem hier verfolgten Konzept sind Entitäten Gegenstände,<br />
die als Individuen in der Informationswelt explizit<br />
verwaltet und in ihrem Lebenszyklus verfolgt werden.<br />
Es ist also nicht eine Eigenschaft des Gegenstands<br />
an sich, ob er als Entität angesehen wird, sondern eine<br />
bewusste Designentscheidung, ob man einem Gegenstand<br />
den Status einer Entität zumisst (siehe Bild 1). So<br />
werden zum Beispiel typischerweise Schrauben, einfache<br />
Ersatzgeräte, Kabelstücke, Dichtungen und so weiter<br />
nur als anonyme Stücke in einem Vorratsspeicher verwaltet<br />
und nicht individuell als Entitäten. Selbstverständlich<br />
haben diese namenlosen Gegenstände auch<br />
einen Lebenszyklus, dieser wird jedoch nicht erfasst und<br />
ist in der Informationswelt prinzipiell unbekannt.<br />
Allgemeine Beschreibung<br />
Eine Entität besteht aus dem tatsächlichen Gegenstand<br />
und einer Verwaltungseinheit. Die Verwaltungseinheit<br />
ist Teil der Informationswelt und unabhängig <strong>von</strong> der<br />
Art ihrer physikalischen Repräsentanz. Gegenstand und<br />
Verwaltungseinheit sind getrennt <strong>von</strong>einander zu betrachten.<br />
Wie dargestellt, ist es eine Designentscheidung,<br />
ob die Verwaltungseinheit überhaupt angelegt wird. Umgekehrt<br />
bleibt eine einmal angelegte Verwaltungseinheit<br />
im Prinzip ewig bestehen und bewahrt sämtliche Informationen<br />
zum Lebensweg ihres Gegenstands auch über<br />
deren Ende hinaus auf. Diese Informationen können<br />
allerdings durch Vernichtung der physikalischen Repräsentanz<br />
der Verwaltungseinheit (Löschen, Vergessen,<br />
Tod) verloren gehen.<br />
Wie in Bild 1 dargestellt, können auch Gegenstände<br />
der Informationswelt als Entitäten klassifiziert werden.<br />
So lässt sich zum Beispiel ein P&I-Diagramm als Entität<br />
klassifizieren und in seiner Entwicklung und Versionierung<br />
verfolgen. In der Informationswelt gibt es<br />
nun nicht nur das P&I-Diagramm, sondern auch dessen<br />
Verwaltungseinheit. Die Verwaltungsinformationen<br />
sind unabhängig vom eigentlichen P&I-Diagramm. Im<br />
Extremfall könnte das P&I-Diagramm selbst gelöscht<br />
werden, seine Lebenszyklusdokumentation jedoch erhalten<br />
bleiben. Die Welt der Entitäten ist nicht disjunkt.<br />
Häufig tritt der Fall auf, dass eine Entität in ihrem Lebenslauf<br />
zeitweise Teil einer anderen Entität ist. Wird<br />
eine I/O-Karte als Entität betrachtet, dann wird diese<br />
irgendwann in eine Remote I/O eingesteckt. Wird die<br />
Remote I/O ebenfalls als Entität modelliert, dann ist für<br />
die Einsteckzeit die I/O-Karte Teil der Entität Remote<br />
I/O. Beide bleiben jedoch selbstständige, getrennt verwaltete<br />
Einheiten. Die Einbauphase ist Teil des Lebenszyklus<br />
<strong>von</strong> beiden Einheiten.<br />
Formale Spezifikation<br />
Bild 2 zeigt den Aufbau einer Entität. Jede Entität hat als<br />
Individualbegriff einen eindeutigen, sie identifizierenden<br />
Namen (ID). Jede Entität besteht aus einem Gegen-<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
43
Hauptbeitrag | Automation 2012<br />
stand – ihrem Sein – und einer Verwaltungseinheit, die<br />
die Informationen zu ihrem Sein in der Informationswelt<br />
explizit verwaltet.<br />
Modellelemente<br />
Gegenstand: Ding der physischen Welt oder der Informationswelt.<br />
Lebenszyklus: Ein Lebenszyklus beschreibt, wie sich<br />
ein Gegenstand im Laufe seiner Existenz verändert<br />
(siehe Abschnitt 3.3).<br />
Verwaltungseinheit: Einheit, die die Informationen<br />
zu einem Gegenstand und seinem Lebenszyklus in<br />
der Informationswelt repräsentiert.<br />
Name: Eindeutige Bezeichnung der individuellen<br />
Entität.<br />
Regeln<br />
R1: Eine Entität ist ein Gegenstand, der zusätzlich<br />
eine Verwaltungseinheit in der Informationswelt besitzt,<br />
die seinen Lebenszyklus erfasst und verwaltet.<br />
R2: Jede Entität ist einmalig und hat einen eindeutigen<br />
Namen.<br />
R3: Entitäten sind keine disjunkten <strong>Komponenten</strong>.<br />
Entitäten können zueinander in sich beliebig überlagernden<br />
Abhängigkeiten, Abstraktions- oder Aggregationsbeziehungen<br />
stehen.<br />
Beziehung zu anderen Modellen<br />
Das Entitätenmodell baut auf dem Zweiweltenmodell auf<br />
und ist Grundlage des Lebenszyklusmodells.<br />
Beispiel<br />
In der Dokumentation eines Produktionsprozesses kann<br />
festgelegt werden, ob einzelne Produkte oder produzierte<br />
Lose als Entitäten verwaltet werden. Diese Festlegung<br />
hat grundlegende Bedeutung, weil entweder dem einzelnen<br />
Produkt oder nur dem Produktionslos die Möglichkeit<br />
der Identifikation und Zuordnung <strong>von</strong> Information<br />
gegeben wird. Die Konsequenzen betreffen nicht nur die<br />
Dokumentation selbst, sondern auch andere Bereiche,<br />
wie die Produktionsplanung, Qualitätsüberwachung,<br />
Logistik oder Kostenrechnung.<br />
3.2 Prozessmodell<br />
Unter einem Prozess wird eine Gesamtheit <strong>von</strong> aufeinander<br />
einwirkenden Vorgängen in einem System verstanden,<br />
durch die Materie, Energie oder Information umgeformt,<br />
transportiert oder gespeichert wird (Definition<br />
nach IEV 351 [9]). Der Prozess-Begriff ist grundlegend,<br />
er dient dazu, alle Vorgänge in beliebigen Systemen (natürlichen,<br />
technischen oder gedanklichen) zu erfassen.<br />
Einordnung/Anwendungsbereich<br />
Der Prozess ist ein grundlegendes begriffliches Konzept<br />
zur Erfassung und Strukturierung <strong>von</strong> Vorgängen in<br />
Systemen. Er wird in praktisch allen Anwendungsdomänen<br />
benutzt und hat immer die gleiche semantische<br />
Bedeutung. Prozesse sind reale Vorgänge, in denen der<br />
Zeitverlauf eine Rolle spielt. Die semantische Bindung<br />
an den Zeitverlauf ist ein typisches Merkmal eines Prozesses.<br />
Dies gilt grundsätzlich für alle Arten <strong>von</strong> Prozessen,<br />
für natürliche Prozesse, für technische Prozesse,<br />
für physische Prozesse und auch für Prozesse in der<br />
Informationswelt. Die Multiplikation zweier Zahlen ist<br />
aus informationstechnischer Sicht kein Prozess, sondern<br />
eine Aktion. Die Ausführungszeit spielt hier keine<br />
semantische Rolle. Werden jedoch die Multiplikation<br />
als eine Aufgabe für einen Mikrocontroller beschrieben<br />
und Taktzyklus für Taktzyklus die Folge der Bearbeitungsschritte<br />
betrachtet, dann handelt es sich um einen<br />
Rechenprozess. Hier spielt der Zeitverlauf eine wesentliche<br />
Rolle zum Verständnis. Mit dem Begriff Prozess<br />
wird der eigentliche Vorgang beschrieben. Diese Beschreibung<br />
kann verschiedene Abstraktionsgrade haben<br />
(Prozesstyp oder konkreter Prozess) und aus unterschiedlichen<br />
zeitlichen Perspektiven erfolgen (zum<br />
Beispiel retrospektiv, prädiktiv oder planerisch). Der<br />
Prozess ergibt sich aus dem dynamischen Eigenverhalten<br />
des Systems unter dem Einfluss der äußeren Einwirkungen.<br />
In technischen Systemen werden bestimmte<br />
äußere Einwirkungen gezielt aufgebracht, um einen<br />
gewünschten Prozessverlauf zu erzwingen. Die dazu<br />
erforderliche Abfolge <strong>von</strong> Einwirkungen wird als Prozedur<br />
bezeichnet.<br />
Allgemeine Beschreibung<br />
Prozesse beziehen sich auf ein abgegrenztes System, eine<br />
abgegrenzte Zeit und einen abgegrenzten Aspekt. Durch<br />
Änderung der Abgrenzungen können Prozesse in Teilprozesse<br />
zerlegt oder zu umfassenderen Prozessen aggregiert<br />
werden. Prozesse sind grundsätzlich reale Vorgänge<br />
in der Zeit. Jeder Prozess ist einmalig. Ein einmal<br />
stattgefundener Prozess lässt sich nicht mehr rückgängig<br />
machen. Anders ist dies bei den Veränderungen, die ein<br />
Prozess in einem System bewirkt. Diese können unter<br />
Umständen durch einen „Undo-Prozess“ rückgängig gemacht<br />
werden.<br />
Ein Prozess kann die Zustände eines betrachteten Systems<br />
und dessen gesamte Struktur verändern. Die Veränderungen<br />
können kontinuierlich und auch diskret<br />
sein. Prozesse können nach folgenden Kriterien klassifiziert<br />
werden:<br />
Klassifikation nach der Art des Flusses <strong>von</strong> Material<br />
und Energie über die Systemgrenzen. Für den Materialtransport<br />
wird zum Beispiel zwischen folgende Prozessarten<br />
unterschieden:<br />
1 | Während des Prozesses erfolgt keinerlei Materialaustausch<br />
mit der Umgebung.<br />
2 | Während des Prozesses wird kontinuierlich<br />
Material zu- und abgeführt (Kontiprozess).<br />
3 | Während des Prozesses werden zu diskreten<br />
Zeitpunkten diskrete Mengen an Material zu- oder<br />
abgeführt.<br />
Klassifikation nach Wirkung auf die Systemstruktur:<br />
1 | Während des Prozesses ändert sich die Systemstruktur<br />
nicht, es ändern sich nur die Zustände.<br />
2 | Während des Prozesses ändert sich die Struktur:<br />
44<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
Bild 1: Klassifikation <strong>von</strong> Gegenständen zu Entitäten<br />
Bild 2: Aufbau einer Entität<br />
Bild 3: Wesensart eines Prozesses<br />
Bild 4: Elemente eines Prozesses<br />
Bild 5: Dichte Folge <strong>von</strong> Lebenszyklusprozessen und<br />
Übergängen<br />
Bild 6: Beziehungsstruktur des Lebenszyklusmodells.<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
45
Hauptbeitrag | Automation 2012<br />
Objekte, Beziehungen, Merkmale und Zustände<br />
kommen als neue semantische Elemente hinzu,<br />
ändern sich oder fallen weg. Dies ist typisch zum<br />
Beispiel bei Erzeugungs- oder Löschprozessen.<br />
Klassifikation nach Art der Änderung:<br />
1 | Nur Veränderung der räumlichen oder logischen<br />
Position (Transportprozess),<br />
2 | Festhalten und Konservieren des Zustands über<br />
die Zeit (Speicherprozess),<br />
3 | Verändern des Zustands (Transformationsprozess).<br />
In den Anwendungsbereichen gibt es eine Vielzahl weiterer<br />
Kriterien, nach denen Prozesse klassifiziert und<br />
geordnet werden. Im Umfeld der industriellen Produktion<br />
wird beispielsweise zwischen fertigungstechnischen<br />
Prozessen und verfahrenstechnischen Prozessen<br />
unterschieden.<br />
Formale Spezifikation<br />
In Bild 4 werden die wesentlichen Eigenschaften eines<br />
Prozesses verdeutlicht. Im Zentrum stehen der Prozessraum<br />
und das Prozessfenster, durch die der Prozess<br />
zeitlich und inhaltlich abgegrenzt wird. Das Prozessfenster<br />
begrenzt den Prozess zeitlich. Der Prozess<br />
startet mit dem Prozessstart und endet mit dem Prozessende.<br />
Alle Vorgänge außerhalb dieses zeitlichen<br />
Fensters sind nicht Teil des Prozesses. Der Prozessraum<br />
wird bei der Modellierung festgelegt. Die Festlegung<br />
ist eine Designentscheidung. So kann in der industriellen<br />
Produktion der Prozessraum zum Beispiel<br />
die Anlage mit enthalten oder nicht. Der Prozessraum<br />
grenzt eindeutig ab, welche physischen Elemente (Anlagenteile,<br />
Materialien, Produkte), welche Energien<br />
und welche Modelle beziehungsweise Elemente der<br />
Informationswelt zu einem Prozess gehören und welche<br />
nicht. Die Grenze ist scharf. Alle zum Prozessraum<br />
im Prozessfenster gehörenden Vorgänge sind Teil des<br />
Prozesses, alle anderen nicht. Bild 4 zeigt, wie der Austausch<br />
über die Prozessraum- und Prozessfenstergrenzen<br />
hinweg stattfindet.<br />
Bei Prozessstart wird der Prozessraum mit folgenden<br />
Inhalten initialisiert:<br />
Den als zugehörig zum Prozessraum vorgesehenen<br />
physischen Einheiten (Pe) mit ihren Anfangszuständen.<br />
Beispielsweise gehören dazu die mit zum Prozessraum<br />
zu zählenden Anlagenteile, Apparate und<br />
Geräte (jeweils mit ihren Anfangszuständen).<br />
Den Produkten, die sich als Vorlage bei Prozessbeginn<br />
im Prozessraum befinden.<br />
Den vorgelegten Energien (En) mit ihren Anfangszuständen.<br />
Im Allgemeinen gibt es die Energien nicht<br />
explizit. Energien werden als Zustände der physischen<br />
Einheiten im Prozessraum (Temperatur, Ladezustand<br />
und so weiter) modelliert, nur im Sonderfall<br />
werden sie als eigene Entität beschrieben.<br />
Den vorgelegten Modellen (Mo) mit ihrem Anfangszustand,<br />
das heißt alle Modelle, Daten, Zustandsinformationen,<br />
die dem Prozess zu Beginn explizit zur<br />
Verfügung stehen.<br />
Während des Prozessablaufs kann der Prozess physische<br />
Einheiten, Information und Energie mit der Umgebung<br />
austauschen. Die Definition des Prozessraums ändert<br />
sich typischerweise während eines Prozesses nicht. Der<br />
Austausch kann in beliebigen Kombinationen kontinuierlich<br />
und oder zu diskreten Zeitpunkten erfolgen. Eintretende<br />
Elemente gehören erst ab dem Zeitpunkt des<br />
Eintritts zum Prozess, das heißt: Auch während der Prozess<br />
schon läuft, sind die Vorgänge, die diese Elemente<br />
betreffen, zunächst außerhalb des Prozessraums und<br />
nicht Teil des Prozesses. Erst am Eintrittszeitpunkt wird<br />
ein Element mit seinen dann aktuellen Zuständen in den<br />
Prozessraum übernommen. Alle Vorgänge, die sich im<br />
Prozessraum innerhalb des Prozessfensters zutragen,<br />
sind Teil des Prozesses. Ein Prozess ist zeitlich und inhaltlich<br />
kompakt.<br />
Bei Prozessende treten alle physischen Einheiten, Produkte<br />
und Modelle mit ihren Zuständen aus dem Prozessraum<br />
aus. Der Prozessraum verschwindet.<br />
Modellelemente<br />
Physische Einheiten: Geräte, Apparate, Anlagenteile,<br />
Produkte, Hilfsstoffe und so fort mit ihren Zuständen.<br />
Energien: Energien werden im Allgemeinen nicht<br />
als eigene Einheiten modelliert, sondern ergeben<br />
sich aus den Zuständen der physikalischen Einheiten.<br />
Energien sind im Allgemeinen stoffgebunden.<br />
Energieströme sind dies jedoch nicht immer. So können<br />
etwa Wärmeströme und elektrische Ströme über<br />
die Prozessraumgrenzen hinweg separat als Energieströme<br />
modelliert werden.<br />
Modelle: Die Informationswelt wird hier in Form<br />
<strong>von</strong> Modellen als Struktur- und Zustandsinformation<br />
hinterlegt. Diese Modelle können durch die Prozesse<br />
genutzt oder selbst umgeformt werden.<br />
Prozessraum: Beschreibt ein System mit allen physischen,<br />
energetischen und modellmäßigen Elementen,<br />
die im Prozess explizit genutzt oder durch den<br />
Prozess in ihrer Struktur und ihrem Zustand verändert<br />
werden.<br />
Prozessfenster: Definiert die ununterbrochene Zeitspanne<br />
<strong>von</strong> Prozessbeginn bis Prozessende.<br />
Regeln<br />
R1: Ein Prozess beschreibt einen Vorgang, bei dem<br />
der zeitliche Ablauf eine semantische Bedeutung<br />
besitzt.<br />
R2: Ein Prozess beginnt an einem Startzeitpunkt und<br />
endet an einem Endzeitpunkt. Startzeitpunkt und<br />
Endzeitpunkt markieren das zeitliche Prozessfenster<br />
und grenzen zum Prozess gehörende Vorgänge <strong>von</strong><br />
anderen Vorgängen ab.<br />
R3: Der Prozessraum ist eine definierte Systemumgebung,<br />
die alle zum Prozess gehörenden Elemente<br />
der physischen Welt und der Informationswelt <strong>von</strong><br />
nicht zum Prozess gehörenden Elementen scharf<br />
abgrenzt.<br />
R4: Alle (im Rahmen der Betrachtung relevanten)<br />
Vorgänge im Prozessraum werden durch den Prozess<br />
beschrieben.<br />
R5: Während des Prozessverlaufs können diskrete Systeme<br />
und Elemente der physischen Welt und der Infor-<br />
46<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
mationswelt oder auch kontinuierliche Material-Energie-<br />
und Informationsströme über die Ränder des Prozessraums<br />
mit der Umgebung ausgetauscht werden.<br />
Diese werden im Moment des Eintritts in den Prozessraum<br />
mit allen ihren Zuständen Teil des Prozesses<br />
beziehungsweise verlieren ihre Bindung an den Prozess<br />
im Augenblick des Austritts aus dem Prozessraum.<br />
Beispiel<br />
Ein Arbeitsprozess wird auf Basis des Prozessmodells<br />
beschrieben. Durch diese Festlegung wird klar, dass zur<br />
Beschreibung des Prozesses die involvierten physischen<br />
Einheiten, Energien und Modelle genannt werden müssen<br />
und welche Bedeutung diese Begriffe für den Arbeitsprozess<br />
haben. Darüber hinaus lässt sich der Arbeitsprozess<br />
durch Prozessfenster und Prozessraum klar abgrenzen.<br />
Ein Außenstehender kann durch die Referenz auf das Prozessmodell<br />
die Beschreibung leichter verstehen, den Arbeitsprozess<br />
einordnen und <strong>von</strong> ihm abstrahieren.<br />
3.3 Lebenszyklusmodell<br />
Unter einem Lebenszyklus wird die Folge <strong>von</strong> Prozessen<br />
verstanden, die eine Entität während ihrer Existenz<br />
durchläuft. Der Lebenszyklus beginnt mit dem Entstehen<br />
der Entität und endet mit dem Vergehen der Entität. Der<br />
Begriff Zyklus ist irreführend, es handelt sich um eine<br />
gerichtete und strikt azyklische Folge. Das Lebenszyklusmodell<br />
ist ein Konzept zur einheitlichen Modellierung<br />
und Beschreibung <strong>von</strong> Lebenszyklusabläufen.<br />
Einordnung/Anwendungsbereich<br />
Der Lebenszyklus ist ein aus dem Bereich der Lebewesen<br />
übernommener Begriff. Bei einem Lebewesen beginnt die<br />
Existenz mit der Geburt und endet mit dem Tod. Mit dem<br />
Ausdruck Zyklus soll veranschaulicht werden, dass diese<br />
Abfolge Geburt-Leben-Tod für das Leben als solches<br />
über die Generationen hinweg immer wieder geschieht.<br />
Es soll jedoch nicht ausdrücken, dass der Lebensweg eines<br />
einzelnen Lebewesens zyklisch verläuft. Technische<br />
Entitäten sind künstlich zu einer Einheit zusammengefasste<br />
Gebilde. Sie sind nicht lebendig. Der Beginn und<br />
das Ende ihrer Existenz ist entsprechend nicht durch<br />
Geburt und Tod abgegrenzt sondern kann und muss, wie<br />
die Entität selbst, geeignet definiert werden.<br />
Das Lebenszyklusmodell ist allgemein und auf alle<br />
Arten <strong>von</strong> Entitäten anwendbar:<br />
auf Entitäten der physischen Welt (Produkte,<br />
Geräte, Anlagenteile, ...),<br />
auf Produkt und Produktlinienbeschreibungen,<br />
auf Systemmodelle (P&I-Diagramme, Funktionspläne,<br />
Baupläne, ...),<br />
auf Metamodelle (Normen, Richtlinien, Gesetze, ...).<br />
Jede Entität hat einen Lebenszyklus. Dieser muss jedoch<br />
nicht bekannt sein. Das Lebenszyklusmodell ist ein Konzept<br />
zur einheitlichen Beschreibung <strong>von</strong> Lebenszyklusprozessen.<br />
Es ist auf der Metamodellebene, der Klassenebene<br />
und der Instanzebene (Systemmodellebene) gleichermaßen<br />
anwendbar.<br />
Allgemeine Beschreibung<br />
Ein Lebenszyklus besteht aus einer Folge <strong>von</strong> einzelnen<br />
Lebenszyklusprozessen (siehe Bild 5). Die Reihenfolge ist<br />
strikt sequenziell und dicht. Jede Entität befindet sich zu<br />
jedem Zeitpunkt in genau einem Lebenszyklusprozess.<br />
Lebenszyklusprozesse finden immer in absoluter Zeit<br />
statt. Lebenszyklen selbst sind immer retrospektiv, das<br />
heißt, ein Lebenszyklus beschreibt immer was war und<br />
nicht was in Zukunft sein könnte. Im Lebenszyklus gibt<br />
es daher auch keine Verzweigungen oder offene Alternativen.<br />
Die Entität selbst befindet sich zu jedem Zeitpunkt<br />
in einem definierten Zustand. Von besonderer Bedeutung<br />
sind die Zustände an den Übergängen zwischen den Prozessabschnitten.<br />
Das Modell gibt eine Gliederung vor, in<br />
der für jeden Prozessabschnitt und für jeden Übergang<br />
ein eigenes Beschreibungsobjekt vorgesehen wird. Sind<br />
keine Informationen über einen Zeitabschnitt verfügbar,<br />
dann muss ein Leerprozess eingefügt werden.<br />
Formale Spezifikation<br />
In Bild 6 ist die Beziehungsstruktur des Lebenszyklusmodells<br />
für einen abgeschlossenen Lebenszyklus dargestellt.<br />
Für aktuell existierende Entitäten ist der Lebenszyklus<br />
nicht abgeschlossen. Ein abgeschlossener Lebenszyklus<br />
besteht aus einem Entstehungsprozess, beliebig<br />
vielen Lebenszyklusprozessen und einem Vergehensprozess.<br />
Die Pfeile markieren die Übergänge zwischen den<br />
Teilprozessen. Ein Übergang erfolgt immer über einen<br />
zeitlosen Übergangszustand.<br />
Modellelemente<br />
Entstehungsprozess: Der Entstehungsprozess beschreibt<br />
den Vorgang, in dem die Existenz der Entität<br />
begründet wird. Er verbindet die Entität mit ihren<br />
Vorgängern.<br />
Lebenszyklusprozess: Ein Lebenszyklusprozess beschreibt,<br />
wie eine existierende Entität in einem zeitlichen<br />
Abschnitt ihren Zustand ändert.<br />
Vergehensprozess: Der Vergehensprozess beschreibt<br />
den Vorgang, der die Existenz der Entität beendet.<br />
Danach ist die Entität nicht mehr existent.<br />
Übergangszustand: Der Übergangszustand beschreibt<br />
den Zustand, den eine Entität beim Übergang <strong>von</strong> einem<br />
abgegrenzten Teilprozess zum nächsten besitzt.<br />
Die Zeitdauer des Übergangszustands ist Null. Ein<br />
Übergangszustand ist zu unterscheiden <strong>von</strong> einem<br />
Leerprozess, in dem sich in einer Entität außer dem<br />
Alter kein Zustand ändert.<br />
Regeln<br />
R1: Lebenszyklusprozesse sind Prozesse im Sinne<br />
des Prozessmodells.<br />
R2: Jede Entität hat ein definiertes Alter.<br />
R3: Jeder Zustand im Lebenszyklus ist einmalig und<br />
unterscheidet sich zumindest durch das Alter <strong>von</strong><br />
allen anderen Zuständen.<br />
R4: Ein zurückgelegter Lebensweg ist irreversibel.<br />
Beispiel<br />
Der Inhalt der Lebenszyklusdokumentation eines Geräts<br />
wird mit Referenz auf das Lebenszyklusmodell spezifiziert.<br />
Die grundlegenden Begriffe (Enstehungsprozess,<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
47
Hauptbeitrag | Automation 2012<br />
Lebenszyklusprozess, Vergehensprozess, Übergangzustand)<br />
werden damit gültig und geben Rahmenbedingungen<br />
für den Inhalt vor. Diese Rahmenbedingungen<br />
gelten für die Beschreibung geplanter und vorhergesagter<br />
und zurückgelegter Lebenszyklusprozesse.<br />
Zusammenfassung und Ausblick<br />
In vielen technischen Spezifikationen treten ähnliche<br />
logische Strukturen wiederholt auf und werden gemeinhin<br />
als bekannte Konzepte angesehen. Solange es jedoch<br />
keine unabhängige Spezifikation dieser Konzepte gibt,<br />
wird es notwendig sein, sie in jedem Anwendungskontext<br />
vollständig zu beschreiben. Die vom DKE-Arbeitskreis<br />
931.0.4 identifizierten und als Kernmodelle beschriebenen<br />
Konzepte sind ein erster Schritt dazu, implizit bekannte<br />
Strukturen einmalig referenzierbar festzulegen.<br />
Wenn es in Zukunft gelingt, diese Kernmodelle konsequent<br />
zu verwenden, ist ein großer Fortschritt für die Vereinfachung<br />
<strong>von</strong> Normen und anderen Spezifikationen<br />
erreicht. Viele ermüdende Diskussionen um grundlegende<br />
Begriffe erübrigen sich, und es wird möglich, sich auf<br />
die im jeweiligen Fokus stehenden Themen zu konzentrieren.<br />
Kernmodelle bieten das Potenzial, in technischer<br />
und struktureller Hinsicht die Entwicklung <strong>von</strong> Systemen<br />
neu zu gestalten. Diese Aufgabe hat ohne Zweifel andere<br />
Ansprüche als das modulare Zusammenfügen <strong>von</strong> technischen<br />
Systemen, denn Kernmodelle können nicht als<br />
fertige Lösung in eine Spezifikation eingefügt werden – sie<br />
sind in den speziellen Anwendungslösungen verwoben.<br />
Sie eröffnen daher die Möglichkeit, logische Systemaspekte<br />
auf einfache Art zu beschreiben und damit Spezifikationen<br />
leichter und schneller erfassbar zu machen. Die<br />
Beschreibung <strong>von</strong> Schnittstellen, um Kernmodelle explizit<br />
sichtbar und interaktionsfähig zu machen, eröffnet<br />
eine interessante Perspektive für einen einheitlichen und<br />
automatisierten Umgang mit ihrer Funktionalität.<br />
Manuskripteingang<br />
19.03.2012<br />
Im Peer-Review-Verfahren begutachtet<br />
Referenzen<br />
Autoren<br />
[1] alexander, C., Ishikawa, S. und Silverstein, M.:A Pattern<br />
Language. Oxford University Press, New York 1977<br />
[2] bieger, T., zu Knyphausen-Aufseß, D. und Krys, C.<br />
(Hrsg.): Innovative Geschäftsmodelle. Springer, Berlin<br />
2011<br />
[3] DIN 820-1: Normungsarbeit – teil 1: Grundsätze. Mai 2009<br />
[4] DIN 2330: Begriffe und Benennungen. Dezember 1993<br />
[5] DIN 2342: Begriffe der Terminologielehre. August 2011<br />
[6] DIN en 61360-1: Genormte Datenelementtypen mit<br />
Klassifikationsschema für elektrische Bauteile – Teil 1:<br />
Definitionen – Regeln und Methoden. März 2008<br />
[7] DIN en 61512-1: Chargenorientierte Fahrweise – Teil 1:<br />
Modelle und Terminologie. Januar 2000<br />
[8] gamma, E.,Helm, R., Johnson, R. und Vlissides, J.:<br />
Entwurfsmuster: Elemente wiederverwendbarer objektorientierter<br />
Software. Addison-Wesley, München 2010<br />
[9] ieC 60050-351: International Electrotechnical Vocabulary<br />
– Part 351: Control technology. Oktober 2006<br />
[10] iSO 13584-42: Industrial automation systems and<br />
integration - Parts library - Part 42: Description<br />
methodology: Methodology for structuring parts<br />
families. Dezember 2010<br />
[11] Morbach, J.: A Reusable Ontology for Computer-Aided<br />
Process Engineering. Verlag Dr. Hut, München 2009<br />
[12] Schnieder, E., Schnieder, L.: Axiomatik der Begriffe für<br />
die Automatisierungstechnik. <strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische<br />
Praxis 50 (10), S. 62–73, 2008<br />
An der Ausarbeitung der dargestellten Kernmodelle haben<br />
im AK 931.0.4 aktiv mitwirkt: Prof. Dr.-Ing. C. Diedrich<br />
(Universität Magdeburg), U. Döbrich (Siemens ag), Prof.<br />
Dr.-Ing. U. Epple (RWTH Aachen), H. Fittler (Honeywell), D.<br />
Kampert (RWTH Aachen), A. Kießling (MVV Energie), E. Klemm<br />
(Phoenix Contact), Dr. U. Löwen (Siemens ag), I. Rolle (DKE).<br />
Dipl.-Inf. David KampERT (geb.1981),<br />
2008-2010 Softwareent wickler bei der<br />
dSPACE GmbH, seit 2010 wissenschaftlicher<br />
Mitarbeiter am Lehrstuhl<br />
für Prozessleittechnik/RTWH Aachen.<br />
Hauptarbeitsgebiete: Modellentwicklung<br />
für merkmalbezogene Datenverwaltung,<br />
Asset Management.<br />
RWTH Aachen, Lehrstuhl für Prozessleittechnik,<br />
Turmstraße 46, D-52064 Aachen,<br />
Tel. +49 (0) 241 809 76 18,<br />
E-Mail: d.kampert@plt.rwth-aachen.de<br />
Prof. Dr.-Ing. Ulrich Epple (geb. 1953),<br />
1979-1985 Wissenschaftlicher Mitarbeiter<br />
am Institut für Systemdynamik<br />
und Regelungstechnik Universität<br />
Stuttgart, 1985-1990 Mitarbeiter im<br />
Ressort Prozessleittechnik in der<br />
Bayer AG, 1991-1995 Geschäftsführer<br />
der Gesellschaft für Prozesstechnik<br />
GmbH, seit 1995 Leiter des Lehrstuhls<br />
für Prozessleittechnik, RWTH Aachen. Hauptarbeitsgebiete:<br />
Modellbildung in der Leittechnik, formale<br />
Beschreibungsmethoden, Anwendung modellgetriebener<br />
Verfahren in der Prozess automatisierung. Assistenzsysteme<br />
zur Unterstützung <strong>von</strong> Ingenieurprozessen.<br />
RWTH Aachen, Lehrstuhl für Prozessleittechnik,<br />
Turmstraße 46, D-52064 Aachen,<br />
Tel. +49 (0) 241 809 43 39,<br />
E-Mail: u.epple@plt.rwth-aachen.de<br />
48<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
Hauptbeitrag | Automation 2012<br />
Vorgehensmodellierung im<br />
Anlagen-Engineering<br />
Planungstätigkeiten identifizieren und kennzeichnen<br />
Bei der Anlagenplanung gewinnt das Wissen um die Abläufe neben dem Faktenwissen<br />
zu den Betriebsmitteln an Bedeutung. Es ist Stand der Technik, Best-practice-Lösungen<br />
als Arbeitsflussdiagramme abzuspeichern, um ihre Wiederverwendung zu ermöglichen.<br />
Das Fehlen eines etablierten Kennzeichnungssystems für Engineering-Vorgänge schränkt<br />
allerdings den Wissensaustausch über die Gewerkegrenzen hinaus erheblich ein. Dieser<br />
Beitrag beschreibt ein neuartiges Engineering-Aufgaben-Kennzeichnung-System für die<br />
Anlagenplanung und wie es sich für die Vorgangsmodellierung verwenden lässt.<br />
SCHLAGWÖRTER Vorgehensmodellierung / Vorgangskennzeichnung / Planungsassistenz<br />
Process modelling in plant engineering –<br />
Identification and designation of planning activities<br />
In many areas of plant engineering, knowledge about engineering processes has become<br />
increasingly important along with knowledge about technical resources. It is state of the<br />
art to save "best practices" as work flow diagrams to allow their reuse. However the lack<br />
of an established designation system for engineering activities considerably limits the<br />
knowledge exchange within and between technical disciplines. A new designation system<br />
for engineering activities is described for use in plant engineering. Some applications for<br />
process modelling are also discussed.<br />
KEYWORDS process modelling / designation of planning activities / planning assistance<br />
50<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
Sergiy Sokolov, Otto-<strong>von</strong>-Guericke-Universität Magdeburg<br />
Hans-Peter FiCHTner, Koramis<br />
Zbynek CiHLAR, Senior Consultant<br />
Michael KaiSER, Ixit Engineering Technology<br />
Christian DiEDRiCH, Otto-<strong>von</strong>-Guericke-Universität Magdeburg<br />
Der effiziente Informationsfluss gewinnt in fast<br />
allen Bereichen der Automatisierungstechnik<br />
immer größere Bedeutung [1][2]. Hinter den<br />
stark arbeitsteiligen und iterativen Prozessschritten<br />
der einzelnen Gewerke verbirgt sich<br />
eine hohe Komplexität. Eine methodische und informationstechnische<br />
Unterstützung bei der Detektion, Analyse<br />
und Bewertung vorhandener Planungsinformationen<br />
für einen Arbeitsschritt ist ein wirksames Mittel<br />
zur Handhabung der Planungskomplexität [3].<br />
Durch die systematische Untersuchung der Engineering-Prozesse<br />
im Anlagenbau ist es möglich, ein fundiertes<br />
Prozessmodell zu entwickeln [4][5], das zum<br />
Aufbau eines Workflow-Management-Systems (WFMS)<br />
zur Steuerung der Engineering-Prozesse herangezogen<br />
werden kann [6].<br />
Im Beitrag wird ein Engineering-Aufgaben-Kennzeichnung-System<br />
(EAKS) zur Identifizierung der Vorgänge<br />
bei der Erfassung <strong>von</strong> Engineering-Aufgaben für die Vorgehensmodellierung<br />
beschrieben und zur Diskussion<br />
vorgestellt. EAKS unterstützt die systematische Strukturierung<br />
<strong>von</strong> Arbeitsabläufen und ermöglicht deren<br />
transparente Wiederverwendung.<br />
1. Vorgehensmodellierung<br />
Das Vorgehensmodell (auch Prozessmodell) stellt ein<br />
Abbild der logischen Abfolge <strong>von</strong> Aktivitäten dar, die für<br />
die Bearbeitung einer Aufgabe beziehungsweise eines<br />
Arbeitspakets erforderlich sind. Obwohl die Komplexität<br />
und eine hohe Individualität <strong>von</strong> Projekten im Anlagenbau<br />
das Aufstellen eines allgemein gültigen Vorgehensmodells<br />
erschweren, entstanden dennoch zwei standardisierungsrelevante<br />
Dokumente auf diesem Gebiet – PAS<br />
1059 [7] und NA 35 [8].<br />
PAS 1059 definiert die fünf Hauptaktivitäten: Machbarkeitsstudie<br />
durchführen, Grundlagen ermitteln, Vorplanung<br />
durchführen, Entwurfsplanung durchführen,<br />
Detailplanung durchführen. Jede der Hauptaktivitäten<br />
wird in – teilweise mehrstufigen – Detaillierungsstufen<br />
durch deren Teilaktivitäten sowie deren Ergebnisse<br />
beschrieben. Die ersten beiden Hauptaktivitäten Machbarkeitsstudie<br />
durchführen und Grundlagen ermitteln<br />
werden meistens <strong>von</strong> den Entwicklungsabteilungen im<br />
Unternehmen durchgeführt und bilden zunächst die<br />
wirtschaftlichen Rahmenvorgaben für die Ermittlung<br />
einer Grundlage zur Ausschreibung. Aus Sicht der Prozessplanung<br />
spielen diese eine untergeordnete Rolle<br />
(siehe Abschnitt 2). Während der Phasen Vorplanung<br />
durchführen und Entwurfsplanung durchführen werden<br />
die meisten anforderungsrelevanten Planungsinformationen<br />
spezifiziert. Diese Informationen werden im<br />
Rahmen der sich zeitlich anschließenden Planungsschritte<br />
weiter detailliert.<br />
Ein weiteres Vorgehensmodell mit dem Schwerpunkt<br />
in der Abwicklung <strong>von</strong> PLT-Projekten steht als Namur-<br />
Arbeitsblatt NA 35 zur Verfügung. In diesem sind die<br />
Projektphasen mit unterlagerten Planungsvorgängen und<br />
die Planungsaktivitäten sowie Eingangs- und Ausgangsinformationen,<br />
Rollen, Methoden und Werkzeuge angegeben<br />
(siehe Bild 1).<br />
2. Engineering-Aufgaben-Kennzeichnung-<br />
System<br />
2.1 Strukturierung der Aufgaben<br />
Beim Projekt PASS – Planungsassistenzsystem das diesem<br />
Beitrag zugrunde liegt (die Arbeit wurde vom Bundesministerium<br />
für Wirtschaft und Technologie im<br />
Rahmen des FuE-Kooperationsprojektes gefördert), wurde<br />
herausgearbeitet, dass eine Identifizierung der genauen<br />
Vorgänge bei der Erfassung <strong>von</strong> Engineering-Aufgaben<br />
mithilfe eines Kennzeichensystems (Bild 2) benötigt<br />
wird. Hauptgrund dafür ist, dass so eine direkte Zuordnung<br />
<strong>von</strong> Vorgangsergebnissen als Eingangsinformation<br />
<strong>von</strong> Folgevorgängen möglich wird. Die Überprüfung der<br />
Voraussetzung für einen Engineering-Vorgang hinsichtlich<br />
ausreichender und konsistenter Datenlage wird<br />
hiermit ermöglicht. Außerdem unterstützt dieses Kenn-<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
51
Hauptbeitrag | Automation 2012<br />
zeichensystem die logische Strukturierung der Vorgehensmodelle.<br />
Bei der Entwicklung des Kennzeichnungssystems<br />
wurden folgende Grundsätze aufgestellt:<br />
Verwendung eines hierarchisch aufgebauten<br />
alphanumerischen Systems<br />
Einheitliche Struktur für alle Disziplinen ist<br />
soweit wie möglich einzuhalten<br />
EAKS auf Tätigkeiten (sprich Vorgänge) zu fokussieren<br />
und zu beschränken<br />
Zur Unterstützung der Denkweise in Tätigkeiten<br />
sollen die Benennungen <strong>von</strong> Vorgängen in Form<br />
<strong>von</strong> Tätigkeiten erfolgen. Zum Beispiel Vorgang<br />
„RL Routing in 3D-Model“ soll „RL Routing in<br />
3D-Model ausführen“ heißen<br />
„So wenig wie möglich und nur so viel wie nötig“<br />
als Leitwort walten zu lassen<br />
Mnemotechnik bei der Wahl <strong>von</strong> Kennbuchstaben<br />
restriktiv anwenden<br />
2.2 Datenstellen und Zuordnung <strong>von</strong> Codes<br />
Engineering-Aufgaben definieren die Vorgehensweise,<br />
das heißt die Tätigkeiten, die zur Planung einer industriellen<br />
Anlage erforderlich sind. Hierbei wird <strong>von</strong> den<br />
einzelnen am Projekt beteiligten Engineering-Disziplinen<br />
ausgegangen (Datenstelle D1, Tabelle 1), die in kleinere<br />
Einheiten aufgeteilt werden (Datenstellen D2-DN,<br />
Tabelle 2, Tabelle 3, Tabelle 4), die überschaubarer und<br />
einfacher zu planen und zu bearbeiten sind. Mit dieser<br />
sukzessiven Unterteilung wird es möglich, bis zur<br />
kleinsten zu betrachtenden Einheit zu gelangen.<br />
So entsteht eine hierarchisch auf dem Bestandsbeziehungsprinzip<br />
aufgebaute Struktur: Eine Aufgabe kann<br />
aus mehreren Teilaufgaben bestehen, ist aber Bestandteil<br />
<strong>von</strong> nur einer höheren Aufgabe.<br />
Bis zur und mit der Datenstelle D3 können alle Engineering-Disziplinen<br />
ihre Aufgabengruppen und Aufgabenuntergruppen<br />
weitgehend einheitlich den Klassen<br />
D1 bis D3 zuordnen. Bei den Teilaufgaben einer<br />
Auf gabenuntergruppe ist diese Einheitlichkeit nicht<br />
mehr möglich, weil die Detailaufgaben bei jeder Disziplin<br />
spezifisch und damit unterschiedlich sind. Sie<br />
müs sen sich auch nach Klassen D1 bis D3 richten. Die<br />
zweistellige Zahl, die hier zur Identifikation der<br />
Teilauf gaben zur Verfügung steht, erlaubt eine Gruppierung<br />
der Teilaufgaben nach den disziplinspezifischen<br />
Bedürfnissen.<br />
Kennzeichnen der Vorgangsgruppe und der Vorgänge<br />
(Datenstellen V1-V2,) erfolgt gewerkeübergreifend entsprechend<br />
der in der Tabelle 5 und der Tabelle 6 aufgeführten<br />
Klassifikation. Anpassung an einzelne Engineering-Disziplinen<br />
geschieht durch Weglassen nicht relevanter<br />
Vorgänge.<br />
Mit der zweistelligen Nummer (Datenstelle VN, Tabelle<br />
7) werden Vorgänge mit der gleichen Identifizierung<br />
<strong>von</strong>einander unterschieden (und zwar nur, wenn alle<br />
vorausgehenden Datenstellen – <strong>von</strong> D1 bis V2 gleich<br />
sind). Ein EAKS-Anwendungsbeispiel für die Kennzeichnung<br />
der Engineering-Vorgänge für die Engineering-Disziplin<br />
Rohrleitungstechnik zeigt die Tabelle 8.<br />
Ist es erforderlich, weitere Kodierung hinzuzufügen,<br />
zum Beispiel nach Prolist oder eCl@ss, kann dies nach<br />
dem Gliederungszeichen *•* (Bild 2) gemacht werden.<br />
Die Struktur des Codes wird <strong>von</strong> der Quelle (zum Beispiel<br />
Prolist, eCl@ss und andere) übernommen, was im<br />
Bild 2 durch das Zeichen *A../..N* signalisiert wird. Spezifische<br />
Codes ergänzen, wenn erforderlich, das EAKS-<br />
Kennzeichen. Sie dürfen nicht als Ersatz eines Aufgaben-<br />
Kennzeichenteils verwendet werden.<br />
Code<br />
Engineering-Disziplin – Benennung<br />
Code<br />
Aufgabengruppe – Benennung<br />
A<br />
B<br />
E<br />
L<br />
M<br />
R<br />
S<br />
C – D; F – K;<br />
N – P; T – Z;<br />
Allgemein, übergeordnet<br />
Bautechnik und Anordnungsplanung<br />
Elektrotechnik<br />
Prozessleittechnik<br />
Verfahrenstechnische Maschinentechnik<br />
Rohrleitungstechnik<br />
Verfahrenstechnische Systemtechnik<br />
Reserviert für weitere Engineering-<br />
Disziplinen<br />
A<br />
B<br />
D<br />
E – Z<br />
Übergeordnete Aufgaben<br />
Basic-Engineering-Aufgaben<br />
Detail-Engineering-Aufgaben<br />
Reserviert für weitere Aufgabengruppen<br />
TabELLE 2: Datenstelle D2 – Aufgabengruppen einer<br />
Engineering-Disziplin<br />
Tabelle 1: Datenstelle D1 - Engineering–Disziplin<br />
52<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
endgültiges Lastenheft /<br />
Pflichtenheft PLT<br />
PLT-Stellenblätter<br />
endgültiges Lastenheft /<br />
Pflichtenheft RI-Fließbilder PLT<br />
PLT-Stellenblätter<br />
RI-Fließbilder<br />
Methode<br />
- Analysieren der Anforderung<br />
- Standards anwenden<br />
- Methode Berechnen <strong>von</strong> Auslegungsdaten<br />
- Betriebserfahrungen Analysieren der Anforderung nutzen<br />
- Bewerten Standards der anwenden möglichen Lösungen<br />
- Berechnen <strong>von</strong> Auslegungsdaten<br />
Hilfsmittel - Betriebserfahrungen nutzen<br />
- Bewerten Standardgerätekatalog<br />
der möglichen Lösungen<br />
- Lagerliste<br />
Hilfsmittel - Herstellerunterlagen<br />
- Vorschriften, Standardgerätekatalog Normen, Standards<br />
- PC-Programme<br />
Lagerliste<br />
- CAE Herstellerunterlagen<br />
- Vorschriften, Normen, Standards<br />
- PC-Programme<br />
- CAE<br />
Geräte<br />
festlegen<br />
Geräte<br />
festlegen<br />
Aktivitäten<br />
- Mess- und Stellorte in PLT-Stellenblätter<br />
eintragen<br />
- Aktivitäten Geräte spezifizieren<br />
- Lieferungen Mess- und Stellorte anfragen in PLT-Stellenblätter<br />
- eintragen Gerätetyp- / hersteller festlegen<br />
- Geräte spezifizieren<br />
Wer - Lieferungen anfragen<br />
- Gerätetyp- PLT-Planer/ hersteller festlegen<br />
Wer<br />
- PLT-Planer<br />
PLT-Stellenblätter<br />
Gerätelisten nach<br />
unterschiedlichen Kriterien sortiert<br />
PLT-Stellenblätter<br />
Gerätespezifikationen<br />
Gerätelisten nach<br />
Mengengerüste<br />
unterschiedlichen Kriterien sortiert<br />
Gerätespezifikationen<br />
Mengengerüste<br />
BILD 1: Planungsvorgang Geräte festlegen<br />
(angelehnt an [8])<br />
Gliederungsstufe (GS)<br />
1 2 3<br />
Datenstelle / Datentyp A A A NN A A NN A../..N<br />
Kurzzeichen der Datenstelle D 1 D 2 D 3 D N V 1 V 2 V N<br />
S<br />
Engineering Disziplin<br />
Aufgaben-Gruppe einer<br />
Engineering Disziplin<br />
Aufgaben-Untergruppe einer<br />
Engineering Disziplin<br />
Teilaufgaben einer Aufgaben-<br />
Untergruppe<br />
Vorgangsgruppe<br />
Vorgangs-Untergruppe<br />
Vorgang<br />
Gliederungszeichen<br />
BILD 2: Strukturschema der Engineering-<br />
Disziplinen, -Aufgaben und -Vorgänge<br />
Spezifische Codes<br />
A = Lateinische Großbuchstaben (:*I*, *O* und nationale Buchstaben wie Æ, R, Ä sind zu vermeiden);<br />
N = Arabische Zahlen 1 – 9 und 0 (Null)<br />
Software<br />
Intelligentes Gerät<br />
Produkt<br />
Hardware<br />
Merkmalleiste<br />
definiert durch<br />
Merkmalmodell<br />
nach IEC 61360<br />
Merkmal<br />
Eingangsinformation A vom Gewerk Y<br />
Eingangsinformation B vom Gewerk Z<br />
Eingangsinformation C vom Gewerk Z<br />
Eingangsinformation D vom Gewerk Y<br />
EAKS-Code<br />
EAKS-Code<br />
EAKS-Code<br />
Merkmalleisten-Typ<br />
Block<br />
beschreibt<br />
Referenzmerkmal<br />
Planungsaufgabe<br />
N-1<br />
Planungsaufgabe<br />
N<br />
Planungsaufgabe<br />
N+1<br />
beschreibt Aspekte des Gerätes<br />
bild 3: UML-Klassen diagramm einer merkmalbasierten<br />
Produktbeschreibung (vereinfacht)<br />
bild 4: Engineering-Tätigkeit<br />
aus Informationssicht<br />
Ausgangsinformation A<br />
Ausgangsinformation B<br />
Ausgangsinformation C<br />
Ausgangsinformation D<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
53
Hauptbeitrag | Automation 2012<br />
3. Planungsassistenz<br />
Wird dieses EAKS mit einer Kennzeichnungssystematik<br />
(Identifikation <strong>von</strong> zu engineerenden Funktionen, Produkten<br />
einschließlich derer Einbauorte) zum Beispiel<br />
RDS-PP [9] verbunden, entsteht eine Basis für die Entwicklung<br />
eines semantischen Anlagenwissensmodells,<br />
das das Engineering-Vorgehensmodell mit anpassbarer<br />
Abstraktionstiefe und den aktuellen Planungszustand<br />
abbildet. Die Planungsinformationen werden hierbei<br />
merkmalbasiert (Bild 3) abgelegt. Eine wohldefinierte<br />
Menge <strong>von</strong> Attributen zum Beispiel nach IEC 61360 [10]<br />
wird zur Identifikation, Beschreibung, Wertebevorratung<br />
eines Merkmals sowie zur Spezifikation seiner weiteren<br />
spezifischen Charakteristiken genutzt. Da neben der<br />
Struktur der Merkmale auch deren Inhalte anerkannt<br />
und unmissverständlich definiert werden müssen, wurde<br />
auf etablierte Definitionen sowie Produktbeschreibungen<br />
zum Beispiel nach Prolist zurückgegriffen.<br />
Die Planungsinformationen bestehend aus Merkmalen<br />
bilden eine Soll-Menge <strong>von</strong> Eingangsinformationen im<br />
Kontext einer bestimmten Engineering-Tätigkeit (Aufgabe<br />
beziehungsweise Vorgang und andere) (Bild 4).<br />
Basierend darauf wurde eine rechnergestützte Planungsassistenz<br />
PASS (Bild 5) entwickelt. Hierbei ging es<br />
um die Sicherstellung des konsistenten Planungsdatenaustauschs<br />
im Anlagenengineering sowie eine reproduzierbare<br />
Bewertung der Vollständigkeit, der Qualität und<br />
der Genauigkeit der Planungsinformationen vor jedem<br />
gewerkeübergreifenden Engineering-Schritt und die<br />
Analyse der Risiken infolge <strong>von</strong> unscharfen Eingangsinformationen<br />
[11].<br />
Ausgehend vom hinterlegten Vorgehensmodell (Kennzeichnung<br />
und Strukturierung der Engineering-Tätigkeiten<br />
entsprechend dem EAKS) wird ermittelt, welche<br />
Informationen für den aktuellen Engineering-Schritt<br />
notwendig sind. Werden fehlende beziehungsweise unsichere<br />
Informationen (Identifikation erfolgt hierbei anhand<br />
eines Merkmalattributes) festgestellt, erfolgt deren<br />
Auswertung durch eine hinterlegte Risikoroutine, was<br />
eine reproduzierbare Bewertung <strong>von</strong> Risiken ermöglicht,<br />
die mit der Nutzung der Information verbunden sind.<br />
Diese Risiken äußern sich in falsch ausgelegten Betriebsmitteln<br />
beziehungsweise Koppelstellen zu anderen<br />
Betriebsmitteln (falscher Flansch, falsches elektrisches<br />
Signalformat), wodurch spätere Änderungen notwendig<br />
sind, die zu Zeitverzug oder erheblichen Mehrkosten<br />
führen. Die umgesetzte Risikoabschätzung erfolgt unter<br />
anderem unter Zuhilfenahme <strong>von</strong> Erfahrungswissen<br />
und führt in ausgewählten Fällen auch zu direkten Empfehlungen<br />
[11].<br />
Weiterhin stellt das Anlagenwissensmodell Strukturen<br />
bereit, die die Umsetzung <strong>von</strong> ergänzenden analytischen<br />
Methoden zur Qualitätssicherung <strong>von</strong> Planungsergebnissen<br />
– unter anderem Prüfung auf Einhaltung der definierten<br />
Designregeln und der Konsistenz – ermöglichen.<br />
4. Anwendungsbeispiel<br />
Die vorgeschlagene Vorgehensweise wurde exemplarisch<br />
für die Planung einer Pilotanlage im Kraftwerksbereich<br />
zur Vorgehensmodellierung <strong>von</strong> eng miteinander verzahnten<br />
Gewerken der Verfahrenstechnik, Rohrleitungs-<br />
Code<br />
Aufgabenuntergruppe – Benennung<br />
Code<br />
Vorgangsgruppe – Benennung<br />
A<br />
B<br />
C<br />
D – Z<br />
TabELLE 3: Datenstelle D3 - Aufgabenuntergruppen<br />
einer Engineering-Disziplin<br />
Code<br />
00 – 99<br />
Übergeordnete Aufgaben<br />
Objekt bestimmende Aufgaben<br />
Objekt verbindende Aufgaben<br />
Reserviert für weitere Aufgabenuntergruppen<br />
Benennung der Teilaufgabe einer<br />
Aufgabenuntergruppe<br />
Reserviert für gewerkespezifische<br />
Teilauf gaben einer Aufgabenuntergruppe<br />
A<br />
B<br />
C<br />
D<br />
E<br />
F<br />
G<br />
H<br />
J<br />
K – P<br />
Q – Z<br />
Eingangsdaten einholen<br />
Berechnung durchführen<br />
Auslegung ausführen<br />
Konstruktion bearbeiten<br />
Aufstellung Systeme bearbeiten<br />
Listen anfertigen (keine Dokumente)<br />
Dokumente anfertigen<br />
Kontrolle, Bewertung durchführen,<br />
Freigabe, Genehmigung erteilen<br />
Ergebnisdaten für Übergabe an<br />
weitere Verarbeitung aufbereiten<br />
Reserviert für weitere Vorgangsgruppen<br />
Reserviert für gewerkespezifische<br />
Vorgangsgruppen<br />
Tabelle 4: Datenstelle DN – Teilaufgaben einer<br />
Aufgabenuntergruppe<br />
TabELLE 5: Datenstelle V1 - Vorgangsgruppe<br />
54<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
Code<br />
Vorgang - Benennung<br />
Code<br />
Vorgangsidentifikation – Benennung<br />
A<br />
B<br />
Eingangsdaten bearbeiten<br />
Eingangsdaten prüfen, verifizieren<br />
0 – 99<br />
Reserviert für Identifikation gewerkespezifischer<br />
Vorgänge<br />
C – N<br />
Reserviert für gewerkespezifische<br />
Vorgänge<br />
TabELLE 7: Datenstelle VN – Vorgangsidentifikation<br />
P<br />
Q<br />
R<br />
S<br />
T – Z<br />
Listen anfertigen: zum Beispiel Stoff-<br />
Datenlisten, MTO<br />
Dokumente anfertigen: wie Angebot,<br />
Einkaufsantrag, Materialantrag,<br />
Genehmigung zur Fabrikation, Design-<br />
Freeze Protokolle<br />
CE- Konformität-Dokumentation<br />
anfertigen<br />
Betriebsdokumentation anfertigen<br />
Reserviert für gewerkespezifische<br />
Vorgänge<br />
Tabelle 6: Datenstelle V2 – Vorgang<br />
TabELLE 8: Anwendungsbeispiele für Datenstellen D1, D2,<br />
D3, DN, V1,V2, VN<br />
Code<br />
R<br />
RD<br />
RDB<br />
RDB01<br />
RDB01GQ<br />
RDB01GQ01<br />
RDB01GQ02<br />
Benennung<br />
Rohrleitungstechnik<br />
Rohrleitungstechnik / Detail Engineering<br />
Rohrleitungstechnik / Detail Engineering<br />
/ Objekt bestimmende Aufgaben<br />
Rohrleitungstechnik / Detail Engineering<br />
/ Objekt bestimmende Aufgaben /<br />
vorfabrizierte Rohrleitungen planen<br />
Rohrleitungstechnik / Detail Engineering<br />
/ Objekt bestimmende Aufgaben /<br />
vorfabrizierte Rohrleitungen planen /<br />
Dokumente anfertigen<br />
… / Materialanfrage anfertigen<br />
… / Freigabe für Vorfabrikation aufstellen<br />
Gewerk A<br />
Gewerk B<br />
Transformator<br />
XML Import <strong>von</strong><br />
Planungsinformationen<br />
Transformator<br />
XML Export <strong>von</strong><br />
Planungsinformationen<br />
Planer Team mit Know-how<br />
Datenbestandsanalyse<br />
Risiko Management<br />
Definition<br />
und<br />
Bewerten<br />
der<br />
Risiken<br />
Überwachung<br />
und<br />
Akzeptanz<br />
<strong>von</strong> Risiken<br />
Festlegen<br />
der Anforderungen<br />
Entscheidung<br />
und<br />
Ausführung<br />
Risikoportfolio<br />
Entscheidungsalgorithmen<br />
Semantisches Anlagenwissensmodell<br />
(EAKS, RDS-PP, merkmalbasiert)<br />
Vorgehensmodell für PLT Planung (anwendungsorientierte<br />
Abstraktionstiefe, EAKS)<br />
Feldgeräte<br />
spezifizieren<br />
PLS-Geräte<br />
spezifizieren<br />
... L-Fup<br />
PLS-<br />
Programmierung<br />
Vorgehensmodell für RL Planung (anwendungsorientierte Abstraktionstiefe, EAKS)<br />
RL- Konzept<br />
festlegen<br />
RL verlegen ...<br />
RL<br />
berechnen<br />
RL-Bauteile<br />
spezifizieren<br />
Vorgehensmodell für VT Planung (anwendungsorientierte Abstraktionstiefe, EAKS)<br />
Verfahrenskonzept<br />
erstellen<br />
Werkstoffkonzept<br />
erstellen<br />
...<br />
Verfahrensbeschreibung<br />
detaillieren<br />
R&I<br />
Fließbilder<br />
erstellen<br />
PASS<br />
Planungsassistenzsystem<br />
bild 5: Planungsassistenz für Datenaustausch<br />
im Anlagenengineering (PASS)<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
55
Hauptbeitrag | Automation 2012<br />
planung sowie der PLT-Planung erprobt. Bei den hierbei<br />
zu planenden Systemen handelt es sich um einige Module<br />
eines Gas-und-Dampf-Kombikraftwerks.<br />
Zuerst wurde das gewerkeübergreifende Prozessmodell<br />
mit Engineering-Tätigkeiten für die Projektphasen<br />
Entwurfsplanung und Detailplanung (bis Meilenstein<br />
„as planned“) in Netzplantechnik erstellt (Bild 6). Die<br />
Abstraktionstiefe war so gewählt, dass jeder Engineering-Schritt<br />
(Arbeitspaket) nur <strong>von</strong> einem Gewerk bearbeitet<br />
wurde (keine Kooperation innerhalb des Engineering-Schrittes).<br />
Durch weitere Detaillierung war<br />
es möglich, interne Planungsabläufe zu beschreiben<br />
(Bild 7). Das iterative Vorgehen bei der Bearbeitung der<br />
Planungsaufgaben im gewerkeübergreifenden Vorgehensmodell<br />
wurde aus Gründen der Übersichtlichkeit<br />
nicht abgebildet.<br />
Das gewerkeübergreifende Vorgehensmodell (Bild 6)<br />
wurde zu einem Workflow weiterentwickelt und anschließend<br />
zur Steuerung des Planungsprozesses eingesetzt.<br />
Bei der Modellierung wurde auf formale Modellierungstechniken<br />
mit Petri-Netzen zurückgegriffen [12].<br />
Bei der prototypischen Realisierung des Planungsassistenzsystems<br />
PASS stellte das CAE-Planungswerkzeug<br />
Comos-PT <strong>von</strong> Siemens eine Plattform für verfahrenstechnische<br />
und PLT-Planung dar und bot gleichzeitig<br />
eine parametrierbare XML-Export/Import-Schnittstelle,<br />
die zum Datenaustausch mit der PASS-Datenbank diente.<br />
Die Rohrleitungsplanung erfolgte mit dem CAE-Planungswerkzeug<br />
Aveva PDMS.<br />
Durch Hinterlegung <strong>von</strong> typbezogenen Typicals wurden<br />
die Informationsbedarfe einzelner Engineering-<br />
Schritte im Allgemeinen beschrieben. Abhängig <strong>von</strong> der<br />
Rolle und dem aktuellen Planungsschritt ließen sich<br />
Soll-Informationsbedarfe für Engineering-Tätigkeiten<br />
generisch ermitteln (Bild 8) und mit dem Ist-Informationsbestand<br />
vergleichen. Folgende Methoden wurden zur<br />
Sicherstellung <strong>von</strong> Planungsqualität basierend auf dem<br />
Anlagenwissensmodell entwickelt und realisiert:<br />
Vollständigkeitsuntersuchung der Daten,<br />
Konsistenzuntersuchung der Daten,<br />
Datenbestandsanalyse vor der Übernahme für den<br />
nächsten Planungsschritt,<br />
Einhaltung der definierten Designregeln,<br />
Vollständigkeitsuntersuchung der verwendeten<br />
Vorgaben.<br />
Die Ergebnisse der Datenanalyse flossen in die Risikobewertung<br />
zur Folgenabschätzung des aktuellen Planungsstands<br />
ein. Somit beschleunigte sich der Planungsprozess<br />
und die Zahl der Planungsfehler nahm ab.<br />
Fazit<br />
Das Engineering-Aufgaben-Kennzeichnung-System<br />
(EAKS) zur Identifizierung der Vorgänge bei der Erfassung<br />
<strong>von</strong> Engineering-Aufgaben unterstützt und fördert<br />
die logische Strukturierung der Engineering-Vorgehensmodelle.<br />
Es trägt zur Effizienzsteigerung der gewerkeübergreifenden<br />
Kooperation in Anlagenbauprojekten bei.<br />
Außerdem können Engineering-Tätigkeiten innerhalb<br />
einzelner Gewerke erfasst und dokumentiert werden,<br />
was die Formalisierung des planerischen Wissens vorantreibt<br />
und somit eine nachhaltige Basis für die Wissenswiederverwendung<br />
sicherstellt.<br />
Kombiniert mit merkmalbasierter Ablage <strong>von</strong> Planungsinformationen<br />
schafft EAKS eine Basis, um zusätzlich<br />
zu den Planungsdaten selbst auch deren Entstehungsprozess<br />
reproduzierbar abzulegen. Somit können<br />
die Informationen rückverfolgt werden, was im Rahmen<br />
<strong>von</strong> technischem Audit und der Compliance besonders<br />
<strong>von</strong> Vorteil ist. Außerdem wurde am Beispiel eines Planungsassistenzsystems<br />
gezeigt, dass weitere Anwendungsmöglichkeiten<br />
gegeben sind.<br />
Referenzen<br />
Manuskripteingang<br />
04.06.2012<br />
Im Peer-Review-Verfahren begutachtet<br />
[1] bernecker, G.: Planung und Bau verfahrenstechnischer<br />
Anlagen. 4. Aufl. Springer Verlag, Berlin, 2001<br />
[2] Fay, A., Schleipen, M., Mühlhause, M.: Wie kann man<br />
den Engineering-Prozess systematisch verbessern?<br />
<strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische Praxis<br />
51 (1-2), S. 80-85, 2009<br />
[3] rüppel, U.: Vernetzt-kooperative Planungsprozesse im<br />
konstruktiven Ingenieurbau: Grundlagen, Methoden,<br />
Anwendung und Perspektiven zur vernetzten Ingenieur-kooperation.<br />
Springer, Berlin 2007<br />
[4] Hauser, A. S.: Ein Referenzmodell zur Modellierung<br />
wissensintensiver Prozesse bei Ingenieurdienstleistungen<br />
zur kooperativen Planung verfahrenstechnischer<br />
Anlagen. Shaker, Aachen 2008<br />
[5] entrup, Ch. L.: Ein Referenzmodell zur Unterstützung<br />
wissensintensiver Prozesse im Produktlebenszyklus<br />
durch Analyse <strong>von</strong> Produkt- und Prozessdaten. Ein<br />
Beitrag zum prozessorientierten Wissensmanagement.<br />
Wissenschaftlicher Verlag, Berlin 2009<br />
[6] Goesmann, T.: Ein Ansatz zur Unterstützung wissensintensiver<br />
Prozesse durch Workflow-Management-<br />
Systeme. Dissertation, tu Berlin, Berlin, 2002<br />
[7] PAS 1059: Planung einer verfahrenstechnischen Anlage –<br />
Vorgehensmodell und Terminologie. Februar 2006<br />
[8] namur-Arbeitsblatt na 35: Abwicklung <strong>von</strong> PLT-Projekten.<br />
März 2003<br />
[9] Königstein, H., Müller, H., Kaiser, J.: Das RDS-PP<br />
- Übergang vom KKS zu einer internationalen Norm.<br />
VGB PowerTech, 8, S. 1-8, 2007<br />
[10] Döbrich, U., Heidel, R.: Datengetriebene Programmsysteme.<br />
Ein Ausweg aus dem Schnittstellenchaos.<br />
Informatik-Spektrum 35(3), S. 190-203, 2012<br />
[11] Sokolov, S., Mühlhause, M., Diedrich, Ch., Fichtner,<br />
H.-P., Kaiser, M.: Rechnergestützte Assistenz zur<br />
Risikobewertung und zum Ableiten <strong>von</strong> Handlungsvarianten<br />
in der Anlagenplanung. In: Automation 2011:<br />
Kongress Baden-Baden, 28. und 29. Juni 2011; Der<br />
12. branchentreff der Mess- und Automatisierungstechnik.<br />
VDI/VDE-Gesellschaft Meß- und Automatisierungstechnik,<br />
S. 161-164, VDI-Verlag, Düsseldorf 2011<br />
[12] Winkelmann, K., Luczak, H.: Prospective analysis of<br />
cooperative provision of industrial services using<br />
coloured petri nets. In: Petri nets and other models of<br />
concurrency: proceedings – ICATPN 2006, 27th International<br />
Conference on Applications and Theory of Petri<br />
Nets and Other Models of Concurrency, Turku, Finland,<br />
June 26-30, 2006, S. 362-380, Springer, Berlin 2006<br />
56<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
SBB12C<br />
SBB81<br />
SBB20<br />
SDB12<br />
SDC82<br />
Apparate,<br />
Maschinen, PU’s<br />
u.a. verfahrenstechnisch<br />
auslegen<br />
09.07<br />
2012<br />
12.08<br />
2012<br />
Fließschemata<br />
detaillieren<br />
13.08<br />
2012<br />
19.08.<br />
2012<br />
SBB12D<br />
Ausführungsleitzeichnungen<br />
/<br />
Spezifikation:<br />
Apparate,<br />
Maschinen, PU’s<br />
u.a. erstellen<br />
13.08<br />
2012<br />
26.08<br />
2012<br />
Verfahrenstechnische<br />
Vorgaben für PLT<br />
erstellen<br />
20.08<br />
2012<br />
SBB12GQ<br />
Anfrage /<br />
Angebotsvergleich:<br />
Apparate,<br />
Maschinen, PU’s<br />
u.a.<br />
27.08<br />
2012<br />
SBC82<br />
26.08<br />
2012<br />
09.09<br />
2012<br />
Erste Fassung<br />
R&I Fließbild<br />
erstellen<br />
20.08<br />
2012<br />
16.09<br />
2012<br />
Meilenstein<br />
Basic<br />
Engineering<br />
17.09<br />
2012<br />
Apparate,<br />
Maschinen, PU’s<br />
u.a. detaillieren<br />
(Datenblätter,<br />
Anschlüsse)<br />
18.09<br />
2012<br />
LDB10C<br />
04.11<br />
2012<br />
Geräte festlegen<br />
18.09<br />
2012<br />
30.09<br />
2012<br />
R&I-Fließbilder<br />
detaillieren<br />
05.11<br />
2012<br />
02.12<br />
2012<br />
LDB10GQ<br />
Anfrage /<br />
Angebotsvergleich<br />
01.10<br />
2012<br />
LDC80C<br />
14.10<br />
2012<br />
Zentrale<br />
Einrichtungen<br />
festlegen<br />
01.10<br />
2012<br />
14.10<br />
2012<br />
Arrangement Input / Output<br />
RAA05AB01<br />
R&Is,<br />
Rohrklassen,<br />
Konstruktions-Checklisten,<br />
CE-Konformitätsvorgaben,<br />
3d-Model usw.<br />
RBC21EM01<br />
RL-Routing<br />
in 3D-Modell<br />
RBC21DL01<br />
RL-Längen<br />
und Anzahl<br />
Formstücke<br />
RBC21BE01<br />
Input für Bautechnik<br />
(Belastung), Aufhängungspunkte<br />
RDC21EM01<br />
Finales RL-<br />
Routing, 3D-<br />
Aktualisierung,<br />
Isometrien<br />
RDB11GR01<br />
Konsolidierte<br />
CE-<br />
Konformitäts<br />
-<br />
Dokumentation<br />
RBD21HR02<br />
Input für<br />
CE- Deklaration<br />
RDB21GQ02<br />
Einkaufsauftrag<br />
für<br />
Bulk Piping<br />
RBB21B<br />
Rohrleitungen<br />
festlegen<br />
20.08<br />
2012<br />
16.09<br />
2012<br />
RDB21C<br />
Rohrleitungsbauteile<br />
spezifizieren<br />
18.09<br />
2012<br />
30.09<br />
2012<br />
RDB21E<br />
Isometrien planen<br />
01.10<br />
2012<br />
28.10<br />
2012<br />
Design<br />
RBB21BF01<br />
RBB21GQ01<br />
Margin-<br />
Definition,<br />
Material-<br />
Antrag-<br />
Ausarbeitung<br />
Stressanalyse,<br />
3D-Modell<br />
Update<br />
RBB12FP01<br />
Material<br />
Take Off<br />
Liste<br />
1-<br />
Vorbereitung<br />
J<br />
N<br />
RBB21FP02<br />
Material<br />
Take Off<br />
Liste 1<br />
RDB21BF01<br />
Finale<br />
Stressanalyse<br />
&<br />
RL-<br />
Konstruktion<br />
RDB21FP01<br />
Material<br />
Take Off<br />
Liste 2 -<br />
Vorbereitung<br />
RDB21GQ01<br />
Marge-<br />
Definition,<br />
Material-<br />
Antrag -<br />
Ausarbeitung<br />
J<br />
N<br />
bild 6: Gewerkeübergreifendes Vorgehensmodell<br />
für Planung des Speisewasser-Versorgungssystems<br />
(im Rahmen vom Pilotprojekt)<br />
bild 7: Detailliertes Vorgehensmodell für Planung <strong>von</strong><br />
nicht-vorfabrizierten Rohrleitungen<br />
Eingangsinformationen<br />
bild 8: Generisches<br />
Modell einer Engineering-<br />
Tätigkeit (Festlegung <strong>von</strong><br />
Feldgeräten)<br />
Eingangsinformationen<br />
EAKS-Code<br />
EAKS-Code<br />
Planungs-<br />
Vorgang<br />
Füllstandmessgerät<br />
Analysieren<br />
Eingangsinformationen<br />
EAKS-Code<br />
Planungsvorgang<br />
Instanziieren<br />
Druck<br />
-messgerät<br />
Planungsvorgang<br />
Eingangsinformationen<br />
EAKS-Code<br />
Planungsvorgang<br />
Temperaturmessgerät<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
57
Hauptbeitrag | Automation 2012<br />
Autoren<br />
Dipl.-Ing. Sergiy SOKOLOv (geb. 1979) ist seit 2010 wissenschaftlicher<br />
Mitarbeiter am Lehrstuhl Integrierte Automation<br />
an der Otto-<strong>von</strong>-Guericke-Universität Magdeburg. Seine<br />
Forschungsgebiete sind Planungs- und Workflow-Methodik bei<br />
der Projektierung <strong>von</strong> Automatisierungsanlagen, Modellierung<br />
wissensintensiver Prozesse zur kooperativen Planung <strong>von</strong><br />
Automatisierungs anlagen, merkmalbasierte Produk- und<br />
Prozess beschreibung.<br />
Otto-<strong>von</strong>-Guericke-Universität Magdeburg,<br />
Institut für Automatisierungstechnik,<br />
PF 4120, D-39016 Magdeburg,<br />
Tel. +49 (0) 391 671 89 16,<br />
E-Mail: sergiy.sokolov@ovgu.de<br />
Dipl.-Ing. Hans-PETER FiCHTner (geb. 1948) ist Geschäftsführer<br />
der Koramis GmbH und beschäftigt sich seit 1983 mit<br />
CAE/CAD-Entwicklung im prozessleittechnischen Umfeld.<br />
Schwerpunkt ist die rechnergestützte digitale Planung mit<br />
Ziel der 0-Fehler-Konstruktion in den Bereichen Funktions-,<br />
<strong>Komponenten</strong>- und Ortsplanung.<br />
Koramis GmbH,<br />
Ensheimer Straße 37, D-66386 St. Ingbert,<br />
Tel. +49 (0) 6894 963 07 81,<br />
E-Mail: hp.fichtner@koramis.de<br />
Ing. HTL, Dipl.-Oec. Zbynek CiHLAR (geb. 1940). Über 50 Jahre<br />
Erfahrung in Projekt abwicklung. Spezialist in Kennzeichensystemen<br />
(KKS, RDS, EAKS). Mitarbeit in ISO, IEC, DIN, VGB.<br />
Haldenstr. 30, CH-5415 Nussbaumen AG,<br />
Tel. +41 (0) 56 282 50 74,<br />
E-Mail: zbcih@vtxmail.ch<br />
Dr.-Ing. Dipl.-Inform. Michael Kaiser (geb.<br />
1966) ist seit 2001 Geschäftsführer der iXIT<br />
Engineering Technology GmbH in Karlsruhe.<br />
Schwerpunkte seiner Tätigkeit sind die<br />
Themen Fabrikautomation und vertikale<br />
Integration sowie Optimierung <strong>von</strong> Engineering-Prozessen.<br />
iXIT Engineering Technology GmbH,<br />
Südendstraße 8b, D-76137 Karlsruhe,<br />
Tel. +49 (0) 721 968 83 70,<br />
E-Mail: michael.kaiser@ixit.de<br />
Prof. Dr.-Ing. Christian DiedriCH (geb.<br />
1957) leitet den Lehrstuhl Integrierte Automation<br />
an der Otto-<strong>von</strong>-Guericke-Universität<br />
Magdeburg. Seine Hauptarbeitsfelder umfassen<br />
Beschreibungsmethoden für Automatisierungsgeräte<br />
und -systeme (Funktionsblocktechnologie,<br />
Feldbusprofile,<br />
Gerätebeschreibungen (EDD), FDT, IEC<br />
61131), Engineeringmethoden und Informationsmanagement<br />
(Objektorientierte Analyse<br />
und Design, UML, Web-Technologien,<br />
Wissensverarbeitung), formale und formalisierte<br />
Methoden in der Automatisierungstechnik.<br />
Er ist in nationalen und internationalen<br />
Standardisierungs- und Fach gremien<br />
(IEC, DKE, ZVEI, PNO) tätig.<br />
Otto-<strong>von</strong>-Guericke-Universität Magdeburg,<br />
Institut für Automatisierungstechnik,<br />
PF 4120, D-39016 Magdeburg,<br />
Tel. +49 (0) 391 671 84 99,<br />
E-Mail: christian.diedrich@ovgu.de<br />
Sprechstunde<br />
3. Explosionsschutz-Sprechstunde<br />
Explosionsschutz<br />
14. + 15.11.2012, Mannheim, Pepperl+Fuchs GmbH<br />
www.explosionsschutz-sprechstunde.de<br />
Save the date!<br />
Themen<br />
Installation und Betrieb explosionsgeschützter Anlagen<br />
Typische Fehler bei unterschiedlichen Zündschutzarten<br />
Der korrekte Nachweis der Eigensicherheit<br />
Fachgerechte Reparatur und Prüfung <strong>von</strong><br />
explosionsgeschützten Betriebsmitteln<br />
58<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
Termin<br />
Mittwoch, 14.11.2012<br />
Veranstaltung (11:30 – 17:30 Uhr)<br />
„Get-Together“ mit Abendessen (ab 18:30 Uhr)<br />
Donnerstag, 15.11.2012<br />
Veranstaltung (9:00 – 15:00 Uhr)<br />
Weitere Informationen und Online-Anmeldung unter www.explosionsschutz-sprechstunde.de
SIL<br />
Sprechstunde<br />
4. SIL-Sprechstunde<br />
Funktionale Sicherheit<br />
18. + 19.9.2012, Mannheim, Pepperl+Fuchs GmbH<br />
www.sil-sprechstunde.de<br />
PLT-Schutzeinrichtung<br />
Programm<br />
Moderation: Jürgen George,<br />
Pepperl+Fuchs GmbH<br />
Wann und Wo?<br />
Prinzip der SIL-Bewertung<br />
Parameter der SIL-Bewertung<br />
Vermeidung systematischer Fehler<br />
Bewertung zufälliger Fehler<br />
Gerätequalifikation aufgrund „früherer Verwendung“<br />
Referenten<br />
Dirk Hablawetz, BASF SE<br />
Dr. Andreas Hildebrandt, Pepperl+Fuchs GmbH<br />
Udo Hug, BImSchG § 29a Sachverständiger<br />
Gerhard Jung, Pepperl+Fuchs GmbH<br />
Dr. Thomas Karte, Samson AG<br />
Dr. Gerold Klotz-Engmann, Endress+Hauser Messtechnik<br />
GmbH + Co. KG<br />
Josef Kuboth, Landesamt für Natur, Umwelt und Verbraucherschutz<br />
Nordrhein-Westfalen<br />
Bernd Schroers, Bayer Technology Services<br />
Heiko Schween, HIMA Paul Hildebrandt GmbH + Co KG<br />
Johann Ströbl, TÜV Süd Industrie Service GmbH<br />
Termin<br />
Dienstag, 18.09.2012<br />
Veranstaltung (11:30 – 16:30 Uhr)<br />
„Get-Together“ mit Abendessen (ab 17:30 Uhr)<br />
Mittwoch, 19.09.2012<br />
Veranstaltung (9:00 – 15:00 Uhr)<br />
Ort<br />
Mannheim, Pepperl+Fuchs GmbH<br />
Thema<br />
SIL – Qualifizierung <strong>von</strong> PLT-Schutzeinrichtungen<br />
Teilnahmegebühr<br />
<strong>atp</strong> <strong>edition</strong>-Abonnenten 540 € zzgl. MwSt<br />
Firmenempfehlung 590 € zzgl. MwSt<br />
reguläre Teilnahmegebühr 690 € zzgl. MwSt<br />
Im Preis enthalten sind die Tagungsunterlagen<br />
sowie das Catering (Kaffee, 2x Mittagsimbiss,<br />
„Get-Together“ mit Abendessen).<br />
Veranstalter<br />
Fragen Sie!<br />
Die Explosionsschutz-Sprechstunde gibt Ihnen ausreichend Gelegenheit,<br />
Ihre individuellen Fragen zu stellen und offen mit den praxiserfahrenen<br />
Referenten zu diskutieren.<br />
Stellen Sie Ihre Fragen rechtzeitig unter www.sil-sprechstunde.de<br />
Weitere Informationen und Online-Anmeldung<br />
unter www.sil-sprechstunde.de<br />
Fax-Anmeldung: +49 (0) 89 45051-323 oder Online-Anmeldung: www.sil-sprechstunde.de<br />
Ich habe die <strong>atp</strong> <strong>edition</strong> abonniert<br />
Ich komme auf Empfehlung <strong>von</strong> Firma: .....................................................................................................................................................................<br />
Vorname Nachname<br />
Telefon<br />
Telefax<br />
Firma/Institution<br />
E-Mail<br />
Straße/Postfach<br />
Land, PLZ, Ort<br />
Hausnummer<br />
✘<br />
Ort, Datum, Unterschrift<br />
Ihre freiwilligen Angaben werden zusammen mit den für die Vertragsabwicklung erforderlichen Daten <strong>von</strong> uns und der Unternehmensgruppe, unseren Dienstleistern sowie anderen<br />
ausgewählten Unternehmen verarbeitet und genutzt, um Sie über Produkte und Dienstleistungen zu informieren.<br />
Wenn Sie dies nicht mehr wünschen, schreiben Sie bitte an: Oldenbourg Industrieverlag, Rosenheimer Str. 145, D-81671 München
hauptbeitrag<br />
Modellbasierte<br />
Software-Entwicklung<br />
Prozess für sicherheitskritische embedded Systeme<br />
Dieser Beitrag beschreibt einen Prozess zur modellbasierten Entwicklung <strong>von</strong> IEC 61508-konformer<br />
eingebetteter Software in der industriellen Messtechnik. Die Entwicklungsaktivitäten<br />
einer V-Modell-Anpassung (Tailoring) werden dabei auf Basis <strong>von</strong> Unified-Modeling-<br />
Language-Modellen durchgeführt. Bestehende Schwächen der UML hinsichtlich der Modellierung<br />
<strong>von</strong> Sicherheitsaspekten werden durch eine UML-Erweiterung überwunden,<br />
die die Modellierung auf Produkt- und Prozessebene unterstützt. Damit wird die Dokumentation<br />
der Software in die Modelle integriert und somit der Aufwand für Zertifizierung<br />
und Entwicklung reduziert.<br />
SCHLAGWÖRTER Modellbasierte Softwareentwicklung / UML Profil / IEC 61508<br />
Model-based software development –<br />
A Process for safety-critical embedded Systems<br />
This article describes a model-based process for the development of IEC 61508 compliant<br />
embedded software in the industrial measurement domain. The process implements<br />
the activities of a V-Model tailoring based on UML models. Existing drawbacks of UML<br />
concerning the modelling of safety aspects are overcome by a UML extension that supports<br />
the process-side as well as the product side of the development. Integrating the<br />
software documentation into the UML models reduces the effort for software certification<br />
and development.<br />
KEYWORDS model-based software development / UML profile / IEC 61508<br />
60<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
Dirk Kuschnerus, MiCHAEL GERDing, Attila Bilgic, Krohne Messtechnik<br />
Thomas MuSCH, Ruhr-Universität Bochum<br />
Ein immer bedeutenderer Teil des Mess- und Regelungsaufwands<br />
in der Prozessautomatisierung<br />
wird durch eingebettete Systeme realisiert, um<br />
bestehenden Einschränkungen bezüglich verfügbarer<br />
Energie und Gerätegröße gerecht zu<br />
werden. Wird ein solches eingebettetes System bei einem<br />
industriellen Prozess verwendet, der ein Risiko für Umwelt<br />
und Menschen darstellt, so ist das eingebettete System<br />
als sicherheitskritisch einzustufen.<br />
Diese spezielle Klasse <strong>von</strong> eingebetteten Systemen unterliegt<br />
besonderen Anforderungen hinsichtlich der Methodik<br />
und Dokumentation der Softwareentwicklung.<br />
Domänenspezifische und generische Sicherheitsstandards<br />
dokumentieren diese Anforderungen und dienen damit<br />
Entwicklern und Auditoren <strong>von</strong> sicherheitskritischen Systemen<br />
als Referenz. In der Prozessautomatisierung ist insbesondere<br />
der generische Standard IEC 61508 [1] relevant,<br />
der allgemeine Sicherheitsaspekte definiert sowie Empfehlungen<br />
für Aktivitäten und Techniken in den einzelnen<br />
Lebenszyklusphasen eines Softwaresystems gibt.<br />
Zusätzlich zu den Anforderungen dieses Standards<br />
wird die Entwicklung <strong>von</strong> sicherheitskritischen eingebetteten<br />
Systemen durch eine kontinuierlich steigende<br />
Systemkomplexität beeinflusst, deren Ursache beispielsweise<br />
in der Verlagerung <strong>von</strong> Systemfunktionen <strong>von</strong><br />
Hardware auf Software und im Bedarf nach umfassenderen<br />
Gerätelösungen zu finden ist. Diese steigende Komplexität<br />
– in Verbindung mit der Anforderung, ein breites<br />
Portfolio <strong>von</strong> Gerätekonfigurationen in verschiedenen<br />
Produktlinien in kürzester Zeit entwickeln und anbieten<br />
zu können – ist eine große Herausforderung bei der Entwicklung<br />
industrieller Messgeräte. Um dieser Herausforderung<br />
zu begegnen, muss die Systementwicklung in<br />
einem strukturierten Prozess durchgeführt werden, der<br />
besonderes Augenmerk auf die Wiederverwendung <strong>von</strong><br />
Entwicklungsartefakten auf verschiedenen Ebenen legt.<br />
Ein möglicher Ansatz hierzu ist die modellbasierte Softwareentwicklung,<br />
die sich im Rahmen bestehender Vorgehensmodelle<br />
verwenden lässt und Softwaremodelle<br />
als Schlüsselartefakte im Lebenszyklus eines Softwaresystems<br />
betrachtet.<br />
In diesem Beitrag wird als Modellierungstechnik die<br />
Unified Modeling Language (UML) genutzt, da sie einen<br />
industriellen Quasi-Standard darstellt und dementsprechend<br />
weit verbreitet ist. Im Artikel wird beschrieben,<br />
wie die UML verwendet und erweitert werden kann, um<br />
in Verbindung mit einem angepassten V-Modell vor dem<br />
Hintergrund der Sicherheitsnorm IEC 61508 sicherheitskritische<br />
eingebettete Systeme für die industrielle Messtechnik<br />
zu entwickeln.<br />
1. Das V-Modell im Kontext <strong>von</strong> ieC 61508<br />
Der Sicherheitsstandard IEC 61508 definiert mit dem<br />
Overall-Safety-Lifecycle einen Rahmenprozess, der für<br />
alle Lebenszyklusphasen eines sicherheitskritischen<br />
Systems Aktivitäten zur Gewährleistung der funktionalen<br />
Sicherheit definiert. Die Realisierung einer sicherheitskritischen<br />
Software als Teil des Overall-Safety-<br />
Lifecycles ist in einem eigenen Subprozess Software-<br />
Safety-Lifecycle in der Phase Realisierung beschrieben.<br />
Der Standard erlaubt hierbei die Wahl und Anpassung<br />
eines Vorgehensmodells für das individuelle Softwareentwicklungsprojekt,<br />
verlangt aber, bestimmte Anforderungen<br />
an Aktivitäten und deren Produkte und<br />
verwendete Methoden zur Durchführung einzuhalten.<br />
Die Verwendung eines V-Modell-Tailorings, das die Anforderungen<br />
an einen sicheren Softwareprozess erfüllt,<br />
wird in IEC 61508 dabei explizit als Option genannt und<br />
ist in Bild 1 dargestellt<br />
Die Ausprägung der Aktivitäten im Sicherheitsprozess<br />
hängt <strong>von</strong> den Sicherheitsanforderungen ab, die an die<br />
Sicherheitsfunktion gestellt werden, für deren Ausführung<br />
die zu entwickelnde Software verantwortlich ist.<br />
Je nach Einsatzgebiet müssen die Sicherheitsfunktionen<br />
einem bestimmten Sicherheitslevel (Safety Integrity Level,<br />
SIL) genügen. Für Hardwarebestandteile eines Systems<br />
bedeutet die Konformität zu einem bestimmten<br />
Level dabei primär den Nachweis einer bestimmten Zuverlässigkeit,<br />
während für Software hauptsächlich die<br />
zu verwendenden Methoden und Techniken für die Ent-<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
61
Hauptbeitrag | aUtomation 2012<br />
wicklungsaktivitäten vom SIL abhängen. Der Standard<br />
macht dabei für jede Aktivität Empfehlungen bezüglich<br />
der Verwendbarkeit für die verschiedenen Sicherheitslevel.<br />
In einem Sicherheitsaudit der Software muss vor<br />
der Marktreife nachgewiesen werden, dass die stark<br />
empfohlenen (highly recommended) Techniken verwendet<br />
und die nicht empfohlenen Techniken gemieden<br />
wurden. Der vorgestellte Prozess orientiert sich an den<br />
Empfehlungen für das zweithöchste Sicherheitslevel<br />
SIL 3. Die im folgenden Abschnitt beschriebene UML-<br />
Erweiterung bietet dem Entwickler umfassende Unterstützung<br />
für die Einhaltung des Sicherheitsstandards in<br />
Hinblick auf die Entwicklungsaktivitäten. Die Verwendung<br />
<strong>von</strong> modellbasierten Methoden an sich deckt dabei<br />
bereits Anforderungen aus IEC 61508 ab.<br />
2. Erweiterung der UML<br />
Die UML verfügt, wie eingangs beschrieben, nur über<br />
unzureichende Notationselemente in Hinblick auf Sicherheitsaspekte.<br />
Beispielsweise ist es nicht möglich,<br />
bereits zertifizierte Softwarekomponenten zu kennzeichnen,<br />
oder explizit darzustellen, welche Modellelemente<br />
sicherheitskritisch sind. Dieser Mangel führt zu einer<br />
Auslagerung <strong>von</strong> Sicherheitsaspekten in externe Dokumente,<br />
was den Wartungsaufwand und die Komplexität<br />
der Gesamtbeschreibung erhöht und zudem dem Ansatz<br />
der modellbasierten Softwareentwicklung widerspricht,<br />
Modelle als Schlüsselartefakte zu verwenden. Ferner<br />
haben weiterführende Techniken, wie die modellbasierte<br />
Analyse <strong>von</strong> Softwareänderungen und automatische<br />
Codegenerierung, die Möglichkeit, modellierte Sicherheitsaspekte<br />
auszunutzen und so den Arbeitsaufwand<br />
für Softwareentwickler zu reduzieren.<br />
Aus dieser Motivation heraus wurde <strong>von</strong> uns eine Erweiterung<br />
der UML um Sprachelemente zur Abbildung<br />
<strong>von</strong> IEC 61508 in UML-Modellen entwickelt. Die Erweiterung<br />
nutzt den UML-Profilmechanismus [3], der auf<br />
bestehenden UML-Metamodellen aufsetzt und dadurch<br />
eine problemlose Integration der Erweiterung in bestehende<br />
Modellierungswerkzeuge erlaubt.<br />
Bild 2 zeigt die Vorgehensweise bei der Erstellung des<br />
UML-Profils. Die Sicherheitskonzepte des Standards IEC<br />
61508 wurden zunächst in ein Domain-Model extrahiert,<br />
das als Zwischenbeschreibung vor der Realisierung des<br />
eigentlichen Profils dient. Dieses Vorgehen führt zu präziseren<br />
Ergebnissen als die direkte Ableitung, da sich<br />
die Konzepte des Sicherheitsstandards ohne jegliche<br />
Implementierungsdetails, in diesem Fall also ohne unerwünschte<br />
Seiteneffekte des UML-Profilmechanismus,<br />
ableiten lassen [4]. Bei der anschließenden Ableitung des<br />
Profils aus dem Domain-Model wurde Wert darauf gelegt,<br />
Konzepte wiederzuverwenden, die bereits in den standardisierten<br />
Profilen SysML [6] und Marte (Modeling<br />
and Analysis of Real-Time and Embedded Systems) [5]<br />
realisiert sind, um so die Akzeptanz zu steigern und eine<br />
Einarbeitung in das Profil zu erleichtern.<br />
Das Profil ist in die beiden Teile Software-Development-Activities<br />
und Standard-Specific-Concepts unterteilt,<br />
um die zwei Hauptbereiche <strong>von</strong> IEC 61508 bezüglich<br />
der Softwareentwicklung abzubilden. Der erste Teil<br />
des Profils zielt darauf ab, Prozessbeteiligten ein Rahmenwerk<br />
zur Hand zu geben, das die Empfehlungen und<br />
Anforderungen des Sicherheitsstandards an den Prozess<br />
der Softwareentwicklung abbildet.<br />
Bild 3 zeigt das Grundmodell des Rahmenwerks, das<br />
den Zusammenhang eines zertifizierten Softwaremoduls<br />
(TrustedSWModule) mit dem Prozess zeigt, in dem das<br />
Modul entwickelt wurde. Wie in Abschnitt 1 erläutert,<br />
enthält IEC 61508 detaillierte Anforderungen in Form<br />
<strong>von</strong> empfohlenen Methoden und Techniken für jede Aktivität<br />
dieses Software-Entwicklungsprozesses. Diese<br />
Anforderungen sind im UML-Profil durch die SILActivity<br />
und die damit verbundene SILTechnique dargestellt.<br />
Jeder Technik kann ein Satz <strong>von</strong> Recommendations zugeordnet<br />
werden, die Empfehlungen des Sicherheitsstandards<br />
für verschiedene Sicherheitsstufen darstellen.<br />
Wird eine Empfehlung verletzt, muss dies durch eine<br />
Rationale begründet werden. Zur Überprüfung der Einhaltung<br />
der Empfehlungen aus IEC 61508 verwendet das<br />
UML-Profil formale Constraints der Object-Constraint-<br />
Language [7], mit deren Hilfe eine automatisierte Überprüfung<br />
realisiert werden kann. Analog zur Verwendung<br />
des Profilmechanismus besteht auch hier der Vorteil,<br />
dass weiterführende Ansätze und viele vorhandene Modellierungswerkzeuge<br />
in der Lage sind, OCL Constraints<br />
zu evaluieren.<br />
Das vorgestellte Rahmenwerk wird im Entwicklungsprozess<br />
zu mehreren Zwecken eingesetzt. Durch die<br />
explizite Modellierung <strong>von</strong> verwendeten Methoden und<br />
Techniken und die damit verbundenen Hintergrundinformationen<br />
bezüglich IEC 61508 kann zum einen eine<br />
direkte Rückmeldung der noch offenen Prozessanforderungen<br />
an den Entwickler erfolgen. Dadurch wird<br />
dieser bei der Entwicklung sicherheitskritischer Software<br />
deutlich entlastet. Das Rahmenwerk kann zum<br />
anderen verwendet werden, um Auditoren detaillierte<br />
Einblicke in die Methodik der Softwareentwicklung zu<br />
geben, um so die Ab nahme der Software zu erleichtern.<br />
Beide Facetten tragen zur Integration <strong>von</strong> Sicherheitsinformationen<br />
in Modelle bei und verringern so orthogonale<br />
Dokumentations- und Wartungsarbeit. Der erste<br />
Profilteil ist beispielhaft in der Sicht SIL-Prozessrahmenwerk<br />
in Bild 4 dargestellt.<br />
Der zweite Teil des UML-Profils, die Standard-Specific-Concepts,<br />
enthält Modellierungselemente, die,<br />
wie zuvor beschrieben, in der UML nicht vorhanden,<br />
aber für ein sicherheitskritisches Softwaresystem <strong>von</strong><br />
Bedeutung sind. Durch Ihre Verwendung wird der Modellierungsaufwand<br />
für die Entwickler verringert und<br />
die Informationsdichte der Softwaremodelle deutlich<br />
verbessert. Beispielsweise beinhaltet dieser Profilteil<br />
ein Konzept zur Unterscheidung <strong>von</strong> sicherheitskritischen<br />
und nichtkritischen Modellelementen durch<br />
Stereotypen sowie zur Modellierung eines bereits zertifizierten<br />
Teils der Software zur Unterstützung der<br />
Wiederverwendung.<br />
Die Anwendung des UML-Profils im beschriebenen<br />
Software-Entwicklungsprozess wird im folgenden<br />
Abschnitt erläutert. Weitere Aspekte des Profils finden<br />
sich in [2].<br />
62<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
3. Modellbasierter Entwicklungsprozess<br />
Dieser Abschnitt beschreibt die modellbasierte Umsetzung<br />
der Entwicklungsaktivitäten des in Abschnitt 1<br />
beschriebenen V-Modell-Tailorings. Bild 4 zeigt eine<br />
Übersicht der in den einzelnen Entwicklungsaktivitäten<br />
verwendeten Modelle. Besonderes Augenmerk bei der<br />
Definition des modellbasierten Prozesses lag auf der Modellierung<br />
<strong>von</strong> Sicherheitsaspekten durch das zuvor<br />
eingeführte UML-Profil sowie der Beherrschung <strong>von</strong><br />
Komplexität durch Abstraktion und Sichten. In Bild 4<br />
sind zur besseren Veranschaulichung die Abstraktionsbeziehungen<br />
durch durchgezogene Pfeile sowie die Sichten<br />
durch vertikale Unterteilungen gekennzeichnet.<br />
Weiterhin legt die Norm IEC 61508 besonderen Wert auf<br />
eine durchgehende Nachverfolgbarkeit (Traceability) der<br />
Anforderungen auf spätere Entwicklungsartefakte und<br />
umgekehrt. Diese Nachverfolgbarkeit kann entweder explizit<br />
durch Tracelinks in den Modellen oder implizit<br />
durch die Bezeichner der Modellelemente realisiert werden.<br />
Bild 4 stellt die Traceability-Beziehungen exemplarisch<br />
durch gestrichelte Pfeile dar. Im Folgenden werden<br />
die Prozessaktivitäten jeweils als Querschnitt über alle<br />
drei Ebenen beschrieben.<br />
Der Entwicklungsprozess beginnt mit der Spezifikation<br />
der Anforderungen an die zu erstellende Software.<br />
Dieser Anforderungsbeschreibung wird in der Softwareentwicklung<br />
nach IEC 61508 eine essenzielle Bedeutung<br />
zugewiesen. Um <strong>von</strong> Beginn an eine lückenlose<br />
Traceability zu gewährleisten, erweitert der hier vorgestellte<br />
Prozess das SysML-Anforderungsdiagramm um<br />
die Möglichkeit, Sicherheitsanforderungen (SR) zu modellieren.<br />
So lassen sich Sicherheitsanforderungen direkt<br />
oder aus einer anderen Quelle, wie einem Anforderungsmanagement-Werkzeug,<br />
in die modellbasierte<br />
Darstellung integrieren.<br />
Die funktionalen Anforderungen (FR) werden mithilfe<br />
<strong>von</strong> Use-Cases beschrieben und deren Ablauf mithilfe<br />
<strong>von</strong> Sequenzdiagrammen detailliert. Die Modellierung<br />
<strong>von</strong> nichtfunktionalen Anforderungen (NFR) hängt vom<br />
Typ der jeweiligen Anforderung ab. Die im Hinblick auf<br />
Messwerte besonders relevanten Anforderungen an Performanz<br />
oder Antwortzeiten können beispielsweise in<br />
Sequenzdiagramme eingebracht werden, Anforderungen<br />
wie Energiebedarf werden aus dem SysML-Anforderungsdiagramm<br />
heraus mit korrespondierenden Architekturelementen<br />
verknüpft. Zudem leiten sich die im<br />
UML-Profil enthaltenen Techniken und Maßnahmen<br />
meist aus Sicherheitsanforderungen ab. Bestimmte sichere<br />
Übertragungskonzepte für Messdaten werden beispielsweise<br />
in den Sicherheitsanforderungen verlangt<br />
und auch in der Architektur umgesetzt. Dies kann durch<br />
das UML-Profil explizit dargestellt werden und spiegelt<br />
sich in Bild 4 durch die Tracelinks zwischen Sicherheitsanforderungen,<br />
Techniken und Deployment-Diagramm<br />
wider. Bereits bei der Definition <strong>von</strong> Anforderungen dienen<br />
also die oben beschriebenen drei Sichten SIL-Prozessrahmenwerk,<br />
Struktur und Verhalten sowie die Abstraktionsmöglichkeiten<br />
des Anforderungsdiagramms<br />
und die Verfeinerung <strong>von</strong> Use-Cases durch Sequenzdiagramme<br />
der Beherrschung der Komplexität. Die Verbindung<br />
zwischen Techniken der Sicherheitsprozesssicht<br />
und Modellelementen der anderen Sichten, die hier für<br />
Anforderungen beschrieben wurde, ist zur Realisierung<br />
des Rahmenwerks in allen Aktivitäten des Entwicklungsprozesses<br />
vorhanden.<br />
Ausgehend <strong>von</strong> den Anforderungen wird eine Darstellung<br />
der Softwarearchitektur auf hoher Abstraktionsebe-<br />
BILD 1: Vorgehensbausteine für die Softwareentwicklung<br />
aus IEC 61508 [1]<br />
BILD 2: Entwicklung des UML-Profils<br />
für IEC 61508<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
63
Hauptbeitrag | aUtomation 2012<br />
ne entwickelt. Die Struktursicht beinhaltet dabei eine<br />
funktionale Unterteilung der Software in <strong>Komponenten</strong><br />
eines UML-<strong>Komponenten</strong>diagramms. In Hinblick auf<br />
IEC 61508 sind dabei insbesondere die durch das UML-<br />
Profil ermöglichte Unterteilung in sicherheitskritische<br />
und nichtkritische <strong>Komponenten</strong> sowie die Darstellung<br />
vorhandener Trennmechanismen zwischen diesen <strong>Komponenten</strong><br />
auf hoher Abstraktionsebene relevant.<br />
Die spezifizierten <strong>Komponenten</strong> werden anschließend<br />
mithilfe des UML-Deployment-Diagramms den<br />
jeweils ausführenden Knoten zugeordnet. Um das Verhalten<br />
des Systems auf der Abstraktionsebene der Architektur<br />
zu beschreiben, verwendet unser Prozess ein<br />
abstraktes Aktivitätsdiagramm, in dem das Zusammenwirken<br />
der verschiedenen <strong>Komponenten</strong> dargestellt ist.<br />
In diesem Stadium der Entwicklung ist das Verhalten<br />
dabei auf abstrakte Funktionsbeschreibungen reduziert.<br />
Die Sicht des Sicherheitsprozesses beinhaltet in<br />
dieser Entwicklungsaktivität die bereits beschriebenen<br />
Techniken. Im Deployment-Diagramm wäre eine solche<br />
Maßnahme beispielsweise die physikalische Trennung<br />
<strong>von</strong> sicherheitskritischen und nichtkritischen <strong>Komponenten</strong><br />
auf unterschiedlichen Knoten. Hierbei können<br />
Konzepte des Marte-Profils verwendet werden, die es<br />
ermöglichen, Hardwaredetails sowie Speicherpartitionen<br />
zu beschreiben.<br />
Nach der Spezifikation einer Softwarearchitektur erfolgt<br />
in der Prozessaktivität Software-System-Design<br />
deren Dekomposition in eine detailliertere Form. Die<br />
<strong>Komponenten</strong> der Software werden in diesem Schritt<br />
in funktionale Subkomponenten aufgespalten. Ein Beispiel<br />
für eine solche Dekomposition wäre die Unterteilung<br />
einer Sensorsoftware in die Subkomponenten Datenverarbeitung<br />
und Datenübertragung. Dazu werden<br />
weiterhin UML-<strong>Komponenten</strong>diagramme verwendet,<br />
die die Verfeinerung durch Kompositionsbeziehungen<br />
zwischen einer Komponente und deren Subkomponenten<br />
darstellen.<br />
Alle beschriebenen Elemente bis auf Klassenebene<br />
hinab können in der Sicht des Sicherheitsprozesses als<br />
bereits zertifiziert gekennzeichnet und die zugehörige<br />
Zertifizierung detailliert mit Profilmodellelementen beschrieben<br />
werden. Im Software-System-Design sind diesbezüglich<br />
besonders die Schnittstellen zwischen sicherheitskritischen<br />
und nichtkritischen Subkomponenten<br />
interessant. Hierfür bietet das zuvor beschriebene UML-<br />
Profil die Möglichkeit, sicherheitsrelevante Schnittstellen<br />
explizit zu kennzeichnen.<br />
Die Verhaltenssicht besteht in dieser Entwicklungsphase<br />
aus der Verfeinerung der Aktivitätsdiagramme aus<br />
der Architektur. Jede Komponente ist dabei wie in Bild 4<br />
skizziert durch Aktivitätsdiagramme spezifiziert, die<br />
das Zusammenwirken der Subkomponenten innerhalb<br />
der Komponente zeigen. Dabei sind die Aktivitäten der<br />
Diagramme bereits auf Funktionsebene detailliert, zeigen<br />
also die eigentlichen Funktionen der Subkomponenten<br />
und deren Aufrufreihenfolge. Bei stark ereignisbasierten<br />
Systemen kann es auf dieser Abstraktionsebene<br />
sinnvoll sein, die Funktionen der Subkomponenten in<br />
UML-Zustandsdiagrammen abzubilden, was daher in<br />
diesem Prozess alternativ vorgesehen ist.<br />
Die tiefste konzeptuelle Verfeinerungsebene des V-<br />
Modell-Tailorings wird durch das Moduldesign realisiert.<br />
Dabei werden in der strukturellen Sicht UML-<br />
Klassen aus den Subkomponenten auf tiefster Ebene<br />
abgeleitet, die eine vollständige Spezifikation der später<br />
zu implementierenden Funktionssignaturen und Variablendeklarationen<br />
enthalten. Da dieser Prozess auf eingebettete<br />
Systeme abzielt, die größtenteils nicht objektorientiert<br />
realisiert sind, ist die Klassendefinition nicht<br />
im objektorientierten Sinne, sondern als Repräsentation<br />
einer physikalischen Entität zu betrachten. Eine Klasse<br />
ist bei Verwendung der Programmiersprache C beispielsweise<br />
durch eine C-Datei und eine korrespondierende<br />
Headerdatei repräsentiert. Die Beschreibung des Verhaltens<br />
dieser Klassen wird durch Aktivitätsdiagramme<br />
realisiert, die jeweils eine Funktion der Klassen in ihrem<br />
Ablauf spezifizieren.<br />
Die Modulbeschreibung liefert die detaillierte Vorlage<br />
für die Implementierung des Softwaresystems. Die eigentliche<br />
Umsetzung dieser Vorlage kann entweder<br />
durch automatisierte Codegenerierung bei ausreichend<br />
detailliert modellierten Aktivitätsdiagrammen, durch<br />
manuelles Erzeugen des Quellcodes oder durch Wiederverwendung<br />
erfolgen. Die Wiederverwendung basiert<br />
dabei auf der zuvor beschriebenen expliziten Modellierung<br />
<strong>von</strong> zertifizierten Modellelementen und deren Traceability<br />
zu Codefragmenten in einer Code-Datenbank.<br />
Zusätzlich besteht durch das Rahmenwerk die Möglichkeit,<br />
Techniken aus IEC 61508 mit Codefragmenten zu<br />
verknüpfen und so beispielsweise zertifizierten Code für<br />
die sichere Kommunikation bereitzustellen. Auf diese<br />
Weise können modellbasierte Spezifikation sowie Quellcode<br />
ohne redundanten Dokumentationsaufwand wiederverwendet<br />
werden.<br />
Die Validierungs- und Verifikationsaktivitäten des V-<br />
Modells profitieren ebenfalls in hohem Maße <strong>von</strong> dem<br />
beschriebenen modellbasierten Vorgehen. Die Modelle<br />
der jeweiligen Entwicklungsphasen dienen dabei jeweils<br />
als Grundlage zur Ableitung und Durchführung <strong>von</strong><br />
Testfällen. Der unmittelbar auf die Implementierungsphase<br />
folgende Modultest profitiert beispielsweise <strong>von</strong><br />
den detaillierten Aktivitätsdiagrammen, die unter anderem<br />
zur Bestimmung der Testabdeckung verwendet werden<br />
können.<br />
Beim Integrationstest auf Modulebene sind hinsichtlich<br />
des Testens insbesondere die Schnittstellenbeschreibungen<br />
der Subkomponenten relevant. Durch die<br />
explizite Modellierung <strong>von</strong> sicherheitskritischen<br />
Schnittstellen unterstützt unser Prozess dabei Betrachtungen<br />
der Fehlerfortpflanzung zwischen sicherheitskritischen<br />
und nichtkritischen Subkomponenten. Im Integrationstest<br />
auf Architekturebene können die <strong>von</strong> unserem<br />
Prozess geforderte modellbasierte Beschreibung des<br />
Deployments und die durch das Rahmenwerk bereitgestellten<br />
Kommunikationskonzepte zur Ableitung <strong>von</strong><br />
Integrationstests dienen. Die abschließende Validierung<br />
des Softwaresystems erfolgt anhand der SysML-Anforderungen<br />
und Testfallszenarien, die sich aus den Detailszenarien<br />
der Use Cases ableiten lassen.<br />
Das in Abschnitt 2 beschriebene Rahmenwerk unterstützt<br />
zudem aktiv die Zertifizierung des Softwaresys-<br />
64<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
ild 3: Grundmodell des Rahmenwerks zur Prozessunterstützung<br />
bild 4: Modellbasierter Entwicklungsprozess<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
65
Hauptbeitrag | aUtomation 2012<br />
tems, indem die Sicht SIL-Sicherheitsprozess eine auswert-<br />
und belastbare Übersicht der in den jeweiligen<br />
Entwicklungsaktivitäten verwendeten Methoden und<br />
Techniken bietet. So lässt sich die standardkonforme<br />
Entwicklung der einzelnen Softwareteile zeigen.<br />
Fazit und Ausblick<br />
Dieser Beitrag definiert einen Prozess zur modellbasierten<br />
Softwareentwicklung in Anlehnung an ein im Sicherheitsstandard<br />
IEC 61508 definiertes V-Modell-<br />
Tailoring. Der Prozess verwendet zur Darstellung funktionaler<br />
Sicherheit eine hierzu entwickelte UML-Erweiterung,<br />
die die Modellierung <strong>von</strong> Sicherheitsaspekten<br />
auf Prozess- und Produktebene ermöglicht. Das mit unserem<br />
UML-Profil eingeführte Rahmenwerk unterstützt<br />
dabei prozessbegleitend den Nachweis normkonformer<br />
Entwicklung sowie die effiziente Modellierung spezieller<br />
Sicherheitskonzepte.<br />
Zukünftige Tätigkeiten enthalten die Evaluierung des<br />
Prozesses anhand <strong>von</strong> Fallstudien und realen Softwareprojekten<br />
sowie – wie im Overall-Safety-Lifecycle der IEC<br />
61508 vorgesehen – die ständige Prozessverbesserung im<br />
Anschluss an abgeschlossene Entwicklungsprojekte.<br />
Manuskripteingang<br />
09.05.2012<br />
Im Peer-Review-Verfahren begutachtet<br />
Autoren<br />
M.Sc. Dirk KuSCHnerus (geb. 1984) arbeitet seit<br />
2010 als Entwicklungsingenieur bei Krohne<br />
Messtechnik und als wissenschaftlicher Mitarbeiter<br />
an der Ruhr-Universität Bochum. Sein Forschungsschwerpunkt<br />
ist die modellbasierte<br />
Software-entwicklung für sicherheitskritische<br />
eingebettete Systeme.<br />
Krohne Messtechnik GmbH,<br />
Ludwig-Krohne-Straße 5, D-47058 Duisburg,<br />
Tel. +49 (0) 203 301 45 31,<br />
E-Mail: d.kuschnerus@krohne.com<br />
Dr.-Ing. MiCHAEL Gerding (geb. 1975) arbeitet seit<br />
2005 bei Krohne Messtechnik. Er war seit 2008 für<br />
die Forschung der Krohne-Gruppe verantwortlich<br />
und leitet heute die zentrale Konverter-Elek tronik-<br />
Entwicklung mit Schwerpunkten im Bereich<br />
energieeffizienter, wiederverwendbarer Embedded-<br />
Elektronik-<strong>Komponenten</strong>.<br />
Krohne Messtechnik GmbH,<br />
Ludwig-Krohne-Straße 5, D-47058 Duisburg,<br />
Tel. +49 (0) 203 301 41 52,<br />
E-Mail: m.gerding@krohne.com<br />
Referenzen<br />
[1] IEC 61508-3: Functional safety of electrical/electronic/<br />
programmable electronic safety-related systems.<br />
Part 3: Software requirements, 2010<br />
[2] Kuschnerus, D., Bruns, F., Bilgic, A., Musch, T.: A UML<br />
Profile for the Development of IEC 61508 Compliant<br />
Embedded Software. In: Online-Proceeedings<br />
Embedded Real-Time Software and Systems 2012<br />
(ERTS² 2012), 2012 (http://www.erts2012.org/<br />
Site/0P2RUC89/3C-4.pdf)<br />
[3] Fuentes-Fernandez, L., Vallecillo-Moreno, A.:<br />
An Introduction to UML Profiles. The European Journal<br />
for the Informatics Professional 5(2), April 2004<br />
[4] Selic, B.: A systematic approach to domain-specific<br />
language design using UML. In: Proceedings 10th IEEE<br />
International Symposium on Object and Component-<br />
Oriented Real-Time Distributed Computing (ISORC ’07),<br />
S. 2–9. IEEE CS, Washington DC 2007<br />
[5] object Management Group: UML Profile for MartE:<br />
Modeling and Analysis of Real-Time Embedded<br />
Systems, Version 1.0, 2009<br />
[6] object Management Group: OMG Systems Modeling<br />
Language, Version 1.2, 2010<br />
[7] object Management Group: Object Constraint<br />
Language, Version 2.2, 2010<br />
Dr.-Ing. Attila Bilgic (geb. 1968) ist Managing<br />
Director des Krohne-Stammsitzes in Duisburg<br />
und leitet als Chief Technology Officer die<br />
Forschungs- und Entwicklungstätigkeiten<br />
der Krohne-Gruppe. Seine Forschungsschwerpunkte<br />
reichen <strong>von</strong> grundlegenden physikalischen<br />
Messprinzipien bis zu eingebetteten<br />
Systemarchitekturen.<br />
Krohne Messtechnik GmbH,<br />
Ludwig-Krohne-Straße 5, D-47058 Duisburg,<br />
Tel. +41 (0) 203 301 45 53,<br />
E-Mail: a.bilgic@krohne.com<br />
Prof. Dr.-Ing. THOMAS MuSCH (geb. 1968) leitet seit<br />
2008 den Lehrstuhl für Elektronische Schaltungstechnik<br />
an der Ruhr-Universität Bochum. Seine<br />
Forschungsschwerpunkte sind rausch arme<br />
fraktionale Synthesegeneratoren, Radar systeme<br />
für Mikrowellen-Entfernungsmessung sowie die<br />
industrielle Anwendung <strong>von</strong> Mikrowellen.<br />
Ruhr-Universität Bochum,<br />
Lehrstuhl für Elektronische Schaltungstechnik,<br />
Universitätsstraße 150, D-44780 Bochum,<br />
Tel. +49 (0) 234 322 71 15,<br />
E-Mail: thomas.musch@rub.de<br />
66<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
BUS<br />
Sprechstunde<br />
BUS<br />
2. Feldbus-Sprechstunde<br />
Feldbus in der Prozessindustrie<br />
27. + 28.09.2012, Mannheim, Pepperl+Fuchs GmbH<br />
www.feldbus-sprechstunde.de<br />
Programm<br />
Moderation: Jürgen George,<br />
Pepperl+Fuchs GmbH<br />
Wann und Wo?<br />
Systemplanung: Auswahl der Geräte und <strong>Komponenten</strong><br />
Systemplanung: Feldbusinfrastruktur<br />
Systemplanung: Einsatz <strong>von</strong> Planungstools<br />
Systemplanung: Explosionsschutz und<br />
funktionale Sicherheit<br />
Inbetriebnahme: Hardware-Installation und<br />
-Inbetriebnahme<br />
Inbetriebnahme: Implementierung<br />
Inbetriebnahme: Systematische Fehlersuche<br />
Referenten<br />
Ronny Becker, Prüflabor MSR u. Analysentechnik,<br />
BIS Prozesstechnik GmbH<br />
Dr. Andreas Hildebrandt, Thomas Klatt,<br />
Thomas Westers, Pepperl+Fuchs GmbH<br />
Dr. Niels Kiupel, Degussa GmbH<br />
Sven Seintsch, Prüflabor MSR u. Analysentechnik,<br />
BIS Prozesstechnik GmbH<br />
Termin<br />
Donnerstag, 27.09.2012<br />
Veranstaltung (11:30 – 17:30 Uhr)<br />
„Get-Together“ mit Abendessen (ab 18:30 Uhr)<br />
Freitag, 28.09.2012<br />
Veranstaltung (9:00 – 15:00 Uhr)<br />
Ort<br />
Mannheim, Pepperl+Fuchs GmbH<br />
Thema<br />
Antworten zur Planung und<br />
Inbetriebnahme <strong>von</strong> Feldbussen<br />
Teilnahmegebühr<br />
<strong>atp</strong> <strong>edition</strong>-Abonnenten 540 € zzgl. MwSt<br />
Firmenempfehlung 590 € zzgl. MwSt<br />
reguläre Teilnahmegebühr 690 € zzgl. MwSt<br />
Im Preis enthalten sind die Tagungsunterlagen<br />
sowie das Catering (Kaffee, 2x Mittagsimbiss,<br />
„Get-Together“ mit Abendessen).<br />
Veranstalter<br />
Fragen Sie!<br />
Die Feldbus-Sprechstunde gibt Ihnen ausreichend Gelegenheit, Ihre<br />
individuellen Fragen zu stellen und offen mit den praxiserfahrenen<br />
Referenten zu diskutieren.<br />
Stellen Sie Ihre Fragen rechtzeitig unter<br />
www.feldbus-sprechstunde.de<br />
Weitere Informationen und Online-Anmeldung unter<br />
www.feldbus-sprechstunde.de<br />
Fax-Anmeldung: +49 (0) 89 45051-323 oder Online-Anmeldung: www.feldbus-sprechstunde.de<br />
Ich habe die <strong>atp</strong> <strong>edition</strong> abonniert<br />
Ich komme auf Empfehlung <strong>von</strong> Firma: .....................................................................................................................................................................<br />
Vorname Nachname<br />
Telefon<br />
Telefax<br />
Firma/Institution<br />
E-Mail<br />
Straße/Postfach<br />
Land, PLZ, Ort<br />
Hausnummer<br />
✘<br />
Ort, Datum, Unterschrift<br />
Ihre freiwilligen Angaben werden zusammen mit den für die Vertragsabwicklung erforderlichen Daten <strong>von</strong> uns und der Unternehmensgruppe, unseren Dienstleistern sowie anderen<br />
ausgewählten Unternehmen verarbeitet und genutzt, um Sie über Produkte und Dienstleistungen zu informieren.<br />
Wenn Sie dies nicht mehr wünschen, schreiben Sie bitte an: Oldenbourg Industrieverlag, Rosenheimer Str. 145, D-81671 München
hauptbeitrag<br />
Automatische<br />
Wertebereichsanalyse<br />
Formale Verifikation für SPS-Programme<br />
Der Wertebereich ist die Menge aller Werte, die eine Variable während der Programmausführung<br />
tatsächlich annehmen kann. Der Beitrag stellt eine automatische Bestimmung<br />
der Wertebereiche <strong>von</strong> Variablen in SPS-Programmen vor. Mit dieser Information lassen<br />
sich Fehler schnell erkennen beziehungsweise ausschließen, ohne dass das korrekte Programmverhalten<br />
formal spezifiziert werden muss. Die verwendeten Techniken benötigen<br />
kein Modell des Programmverhaltens, sondern verarbeiten direkt den Programmcode. Der<br />
Ansatz ist im Werkzeug Arcade.PLC implementiert und wird an einer industriellen Fallstudie<br />
illustriert.<br />
SCHLAGWÖRTER SPS-Programmanalyse / Formale Verifikation / PLCopen<br />
Automatic Value-Set Analysis –<br />
Formal Verification of PLC Programs<br />
We present an approach to automatically determine the value sets of variables in PLC<br />
programs. The value set includes all values that a variable can take during all possible<br />
program executions. This information makes it possible to detect or exclude errors in PLC<br />
code without having to specify the correct behaviour formally. The verification techniques<br />
work directly on the program code so they do not require the program to have been translated<br />
into a formal model. The approach is implemented in the Arcade.PLC tool. An industrial<br />
case study is included.<br />
KEYWORDS PLC program analysis / formal verification / PLCopen<br />
68<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
Sebastian BiALLAS, Stefan KOWALEWSKi, RWTH Aachen<br />
Bastian SCHLiCH, ABB Forschungszentrum Deutschland<br />
Speicherprogrammierbare Steuerungen (SPSen)<br />
werden oftmals in sicherheitskritischen Umgebungen<br />
eingesetzt, in denen ein Fehlverhalten<br />
des Programms schwerwiegende Folgen<br />
für Mensch oder Umwelt haben kann. Eine<br />
formale Überprüfung der Programme ist in solchen Fällen<br />
sinnvoll beziehungsweise nach IEC 61508 [1] empfohlen.<br />
Die meisten Ansätze zur formalen Verifikation<br />
<strong>von</strong> SPS-Code erfordern aber die Übertragung des Programmcodes<br />
in eine formale Darstellung als Eingabe in<br />
das entsprechende Werkzeug (zum Beispiel durch händische<br />
Modellierung) und die formale Spezifikation des<br />
korrekten Verhaltens (beispielsweise in einer geeigneten<br />
Logik). Die Autoren stellen ein Verfahren vor, das<br />
ohne diesen Aufwand funktioniert und trotzdem aussagekräftige<br />
Informationen über das Programmverhalten<br />
liefert, aus denen der Entwickler dann Rückschlüsse<br />
auf mögliche Fehler ziehen kann. Der Aufsatz ist eine<br />
erweiterte Fassung des Beitrags [3] zum Automation-<br />
Kongress 2012.<br />
Die <strong>von</strong> dem Analyseverfahren gelieferten Informationen<br />
sind die Wertebereiche der Variablen eines gegebenen<br />
SPS-Programms. Der Wertebereich ist die Menge<br />
aller Werte, die eine Variable in allen möglichen Programmabläufen<br />
annehmen kann. Wir stellen ein Verfahren<br />
vor, das für SPS-Programme in den Sprachen Anweisungsliste<br />
(IEC 61131 oder Siemens) und Strukturierter<br />
Text die Wertebereiche der Variablen mit den Typen<br />
Bool, Int und Enum ermittelt. Das Verfahren ist neben<br />
anderen formalen Analysetechniken für SPS-Programme<br />
in dem an der RWTH Aachen entwickelten Werkzeug<br />
Arcade.PLC implementiert.<br />
Die Ergebnisse der Wertebereichsanalyse unterstützen<br />
den Entwickler in mehrerer Hinsicht: Er sieht direkt, ob<br />
die Werte der Ausgänge innerhalb der erlaubten Spezifikation<br />
liegen. Kann ein Ausgang beispielsweise negative<br />
Werte annehmen, obwohl dies eigentlich nicht erlaubt<br />
ist, so ist dies unmittelbar zu erkennen. Zum anderen<br />
können in den ermittelten Wertebereichen unerwartete<br />
Werte stehen. Es könnte zum Beispiel ein<br />
Diagnosecode ermittelt werden, der in der Spezifikation<br />
nicht vorgesehen ist. Dies kann passieren, wenn Diagnosecodes<br />
falsch berechnet werden oder sie in der falschen<br />
Kodierung (binär, dezimal, hexadezimal) im<br />
Quelltext angegeben wurden. Die Wertebereichsanalyse<br />
erlaubt es, viele dieser Fehler direkt während der Entwicklungszeit<br />
zu erkennen.<br />
1. Verwandte Arbeiten<br />
Die erste Arbeit zur formalen Verifikation <strong>von</strong> SPS-Programmen<br />
geht zurück auf Moon [4]. Wie in späteren Ansätzen<br />
<strong>von</strong> Canet et al. [5], Mertke und Frey [6] und Pavlovic<br />
et al. [7] werden hier SPS-Programme in die Eingabe-Sprache<br />
eines Model-Checkers beziehungsweise in<br />
Petri-Netze übersetzt. Anschließend kann dann überprüft<br />
werden, ob die Programme einer Spezifikation genügen.<br />
Einen Ansatz zur formalen Verifikation beschreibt<br />
auch unsere Vorarbeit [8], die allerdings ohne<br />
den Übersetzungsschritt auskommt und das Modell direkt<br />
mit einem Simulator erzeugt.<br />
Im Gegensatz zu diesen Ansätzen, die überprüfen, ob<br />
das Programm eine (gegebene) Spezifikation einhält, beschreiben<br />
Bornot et al. [9] sowie Huuck [10] ein Verfahren<br />
zur statischen Analyse <strong>von</strong> Programmen in Anweisungsliste.<br />
Sie benutzen abstrakte Interpretation, um die Wertebereiche<br />
aller Variablen in jeder Zeile des Programmes<br />
zu ermitteln. Unser Ansatz hier folgt im Grundsatz derselben<br />
Idee, jedoch betrachten wir die Programmzeilen<br />
nicht einzeln, sondern werten nur die zwischen den<br />
Zyklen erreichbaren Zustände aus. Wir ermitteln so nur<br />
die tatsächlichen nach außen weitergeleiteten Werte und<br />
blenden innerhalb der Zyklen anfallende temporäre Werte<br />
aus. Wir unterstützen außerdem zusätzlich die Sprache<br />
Strukturierter Text.<br />
2. Wertebereichsanalyse<br />
Die Kernidee der Wertebereichsanalyse ist es, sämtliche<br />
einzelnen Werte, die eine Variable während der Pro-<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
69
Hauptbeitrag | Automation 2012<br />
grammausführung annehmen kann, zusammenzufassen<br />
und dem Benutzer zu präsentieren.<br />
2.1 Formales Modell<br />
Die Wertebereichsanalyse operiert auf einem Modell, das<br />
automatisch aus dem Programm erstellt wird. Dieses<br />
Modell repräsentiert den Zustandsraum des SPS-Programms.<br />
Jeder Zustand ist ein Tripel bestehend aus den<br />
Werten der Eingabevariablen, der Ausgabevariablen und<br />
der vom Programm intern benutzten Variablen (Merkern),<br />
die ihren Wert beim Zykluswechsel behalten. Eine<br />
Transition zwischen zwei Zuständen S1 und S2 wird in<br />
diesem Modell angenommen, wenn S2 in einem Zyklus<br />
<strong>von</strong> S1 erreichbar ist.<br />
Zur automatischen Erstellung des Modells nutzt Arcade.PLC<br />
einen eingebauten Simulator. Ausgehend vom<br />
Initialzustand des Programms werden sämtliche möglichen<br />
Programmverläufe simuliert. Dies geschieht, indem<br />
für jeden neuen Zustand S alle Werte des Wertebereiches<br />
aller Eingangsvariablen aufgezählt werden, und der Simulator<br />
einen Zyklus des Programms durchläuft. Alle<br />
sich daraus ergebenden Zustände sind dann die Folgezustände<br />
<strong>von</strong> S.<br />
Zwar lassen sich so theoretisch die Zustandsräume<br />
beliebiger Programme erstellen, jedoch ist dieser Ansatz<br />
für reale Programme nicht praktikabel: Für einen Eingang<br />
vom Typ Dint (Definitionsbereich: 0..2 32 -1) müssen<br />
bei diesem Ansatz für jeden Zustand über 4 Milliarden<br />
Nachfolger erstellt werden. Um diesem, auch als Zustands-Explosion<br />
bekannten Problem zu begegnen, fassen<br />
wir Zustände, die zu gleichem oder ähnlichen Programmverhalten<br />
führen, in Makrozuständen zusammen,<br />
das heißt wir führen eine Abstraktion durch. Das eingesetzte<br />
Abstraktionsverfahren wurde bereits in früheren<br />
Arbeiten beschrieben [12] und verwendet eine Verfeinerung<br />
der relevanten Wertebereiche. In dieser Arbeit benutzen<br />
wir diese Technik zum Zusammenfassen der<br />
einzelnen Variablenwerte.<br />
2.2 Abstraktion<br />
Die Abstraktion des Zustandsraumes erfolgt mit verschiedenen<br />
abstrakten Datentypen (im folgenden Domänen<br />
genannt), die sich zur unterschiedlichen Darstellung<br />
<strong>von</strong> Makrozuständen eignen. Wir nutzen zur kompakten<br />
und effizienten Speicherung <strong>von</strong> Wertebereichen verschiedene<br />
Domänen, welche unterschiedliche Genauigkeit<br />
in Abhängigkeit der auf ihnen durchgeführten Operationen<br />
erlauben. Durch Kombination der Domänen<br />
lassen sich so auch unterschiedliche Programmverläufe<br />
und -operationen präzise darstellen. Die implementierten<br />
Domänen werden nun im Einzelnen vorgestellt.<br />
Intervalle werden als Tupel [min, max] gespeichert.<br />
Lineare mathematische Operationen und Vergleiche<br />
lassen sich so einfach als Operationen auf den Intervallgrenzen<br />
implementieren. Multiplikationen führen jedoch<br />
zu einem Präzisionsverlust: Die Multiplikation des<br />
Intervalls [5, 7] mit 2 resultiert beispielsweise im Intervall<br />
[10, 14], welches die Werte 11 und 13 enthält, die<br />
keine Vielfachen <strong>von</strong> 2 sind. Nicht-lineare Operationen<br />
(wie beispielsweise ein bitweises Exklusives-Oder) führen<br />
in der Regel sogar dazu, dass die Intervalle den gesamten<br />
Definitionsbereich der Variable umfassen müssen,<br />
weil es nicht möglich ist, solche Operationen auf<br />
die Intervallgrenzen zurückzuführen. Auch arithmetische<br />
Überläufe können dazu führen, dass Intervalle<br />
aufgeteilt werden.<br />
Bit-Mengen stellen das Programmverhalten <strong>von</strong> Booleschen<br />
Verknüpfungen dar. In diesen Bit-Mengen wird für<br />
jedes einzelne Bit einer Variablen gespeichert, ob es 0, 1<br />
oder unbekannt (gekennzeichnet durch *) ist. Die Implementierung<br />
der Booleschen Funktionen geschieht dann<br />
bitweise: Zum Beispiel ist eine Oder-Verknüpfung eines<br />
gesetzten Bits mit einem unbekannten Bit wieder ein<br />
gesetztes Bit. Bei arithmetischen Verknüpfungen hingegen<br />
wirkt sich eine Operation mit einem unbekannten<br />
Bit auf alle Bits im Ergebnis aus, sodass die Anzahl der<br />
unbekannten Bits anwächst. Zum Beispiel gilt für die<br />
bitweise Und-Verknüpfung (1,0,1,*) & (*,1,1,0) = (*,0,1,0)<br />
wohingegen für die arithmetische Addition (1,0,1,*) +<br />
(0,0,0,1) = (1,*,*,*) gilt.<br />
k-Mengen sind Mengen, die maximal k verschiedene<br />
diskrete Werte speichern. Sobald es nötig ist, mehr als k<br />
Werte zu speichern, wird eine k-Menge auf den gesamten<br />
Definitionsbereich der Variable gesetzt. Dies ist nötig, da<br />
die Handhabung der k-Mengen ab einer gewissen Größe<br />
<strong>von</strong> k impraktikabel wird, weil alle Werte einzeln gespeichert<br />
und alle Programm-Operationen mit allen k<br />
Werten durchgeführt werden müssen. Die k-Mengen eignen<br />
sich besonders gut zur präzisen Speicherung <strong>von</strong><br />
Wertebereichen <strong>von</strong> Enum-Typen sowie Status- und Diagnose-Variablen.<br />
Unserer Erfahrung nach reicht dabei<br />
ein Wert <strong>von</strong> k = 50 für die meisten Anwendungen aus.<br />
Während der Simulation werden alle Rechenoperationen<br />
auf allen Domänen parallel ausgeführt. Wir erlauben<br />
es auch, dass zwischen den Domänen Informationen<br />
ausgetauscht werden, wenn eine Domäne präzisere Informationen<br />
als die anderen enthält. Sind zum Beispiel<br />
am Ende des Zyklus in der Bit-Menge alle Bits unbekannt,<br />
aber in der Intervall-Domäne steht [0, 3], so können<br />
alle Bits der Bit-Menge bis auf die unteren beiden auf<br />
0 gesetzt werden.<br />
2.3 Analyse der Wertebereiche<br />
Während der Zustandsraum erstellt wird, läuft gleichzeitig<br />
die Wertebereichsanalyse. Es wird dabei zunächst<br />
angenommen, dass für alle Variablen im Startzustand der<br />
Initialwert gilt. Dann wird der Zustandsraum aufgebaut,<br />
wobei für jeden neuen Zustand die dort möglichen Werte<br />
der Variablen ermittelt werden und der bisherige Wertebereich<br />
jeder Variablen mit dem neuen Wertebereich<br />
vereinigt wird. Diese Vereinigung wird unabhängig auf<br />
allen Domänen ausgeführt: Intervalle werden falls nötig<br />
vergrößert, bei Bitmengen werden Bits unter Umständen<br />
auf unbekannt gesetzt, und für die k-Mengen wird die<br />
übliche Mengenvereinigung durchgeführt. Am Ende der<br />
Analyse sind dann die Wertebereiche aller Variablen bekannt.<br />
Ihre Darstellung geschieht auf drei verschiedene<br />
Arten. Ein Beispiel ist in Bild 1 zu sehen. Hier wurde eine<br />
70<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
BILD 1: Wertebereichsanalyse<br />
des Emergency-<br />
Stop-Bausteins mit<br />
Arcade.PLC. Dargestellt<br />
ist das Resultat für die<br />
Variable DiagCode.<br />
State: 1<br />
DiagCode=0<br />
Activate=1<br />
SF EmergencyStop<br />
BOOL Activate Ready BOOL<br />
SAFEBOOL S EStopIn S EStopOut SAFEBOOL<br />
SAFEBOOL S StartReset Error BOOL<br />
SAFEBOOL S AutoReset DiagCode WORD<br />
BOOL Reset<br />
BILD 3: SF_Equivalent-Funktionsblock aus der<br />
PLCopen [2]<br />
State: 2<br />
DiagCode=16#8001<br />
Activate=1, S_EStopIn=1, S_StartReset=1<br />
State: 3<br />
DiagCode=16#8000<br />
Activate=1, S_EStopIn=0<br />
State: 4<br />
DiagCode=16#8004<br />
Activate=1, S_EStopIn=1, S_AutoReset=0<br />
BILD 2: Zeuge, dass<br />
DiagCode=16#8005<br />
erreicht wird<br />
State: 5<br />
DiagCode=16#8005<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
71
Hauptbeitrag | Automation 2012<br />
Implementierung des <strong>von</strong> der PLCopen vorgegebenen<br />
EmergencyStop-Bausteins untersucht, die an unserem<br />
Lehrstuhl erstellt wurde. Es wird die Wertebereichsanalyse<br />
der Variablen DiagCode gezeigt, wobei die verschiedenen<br />
Darstellungen der Domänen in dem hervorgehobenen<br />
Rahmen nach Possible Values erkennbar sind.<br />
2.4 Wertebereichsanalyse als Überapproximation<br />
Zwar kann die Wertebereichsanalyse prinzipiell exakt<br />
ausgeführt werden, indem die Simulation nur auf konkreten<br />
Werten durchgeführt wird, jedoch ist dies bei<br />
realen Programmen nicht mehr praktikabel. Deswegen<br />
nutzen wir die bereits dargestellte Abstraktion durch<br />
die verschiedenen Domänen. Jede diese Domänen ist<br />
die Überapproximation einer Menge: Beispielsweise<br />
werden mehr als k Werte in den k-Mengen durch den<br />
gesamten Wertebereich überapproximiert und eine<br />
Menge gerader Werte durch ein Intervall, das auch die<br />
dazwischenliegenden ungeraden Werte enthält. Auch<br />
kann die Wertebereichsanalyse zwar eine Abschätzung<br />
für jede Variable des Programms angeben; relationale<br />
Informationen (Abhängigkeiten zwischen Variablen)<br />
lassen sich mit den gewählten Domänen nicht darstellen.<br />
Das bedeutet zum Beispiel, wenn für die Variable<br />
x und die Variable y der Wertebereich [0, 10] gilt, dass<br />
sowohl x als auch y Werte zwischen 0 und 10 annehmen;<br />
falls jedoch x immer dem Wert <strong>von</strong> y entspricht,<br />
so lässt sich dies nicht aus der Ausgabe der Wertebereichsanalyse<br />
entnehmen.<br />
Die Wertebereichsanalyse gibt also eine Überapproximation<br />
des Programmverhaltens an, das heißt, dass nicht<br />
jeder der angezeigten Werte (und nicht jede Kombination)<br />
tatsächlich angenommen werden muss. Allerdings<br />
ist garantiert, dass nicht angezeigte Kombinationen niemals<br />
angenommen werden können. Dies ist bereits sehr<br />
hilfreich, wenn man „auf einen Blick“ bestimmtes Programmverhalten<br />
ausschließen möchte. Möchte man sicher<br />
wissen, ob ein bestimmter Wert der angezeigten<br />
Werte tatsächlich erreicht werden kann, so kann <strong>von</strong><br />
Arcade.PLC ein sogenannter „Zeuge“ generiert werden<br />
(Bild 2). Der Zeuge zeigt eine Sequenz <strong>von</strong> Eingabewerten<br />
des Programms, mit denen der gewünschte Zustand erreicht<br />
wird. Zur Generierung eines Zeugen verwenden<br />
wir die bereits in früheren Arbeiten beschriebene Technik<br />
des Model-Checkings [7, 11], die – ohne dass der Benutzer<br />
eingreifen muss – eine geeignete Formel generiert<br />
und überprüft.<br />
Zur Evaluierung des Ansatzes greifen wir ein Fallbeispiel<br />
auf, das bereits in [8] verwendet wurde. Es handelt<br />
sich um eine innerhalb <strong>von</strong> ABB für die AC500 entwickelte<br />
PLCopen Safety Bibliothek [2], aus der 17 verschiedene<br />
FBs betrachtet werden. Da es sich bei der Bibliothek<br />
um eine sicherheitsrelevante Bibliothek handelt, lohnt<br />
der zusätzliche Aufwand, den die Anwendung <strong>von</strong> formalen<br />
Methoden mit sich bringen kann.<br />
In unserem Beitrag zur Automation 2011 [8] haben<br />
wir zwei unterschiedliche Methoden verwendet: Model-Checking<br />
und Invarianten-Generierung. Beim Model-Checking<br />
spezifiziert der Anwender Eigenschaften<br />
mithilfe einer Logik (CTL und ptLTL). Arcade.PLC überprüft<br />
dann, ob der gewählte Funktionsblock die angegebene<br />
Eigenschaft erfüllt. In dem Fallbeispiel konnten<br />
alle gewünschten Eigenschaften mithilfe <strong>von</strong> Arcade.<br />
PLC bewiesen werden. Die Methode des Model-Che-<br />
Funktionsblock<br />
# Eingänge # Zeilen Zeit [s]<br />
1
ckings lohnt sich vor allem, um einzelne Bausteine im<br />
Detail zu untersuchen. Eine schnelle Überprüfung <strong>von</strong><br />
vielen Bausteinen ist nur eingeschränkt möglich, da die<br />
meisten funktionalen Eigenschaften nur für den jeweiligen<br />
Baustein gelten und somit für jeden zu überprüfenden<br />
Baustein erst die Eigenschaften spezifiziert werden<br />
müssen. Dieser Prozess kann langwierig sein und<br />
erfordert die Einarbeitung in die verwendete Spezifikationssprache.<br />
Die andere Technik, die wir in Biallas et al. 2011 [8]<br />
verwendet haben, ist die der Generierung <strong>von</strong> Invarianten.<br />
Dabei werden automatisch für alle Funktionsblöcke<br />
Invarianten erzeugt, die für den jeweiligen Funktionsblock<br />
gelten, das heißt, diese Technik benötigt keine<br />
Eingabe <strong>von</strong> Eigenschaften, die sie dann überprüft, sondern<br />
liefert <strong>von</strong> sich aus Eigenschaften des Programms.<br />
Dadurch lässt sie sich schnell auf eine größere Anzahl<br />
<strong>von</strong> Funktionsblöcken anwenden, ohne dass spezifische<br />
Eingaben nötig sind. Allerdings sind die erzeugten Invarianten<br />
nur eine Unterklasse der Eigenschaften, die das<br />
Model-Checking untersuchen kann, und zusätzlich benötigt<br />
die Interpretation der Invarianten häufig tieferes<br />
Wissen über das gewünschte Programmverhalten. In der<br />
Veröffentlichung konnten wir aber zeigen, dass der Ansatz<br />
interessante Erkenntnisse über die Funktionsblöcke<br />
erlaubt und dass viele der Invarianten ohne Fachwissen<br />
leicht zu verstehen sind.<br />
Hier stellen wir eine neue Technik vor, die in Arcade.<br />
PLC umgesetzt wurde, nämlich die zuvor beschriebene<br />
Wertebereichsanalyse. In der Fallstudie haben wir alle<br />
in der PLCopen-Safety-Bibliothek implementierten Bausteine<br />
mithilfe der Wertebereichsanalyse überprüft. Wir<br />
stellen zuerst die Größen und Laufzeiten der unterschiedlichen<br />
Funktionsbausteine dar. Danach gehen wir<br />
auf die detaillierte Analyse eines der Bausteine ein und<br />
präsentieren im Anschluss die generellen Ergebnisse aus<br />
der Fallstudie. Die gesamte Fallstudie wurde auf einem<br />
Laptop mit einem Intel Core Duo Prozessor mit 2,40 GHz<br />
und 4 GB Arbeitsspeicher durchgeführt. Als Betriebssystem<br />
wurde Windows 7 verwendet. In Arcade.PLC<br />
sind verschiedene weitere Abstraktionstechniken implementiert,<br />
die alle aktiviert wurden.<br />
Tabelle 1 stellt die Größen und die Laufzeiten der Analyse<br />
für die Bausteine aus der PLCopen-Safety-Bibliothek<br />
dar. Die Bausteine sind aus Gründen der Vertraulichkeit<br />
ohne Namen in randomisierter Reihenfolge dargestellt.<br />
Die Tabelle verdeutlicht, dass die Mehrzahl der Bausteine<br />
in unter 2 Sekunden überprüft werden konnte. Die<br />
Überprüfung <strong>von</strong> zwei Bausteinen hat etwas länger (< 20<br />
Sekunden) und <strong>von</strong> zwei weiteren Bausteinen deutlich<br />
länger gebraucht (< 350 Sekunden). Lediglich zwei Bausteine<br />
konnten innerhalb <strong>von</strong> 600 Sekunden (Timeout)<br />
nicht überprüft werden.<br />
Die Ergebnisse in der Tabelle zeigen, dass die Dauer<br />
der Überprüfung der Bausteine nicht linear mit ihrer<br />
Größe wächst. Die Überprüfung der zwei größten Bausteine<br />
wurde zwar in beiden Fällen abgebrochen, für die<br />
anderen Bausteine konnte dieser Zusammenhang aber<br />
nicht beobachtet werden. Der Baustein 8 hat beispielsweise<br />
593 Zeilen, die Überprüfung dauert aber nur 7,22<br />
Sekunden. Baustein 11 hat nur 392 Zeilen, die Überprüfung<br />
dauert aber fast 350 Sekunden. Die Dauer der Überprüfung<br />
hängt vor allem <strong>von</strong> der Anzahl und dem Typ<br />
der Ein- und Ausgänge ab. Im schlechtesten Fall ist die<br />
Laufzeit exponentiell zur Anzahl und Bitbreite (Typ) der<br />
Ein- und Ausgänge.<br />
Im Folgenden zeigen wir das Vorgehen beispielhaft<br />
für den SF_Equivalent Funktionsblock aus der PLCopen-<br />
Safety-Bibliothek, der auch in [8] als Beispiel diente.<br />
Die Spezifikation des Funktionsblocks haben wir direkt<br />
aus der PLCopen-Spezifikation [2] übernommen.<br />
Bild 3 stellt diesen Funktionsblock dar. Er hat vier Eingänge<br />
und vier Ausgänge. Die Hauptaufgabe dieses<br />
Bausteins ist es anzuzeigen, ob die beiden Eingänge<br />
S_ChannelA und S_ChannelB beide true sind. Ist dies<br />
der Fall und ist der Baustein gleichzeitig auch aktiv,<br />
wird am Ausgang S_Equivalent true ausgegeben. Ist einer<br />
der beiden Ausgänge false, so ist auch der Ausgang<br />
S_Equivalent false. Zusätzlich dazu werden noch bestimmte<br />
andere Bedingungen überprüft und gegebenenfalls<br />
ein Fehler angezeigt.<br />
Wie alle Funktionsblöcke aus der PLCopen hat auch<br />
der SF_Equivalent-Funktionsblock interne Zustände, die<br />
mithilfe des DiagCodes abgebildet werden. Dieser Funktionsblock<br />
hat 9 interne Zustände (0, 16#8000, 16#8001,<br />
16#8004, 16#8005, 16#8014, 16#C001, 16#C002, 16#C003),<br />
wobei die Zustände, die mit „C“ beginnen, Fehlerzustände<br />
repräsentieren (siehe auch Bild 1).<br />
Die Überprüfung dieses Bausteins mithilfe der Wertebereichsanalyse<br />
<strong>von</strong> Arcade.PLC dauerte weniger als 1<br />
Sekunde. Das Ergebnis ist für jede der im Programm<br />
vorkommenden Variablen und Konstanten eine Menge<br />
<strong>von</strong> Werten, die <strong>von</strong> diesen maximal angenommen werden.<br />
Für die Eingänge vom Typ Bool ist das Ergebnis hier<br />
nicht überraschend. Alle Booleschen Eingänge können<br />
den Wert false und den Wert true annehmen. Weiterhin<br />
hat Arcade.PLC festgestellt, dass Time alle möglichen<br />
Werte im Wertebereich annehmen kann. Diese Ergebnisse<br />
sind nicht verwunderlich, da dieses Eingaben für den<br />
Baustein sind und als offen betrachtet werden müssen,<br />
wenn der Funktionsblock alleine analysiert wird. Beschränkungen<br />
<strong>von</strong> Eingaben für Funktionsblöcke können<br />
vorkommen, wenn Arcade.PLC ganze Programme<br />
überprüft und Funktionsblöcke dann in bestimmten<br />
Kontexten ausgeführt werden.<br />
Für die Ausgänge vom Typ Bool liefert Arcade.PLC das<br />
gleiche Ergebnis wie für die Eingänge. Dieses Ergebnis<br />
gibt dem Anwender erst einmal keine zusätzlichen Informationen.<br />
Hier wäre die Invariantengenerierung [11].<br />
aussagekräftiger, da sie insbesondere Zusammenhänge<br />
zwischen Eingaben und Ausgaben darstellt. Allerdings<br />
konnten wir für frühe Entwicklungsversionen <strong>von</strong> anderen<br />
Funktionsblöcken mithilfe der Wertebereichanalyse<br />
feststellen, dass manche Boolesche Ausgänge nur<br />
auf false beziehungsweise true gesetzt wurden und somit<br />
ein Fehler in der Implementierung vorliegt.<br />
Den größten Nutzen für den Anwender hat die Analyse<br />
der Variablen DiagCode. Diese hat für den Funktionsblock<br />
SF_Equivalent herausgefunden, dass genau die<br />
oben beschriebenen Werte angenommen werden, das<br />
heißt, dass nur interne Zustände besucht werden, die<br />
auch im Standard definiert sind. Auch hier haben wir in<br />
anderen Funktionsblöcken in frühen Entwicklungsversionen<br />
Abweichungen feststellen können.<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
73
Hauptbeitrag | Automation 2012<br />
Arcade.PLC gibt auch Auskunft über interne Variablen<br />
und Konstanten. Dadurch lässt sich feststellen, ob die Werte<br />
richtig definiert wurden und ob sie richtig verwendet<br />
wurden. Es fällt zum Beispiel auf, wenn eine Konstante<br />
definiert wurde, aber nicht in den Ergebnissen auftaucht.<br />
In der letzten Version, die wir <strong>von</strong> der PLCopen-Safety-<br />
Bibliothek überprüft haben, waren alle Wertebereiche<br />
der Variablen wie erwartet. Daher haben wir auch frühe<br />
Forschungs- und Entwicklungsversionen der Bibliothek<br />
überprüft. Hier konnten wir alle oben beschriebenen<br />
Probleme finden. Es gab Ausgaben, die nicht gesetzt wurden,<br />
Timer, die nicht gestartet wurden, DiagCodes, die<br />
gefehlt haben und DiagCodes, die falsch waren. Der Einsatz<br />
<strong>von</strong> Arcade.PLC beim Debugging hätte hier während<br />
der Entwicklung Zeit gespart.<br />
Die Überprüfung der Wertebereiche vor allem in frühen<br />
Entwicklungsphasen ist besonders nützlich. Die<br />
Analyse gibt ein schnelles Feedback und weist auf Fehler<br />
hin. Ein Entwickler kann die Analyse insbesondere<br />
auch als Regressionstest zwischen unterschiedlichen<br />
Versionen verwenden, das heißt, er könnte sie beispielsweise<br />
verpflichtend als Test vor dem Einchecken in die<br />
Versionskontrolle einführen. Die Überprüfung der Invarianten<br />
[8] geht hier zwar einen Schritt weiter, da sie<br />
auch bestimmte Beziehungen zwischen den Ein- und<br />
Ausgängen anzeigt. Sie erfordert aber mehr inhaltliches<br />
Verständnis der darunterliegenden Methoden. Zusätzlich<br />
würde ein Regressionstest auf Basis der Invarianten<br />
auch öfter eine Abweichung zwischen zwei Versionen<br />
melden, da sich die Beziehungen zwischen Variablen in<br />
der Entwicklung oft beabsichtigt ändern. Zur ausführlichen<br />
Analyse eines einzelnen Bausteins ist unserer<br />
Erfahrung nach die Methode des Model-Checkings am<br />
besten geeignet [8].<br />
Fazit und Ausblick<br />
Der Beitrag stellte ein formales Verfahren zur Unterstützung<br />
der Fehlersuche in SPS-Programmen vor. Dazu<br />
werden für ein gegebenes Programm automatisch alle<br />
Werte ermittelt, die die Variablen in allen möglichen<br />
Programmabläufen annehmen können. Befinden sich in<br />
diesen Wertemengen unerwartete Werte, so lässt sich<br />
daraus auf mögliche Fehler im Programm schließen.<br />
Der Ansatz wurde an einer Bibliothek <strong>von</strong> Funktionsbausteinen<br />
demonstriert. Zukünftige Arbeiten werden<br />
sich unter anderem mit der Erweiterung des Ansatzes<br />
auf andere Datentypen und die Behandlung <strong>von</strong> neuen<br />
Sprachelementen wie Pointern befassen.<br />
Danksagung<br />
Manuskripteingang<br />
01.06.2012<br />
Im Peer-Review-Verfahren begutachtet<br />
Die vorgestellten Arbeiten wurden zum Teil <strong>von</strong><br />
der Deutschen Forschungsgemeinschaft unter<br />
dem Kennzeichen SCHL 1868/2-1 gefördert.<br />
Autoren<br />
Prof. Dr.-Ing. Stefan<br />
KOWALEWSKi (geb. 1962)<br />
leitet den Lehrstuhl<br />
Informatik 11 – Software<br />
für eingebettete Systeme an<br />
der RWTH Aachen. Seine<br />
Forschungsinteressen liegen<br />
in der Anwendung und<br />
Weiterentwicklung modellbasierter<br />
und formaler Methoden beim Entwurf<br />
und der Validierung eingebetteter Software.<br />
RWTH Aachen,<br />
Informatik 11,<br />
Ahornstraße 55, D-52074 Aachen,<br />
Tel. +49 (0) 241 802 11 50,<br />
E-Mail: kowalewski@embedded.rwth-aachen.de<br />
Dr. rer. nat. bASTian<br />
Schlich (geb. 1978) arbeitet<br />
seit 2010 am ABB Forschungszentrum<br />
in Ladenburg<br />
und leitet seit Januar<br />
2012 die Gruppe Industrial<br />
Software Technologies.<br />
Seine Themen reichen <strong>von</strong><br />
Softwaretechnologien über<br />
Softwarearchitekturen bis hin zu formalen<br />
Methoden in der Softwareentwicklung.<br />
ABB Forschungszentrum Deutschland,<br />
Industrial Software Systems Program,<br />
Wallstadter Straße 59,<br />
D-68526 Ladenburg,<br />
Tel. +49 (0) 6203 71 62 70,<br />
E-Mail: bastian.schlich@de.abb.com<br />
Dipl.-Inform. SebASTian<br />
BiALLAS (geb. 1981) arbeitet<br />
seit 2010 als wissenschaftlicher<br />
Mitarbeiter am<br />
Lehrstuhl Informatik 11 –<br />
Software für eingebettete<br />
Systeme an der RWTH<br />
Aachen. Er beschäftigt sich<br />
mit der formalen Verifikation<br />
<strong>von</strong> SPS-Programmen und leitet das<br />
Arcade.PLC-Projekt.<br />
RWTH Aachen,<br />
Informatik 11,<br />
Ahornstraße 55, D-52074 Aachen,<br />
Tel. +49 (0) 241 802 11 58,<br />
E-Mail: biallas@embedded.rwth-aachen.de<br />
74<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
Referenzen<br />
[1] IEC 61508: Functional Safety of Electrical, Electronic and<br />
Programmable Electronic Safety-Related Systems, 1998<br />
[2] PLCopen TC5: Safety Software Technical Specification, Version<br />
1.0, Part 1: Concepts and Function Blocks. PLCopen, 2006<br />
[3] biallas, S., Kowalewski, S., Schlich, B., Automatische<br />
Wertebereichsanalyse <strong>von</strong> SPS-Programmen. In: Tagungsband<br />
automation 2012, S. 79-83. VDI, Düsseldorf, 2012<br />
[4] moon, I.: Modeling Programmable Logic Controllers for Logic<br />
Verification. ieee Control Systems Magazine 14 (2), S. 53–59,<br />
1994<br />
[5] Canet, G., Couffin, S., Lesage, J.-J., Petit, A., Schnoebelen, P.:<br />
Towards the Automatic Verification of PLC Programs Written<br />
in Instruction List. In: ieee International Conference on<br />
Systems, Man, and Cybernetics Band 4, S. 2449-2454. ieee<br />
Computer Society Press, 2000<br />
[6] mertke, T., Frey, G.: Formal verification of PLC-programs<br />
generated from signal interpreted petri nets. ieee International<br />
Conference on Systems, Man, and Cybernetics Band 4., S.<br />
2700–2705. ieee Computer Society Press 2001<br />
[7] Pavlovic, O., Pinger, R., Kollmann, M.: Automated formal verification<br />
of PLC programs written in IL. In: In 4th International<br />
Verification Workshop, S. 152–163. Ceur-WS.org 2007<br />
[8] Biallas, S., Kowalewski, S., Schlich, B.: Leistungsfähige<br />
Verifikation <strong>von</strong> industriellen SPS-Programmen mittels<br />
Model-Checking und statischer Analyse. In: Tagungsband<br />
automation 2011, S. 67-72. VDI, Düsseldorf 2011<br />
[9] bornot, S., Huuck, R, Lakhnech, Y., Lukoschus, B.: Utilizing<br />
Static Analysis for Programmable Logic Controllers. In: 4th<br />
International Conference on Automation of Mixed Processes:<br />
Hybrid Dynamic Systems, S. 183–187, Shaker, Aachen 2000.<br />
[10] huuck, R.: Software Verification for Programmable Logic<br />
Controllers. Dissertation. Universität Kiel, 2003<br />
[11] biallas, S., Brauer, J., Kowalewski, S., Schlich, B.: Automatically<br />
Deriving Symbolic Invariants for PLC Programs Written<br />
in IL. In: Proc. FormS/Format 2010, S. 237–245, Springer,<br />
Berlin Heidelberg 2011<br />
[12] biallas, S., Brauer, J., Kowalewski, S.: Counterexample-Guided<br />
Abstraction Refinement for PLCs. In Proc. 5th International<br />
Workshop on Systems Software Verification (SSV 2010), S.<br />
2-12, USeniX Association, Berkeley, CA, USA 2010<br />
Programm<br />
BUS<br />
Sprechstunde<br />
Moderation: Jürgen George,<br />
Pepperl+Fuchs GmbH<br />
BUS<br />
2. Feldbus-Sprechstunde<br />
Feldbus in der Prozessindustrie<br />
27. + 28.09.2012, Mannheim, Pepperl+Fuchs GmbH<br />
www.feldbus-sprechstunde.de<br />
Wann und Wo?<br />
Systemplanung: Auswahl der Geräte und <strong>Komponenten</strong><br />
Systemplanung: Feldbusinfrastruktur<br />
Systemplanung: Einsatz <strong>von</strong> Planungstools<br />
Systemplanung: Explosionsschutz und funktionale Sicherheit<br />
Inbetriebnahme: Hardware-Installation und -Inbetriebnahme<br />
Inbetriebnahme: Implementierung<br />
Inbetriebnahme: Systematische Fehlersuche<br />
Referenten<br />
Ronny Becker, Prüflabor MSR u. Analysentechnik, BIS Prozesstechnik GmbH<br />
Dr. Andreas Hildebrandt, Thomas Klatt,<br />
Thomas Westers, Pepperl+Fuchs GmbH<br />
Dr. Niels Kiupel, Degussa GmbH<br />
Sven Seintsch, Prüflabor MSR u. Analysentechnik, BIS Prozesstechnik GmbH<br />
Termin<br />
Donnerstag, 27.09.2012<br />
Veranstaltung (11:30 – 17:30 Uhr)<br />
„Get-Together“ mit Abendessen (ab 18:30 Uhr)<br />
Freitag, 28.09.2012<br />
Veranstaltung (9:00 – 15:00 Uhr)<br />
Ort<br />
Mannheim, Pepperl+Fuchs GmbH<br />
Thema<br />
Antworten zur Planung und Inbetriebnahme<br />
<strong>von</strong> Feldbussen<br />
Teilnahmegebühr<br />
<strong>atp</strong> <strong>edition</strong>-Abonnenten 540 € zzgl. MwSt<br />
Firmenempfehlung 590 € zzgl. MwSt<br />
reguläre Teilnahmegebühr 690 € zzgl. MwSt<br />
Im Preis enthalten sind die Tagungsunterlagen<br />
sowie das Catering (Kaffee, 2x Mittagsimbiss,<br />
„Get-Together“ mit Abendessen).<br />
Weitere Informationen und Online-Anmeldung unter www.feldbus-sprechstunde.de<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
75
hauptbeitrag<br />
Mensch-Maschine-Schnittstelle<br />
im demografischen Wandel<br />
Neue ergonomische Gestaltungsanforderungen<br />
Der demografische Wandel und die damit verbundene Zunahme älterer Mitarbeiter in<br />
industriellen Bereichen erfordert ein Umdenken bei der Gestaltung des Arbeitssystems.<br />
Ziel: den Erhalt der Wettbewerbsfähigkeit des produzierenden Gewerbes zu gewährleisten.<br />
Der Beitrag stellt den aktuellen Forschungsstand aus der Chemnitzer Altersdatenbank<br />
bezüglich der Leistungswandlung älterer Mitarbeiter den Gestaltungsfeldern der Mensch-<br />
Maschine-Schnittstelle (MMS) gegenüber. Es werden Handlungsfelder aufgezeigt, die im<br />
Zuge einer altersdifferenzierten Gestaltung <strong>von</strong> Arbeitsmitteln der industriellen Produktion<br />
zukünftig stärker beachtet werden müssen.<br />
SCHLAGWÖRTER Ergonomische Gestaltung / Demografischer Wandel /<br />
Mensch-Maschine-Schnittstelle<br />
The human machine interface in times of demographic change –<br />
Ergonomic design requirements<br />
The demographic change and the associated increase of elderly employees in the industrial<br />
sector demands a rethinking regarding the working system in order to guarantee the<br />
competitiveness of the manufacturing industry sector. This report details the current<br />
status of research, using the Chemnitz Age Database, on the subject of human machine<br />
interface (HMI) with respect to the performance of elderly employees in the industrial<br />
sector. The report also highlights the fields of activities in age-differentiated HMI design<br />
in the industrial sector, which have to be looked at more closely in future.<br />
KEYWORDS Ergonomic Design / Demographic Change / Human-Machine-Interface<br />
76<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
Frank DiTTRiCH, TU Chemnitz<br />
Die demografische Entwicklung ist in vielen<br />
Industrienationen durch eine stetige Alterung<br />
der Gesellschaft gekennzeichnet. Dieser demografische<br />
Wandel ist relevant im Hinblick<br />
auf die Entwicklung neuer gesellschafts- und<br />
sozialpolitischer Strategien und stellt auch Unternehmen<br />
vor neue Herausforderungen. Der derzeit in<br />
Deutschland stattfindende Wandel führt dazu, dass die<br />
heute zahlenmäßig stärkste Altersgruppe der 35-49-Jährigen<br />
im Jahr 2040 <strong>von</strong> der Gruppe der 50-64-Jährigen<br />
abgelöst sein wird [1]. Künftig werden damit immer<br />
weniger junge Menschen dem Arbeitsmarkt zur Verfügung<br />
stehen. Verbunden mit dem Anstieg der Lebensarbeitszeit<br />
führt dies dazu, dass sich die Altersstruktur<br />
der Unternehmen zunehmend verändern wird. Der bereits<br />
spürbare Fachkräftemangel wird sich verschärfen<br />
und es notwendig machen, dass ältere Mitarbeiter in<br />
allen Unternehmensbereichen, auch in der Produktion,<br />
länger eingebunden werden müssen. Die bisher weitverbreitete<br />
betriebliche Frühverrentung als Antwort auf<br />
die Leistungsminderung älterer Mitarbeiter muss neuen<br />
Konzepten und Maßnahmen weichen, um Ältere länger<br />
aktiv ins Arbeitsleben einzubinden. Ein wesentlicher<br />
Baustein hierbei ist die ergonomische Gestaltung des<br />
Arbeitssystems [2]. Durch eine entsprechende alternsgerechte<br />
Gestaltung kann der altersbedingten Wandlung<br />
menschlicher Fähigkeiten entgegen getreten und<br />
die Aufrechterhaltung der Arbeitsfähigkeit bis ins hohe<br />
Erwerbsalter begünstigt werden.<br />
1. Wandlung menschlicher Fähigkeiten<br />
Menschliche Fähigkeiten sind im Laufe des Alterungsprozesses<br />
Veränderungen unterworfen, welche das Leistungsvermögen<br />
älterer Mitarbeiter im Vergleich zu jüngeren<br />
einschränken können. Während sich einige Fähigkeiten,<br />
wie die kristalline Intelligenz, also die Repräsentation<br />
<strong>von</strong> Faktenwissen und Erfahrungen, verbessern,<br />
sind andere Fähigkeiten, wie beispielsweise die Sensorik<br />
(Sehen, Hören und Fühlen), negativen Veränderungen<br />
unterworfen. Beginnend meist im mittleren Alter, steigt<br />
die Abnahme zwischen 50 und 60 Jahren stark an. Die<br />
durch das Arbeitssystem hervorgerufenen und objektiv<br />
messbaren Belastungen aus den Bereichen der Arbeitsaufgabe,<br />
der Arbeitsumwelt, sowie der Mensch-Maschine-Schnittstelle<br />
(MMS) führen bei älteren Mitarbeitern<br />
so zu individuell höheren Beanspruchungen als im Vergleich<br />
zu jüngeren (siehe Bild 1) [3]. Dies kann Auswirkungen<br />
auf die Erfüllung der Arbeitsaufgabe haben und<br />
je nach Belastungshöhe und -dauer auch gesundheitliche<br />
Folgen nach sich ziehen.<br />
Im Fall der Mensch-Maschine-Interaktion (MMI), wie<br />
beispielsweise bei der Kontrolle und Steuerung <strong>von</strong> Produktionsabläufen<br />
in Leitwarten, der Manipulation <strong>von</strong><br />
Maschinen und Anlagen oder dem Arbeiten mit mobilen<br />
Geräten, können fähigkeitsüberschreitende Schnittstellengestaltungen<br />
zu ineffektiven (zum Beispiel Fehlbedienungen)<br />
sowie zu ineffizienten (beispielsweise längere<br />
Arbeitsschritte oder Korrekturen) Arbeitsabläufen<br />
führen. Gerade aus Fehlbedienungen ergeben sich nicht<br />
selten hohe Folgekosten und sie können bei sicherheitsrelevanten<br />
Tätigkeiten sogar zu Personenschäden führen.<br />
Psychologische sowie physiologische Beeinträchtigungen<br />
bei der Mensch-Maschine-Interaktion sind in<br />
allen drei menschlichen Handlungsphasen der Informationsaufnahme,<br />
der Informationsverarbeitung sowie der<br />
Informationsumsetzung möglich. Während bei der Informationsaufnahme<br />
vor allem die Fähigkeiten des Sehens,<br />
des Hörens sowie des Fühlens beansprucht werden,<br />
sind bei der Informationsverarbeitung geistige sowie<br />
bei der Informationsumsetzung körperliche Aufwände<br />
die Folge.<br />
Am Beispiel der Beanspruchung des Sehvermögens<br />
zeigt Schierz [4], dass zu hohe Sehanforderungen zu Augenreizungen,<br />
Sehbeschwerden sowie zerebralen Beschwerden,<br />
wie Kopfschmerzen, führen. Das löst Ermüdungserscheinungen<br />
aus, die sich wiederum auf die<br />
Produktivität des Mitarbeiters auswirken und bei sicherheitsrelevanten<br />
Tätigkeiten gravierende Folgen haben<br />
können. Die Belastungen bei der Mensch-Maschine-Interaktion<br />
lassen sich reduzieren, indem die Fähigkeiten<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
77
Hauptbeitrag<br />
der Nutzer bei der Gestaltung der Schnittstellen beachtet<br />
werden. So können auch ältere Mitarbeiter mit gewandelten<br />
Fähigkeiten eine mit jüngeren Mitarbeitern vergleichbare<br />
Arbeitsleistung erbringen und werden nicht<br />
gesundheitlich beeinträchtigt.<br />
2. Folgen für Mensch-Maschine-Interaktion<br />
Im Folgenden wird beschrieben, welche für die Mensch-<br />
Maschine-Interaktion relevanten menschlichen Fähigkeiten<br />
sich im Alterungsprozess wie verändern und<br />
dementsprechend bei der Gestaltung <strong>von</strong> Mensch-Maschine-Schnittstellen<br />
berücksichtigt werden müssen.<br />
Hierbei handelt es sich um den normalen Alterungsprozess,<br />
der möglichst frei <strong>von</strong> pathologischen, also krankhaften,<br />
Veränderungen ist. Die Daten wurden aus der<br />
Chemnitzer Altersdatenbank gewonnen und im Hinblick<br />
auf die Relevanz der Mensch-Maschine-Interaktion<br />
im industriellen Anwendungskontext ausgewertet.<br />
Die Chemnitzer Altersdatenbank verfolgt das Ziel, über<br />
eine umfassende Bestandsanalyse aus Forschungsergebnissen<br />
der Medizin, Biologie, Sportwissenschaft,<br />
Gerontologie, Ingenieurswissenschaft und Psychologie<br />
valide Erkenntnisse über altersbedingte Veränderungen<br />
zusammenzuführen und aufzubereiten. Die etwa 900<br />
wissenschaftlichen Untersuchungen ermöglichen es,<br />
typische Entwicklungsverläufe altersabhängiger Leistungsfaktoren<br />
<strong>von</strong> gesund alternden Personen zwischen<br />
20 und 70 Jahren aufzuzeigen.<br />
2.1 Informationsaufnahme<br />
Im Alter engt sich das Gesichtsfeld ein. So nimmt<br />
die Erkennungsleistung in den peripheren Bereichen<br />
ab [6]. Gegenstände, wie beispielsweise Anzeigen<br />
oder Eingabeelemente, die sich in einem Sichtwinkel<br />
ab 25 Grad befinden, sind nur noch eingeschränkt<br />
wahrnehmbar. Zudem wird auch das Blickfeld kleiner,<br />
da die Beweglichkeit des Kopfes aufgrund <strong>von</strong><br />
Einschränkungen in der Halswirbelsäule abnimmt.<br />
Zum einen können bei falscher Anordnung <strong>von</strong> Eingabe-<br />
und Ausgabeelementen, beispielsweise in Leitwarten,<br />
hohe Beanspruchungen für ältere Mitarbeiter<br />
entstehen. Zum anderen kann es dazu kommen,<br />
dass visuelle Warnanzeigen, wenn diese sich im<br />
äußeren Blickfeldbereich befinden, <strong>von</strong> Älteren<br />
schlechter wahrgenommen werden als <strong>von</strong> Jüngeren.<br />
Das Schärfesehen (Visus) nimmt sowohl für kurze<br />
als auch für weite Distanzen trotz optimal angepasster<br />
Brille ab. So verfügt ein 60-Jähriger bei einem<br />
Sehabstand <strong>von</strong> 2 m durchschnittlich über nur 56 %<br />
der Sehleistung eines 20-Jährigen [7]. Untersuchungen<br />
haben gezeigt, dass Ältere bei Bildschirmaufgaben<br />
mit einer Zeichenhöhe <strong>von</strong> 12 Bogenminuten<br />
eine signifikant langsamere Reaktionszeit als Jüngere<br />
haben [8].<br />
Ab dem 40. bis 50. Lebensjahr kommt es zu einem<br />
zunehmenden Abstieg der Kontrastwahrnehmung [9],<br />
die bei geringer Leuchtdichte zusätzlich abnimmt<br />
und sich auch negativ auf die Sehschärfe auswirkt.<br />
Gerade bei stark reflektierenden Anzeigeoberflächen,<br />
Anzeigen mit geringer Leuchtdichte oder Darstellungen<br />
mit geringen Kontrastverhältnissen kann die Informationsaufnahme<br />
stark beeinflusst werden.<br />
Die Blendempfindlichkeit nimmt ab dem 40. Lebensjahr<br />
abrupt zu [10], was vor allem bei der Aufnahme<br />
<strong>von</strong> Informationen über nicht entspiegelte Displays<br />
zu Beeinträchtigungen führt. Zudem ist eine Überlagerung<br />
des Streulichtes im Auge die Ursache dafür,<br />
dass kontrastarme Objekte deutlich schlechter<br />
erkennbar sind [11].<br />
Bereits ab dem 30. Lebensjahr nimmt die Wahrnehmung<br />
<strong>von</strong> Licht im kurzen Wellenlängenbereich<br />
langsam und ab dem 60. Lebensjahr deutlich ab, sodass<br />
die Farbwahrnehmung verändert wird [12]. So<br />
wird die Lichtmenge im violetten, blauen und grünen<br />
Bereich deutlich reduziert [13]. Beispielsweise<br />
können Blau-Gelb-Kontraste dann nicht mehr wahrgenommen<br />
werden.<br />
Die Hörschwelle, also die untere Hörgrenze, nimmt<br />
bereits ab dem 25. Lebensjahr kontinuierlich zu.<br />
So nehmen 60-65-Jährige Frequenzen im Bereich<br />
1000 und 2000 Hz erst ab einem Pegel <strong>von</strong> 20 dB<br />
wahr, während die Wahrnehmung bei 25-Jährigen<br />
nahezu gegen 0 dB geht [14]. Akustische Informationen<br />
werden deshalb <strong>von</strong> Älteren zunehmend<br />
schlechter wahrgenommen als <strong>von</strong> Jüngeren. Akustische<br />
Anzeigen unterliegen damit ebenfalls, wie<br />
visuelle Anzeigen, Alterseinflüssen. So können vor<br />
allem Rückmeldungen weniger erfolgreich aufgenommen<br />
werden, was wiederum zu Fehlbedienungen<br />
führen kann.<br />
Mit zunehmendem Alter steigt die Hörschwelle vor<br />
allem bei höheren Frequenzen stark an, sodass Töne<br />
mit zunehmender Schallfrequenz immer schlechter<br />
wahrgenommen werden können [14].<br />
Die Wahrnehmung des Nutzschalls, wie beispielsweise<br />
<strong>von</strong> akustischen Signalen, in Abgrenzung des<br />
Störschalls, wie beispielsweise <strong>von</strong> Hintergrundgeräuschen,<br />
wird im Laufe des Älterwerdens zunehmend<br />
schwieriger [15]. Besonders im Hinblick auf Systeme<br />
mit Sprachausgabe oder industrielle Anwendungen,<br />
bei denen viele Hintergrundgeräusche vorliegen,<br />
kann dieser Aspekt die MMI beeinträchtigen.<br />
Die taktile Schwelle steigt im Alter zunehmend an.<br />
Sie ist die Grenze, bei der ein auf die Haut einwirkender<br />
Druck gerade noch wahrgenommen werden<br />
kann. Beispielsweise muss bei 50-60-Jährigen ein<br />
Druck zwei- bis dreimal größer sein als bei 20-Jährigen<br />
[16]. Dies sollte unter anderem bei der Auslegung<br />
<strong>von</strong> Stellteilen mit entsprechender haptischer<br />
Rückmeldung beachtet werden.<br />
Ebenso kann die vibrotaktile Empfindlichkeit einen<br />
Einfluss auf die altersbedingte Wahrnehmung <strong>von</strong><br />
haptischen Rückmeldungen haben. So erhöht sich<br />
die taktile Schwelle mit zunehmendem Alter in Abhängigkeit<br />
der Frequenz. Das heißt, dass auf der Haut<br />
über mechanische Schwingungen einwirkende Drücke<br />
umso schlechter wahrgenommen werden, je höher<br />
deren Frequenz ist [17].<br />
78<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
Auch die räumliche Schärfe, mit der unterschiedliche<br />
Strukturen über die Fingerkuppen wahrgenommen<br />
werden können, lässt im Laufe des Älterwerdens<br />
nach. So verfügen 60-Jährige nur noch über<br />
etwa 40 % der Leistungsfähigkeit <strong>von</strong> 20-Jährigen<br />
[18]. Ältere Menschen sind demzufolge weniger empfindlich<br />
für detailreiche Oberflächenstrukturen.<br />
Dies kann beispielsweise bei der Bedienung <strong>von</strong> mobilen<br />
Geräten und der damit notwendigen Unterscheidbarkeit<br />
<strong>von</strong> Tasten relevant sein.<br />
2.2 Informationsverarbeitung<br />
Die Leistungsfähigkeit des Arbeitsgedächtnisses<br />
nimmt bereits mit 20 Jahren kontinuierlich ab [19].<br />
Dies betrifft vor allem visuell dargebotene Informationen,<br />
was unter anderem dazu führt, dass weniger<br />
Informationen verarbeitet werden können. Entscheidungsprozesse,<br />
die in Abhängigkeit <strong>von</strong> vielen gleichzeitig<br />
aufzunehmenden Informationen stehen, können<br />
demzufolge ineffizient ausgeführt werden oder<br />
selbst zu Fehlentscheidungen führen. Auch wenn die<br />
Geschwindigkeit eines Prozesses, beispielsweise eines<br />
Bedienvorganges oder die Anzeigegeschwindigkeit<br />
<strong>von</strong> Informationen, <strong>von</strong> einer Maschine vorgegeben<br />
wird, können Alterseffekte entstehen.<br />
In engem Zusammenhang mit den Folgen der Verringerung<br />
des Arbeitsgedächtnisses steht die Verlangsamung<br />
der Informationsverarbeitungsgeschwindigkeit.<br />
Auch hier treten ähnliche Leistungsverluste<br />
auf [19]. Bei der MMI ist dies vor allem bei<br />
der Verarbeitung komplexer Informationen relevant.<br />
Eine im Alter auftretende Verschlechterung der<br />
Überführung der Informationen vom Kurzzeitgedächtnis<br />
ins Langzeitgedächtnis [20] kann dazu führen,<br />
dass beispielsweise Bedienvorgänge neuer, für<br />
den Nutzer bisher unbekannter, Maschinen schwerer<br />
erlernt werden können. In Verbindung mit der<br />
Kapazität des Arbeitsgedächtnisses und der Geschwindigkeit<br />
kognitiver Prozesse ist dies vor allem<br />
bei besonders komplexen Bedienvorgängen relevant.<br />
2.3 Informationsumsetzung<br />
Grundlegend lässt sich eine Veränderung der Körpermaße<br />
im Laufe des Älterwerdens feststellen.<br />
Vor allem die Körpergröße ist einer kontinuierlichen<br />
Veränderung unterworfen. Das 5. Perzentil<br />
männlich unterscheidet sich demnach um 8 cm<br />
Körpergröße zwischen dem 18.-25. und dem 61.-<br />
65. Lebensjahr, das 95. Perzentil männlich sogar<br />
um 10,5 cm [21]. Bei der räumlichen Auslegung<br />
<strong>von</strong> Arbeitsmitteln, wie beispielsweise bei Leitständen,<br />
sind diese Veränderungen relevant. Vor<br />
allem Bedienanforderungen an sicherheitsrelevante<br />
Ein- oder Ausgabemöglichkeiten lassen sich<br />
BILD 1: Chemnitzer Altersmodell, aufbauend auf dem Strukturschema menschlicher Arbeit [5]<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
79
Hauptbeitrag<br />
Fazit<br />
bei einer Orientierung an Durchschnittswerten<br />
nicht erfüllen.<br />
Auch der menschliche Bewegungsapparat ist altersbedingten<br />
Veränderungen unterworfen. Beispielsweise<br />
nimmt die Leistungsfähigkeit der Seitneigung<br />
durchschnittlich um 20 % zwischen dem 40. und<br />
55. Lebensjahr ab [22].<br />
Wirkräume, wie das Hand-Arm- oder das Greifsystem,<br />
schränken sich mit dem Älterwerden ein. So<br />
nimmt die Reichweite der Arme nach oben und unten<br />
ab. Die Beweglichkeit des Handgelenks und der<br />
Finger werden eingeschränkt [23]. Bei der Bedienung<br />
<strong>von</strong> Eingabeelementen kann es so zu Einschränkungen<br />
kommen, wenn die räumliche Anordnung der<br />
Eingabeelemente außerhalb der Wirkräume liegt.<br />
Gerade im Alter ist der Körperbau besonders anfällig<br />
für Störeinflüsse, und durch Fehlanordnung bedingte<br />
Verrenkungen können so zu hohen Beanspruchungen<br />
führen.<br />
Obwohl die Muskelkraft eine äußerst individuelle<br />
Fähigkeit ist, die entsprechend trainiert werden<br />
kann, ist da<strong>von</strong> auszugehen, dass sie dennoch im<br />
Alterungsprozess kontinuierlich abnimmt. Dies betrifft<br />
beispielsweise auch die für die Mensch-Maschine-Interaktion<br />
relevante Greifkraft. So verfügt<br />
ein 60-Jähriger im Durchschnitt nur noch über 73%<br />
der Greifkraft eines 20-Jährigen [24].<br />
Es zeigt sich, dass alle drei Phasen der MMI, die Informationsaufnahme,<br />
die Informationsverarbeitung sowie<br />
die Informationsumsetzung, zum großen Teil auf<br />
menschlichen Fähigkeiten aufbauen, die altersbedingten<br />
Veränderungen unterliegen. Da diese Veränderungen<br />
bereits im erwerbstätigen Alter auftreten und Auswirkungen<br />
auf die Effektivität und Effizienz der Aufgabenbewältigung<br />
haben sowie gesundheitliche Folgen<br />
nach sich ziehen können, ist es notwendig, die Bedürfnisse<br />
und Fähigkeiten älterer Menschen in die Gestaltung<br />
der Mensch-Maschine-Schnittstellen <strong>von</strong> industriellen<br />
Arbeitsmitteln einzubeziehen. Hierbei sind im<br />
Zusammenhang mit der Informationsaufnahme vor<br />
allem Aspekte der visuellen Darstellung <strong>von</strong> Informationen<br />
zu berücksichtigen. So sollten entsprechende<br />
Kontraste verwendet, eine entsprechende Farbauswahl<br />
getroffen und optimierte Beleuchtungsmodalitäten ein-<br />
Referenzen<br />
[1] Statistisches Bundesamt (2009). 12. Koordinierte<br />
Bevölkerungsvorausberechnung. www.destatis.de<br />
[2] Kistler, E., Ebert, A., Guggemos, P., Lehner, M., Buck, H.,<br />
Schletz, A. (2006). Altersgerechte Arbeitsbedingungen<br />
Machbarkeitsstudie (Sachverständigengutachten)<br />
für die Bundesanstalt für Arbeitsschutz. Dortmund,<br />
Berlin, Dresden: Bundesanstalt für Arbeitsschutz und<br />
Arbeitsmedizin<br />
[3] Keil, M., Hensel, R., Spanner-Ulmer, B. (2010). Fähigkeitsgerechte<br />
Prozessmodellbausteine zur Generierung<br />
altersdifferenzierter Beanspruchungsprofile.<br />
In: Zeitschrift für Arbeitswissenschaft. 3/2010,<br />
S. 205-215<br />
[4] Schierz, C. (2002). Einfluss der Arbeitsplatzbeleuchtung<br />
auf asthenopische Beschwerden. In: Bericht zum 49.<br />
Kongress der Gesellschaft für Arbeitswissenschaft vom<br />
26.-27. Sep. 2002. Ilmenau: GfA Press<br />
[5] Keil, M. (2011). Konsequenzen des demographischen<br />
Wandels für zukünftige Produktions- und Technologieab<br />
läufe am Beispiel der altersbedingten Veränderungen der<br />
Fähigkeit des Sehens. Dissertationsschrift. Chemnitz:<br />
Wissenschaftliche Schriftenreihe des IBF, Heft 91<br />
[6] Sekuler, A. B., Bennett, P. J., Marmelak, M. (2000). Effects<br />
of aging on the useful field of view. In: Experimental Aging<br />
Research, 26, Nr. 2, S. 103-120<br />
[7] Japanese Industrial Standard (JIS). (2003). JIS S 0032:2003<br />
Guidelines for the elderly and people with disabilities – Visual<br />
signs and displays – Estimation of minimum legible size for<br />
a Japanese single character. Tokyo: Japanese Standard<br />
Association<br />
[8] Schneider, N., Wilkes, J., Grandt, M., Schlick, C. 2008.<br />
Altersgerechte Individualisierung der Mensch-Rechner-<br />
Schnittstelle? In: Wirtschaftspsychologie, 10, S. 106-119<br />
[9] McGrath, C., Morrison, J. D. (1981). The effects of age on<br />
spatial frequency perception in human subjects.<br />
In: Quarterly Journal of Experimental Physiology, Vol. 66,<br />
No. 3, S. 253-261<br />
[10] Wolf, E. (1960). Glare and Age. In: Archives of Ophthalmology,<br />
Vol. 64, No. 4, S. 502-514<br />
[11] Weale, R. A. (1992). The Senescence of Human Vision. New<br />
York: Oxford University Press<br />
[12] Cooper, B. A., Ward, M., Growland, C. A., McIntosh, J. M. (1991).<br />
The use of the Landthony New Color Test in determining the<br />
effects of aging on color vision. In: Journals of Gerontology,<br />
Vol. 46, No. 6, S. 320-324<br />
[13] Schierz, C. (2008). Licht für die ältere Bevölkerung –<br />
Physiologische Grundlagen und ihre Konsequenzen.<br />
In: D.L. e.V., Licht 2008, 10-13. September 2008, Tagungsband<br />
der 18. Gemeinschaftstagung lichttechnischer Gesellschaften,<br />
S. 32-41<br />
80<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012
gesetzt werden. Um die Informationsverarbeitung zu<br />
unterstützen, müssen softwareergonomische Gestaltungsregeln<br />
beachtet werden. Das Hauptaugenmerk<br />
sollte hierbei auf die Dialogregeln der Mensch-Maschine-Interaktion<br />
[25] gelegt werden. Durch eine Verbesserung<br />
der Usability sind Interaktionsvorgänge einfacher<br />
zu erlernen und binden weniger kognitive Ressourcen<br />
[26]. Bei der Informationsumsetzung sind vor allem anthropometrische<br />
Gestaltungsaspekte relevant.<br />
Eine alternsgerechte Schnittstellengestaltung ist keine<br />
Gestaltung nur für Ältere. Vielmehr kommt der Gedanke<br />
des „Design for all“ zum Tragen. So unterstützen alternsgerecht<br />
gestaltete Schnittstellen nicht nur Ältere, sondern<br />
können ebenso den Komfort für jüngere Mitarbeiter<br />
und deren Leistungsfähigkeit erhöhen. Durch eine Verbesserung<br />
der Informationsdarstellung werden auch die<br />
Fähigkeiten und Ressourcen Jüngerer weniger beansprucht,<br />
was wiederum zu geringeren individuellen Beanspruchungen<br />
führt und den Arbeitsablauf effektiver<br />
und effizienter gestaltet. Um industrielle Arbeitsmittel<br />
an den Bedürfnissen und Fähigkeiten der Nutzer auszurichten,<br />
ist es ebenso, wie bei der Entwicklung <strong>von</strong> Produkten<br />
im Consumer-Bereich, sinnvoll, Nutzer in den<br />
Entwicklungsprozess einzubeziehen [27].<br />
ManuskriptEINGaNG<br />
09.05.2012<br />
Im Peer-Review-Verfahren begutachtet<br />
Autor<br />
Dipl.-Wirtsch.-Ing. Frank<br />
Dittrich (geb. 1982) ist<br />
wissenschaftlicher Mitarbeiter<br />
an der Professur Arbeitswissenschaft<br />
des Institutes<br />
für Betriebswissenschaften<br />
und Fabriksysteme der<br />
TU Chemnitz. Sein Arbeitsschwerpunkt<br />
liegt im Bereich<br />
der nutzerzentrierten Produktentwicklung. Neben<br />
Forschungsprojekten führte er zahlreiche Usability-Projekte<br />
mit kleinen und mittleren Unternehmen<br />
durch und ist zudem in Industrieprojekten<br />
mit Großunternehmen eingebunden. Seit 2012<br />
leitet er das Zentrum für nutzerzentrierte Produktentwicklung<br />
(www.znp-online.de) an der<br />
Professur Arbeitswissenschaft.<br />
Zentrum für nutzerzentrierte Produktentwicklung,<br />
Professur Arbeitswissenschaft,<br />
Technische Universität Chemnitz,<br />
Erfenschlager Str. 73, D-09125 Chemnitz,<br />
Tel. +49 (0) 371 53 13 78 78,<br />
E-Mail: frank.dittrich@mb.tu-chemnitz.de<br />
[14] Spoor, A. (1967). Presbycusis values in relation to noise induced<br />
hearing loss. In: International Journal of Audiology, issue 6, pp.<br />
48-57<br />
[15] tun, P. (1998). Fast noisy speech: Age Differences in Processing<br />
Rapid Speech with Background Noise. In: Psychology and<br />
Aging, Vol 13, No. 3, pp. 424-434<br />
[16] bruce, M. F., Sinclair, D. C. (1980). The relationship between<br />
tactile thresholds and histology in the human finger.<br />
In: Journal of Neurology, Neurosurgery, and Psychiatry, 43,<br />
pp. 235-242<br />
[17] Verillo, R. (1980). Age related Changes in the Sensitivity to<br />
Vibration. In: Journal of Gerontology, 1980, Vol. 35, No. 2,<br />
pp. 185-193<br />
[18] Stevens, J. C., Patterson, M. Q. (1995). Dimension of spatial<br />
acuity in the touch sense: Changes of the life span.<br />
In: Somatosensory and Motor Research, Vol. 12, No. 1,<br />
pp. 29-47<br />
[19] park, D. C., Lautenschlager, G., Hedden, T., Davidson, N. S.,<br />
Smith, A. D., Smith, P. K. (2002). Models of visuospatial and<br />
verbal memory across the adult life span. In: Psychology and<br />
Aging, issue 17, pp. 299-320<br />
[20] bruggmann, M. ( 2000). Die Erfahrung älterer Mitarbeiter als<br />
Ressource. Wiesbaden: Dt. Univ.-Verl.<br />
[21] DIN 33402-2 (2005). Ergonomie – Körpermaße des Menschen<br />
– Teil 2: Werte. Berlin: Beuth<br />
[22] Tittlbach, S. (2002). Entwicklung der körperlichen<br />
Leistungsfähigkeit - Eine prospektive Längsschnittstudie<br />
mit Personen im mittleren und späteren Erwachsenenalter.<br />
Schorndorf: Hofmann<br />
[23] Scheffler, C., Voigt, A. (2008). Vergleich statistischer und<br />
dynamischer Körpermaße <strong>von</strong> Jüngeren (20-29 Jahren)<br />
und Älteren (50-85). In: Produktdesign für alle: FÜR JUNG<br />
= FÜR ALT?. BGAB Institut Arbeit und Gesundheit der<br />
Deutschen gesetzlichen Unfallversicherung, Dresden.<br />
S. 125-130<br />
[24] Mathiowetz, V., Kashman, N., Volland, G., Weber, K.,<br />
Dowe, M., Rogers, S. (1985). Grip and Pinch Strentgh:<br />
Normative Data for Adults, In: Arch Phys Med Rehabil,<br />
66, pp. 69-72<br />
[25] DIN EN ISO 9241-110 (2006). Ergonomie der Mensch-System-Interaktion<br />
– Teil 110: Grundsätze der Dialoggestaltung.<br />
Berlin: Beuth<br />
[26] Dittrich, F., Spanner-Ulmer, B. (2010). Industrial-Usability<br />
im Kontext aktueller Trends der industriellen Produktion<br />
– Ganzheitliche Forschung zur Gebrauchstauglichkeit<br />
durch den MTO-Ansatz. 5. VDI Fachtagung USEWarE 2010.<br />
13.-14. Okt. 2010, Baden-Baden, S. 303-314<br />
[27] DIN EN ISO 9241-210 (2011). Ergonomie der Mensch-System-Interaktion<br />
– Teil 210: Prozess zur Gestaltung<br />
gebrauchstauglicher interaktiver Systeme. Berlin: Beuth<br />
<strong>atp</strong> <strong>edition</strong><br />
7- 8 / 2012<br />
81
impressum / <strong>Vorschau</strong><br />
Impressum<br />
<strong>Vorschau</strong><br />
Verlag:<br />
Oldenbourg Industrieverlag GmbH<br />
Rosenheimer Straße 145<br />
D-81671 München<br />
Telefon + 49 (0) 89 4 50 51-0<br />
Telefax + 49 (0) 89 4 50 51-3 23<br />
www.oldenbourg-industrieverlag.de<br />
Geschäftsführer:<br />
Carsten Augsburger, Jürgen Franke<br />
Spartenleiter:<br />
Jürgen Franke<br />
Herausgeber:<br />
Dr. T. Albers<br />
Dr. G. Kegel<br />
Dipl.-Ing. G. Kumpfmüller<br />
Dr. N. Kuschnerus<br />
Beirat:<br />
Dr.-Ing. K. D. Bettenhausen<br />
Prof. Dr.-Ing. Ch. Diedrich<br />
Prof. Dr.-Ing. U. Epple<br />
Prof. Dr.-Ing. A. Fay<br />
Prof. Dr.-Ing. M. Felleisen<br />
Prof. Dr.-Ing. G. Frey<br />
Prof. Dr.-Ing. P. Göhner<br />
Dipl.-Ing. Th. Grein<br />
Prof. Dr.-Ing. H. Haehnel<br />
Dr.-Ing. J. Kiesbauer<br />
Dipl.-Ing. R. Marten<br />
Dipl.-Ing. G. Mayr<br />
Dr. J. Nothdurft<br />
Dr.-Ing. J. Papenfort<br />
Dr. A. Wernsdörfer<br />
Dipl.-Ing. D. Westerkamp<br />
Dr. Ch. Zeidler<br />
Organschaft:<br />
Organ der GMA<br />
(VDI/VDE-Gesell schaft Messund<br />
Automatisierungs technik)<br />
und der NAMUR<br />
(Interessen gemeinschaft<br />
Automatisierungs technik der<br />
Prozessindustrie).<br />
Redaktion:<br />
Anne Hütter (verantwortlich)<br />
Telefon + 49 (0) 89 4 50 51-4 18<br />
Telefax + 49 (0) 89 4 50 51-2 07<br />
E-Mail: huetter@oiv.de<br />
Gerd Scholz<br />
Einreichung <strong>von</strong> Hauptbeiträgen:<br />
Prof. Dr.-Ing. Leon Urbas<br />
(Chefredakteur, verantwortlich<br />
für die Hauptbeiträge)<br />
Technische Universität Dresden<br />
Fakultät Elektrotechnik<br />
und Informationstechnik<br />
Professur für Prozessleittechnik<br />
D-01062 Dresden<br />
Telefon +49 (0) 351 46 33 96 14<br />
E-Mail: urbas@oiv.de<br />
Fachredaktion:<br />
Dr.-Ing. M. Blum<br />
Prof. Dr.-Ing. J. Jasperneite<br />
Dr.-Ing. B. Kausler<br />
Dr.-Ing. N. Kiupel<br />
Dr. rer. nat. W. Morr<br />
Dr.-Ing. J. Neidig<br />
Dipl.-Ing. I. Rolle<br />
Dr.-Ing. S. Runde<br />
Prof. Dr.-Ing. F. Schiller<br />
Bezugsbedingungen:<br />
„<strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische<br />
Praxis“ erscheint<br />
monatlich mit Doppelausgaben im<br />
Januar/Februar und Juli/August.<br />
Bezugspreise:<br />
Abonnement jährlich: € 468,– + € 30,–/<br />
€ 35,- Versand (Deutschland/Ausland);<br />
Heft-Abbonnement + Online-Archiv:<br />
€ 638,40; ePaper (PDF): € 468,–;<br />
ePaper + Online-Archiv: € 608,40;<br />
Einzelheft: € 55,– + Versand;<br />
Die Preise enthalten bei Lieferung<br />
in EU-Staaten die Mehrwertsteuer,<br />
für alle übrigen Länder sind es<br />
Nettopreise. Mitglieder der GMA: 30%<br />
Ermäßigung auf den Heftbezugspreis.<br />
Bestellungen sind jederzeit über den<br />
Leserservice oder jede Buchhandlung<br />
möglich.<br />
Die Kündigungsfrist für Abonnementaufträge<br />
beträgt 8 Wochen zum Bezugsjahresende.<br />
Abonnement-/<br />
Einzelheftbestellung:<br />
Leserservice <strong>atp</strong><br />
Postfach 91 61, D-97091 Würzburg<br />
Telefon + 49 (0) 931 4170-1615<br />
Telefax + 49 (0) 931 4170-492<br />
E-Mail: leserservice@oiv.de<br />
Verantwortlich für<br />
den Anzeigenteil:<br />
Annemarie Scharl-Send<br />
Mediaberatung<br />
sales & communications Medienagentur<br />
Kirchfeldstraße 9, D-82284 Grafrath<br />
Tel. +49 (0) 8144 9 96 95 12<br />
Fax +49 (0) 8144 9 96 95 14<br />
E-Mail: ass@salescomm.de<br />
Es gelten die Preise der Mediadaten 2012<br />
Anzeigenverwaltung:<br />
Brigitte Krawczyk<br />
Telefon + 49 (0) 89 4 50 51-2 26<br />
Telefax + 49 (0) 89 4 50 51-3 00<br />
E-Mail: krawczyk@oiv.de<br />
Art Director:<br />
Deivis Aronaitis | dad |<br />
Druck:<br />
Druckerei Chmielorz GmbH<br />
Ostring 13,<br />
D-65205 Wiesbaden-Nordenstadt<br />
Gedruckt auf chlor- und<br />
säurefreiem Papier.<br />
Die <strong>atp</strong> wurde 1959 als „Regelungstechnische<br />
Praxis – rtp“ gegründet.<br />
© 2012 Oldenbourg Industrieverlag<br />
GmbH München<br />
Die Zeitschrift und alle in ihr enthaltenen<br />
Beiträge und Abbildungen sind urheberrechtlich<br />
geschützt. Mit Ausnahme der<br />
gesetzlich zugelassenen Fälle ist eine<br />
Verwertung ohne Ein willigung des Verlages<br />
strafbar.<br />
Gemäß unserer Verpflichtung nach § 8<br />
Abs. 3 PresseG i. V. m. Art. 2 Abs. 1c DVO<br />
zum BayPresseG geben wir die Inhaber<br />
und Beteiligungsverhältnisse am Verlag<br />
wie folgt an:<br />
Oldenbourg Industrieverlag GmbH,<br />
Rosenheimer Straße 145, 81671 München.<br />
Alleiniger Gesellschafter des Verlages<br />
ist die ACM-Unternehmensgruppe,<br />
Ostring 13,<br />
65205 Wiesbaden-Nordenstadt.<br />
ISSN 2190-4111<br />
Die Ausgabe 9 / 2012 der<br />
erscheint am 03.09.2012<br />
Mit folgenden Beiträgen:<br />
Systemkomplexität in der<br />
Automation beherrschen<br />
Offenheitsmetrik für<br />
Engineering-Werkzeuge<br />
Entwurfsassistenz in der<br />
Gebäudeautomation<br />
Automatisierte Diagnose<br />
für Inbetriebnahme<br />
...und vielen weiteren Themen.<br />
Aus aktuellem Anlass können sich die Themen<br />
kurzfristig verändern.<br />
LeserService<br />
e-Mail:<br />
leserservice@oiv.de<br />
Telefon:<br />
+ 49 (0) 931 4170-1615<br />
82<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2012
SIL<br />
Sprechstunde<br />
4. SIL-Sprechstunde<br />
Funktionale Sicherheit<br />
18. + 19.9.2012, Mannheim, Pepperl+Fuchs GmbH<br />
www.sil-sprechstunde.de<br />
PLT-Schutzeinrichtung<br />
Programm<br />
Moderation: Jürgen George,<br />
Pepperl+Fuchs GmbH<br />
Wann und Wo?<br />
Prinzip der SIL-Bewertung<br />
Parameter der SIL-Bewertung<br />
Vermeidung systematischer Fehler<br />
Bewertung zufälliger Fehler<br />
Gerätequalifikation aufgrund „früherer Verwendung“<br />
Referenten<br />
Dirk Hablawetz, BASF SE<br />
Dr. Andreas Hildebrandt, Pepperl+Fuchs GmbH<br />
Udo Hug, BImSchG § 29a Sachverständiger<br />
Gerhard Jung, Pepperl+Fuchs GmbH<br />
Dr. Thomas Karte, Samson AG<br />
Dr. Gerold Klotz-Engmann, Endress+Hauser Messtechnik<br />
GmbH + Co. KG<br />
Josef Kuboth, Landesamt für Natur, Umwelt und Verbraucherschutz<br />
Nordrhein-Westfalen<br />
Bernd Schroers, Bayer Technology Services<br />
Heiko Schween, HIMA Paul Hildebrandt GmbH + Co KG<br />
Johann Ströbl, TÜV Süd Industrie Service GmbH<br />
Termin<br />
Dienstag, 18.09.2012<br />
Veranstaltung (11:30 – 16:30 Uhr)<br />
„Get-Together“ mit Abendessen<br />
(ab 17:30 Uhr)<br />
Mittwoch, 19.09.2012<br />
Veranstaltung (9:00 – 15:00 Uhr)<br />
Ort<br />
Mannheim, Pepperl+Fuchs GmbH<br />
Thema<br />
SIL – Qualifizierung <strong>von</strong><br />
PLT-Schutzeinrichtungen<br />
Teilnahmegebühr<br />
<strong>atp</strong> <strong>edition</strong>-Abonnenten 540 € zzgl. MwSt<br />
Firmenempfehlung 590 € zzgl. MwSt<br />
reguläre Teilnahmegebühr 690 € zzgl. MwSt<br />
Im Preis enthalten sind die Tagungsunterlagen<br />
sowie das Catering (Kaffee, 2x Mittagsimbiss,<br />
„Get-Together“ mit Abendessen).<br />
Veranstalter<br />
Fragen Sie!<br />
Die Explosionsschutz-Sprechstunde gibt Ihnen ausreichend Gelegenheit,<br />
Ihre individuellen Fragen zu stellen und offen mit den praxiserfahrenen<br />
Referenten zu diskutieren.<br />
Stellen Sie Ihre Fragen rechtzeitig unter www.sil-sprechstunde.de<br />
Weitere Informationen und Online-Anmeldung<br />
unter www.sil-sprechstunde.de<br />
Fax-Anmeldung: +49 (0) 89 45051-323 oder Online-Anmeldung: www.sil-sprechstunde.de<br />
Ich habe die <strong>atp</strong> <strong>edition</strong> abonniert<br />
Ich komme auf Empfehlung <strong>von</strong> Firma: .....................................................................................................................................................................<br />
Vorname Nachname<br />
Telefon<br />
Telefax<br />
Firma/Institution<br />
E-Mail<br />
Straße/Postfach<br />
Land, PLZ, Ort<br />
Hausnummer<br />
✘<br />
Ort, Datum, Unterschrift<br />
Ihre freiwilligen Angaben werden zusammen mit den für die Vertragsabwicklung erforderlichen Daten <strong>von</strong> uns und der Unternehmensgruppe, unseren Dienstleistern sowie anderen<br />
ausgewählten Unternehmen verarbeitet und genutzt, um Sie über Produkte und Dienstleistungen zu informieren.<br />
Wenn Sie dies nicht mehr wünschen, schreiben Sie bitte an: Oldenbourg Industrieverlag, Rosenheimer Str. 145, D-81671 München
Die Referenzklasse für die<br />
Automatisierungstechnik<br />
Erfahren Sie auf höchstem inhaltlichen Niveau, was die<br />
Automatisierungsbranche bewegt. Alle Hauptbeiträge<br />
werden in einem Peer-Review-Verfahren begutachtet,<br />
um Ihnen maximale inhaltliche Qualität zu garantieren.<br />
Sichern Sie sich jetzt dieses erstklassige Lektüreerlebnis.<br />
Als exklusiv ausgestattetes Heft sowie als praktisches<br />
e-Paper – ideal für unterwegs, auf mobilen Endgeräten<br />
oder zum Archivieren.<br />
Gratis für Sie: Der Tagungsband AALE 2012 als e-Paper<br />
Das Kompendium bietet eine Zusammenstellung der Fachreferate des 9. Fachkolloquiums<br />
für angewandte Automatisierungstechnik in Lehre und Entwicklung an Fachhochschulen.<br />
Die Veranstaltung versteht sich als Forum für Fachleute der Automatisierungstechnik aus<br />
Hochschulen und Wirtschaft. Sie wird <strong>von</strong> der Fakultät Mechatronik und Elektrotechnik der<br />
Hochschule Esslingen mit Unterstützung des VFAALE und dem Kompetenzzentrum<br />
Mechatronik BW e.V. organisiert und ausgerichtet.<br />
1. Aufl age 2012, 399 Seiten, Broschur<br />
<strong>atp</strong> <strong>edition</strong> erscheint in der Oldenbourg Industrieverlag GmbH, Rosenheimerstr. 145, 81671 München<br />
Oldenbourg-Industrieverlag<br />
www.<strong>atp</strong>-online.de<br />
Vorteilsanforderung per Fax: +49 (0) 931 / 4170 - 492 oder im Fensterumschlag einsenden<br />
Ja, ich möchte <strong>atp</strong> <strong>edition</strong> im Abo-plus-Paket lesen.<br />
Bitte schicken Sie mir die Fachpublikation für zunächst ein Jahr (12 Ausgaben) als gedrucktes Heft<br />
+ digital als e-Paper (PDF-Datei als Einzellizenz) für € 638,40 (Deutschland) / € 643,40 (Ausland).<br />
Als Dankeschön erhalte ich den Tagungsband AALE 2012 gratis als e-Book.<br />
Nur wenn ich nicht bis <strong>von</strong> 8 Wochen vor Bezugsjahresende kündige, verlängert sich der Bezug um<br />
ein Jahr.<br />
Die sichere, pünktliche und bequeme Bezahlung per Bankabbuchung wird mit einer Gutschrift <strong>von</strong><br />
€ 20,- auf die erste Jahresrechung belohnt.<br />
Firma/Institution<br />
Vorname/Name des Empfängers<br />
Straße/Postfach, Nr.<br />
Land, PLZ, Ort<br />
Telefon<br />
Telefax<br />
Antwort<br />
Leserservice <strong>atp</strong><br />
Postfach 91 61<br />
97091 Würzburg<br />
E-Mail<br />
Branche/Wirtschaftszweig<br />
Bevorzugte Zahlungsweise □ Bankabbuchung □ Rechnung<br />
Bank, Ort<br />
Bankleitzahl<br />
✘<br />
Kontonummer<br />
Widerrufsrecht: Sie können Ihre Vertragserklärung innerhalb <strong>von</strong> 14 Tagen ohne Angabe <strong>von</strong> Gründen in Textform (Brief, Fax, E-Mail) oder durch<br />
Rücksendung der Sache widerrufen. Die Frist beginnt nach Erhalt dieser Belehrung in Textform. Zur Wahrung der Widerrufsfrist genügt die rechtzeitige<br />
Datum, Unterschrift<br />
PAATPE0312<br />
Absendung des Widerrufs oder der Sache an den Leserservice <strong>atp</strong>, Franz-Horn-Str. 2, 97082 Würzburg.<br />
Nutzung personenbezogener Daten: Für die Auftragsabwicklung und zur Pfl ege der laufenden Kommunikation werden personenbezogene Daten erfasst, gespeichert und verarbeitet. Mit dieser Anforderung er kläre ich mich damit einverstanden, dass ich vom<br />
Oldenbourg Industrieverlag oder vom Vulkan-Verlag □ per Post, □ per Telefon, □ per Telefax, □ per E-Mail, □ nicht über interessante, fachspezifi sche Medien- und Informationsangebote informiert und beworben werde. Diese Erklärung kann ich mit Wirkung für<br />
die Zukunft jederzeit widerrufen.