atp edition Datenkopplung mittels UML-Modellen (Vorschau)
Verwandeln Sie Ihre PDFs in ePaper und steigern Sie Ihre Umsätze!
Nutzen Sie SEO-optimierte ePaper, starke Backlinks und multimediale Inhalte, um Ihre Produkte professionell zu präsentieren und Ihre Reichweite signifikant zu maximieren.
12 / 2013<br />
55. Jahrgang B3654<br />
DIV Deutscher Industrieverlag GmbH<br />
Automatisierungstechnische Praxis<br />
<strong>Datenkopplung</strong> <strong>mittels</strong><br />
<strong>UML</strong>-<strong>Modellen</strong> | 26<br />
Modell zur Beschreibung<br />
cyber-physischer Systeme | 38<br />
Nur Befehle befolgt | 46<br />
Komponentenkapselung<br />
und -selbstbeschreibung | 54
<strong>atp</strong> <strong>edition</strong> – die Referenzklasse<br />
der Automatisierungstechnik
EDITORIAL<br />
Industrie 4.0 – was nun?<br />
Die Vorträge sind gehalten, alle Statements abgegeben, Positionspapiere und<br />
Marketingaussagen ausgetauscht, eine Vielzahl von Arbeitskreisen gegründet.<br />
– Wie soll es nun weitergehen mit Industrie 4.0?<br />
Das Ziel des Zukunftsprojekts Industrie 4.0 ist die Optimierung der Organisation<br />
und Steuerung von Wertschöpfungsketten im Umfeld der industriellen Produktion.<br />
Erreicht werden soll dies auf der Grundlage einer durchgängigen IT-<br />
Unterstützung über den gesamten Lebenszyklus. Diese von der Verbändeplattform<br />
Industrie 4.0 in ihrer Definition (www.plattform-i40.de) ausgegebene<br />
Orientierung lenkt den Fokus auf den wirtschaftlichen Nutzen für die Industrie.<br />
IT-Konzepte sind also nicht Selbstzweck, sondern dienen dem Erreichen des<br />
beschriebenen Ziels.<br />
Um den wirtschaftlichen Nutzen möglichst frühzeitig zu generieren und die<br />
Entwicklung nachhaltig abzusichern, müssen die neuen IT-Konzepte stufenweise<br />
eingeführt werden. Im Stufenkonzept muss jede Stufe für sich einen signifikanten<br />
Nutzen generieren, und die Stufen müssen so gestaltet sein, dass Anwendungen<br />
bei der Implementierung einer neuen Stufe lauffähig bleiben.<br />
Im Fachausschuss 7.21 „Industrie 4.0“ der GMA wird an einem Vorschlag für eine<br />
Referenzarchitektur gearbeitet, die eine solche stufenweise Einführung erlaubt.<br />
Ziel der ersten Stufe ist die Schaffung einer Systemschicht, die einen dienstbasierten<br />
Zugriff auf alle Informationen des verteilten Systems ermöglicht. Dazu<br />
gehören Konzepte zur einheitlichen Repräsentanz von Objekten und Merkmalen<br />
im Dienstsystem. Schwerpunkt der zweiten Stufe sind Konzepte zur automatisierten<br />
Verteilung und Virtualisierung der Lokalität der Objekte und Dienste im<br />
Netzwerk. In diese Kategorie fallen zum Beispiel die Cloud-Konzepte. Der industrielle<br />
Einsatz von SelfX-Konzepten, adaptiven Netzwerkstrukturen und KI-<br />
Anwendungen wird erst in einer dritten Stufe erwartet. Eine Anforderung an<br />
das Design der ersten Stufe ist die direkte industrielle Realisierbarkeit als Systemplattform.<br />
Diese muss so gestaltet sein, dass sie später durch die IT-Konzepte<br />
der nächsten Stufen kompatibel ergänzt werden kann.<br />
Ziel muss es sein, im Verlauf der nächsten Monate mit allen Beteiligten – Wissenschaft,<br />
Hersteller und Anwender – unter Führung der Verbändeplattform<br />
einen Plan abzustimmen, der beschreibt, wie unsere Industrie-4.0-IT-Systemlandschaft<br />
morgen aussehen soll, wie übermorgen und wie überübermorgen.<br />
Eine wichtige Voraussetzung dafür ist eine kritische Analyse der neuen IT-<br />
Konzepte auf ihren konkreten Nutzen, den grundsätzlichen Forschungsbedarf,<br />
den Standardisierungs- und Normungsbedarf, den erwarteten Entwicklungsaufwand,<br />
ihre konzeptionelle Einbindbarkeit in die bestehenden Systeme und Prozesse<br />
und die Erfüll- und Nachweisbarkeit der geforderten QoS-Eigenschaften<br />
beziehungsweise der nichtfunktionalen Eigenschaften. Es muss Klarheit geschaffen<br />
werden, welche IT-Konzepte reif sind für die Anwendung in der industriellen<br />
Automation und welche Konzepte zwar Nutzenpotenziale versprechen aber die<br />
Voraussetzungen für einen flächendeckenden Einsatz in der industriellen Automation<br />
in den nächsten Jahren vermutlich nicht erfüllen.<br />
Auf der Grundlage von geprüften und standardisierten IT-Konzepten und einem<br />
in der Fachwelt abgestimmten Einführungs-Stufenplan kann eine zügige<br />
und nachhaltige Umsetzung gelingen, bei Herstellern und Anwendern schnell<br />
Nutzen schaffen und das Zukunftsprojekt Industrie 4.0 zum Erfolg führen.<br />
PROF. DR.-ING.<br />
ULRICH EPPLE,<br />
RWTH Aachen, Lehrstuhl für<br />
Prozessleittechnik<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
3
INHALT 12 / 2013<br />
VERBAND<br />
6 | Markt für elektronische Komponenten<br />
wächst dank Halbleiter-Nachfrage wieder<br />
Technik der Prozessanalyse praktisch betrachtet<br />
VCI: Energiewende nicht um jeden Preis<br />
7 | IEC 62708: Internationale Arbeitsgruppe erarbeitet<br />
Baustein zur besseren Verständigung<br />
FORSCHUNG<br />
8 | Technoseum will mit neuer Initiative<br />
Jugendliche für Technik begeistern<br />
Automation 2014: Call for Papers ist online<br />
9 | Call for experts: Lebenszyklusmanagement<br />
und Total Cost of Ownership<br />
BRANCHE<br />
10 | Automatisierung der Zukunft verlangt dezentrale Steuerung,<br />
Modularität und Wiederverwendbarkeit<br />
12 | PC-basierte Steuerungstechnik als Grundlage<br />
für Entwicklung von Industrie 4.0<br />
RUBRIKEN<br />
3 | Editorial<br />
62 | Impressum, <strong>Vorschau</strong><br />
4<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
PRAXIS<br />
16 | Elektromagnetische Verträglichkeit:<br />
Für industrielle Umgebungen ist sie<br />
besonders wichtig<br />
18 | Frequenzumrichter für den Bergbau<br />
erfüllen hohe Anforderungen bei unwirtlichen<br />
Bedingungen<br />
22 | Komplette Sicherheitslösung modernisiert<br />
größte Bowling-Anlage in Nordrhein-Westfalen<br />
Produkte,<br />
Systeme<br />
und Service<br />
für die<br />
Prozessindustrie?<br />
Natürlich.<br />
HAUPTBEITRÄGE<br />
26 | <strong>Datenkopplung</strong> <strong>mittels</strong> <strong>UML</strong>-<strong>Modellen</strong><br />
B. VOGEL-HEUSER UND B. FEIZ-MARZOUGHI<br />
38 | Modell zur Beschreibung<br />
cyber-physischer Systeme<br />
U. DÖBRICH UND R. HEIDEL<br />
46 | Nur Befehle befolgt<br />
W. SPETH<br />
54 | Komponentenkapselung<br />
und -selbstbeschreibung<br />
W. HERFS, W. LOHSE, D. ÖZDEMIR UND A. MALIK<br />
System 800xA 5.1 hilft Anlagen<br />
noch effizienter zu betreiben<br />
und die Produktivität und Rentabilität<br />
zu verbessern. Dies wird durch<br />
gesteigerte Bediener-Effizienz,<br />
optimiertes Handling bei Batch-<br />
Produktion, effizientere Sequenzkonfiguration,<br />
verbesserte<br />
Asset-Verwendung und optimierte<br />
Engineering Best Practices erreicht.<br />
Wünschen Sie sich auch so eine<br />
effiziente Anlagenbedienung?<br />
www.abb.de/controlsystems<br />
Wussten Sie, dass Ihnen ABB<br />
neben maßgeschneiderten<br />
Leitsystemen ein umfassendes<br />
Portfolio für die Instrumentierung,<br />
herausragende Produkte und<br />
Lösungen für die Analysentechnik<br />
sowie erstklassigen Service bietet?<br />
Lesen Sie mehr unter:<br />
www.abb.de/<br />
prozessautomatisierung<br />
ABB Automation GmbH<br />
Tel.: +49 (0) 1805 26 67 76<br />
marketing.control-products@de.abb.com
VERBAND<br />
Markt für elektronische Komponenten<br />
wächst dank Halbleiter-Nachfrage wieder<br />
Nach Ansicht des ZVEI-Fachverbands Electronic Components<br />
and Systems wird der deutsche Markt für elektronische<br />
Komponenten in diesem Jahr einen Anstieg um<br />
knapp drei Prozent auf gut 17 Milliarden Euro hinlegen.<br />
Das Nachkrisenjahr 2010 war von einer starken Erholung<br />
mit über 40 Prozent Wachstum geprägt. 2011 hatte<br />
diese sich fortgesetzt, allerdings nicht mehr so stark.<br />
„Nach einem Rückgang der Umsätze im vergangenen Jahr<br />
um knapp fünf Prozent wird der Markt für elektronische<br />
Komponenten im laufenden und kommenden Jahr wieder<br />
an Dynamik gewinnen“, sagt Kurt Sievers, Vorsitzender<br />
des ZVEI-Fachverbands. „Risiken bergen allerdings die<br />
Krisenherde im Nahen Osten und die anhaltende europäische<br />
Schuldenkrise.“ Die positive Marktentwicklung<br />
wird nach Einschätzung der Experten vor allem getragen<br />
von der anziehenden Nachfrage nach Halbleiterbauelementen,<br />
die mit einem Anteil von über 60 Prozent den<br />
Gesamtmarkt dominieren.<br />
Eine ähnliche Wachstumsrate wie der<br />
deutsche Markt zeigt der Weltmarkt<br />
für elektronische Komponenten im<br />
laufenden Jahr. Er wird um gut drei<br />
Prozent auf zirka 474 Milliarden US-<br />
Dollar steigen. Im Jahr 2014 erwartet<br />
der Verband einen Anstieg des Weltmarkts<br />
für elektronische Bauelemente<br />
um fünf Prozent auf 497 Milliarden<br />
US-Dollar. Der europäische Markt<br />
wird um gut drei Prozent wachsen<br />
und einen Umsatz von rund 62 Milliarden<br />
US-Dollar erreichen. (aha)<br />
ZVEI – ZENTRALVERBAND ELEKTROTECHNIK-<br />
UND ELEKTRONIKINDUSTRIE E.V.,<br />
Lyoner Straße 9, D-60528 Frankfurt am Main,<br />
Tel. +49 (0) 69 630 20, Internet: www.zvei.org<br />
Technik der Prozessanalyse praktisch betrachtet<br />
KURT SIEVERS,<br />
Vorsitzender des<br />
ZVEI-Fachverbandes<br />
Electronic Components,<br />
blickt zuversichtlich<br />
auf das<br />
kommende Jahr.<br />
(Bild: ZVEI)<br />
BEI DER FACH-<br />
KONFERENZ<br />
„Prozessanalytische<br />
Messtechnik in der<br />
Chemieindustrie“ am<br />
26. und 27. Februar 2014<br />
diskutieren Experten<br />
Anwendungs beispiele.<br />
(Bild: VDI Wissensforum)<br />
Auf der VDI-Fachkonferenz „Prozessanalytische Messtechnik<br />
in der Chemieindustrie“ am 26. und 27. Februar<br />
2014 in Köln werden Möglichkeiten und Grenzen<br />
der Messgeräte und Sensoren in verschiedenen Anwendungen<br />
thematisiert. Unter der fachlichen Leitung von<br />
Dr. Michael Zöchbauer, Leiter Forschung und Entwick-<br />
Die Energiewende darf nicht zulasten von Arbeitsplätzen<br />
gehen. Das meint, laut einer repräsentativen Umfrage<br />
des Verbands der Chemischen Industrie (VCI), ein<br />
Großteil der deutschen Führungskräfte. Das Nürnberger<br />
Marktforschungsinstitut Trend & Move hatte im Auftrag<br />
des VCI 700 Führungskräfte und -anwärter aus Politik,<br />
Behörden, Wirtschaft, Wissenschaft und Medien zur Energiewende<br />
befragt. Demnach befürworten 77 Prozent der<br />
heutigen und angehenden Führungskräfte die von der<br />
Bundesregierung beauftragte Umstellung, sie dürfe den<br />
Wirtschaftsstandort Deutschland jedoch nicht schwälung<br />
bei Sick, diskutieren Experten über Erfahrungen mit<br />
der Prozessanalysentechnik im täglichen Betrieb.<br />
Auf der Konferenz befassen sich Fachleute unter anderem<br />
mit Einsatz- und Entwicklungspotenzialen der dialektrischen<br />
Hochfrequenzspektroskopie. Sie erörtern<br />
Möglichkeiten, virtuelle Gassensor-Arrays als Elektronische<br />
Nase zu verwenden. Wie sich die Röntgenfloureszenzanalyse<br />
zur Festkörper- und Flüssigkeitsanalyse nutzen<br />
lässt, ist ebenfalls Thema eines Vortrags. Am Vortag<br />
der Konferenz, 25. Februar 2014, bietet das VDI Wissensforum<br />
ein Spezialseminar zum Thema „Statische Versuchsplanung<br />
in der Chemie“ an. Konferenz und Spezialseminar<br />
können zu einem reduzierten Kombipreis gebucht<br />
werden. Wer an der Veranstaltung teilnehmen möchte,<br />
kann sich unter www.vdi.de/prozessanalysentechnik das<br />
Programm ansehen und sich anmelden.<br />
(aha)<br />
VDI WISSENSFORUM GMBH,<br />
VDI-Platz 1, D-40468 Düsseldorf,<br />
Tel. +49 (0) 211 621 40, Internet: www.vdi.de<br />
VCI: Energiewende nicht um jeden Preis<br />
chen. Die erfolgreiche Umsetzung der Energiewende ist<br />
wichtiges Ziel – aber nicht um jeden Preis. Sie muss mit<br />
einer Stärkung des Industrielandes Deutschland und der<br />
Sicherung von Arbeitsplätzen einhergehen“, sagt der VCI-<br />
Hauptgeschäftsführer Utz Tillmann.<br />
(aha)<br />
VERBAND DER CHEMISCHEN INDUSTRIE E.V.,<br />
Mainzer Landstraße 55,<br />
D-60329 Frankfurt am Main,<br />
Tel. +49 (0) 69 255 60,<br />
Internet: www.vci.de<br />
6<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
IEC 62708: Internationale Arbeitsgruppe erarbeitet<br />
Baustein zur besseren Verständigung<br />
DKE: In der Anlagenplanung Dokumente weltweit einheitlich benennen<br />
Document kind Type de Document DCC Identifier<br />
Material safety data sheet (MSDS) Fiche technique de sécurité QB 004<br />
Certificate Certificat QC 001<br />
Test report Procès-verbal d'essai QC 002<br />
Acceptance documentation Documentation de réception QC 003<br />
Test sheet for SIF<br />
Feuille d'essai pour appareillages de QC 004<br />
protection<br />
SIL verification Contrôle SIL QC 005<br />
Installation drawing (hook-up) Schéma du montage TC 001<br />
Assembly drawing Dessin de montage TC 002<br />
Document kind Type de Document DCC Identifier<br />
Material safety data sheet (MSDS) Fiche technique de sécurité QB 004<br />
Certificate Certificat QC 001<br />
Test report Procès-verbal d'essai QC 002<br />
Acceptance documentation Documentation de réception QC 003<br />
Test sheet for SIF<br />
Feuille d'essai pour appareillages de QC 004<br />
protection<br />
SIL verification Contrôle SIL QC 005<br />
Installation drawing (hook-up) Schéma du montage TC 001<br />
Assembly drawing Dessin de montage TC 002<br />
AUSZUG AUS IEC 62708: Der Standard liefert in unterschiedlichen<br />
Sprachen einheitliche Benennungen für Dokumente.<br />
Table A.3 — Names of Document kinds in Chinese and German<br />
文 件 种 类 Dokumentenart DCC Identifier<br />
文 件 列 表 Dokumentenliste AB 001<br />
剩 余 工 作 清 单 Restpunktliste BB 001<br />
工 作 分 解 结 构 Projektstrukturplan BD 001<br />
沟 通 计 划 Kommunikationsplan BD 002<br />
项 目 实 施 计 划 Projektabwicklungsplan BD 003<br />
人 力 动 员 计 划 Personaleinsatzplan BE 001<br />
时 间 表 Terminplan BE 002<br />
M限 制 出 口 设 备 清 单<br />
Liste ausfuhrkritischer<br />
it dem neuen internationalen Ausrüstungen Standard IEC 62708<br />
wird es in Kürze eine weltweit einheitliche Basis für<br />
die Bezeichnung von Dokumenten der Anlagenplanung<br />
geben. Auf Initiative des Deutsche Kommisssion Elektrotechnik<br />
Elektronik Informationstechnik im DIN und VDE<br />
(DKE) 总 体 设 计 Arbeitskreises 要 求<br />
K941 Engineering Allgemeine hat sich über vier<br />
Engineeringspezifikation<br />
Jahre eine internationale Arbeitsgruppe der IEC damit<br />
befasst, solche Dokumente zu sammeln und zu dokumentieren.<br />
Diese Arbeiten stehen nun kurz vor dem Abschluss.<br />
Auslöser für die Entwicklung des Standards ist das<br />
Verwirrspiel um die Bezeichnung eines Dokuments. In<br />
allen Unternehmen gibt es eine traditionelle Bezeichnung<br />
für ein Dokument, aber keine einheitliche über<br />
die Unternehmensgrenze hinaus. So kennt man in einigen<br />
Unternehmen eine PLT-Stellenliste, in anderen<br />
eine Messstellenliste und in wieder anderen eine Instrumentenliste.<br />
Diese Dokumente haben dann oftmals<br />
ähnliche Inhalte und könnten Synonyme sein, wenn<br />
nicht zum Beispiel die Vorstellungen davon, was eine<br />
Instrumentenliste beinhaltet, so stark differieren würden.<br />
Andere schöne Beispiele lassen sich leicht finden<br />
und machen die Vereinbarung von Ingenieurleistungen<br />
jedes Mal einer Abstimmung bedürftig.<br />
Zu Beginn der Entwicklung wurden von allen Beteiligten<br />
der Arbeitsgruppe Referenzen und Beispiele für<br />
typische Dokumente aus der Elektro- und Leittechnikplanung<br />
gesammelt und abgestimmt. Eine wichtige Referenz<br />
war hier die IEC 61355, die einen Standard für die<br />
Klassifikation von Dokumenten liefert. Dieser Standard<br />
hilft jedoch nur die richtige Kodierung (Dokumentart-<br />
Klassenschlüssel) für eine Dokumentenart zu finden, sie<br />
normiert keine Dokumentenarten. Dies ist nun die Aufgabe<br />
der IEC 62708, zumindest in den ihr gegebenen Anwendungsbereichen.<br />
BF 001<br />
仪 表 数 据 表 PLT-Stellenblatt DA 001<br />
标 识 系 统 标 识 制 Kennzeichnungssystem DB 001<br />
测 试 与 维 护 建 议 Prüf- und Wartungsanleitung DC 001<br />
使 用 说 明 书 Betriebsanleitung DC 002<br />
测 试 与 维 护 要 求 Prüf- und Wartungsvorschrift DZ 001<br />
EC 001<br />
电 气 易 耗 品 表 Liste elektrischer Verbraucher EC 002<br />
照 明 概 念 设 计 大 纲 Beleuchtungskonzept EC 003<br />
Im Ergebnis der Arbeiten sind die Dokumente mit einer<br />
Dokumentenart klassifiziert, mit einer Beschreibung<br />
versehen und der notwendige Inhalt definiert. Damit<br />
dies einfacher zu erfassen ist, wurden Muster von Dokumenten<br />
beigelegt und die Dokumentenart in mehreren<br />
Sprachen benannt. Es liegen mit Englisch, Französisch,<br />
Deutsch und Chinesisch bereits wichtige Abwicklungssprachen<br />
vor. Mitte August 2013 wurde der CDV<br />
vom IEC TC 65 mit großer Mehrheit angenommen. Da<br />
nur geringfügige Änderungen zu erwarten sind, ist die<br />
Ausgabe des Standards Mitte 2014 realistisch.<br />
AUTOR<br />
Table A.3 — Names of Document kinds in Chinese and German<br />
文 件 种 类 Dokumentenart DCC Identifier<br />
62708 IEC:2011 – 22 – 62708 CEI:2011<br />
文 件 列 表 Dokumentenliste AB 001<br />
剩 余 工 作 清 单 Restpunktliste BB 001<br />
工 作 分 解 结 构 Projektstrukturplan BD 001<br />
沟 通 计 划 Kommunikationsplan BD 002<br />
项 目 实 施 计 划 Projektabwicklungsplan BD 003<br />
人 力 动 员 计 划 Personaleinsatzplan BE 001<br />
时 间 表 Terminplan BE 002<br />
限 制 出 口 设 备 清 单<br />
Liste ausfuhrkritischer<br />
BF 001<br />
Ausrüstungen<br />
仪 表 数 据 表 PLT-Stellenblatt DA 001<br />
标 识 系 统 标 识 制 Kennzeichnungssystem DB 001<br />
测 试 与 维 护 建 议 Prüf- und Wartungsanleitung DC 001<br />
使 用 说 明 书 Betriebsanleitung DC 002<br />
测 试 与 维 护 要 求 Prüf- und Wartungsvorschrift DZ 001<br />
总 体 设 计 要 求<br />
Allgemeine<br />
EC 001<br />
Engineeringspezifikation<br />
电 气 易 耗 品 表 Liste elektrischer Verbraucher EC 002<br />
照 明 概 念 设 计 大 纲 Beleuchtungskonzept EC 003<br />
Dipl.-Ing. SVEN SCHÜLER<br />
ist Head of Electrical &<br />
Instrumentation bei<br />
ThyssenKrupp Uhde in Bad<br />
Soden/Taunus, Mitarbeiter<br />
im DKE K941 und Convenor<br />
der IEC TC65 WG15.<br />
ThyssenKrupp Uhde GmbH,<br />
Friedrich-Uhde-Straße 2,<br />
D-65812 Bad Soden am Taunus,<br />
Tel. +49 (0) 6196 205 16 51,<br />
E-Mail: sven.schueler@thyssenkrupp.com<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
7
FORSCHUNG<br />
Technoseum will mit neuer Initiative<br />
Jugendliche für Technik begeistern<br />
Jugend für Technik“ ist eine Initiative des Landesmuseum<br />
für Technik und Arbeit (Technoseum) und will<br />
durch ungewöhnliche Aktionen Kinder und Jugendliche<br />
an naturwissenschaftliche und technische Themen heranführen.<br />
Mit einer Guerilla-Aktion, einem ungewöhnlichen<br />
Werbefeldzug, in baden-württembergischen Städten<br />
sorgte die Initiative bereits in der Nacht vom 14. auf<br />
den 15. Oktober 2013 für Aufmerksamkeit. In den Goethestraßen<br />
des Landes plakatierten jugendliche Helfer den<br />
Dichter, abgebildet mit Laptop und der Frage „Hätte Goethe<br />
so Faust III geschrieben?“.<br />
Damit wollen die Macher kreativ die nachhaltige Wirkung<br />
technischer Errungenschaften deutlich machen.<br />
„Wir schaffen mit der Initiative ein Dach, unter dem Aktivitäten<br />
und Partner zusammenkommen“, erklärt Technoseum-Direktor<br />
Prof. Dr. Hartwig Lüdtke. Er hat dabei<br />
besonders Kooperationen mit Industrie- und Handelskammern,<br />
Handwerkskammern, politischen Entscheidungsträgern,<br />
anderen Bildungseinrichtungen sowie<br />
Wirtschaftsunternehmen im Blick.<br />
Zu der Auftaktaktion im Oktober soll in den kommenden<br />
Wochen ein Kino-Spot mit Johann Wolfgang Goethe<br />
als Hauptdarsteller in allen Cinemaxx-Kinos in Deutschland<br />
für Aufmerksamkeit sorgen. Das Technoseum nutzt<br />
diese Werbung, um Persönlichkeiten aus Politik, Wirtschaft<br />
und Gesellschaft als Unterstützer zu gewinnen und<br />
sich mit ähnlichen Initiativen zu vernetzen. (aha)<br />
BEI DER MARKETINGAKTION hängten die<br />
Organisatoren Werbeplakate mit Goethe auf.<br />
(Bild: Technoseum)<br />
TECHNOSEUM – LANDESMUSEUM FÜR TECHNIK<br />
UND ARBEIT IN MANNHEIM,<br />
Museumsstraße 1, D-68165 Mannheim,<br />
Tel. +49 (0) 621 429 89, Internet: www.technoseum.de<br />
Automation 2014: Call for Papers ist online<br />
Unter dem Motto „Smart X – Powered by Automation“<br />
findet im kommenden Jahr am 1. und 2. Juli 2014<br />
der Kongress Automation statt. Der 15. Branchentreff<br />
der Mess- und Automatisierungstechnik beschäftigt<br />
sich mit der Frage, in welchem Ausmaß die Automation<br />
Grundlage und Antrieb ist für smarte Technik und<br />
smarte Lösungen in Wirtschaft und Gesellschaft. Bis<br />
zum 11. November 2013 können Experten Kurzfassungen<br />
zu smarten Methoden, Technologien und Anwendungen<br />
unter www.automatisierungskongress.de<br />
einreichen. Die Abgabe der Manuskripte soll dann bis<br />
zum 16. Mai 2014 erfolgen. Beitragsvorschläge zu smarten<br />
Methoden, Technologien und Anwendungen sind<br />
erwünscht. Bei den Anwendungen stehen die Prozessautomation,<br />
die Fertigungsautomation, die Medizintechnik,<br />
die Gebäudeausrüstung und andere technische<br />
und nicht-technische Anwendungsfelder im Vordergrund.<br />
Als zusätzliches Gliederungselement wurde der<br />
Lebenszyklus gewählt – vom Geräte- und Systementwurf<br />
über den Betrieb automatisierter Anlagen bis zu<br />
Aspekten der Wartung und Diagnose. <br />
(aha)<br />
VIEL APPLAUS erwartet die Vortragenden auf dem Kongress<br />
Automation in Baden-Baden. (Bild: Archiv/Purschwitz)<br />
VDI WISSENSFORUM GMBH,<br />
VDI-Platz 1, D-40468 Düsseldorf,<br />
Tel. +49 (0) 211 621 42 01,<br />
Internet: www.automationskongress. de<br />
8<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
www.<strong>atp</strong>-<strong>edition</strong>.de<br />
Jetzt bestellen!<br />
Call for <strong>atp</strong> experts:<br />
Lebenszyklusmanagement<br />
und Total<br />
Cost of Ownership<br />
IN AUSGABE 56(6) DER ATP EDITION im Juni 2014<br />
diskutiert technische Ansätze und geschäftstechnische<br />
Methoden zum Lifecyclemanagement in der<br />
Automation. Dieser Aspekt gewinnt angesichts der<br />
Veränderungen durch steigende Komplexität der<br />
Aufgaben und höheren Anforderungen an Funktionalität<br />
und Flexibilität zunehmend an Bedeutung.<br />
Weitere Treiber sind immer kürzer werdende Lebenszyklen<br />
bei den Basistechnologien und innovative<br />
(Cloud)-Ansätze zur Unterstützung von Wertschöpfungsnetzwerken.<br />
Durch ihre fokussierten<br />
Beiträge kann das Themenheft den aktuellen Diskurs<br />
von Technik bis Organisation, von Konzeption<br />
und Planung bis Betrieb und Optimierung, von zukünftigen<br />
Architekturkonzepten bis zu aktuellen<br />
Lösungen in hinreichender Tiefe abdecken.<br />
Die Referenzklasse für die<br />
Automatisierungstechnik<br />
<strong>atp</strong> <strong>edition</strong> ist das Fachmagazin für die Automatisierungstechnik.<br />
Die Qualität der wissenschaftlichen Hauptbeiträge<br />
sichert ein strenges Peer-Review-Verfahren. Bezug zur<br />
automatisierungstechnischen Praxis nehmen außerdem<br />
die kurzen Journalbeiträge aus der Fertigungs- und Prozessautomatisierung.<br />
Sichern Sie sich jetzt diese erstklassige Lektüre! Als<br />
exklusiv ausgestattetes Heft oder als praktisches ePaper<br />
– ideal für unterwegs, auf mobilen Endgeräten oder zum<br />
Archivieren.<br />
Wählen Sie einfach das Bezugsangebot, das Ihnen zusagt:<br />
als Heft, ePaper oder Heft + ePaper!<br />
Wir bitten Sie bis zum 25.1.2014 zu diesem Themenschwerpunkt<br />
einen gemäß den Autorenrichtlinien<br />
der <strong>atp</strong> <strong>edition</strong> ausgearbeiteten Hauptbeitrag per<br />
eMail an urbas@di-verlag.de einzureichen.<br />
Die <strong>atp</strong> <strong>edition</strong> ist die hochwertige Monatspublikation<br />
für Fach- und Führungskräfte der Automatisierungsbranche.<br />
In den Hauptbeiträgen werden die<br />
Themen mit hohem wissenschaftlichen und technischen<br />
Anspruch und vergleichsweise abstrakt<br />
dargestellt. Im Journalteil werden praxisnahe Erfahrungen<br />
von Anwendern mit neuen Technologien,<br />
Prozessen oder Produkten beschrieben.<br />
Alle Beiträge werden von einem Fachgremium begutachtet.<br />
Sollten Sie sich selbst aktiv an dem Begutachtungsprozess<br />
beteiligen wollen, bitten wir um<br />
kurze Rückmeldung. Für weitere Rückfragen stehen<br />
wir Ihnen selbstverständlich gerne zur Verfügung.<br />
Redaktion <strong>atp</strong> <strong>edition</strong><br />
Leon Urbas, Anne Purschwitz, Aljona Hartstock<br />
CALL FOR<br />
Aufruf zur Beitragseinreichung<br />
Thema: Lebenszyklusmanagement<br />
und Total Cost of Ownership<br />
Kontakt: urbas@di-verlag.de<br />
Termin: 25. Januar 2014<br />
<strong>atp</strong> <strong>edition</strong> erscheint in der DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München
BRANCHE<br />
Automatisierung der Zukunft verlangt dezentrale<br />
Steuerung, Modularität und Wiederverwendbarkeit<br />
Ansatz soll Mechanik, Automatisierung und Elektrik zusammenbringen<br />
MECHANIK,<br />
ELEKTRIK<br />
UND AUTO-<br />
MATISIERUNG<br />
haben jeweils<br />
unterschiedliche<br />
Sichten auf ein<br />
Bauteil. Der<br />
mechatronische<br />
Ansatz bringt<br />
die Bereiche<br />
zusammen.<br />
FÜR DIE AUTOMATISIERUNG DER ZUKUNFT sind Lösungen<br />
gefragt, die zum einen in der Lage sind, Steuerungs -<br />
intelligenz zu verteilen und zum anderen gewährleisten,<br />
dass die notwendige Vernetzung mehrerer Steuerungen<br />
für den Anwender einfach zu handhaben bleibt.<br />
Smart Factory, Industrie 4.0, sich selbst steuernde Produktion,<br />
Internet der Dinge – im Maschinen- und<br />
Anlagenbau wird derzeit weit in die Zukunft geschaut.<br />
Getrieben wird diese Diskussion durch steigende Anforderungen<br />
an Produktivität sowie Verfügbarkeit von Maschinen<br />
und Anlagen. Dezentrale und modulare Steuerungsarchitekturen<br />
nehmen in zukunftsfähigen Automatisierungskonzepten<br />
eine zentrale Rolle ein.<br />
ZENTRALE ARCHITEKTUREN ERREICHT GRENZEN<br />
Mit zentralistisch ausgelegten Speicherprogrammierbaren<br />
Steuerungen (SPS) können die Vorteile einer Modularisierung<br />
nicht ausgeschöpft werden. Denn dort ist die<br />
gesamte Steuerungsfunktion in einer (oder wenigen)<br />
zentralen Steuerungen beheimatet und kommuniziert<br />
mit einfachen Feldgeräten, deren Hauptfunktion das<br />
Einsammeln und Ausgeben von Prozessdaten ist. Änderungen<br />
in einzelnen Anlagenteilen verursachen einen<br />
hohen Aufwand auf Steuerungsebene, da Programmstrukturen<br />
an zentralen Stellen der Steuerung verändert<br />
werden müssen. Im Hinblick auf Flexibilität und Anwenderfreundlichkeit<br />
werden klassische zentrale Automatisierungsarchitekturen<br />
mit monolithischen SPS-<br />
Steuerungen den zukünftigen Anforderungen nicht<br />
mehr gerecht.<br />
In zentralistisch aufgebauten Steuerungssystemen<br />
müssen Anzahl und Anordnung der Steuerungseinheiten<br />
vor Beginn der Konstruktion geklärt sein, da nachträgliche<br />
Änderungen einen erheblichen Mehraufwand<br />
bedeuten. Mit der Software-Entwicklung wird erst begonnen,<br />
wenn feststeht, wie eine Maschine aussehen<br />
soll.<br />
MODULARER AUFBAU AUF DEM VORMARSCH<br />
Im Sinne der Standardisierbarkeit legen Maschinen- und<br />
Anlagenbauer ihr Augenmerk zunehmend auf einen modularen<br />
Aufbau von Maschinen und Anlagen, um die geforderte<br />
Variantenvielfalt von Werkstücken in vorgegebenen<br />
Produktionszyklen zu erreichen. Die Modulbildung<br />
soll gleichermaßen auch auf den steuerungstechnischen<br />
Hardwareaufbau und die funktionalen Logikmodule übertragbar<br />
sein. Nur so entsteht ein durchgängiger mechatronischer<br />
Ansatz mit identischen Teilungsgrenzen, mit dem<br />
sich Engineeringprozesse vereinfachen sowie die Wiederverwendbarkeit<br />
der einzelnen Einheiten steigern lassen.<br />
Die Philosophie der Mechatronik verfolgt den Ansatz<br />
alle am Entstehungsprozess einer Maschine beteiligten<br />
Disziplinen zusammenzuführen: Mechanik, Elektrik und<br />
Automatisierungstechnik. Wichtig ist dabei das Zusammenspiel<br />
diverser automatisierungstechnischer Einzelkomponenten,<br />
Software-Tools und dazugehöriger Services<br />
mit dem Ziel einer einheitlichen Automatisierungslösung.<br />
Diese Durchgängigkeit erstreckt sich über die vier Ebenen<br />
der Automatisierungspyramide (Managementebene, Betriebsführungsebene,<br />
Steuerungsebene und Feldebene).<br />
In der Mechanik drückt sich dies in Form von eigenständigen<br />
Funktionseinheiten aus. Im Hinblick auf die<br />
Umsetzung für die Steuerungsebene stoßen allerdings<br />
heutige Systeme an ihre Grenzen. Denn dort herrschen<br />
zentralistisch ausgelegte Steuerungsarchitekturen vor.<br />
AUTARKE ZELLENSTEUERUNGEN AGIEREN IM VERBUND<br />
Für die Automatisierung der Zukunft rücken Lösungen in<br />
den Fokus, die zum einen in der Lage sind, Steuerungsintelligenz<br />
zu verteilen und zum anderen gewährleisten,<br />
10<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
DEZENTRALITÄT ERHÖHT WIEDERVERWENDBARKEIT<br />
Werden Steuerungsfunktionalitäten dezentralisiert, ergeben<br />
sich Vorteile in zwei Bereichen. Zum einen ermöglicht<br />
die Dezentralisierung der Peripherie den Verkabelungsaufwand<br />
und die damit verbundenen Kosten zu<br />
reduzieren. Zum anderen lassen sich aber auch identische<br />
Steuerungsprogramme und -teilfunktionen dezentralisieren,<br />
was wiederum die komplette Modularisierung<br />
in Form von Maschinenelementen ermöglicht. Ziel dabei<br />
ist es, möglichst viele Teile identisch wiederverwenden<br />
zu können. Dies ermöglicht dem Anwender darüber hinaus<br />
einen sehr hohen Freiheitsgrad, da jedes dezentrale<br />
E/A-System auch nachträglich um Steuerungsfunktionen<br />
erweitert werden kann. Dies kann gleichsinnig oder unabhängig<br />
für die Standardfunktionen alleine – oder gemeinsam<br />
mit den Sicherheitsfunktionen geschehen.<br />
AUTOMATISIERUNGSSTRUKTUREN NACH MASS:<br />
Von Stand-alone-Applikationen über die Umsetzung<br />
klassischer Automatisierung mit einer zentralen Steuerung<br />
bis hin zur konsequenten Verteilung von Steuerungsfunktionen<br />
in die Peripherie. (Bilder: Pilz GmbH & Co. KG)<br />
dass die notwendige Vernetzung mehrerer Steuerungen<br />
für den Anwender einfach zu handhaben bleibt. Mit modernen<br />
Automatisierungsstrukturen entstehen weitgehend<br />
autarke Zellensteuerungen, die untereinander im Verbund<br />
agieren können. Zentrale Idee ist die Verschmelzung der<br />
verschiedenen Teilbereiche wie Standard-Automation und<br />
Sicherheit. Prozess- oder Steuerungsdaten, Fail-safe-Daten<br />
und Diagnoseinformationen werden über Ethernet ausgetauscht<br />
und synchronisiert. Im Gegensatz zu zentralen<br />
SPS-Steuerungen spielt es für die Steuerungsfunktion keine<br />
Rolle, wo der zugehörige Programmteil abgearbeitet<br />
wird. Statt einer zentralen Steuerung, steht dem Anwender<br />
ein zur Laufzeit verteiltes Anwenderprogramm in einem<br />
zentralen Projekt zur Verfügung. Über dieses zentrale Projekt<br />
werden alle Netzteilnehmer konfiguriert, programmiert<br />
und diagnostiziert. So ist ein einfaches, einheitliches<br />
Handling im Gesamtprojekt möglich. Die Vorteile<br />
zeigen sich in einer höheren Verfügbarkeit durch lokale<br />
Fehlerreaktionen sowie einer höheren Produktivität infolge<br />
kürzerer Reaktionszeiten des Gesamtsystems.<br />
PARALLELES ENGINEERING SPART ZEIT<br />
Wird mechatronisch gedacht und konzipiert, können<br />
alle an einem Automatisierungsprojekt beteiligten Fakultäten<br />
bereits nach der initialen Projektabstimmung<br />
ihre konkrete Arbeit beginnen: System- und Hardwareentwicklung<br />
können also parallel arbeiten. Durch<br />
die hardwareunabhängige Programmierung einer Anlage<br />
entfällt diese Querbeziehung und es entsteht die dringend<br />
benötigte Flexibilität im Engineeringprozess. Durch<br />
die parallele Vorgehensweise kann Projektierungszeit<br />
gespart werden. Nur in einzelnen Schritten ist die Synchronisation<br />
beider Aufgabenfelder noch erforderlich.<br />
Sobald die Funktionen einer Maschine durch die Bildung<br />
von Komponenten in Bibliotheken standardisiert<br />
sind, genügen erste Informationen über die zu erstellende<br />
Maschine, um letztlich die Gesamtstruktur aufbauen<br />
zu können. Für den Konstrukteur wird es möglich, sich<br />
auf die Planung der für den Prozess notwendigen Komponenten<br />
zu konzentrieren; Performance- und Strukturthemen<br />
sind weitgehend unabhängig voneinander zu<br />
betrachten und treten – wenn gewünscht – noch weiter<br />
in den Hintergrund. Die detaillierte Funktion einer Komponente<br />
kann zu einem späteren Zeitpunkt über die individuellen<br />
Eigenschaften festgelegt werden.<br />
FAZIT<br />
Um die Automatisierungsaufgaben der Zukunft lösen zu<br />
können, müssen die Aspekte Modularität und Wiederverwendbarkeit<br />
bereits in der frühesten Planungsphase<br />
intensiv einbezogen und berücksichtigt werden. Voraussetzung<br />
dafür sind Automatisierungssysteme wie PSS<br />
4 000 von Pilz, die in der Lage sind, die in den mechatronischen<br />
Einheiten verteilte Intelligenz zentral und<br />
anwenderfreundlich zu verwalten. Anlagen lassen sich<br />
dann in übersichtliche, selbstständig arbeitende Einheiten<br />
zerlegen. Aufwände für Engineering, Inbetriebnahme<br />
und Wartung lassen sich deutlich reduzieren.<br />
AUTOR<br />
MARKUS SCHLÖGL ist Bereichsleiter<br />
Produktmanagement Operating and<br />
Monitoring Systems, Software Tools,<br />
bei Pilz GmbH in Ostfildern.<br />
Pilz GmbH & Co KG,<br />
Felix-Wankel-Straße 2, D-73760 Ostfildern,<br />
Tel. +49 (0) 711 340 96 93, E-Mail: m.schloegl@pilz.de<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
11
BRANCHE<br />
PC-basierte Steuerungstechnik als Grundlage<br />
für die Entwicklung von Industrie 4.0<br />
Vorteile der Konvergenz von IT- und Automatisierungstechnik für Industrie 4.0 nutzen<br />
Die Vision, dass Werkstücke beziehungsweise Rohlinge<br />
sich dank Eigen-Intelligenz selbstständig durch<br />
die Fertigung bewegen und den Produktionseinheiten<br />
die Bearbeitungsparameter vorgeben, ist vielleicht in<br />
Zukunft denkbar, heute aber weit entfernt. Eine hierarchisch<br />
strukturierte Automatisierungstechnik bietet<br />
momentan den größten Nutzen für eine effiziente und<br />
flexible Produktion.<br />
Die Grundlage der Industrie-4.0-Idee bildet das Internet<br />
der Dinge, ein Begriff, der in Zusammenhang mit RFID<br />
und Sensortechnologien im Jahr 1999 entstanden ist und<br />
die Vernetzung von und mit Alltagsgegenständen beschreibt.<br />
Voraussetzung für eine konsequente Umsetzung<br />
sind die erstmals im Jahr 2006 definierten cyber-physischen<br />
Systeme (CPS). Gemeint sind damit die auf allen<br />
Ebenen eng miteinander verbundenen cyber-Komponenten<br />
– zur diskreten Informationsverarbeitung und Kommunikation<br />
– sowie physischen Komponenten. Dies spiegeln<br />
auch die BMBF-Förderrichtlinien wider: „Cyberphysische<br />
Systeme verfügen – in Erweiterung zu heutigen<br />
mechatronischen Systemen – über intelligente Sensoren<br />
zur Wahrnehmung ihrer Umwelt und über Aktoren, mit<br />
denen sie diese beeinflussen können. Sie unterscheiden<br />
sich von bestehenden technischen Systemen jedoch durch<br />
die Fähigkeit, mit ihrer Umgebung zu interagieren, das<br />
eigene Verhalten in Abhängigkeit der Umwelt zu planen<br />
und anzupassen sowie neue Verhaltensweisen und -strategien<br />
zu erlernen und sich somit selbst zu optimieren.“<br />
INTELLIGENZ MODULAR ANORDNEN<br />
PC-Control von Beckhoff bietet die Flexibilität, zentrale<br />
und dezentrale Steuerungskonzepte zu realisieren. Eine<br />
hierarchische Organisation bleibt im Automatisierungsbereich<br />
die erste Wahl, und damit auch eine I/O-Ebene<br />
mit mehr oder weniger stark reduzierter Intelligenz.<br />
Hierzu gehören klar definierte Ebenen sowie Interfaces<br />
zwischen diesen – und die unter Industrie 4.0 im Fokus<br />
stehende Durchgängigkeit der Kommunikation.<br />
Um Industrie 4.0 letztendlich in einer wirklich ganzheitlichen<br />
Sicht zu realisieren, sind drei Aspekte umzusetzen:<br />
die horizontale Integration auch über Unternehmensgrenzen<br />
hinweg, die vertikale Integration mit vernetzten Produktionssystemen<br />
sowie die Durchgängigkeit des Engineerings<br />
während des gesamten Produktlebenszyklus. In Ver-<br />
Ein Partner für alles – und Sie gewinnen<br />
Sicherheit auf der ganzen Linie.<br />
Wenn es um Anlagensicherheit geht, erfüllen Sie mit der<br />
Erfahrung und dem Know-how von Endress+Hauser auch<br />
die höchsten Anforderungen. Dies garantieren Ihnen<br />
unsere zertifizierten Sicherheitsingenieure und Managementsysteme,<br />
die jahrzehntelange vertrauensvolle<br />
Zusammenarbeit mit weltweiten Prüf-, Zertifizierungsund<br />
Normungsstellen sowie über zehn Millionen installierte<br />
Geräte in Sicherheitsanwendungen. Gründe genug dafür,<br />
dass Sie mit uns Sicherheit auf der ganzen Line gewinnen.
TECHNISCHE UND<br />
TECHNO LOGISCHE<br />
ENTWICKLUNGEN<br />
als Voraussetzungen<br />
für die vier industriellen<br />
Revolutionen. (Bild: DFKI)<br />
bindung mit der betriebswirtschaftlichen Anwendungssoftware<br />
kann dies deutliche Optimierungspotenziale<br />
sowie zusätzliche Geschäftsmodelle erschließen – zum<br />
Beispiel über ein ‚Internet der Dienste‘. Für all dies bietet<br />
PC-Control die richtige Lösung. Zumal hier flexibel auf die<br />
jeweiligen Applikationsanforderungen reagiert werden<br />
kann: Intelligenz lässt sich hierarchisch modular unter der<br />
zentralen Steuerung, bei Bedarf auch dezentral, also gleichberechtigt<br />
nebeneinander anordnen. Nicht umsonst hat die<br />
Automatisierungspyramide bis heute Bestand.<br />
Geschäftsführer Hans Beckhoff sieht dementsprechend<br />
weltweit gute Perspektiven, um künftig mit der<br />
Der Film zum Komplettanbieter –<br />
jetzt informieren.<br />
Alles unter<br />
www.einfachalles-alleseinfach.de
BRANCHE<br />
Integration geeignet. Dafür eignet sich PC-Control, denn<br />
es bietet mit der Automation Device Specification (ADS),<br />
dem Ethercat Automation Protocol (EAP) und der OPC<br />
Unified Architecture (OPC UA) die passenden Möglichkeiten<br />
für eine Kommunikation‚ vom Sensor bis in die<br />
Cloud:<br />
ADS ist eine Nachrichten-basierte, routingfähige<br />
Transportschicht innerhalb des Twincat-Softwaresystems.<br />
Sie erlaubt azyklische Kommunikation<br />
innerhalb des Twincat-Systems und zu anderen<br />
Tools (wie zum Beispiel Visualisierung).<br />
Das echtzeitfähige EAP kann per Publisher-Subscriber-Mechanismus<br />
Prozessdaten zwischen Ethercat-<br />
Mastern zyklisch bis in den µs-Bereich hinein übertragen.<br />
OPC UA ist ein standardisierter herstellerunabhängiger,<br />
Ethernet- und Web-basierter Kommunikationsstandard,<br />
der nahtlos in MES- und ERP-Konzepte<br />
integrierbar ist.<br />
PC-CONTROL macht die Vorteile der Techno logie konvergenz aus<br />
IT- und Automatisierungs technik für industrielle Anwendungen<br />
nutzbar. (Bild: Beckhoff Automation)<br />
PC-basierten Steuerungstechnologie im Maschinen- und<br />
Anlagenbau weiter zu wachsen: „Mit unserer auf PC-<br />
Control basierenden Steuerungstechnologie sind unsere<br />
Kunden und wir für die unter dem Titel Industrie 4.0<br />
von der Bundesregierung verfolgte Hightech-Strategie<br />
optimal aufgestellt. Speziell die Konvergenz von IT- und<br />
Automatisierungstechnik ist ein gemeinsames wesentliches<br />
Wirkprinzip von Industrie 4.0 und von PC-Control.<br />
Es freut uns, dass dieses Konzept nun noch weiter<br />
in das Bewusstsein der allgemeinen und speziell der<br />
technischen Öffentlichkeit dringt, und wir sind sicher,<br />
dass der Standort Deutschland und auch die internationale<br />
Automatisierungs-Community sehr von dieser<br />
Philosophie profitieren werden, so wie es die Beckhoff-<br />
Kunden bereits seit dem Anbeginn von PC-Control vor<br />
mehr als 25 Jahren tun.“<br />
PC MIT ETHERNET BILDET TECHNOLOGIEPLATTFORM<br />
Heute gibt es kaum ein technisches System, das nicht<br />
per PC bedienbar oder zumindest über eine Software<br />
darauf anzubinden wäre. Mit PC-Control können aktuelle<br />
und zukünftige Konzepte realisiert werden. Dies gilt<br />
in gleichem Maße für den Kommunikationsstandard<br />
Ethernet. Dank der sehr hohen Übertragungsraten ist er<br />
mittlerweile in der Industrie durchgängig akzeptiert.<br />
Dazu beigetragen haben die ergänzenden Ethernet-basierten<br />
Industrieprotokolle wie Ethercat und Safety-over-<br />
Ethercat, die Forderungen nach kurzen Zykluszeiten,<br />
Deterministik und sicherheitsrelevanter Datenübertragung<br />
erfüllen.<br />
Moderne Kommunikation ist Ethernet-basiert und für<br />
alle Anforderungen einer horizontalen und vertikalen<br />
INDUSTRIE 4.0 ERFORDERT INTEGRATION<br />
Mit dem PC und mit den Kommunikationsprotokollen<br />
ADS, EAP und OPC UA ist die Voraussetzung gegeben,<br />
um die von Industrie 4.0 geforderte vertikale und horizontale<br />
Integration umzusetzen. Dies ist notwendig,<br />
wenn die cyber-physischen Systeme künftig tatsächlich<br />
selbstständig, autonom und via Internet Produktion organisieren<br />
können, und das möglichst ohne Engineering<br />
in Handarbeit.<br />
Um in Zukunft die Automatisierungssoftware beherrschen<br />
zu können, muss die Software-Komplexität modularisiert<br />
werden, das heißt in kleine Einheiten aufgespalten.<br />
Diese Module müssen einen hohen Wiederverwendungsgrad<br />
haben. Die Modularität und Objektorientiertheit<br />
muss von den zugehörigen Softwaretools<br />
unterstützt werden. Zusätzlich muss die Engineeringsoftware<br />
in der Lage sein, die Module, oder besser die<br />
Tasks, auf Kerne eines Mehrkernprozessors zu verteilen.<br />
Die Automatisierungssoftware Twincat 3 kann eine Applikation<br />
auf einer Single-Core-CPU ablaufen lassen.<br />
Außerdem besteht die Möglichkeit, einzelne Tasks der<br />
Anwendung auf verschiedene Cores eines Mehrkernprozessors<br />
aufzuteilen. Damit kann der modulare Ansatz<br />
umgesetzt werden. Die Integration in das Microsoft Visual<br />
Studio bietet die Basis für ein durchgängiges Engineering<br />
über den gesamten Produktlebenszyklus hinweg.<br />
Dem Automatisierer stehen im Visual Studio alle<br />
modernen Software-Engineeringwerkzeuge zur Verfügung.<br />
Die SPS-Programmierer haben mit den um Objektorientierung<br />
erweiterten Programmiersprachen nach<br />
IEC 61131-3 neue Möglichkeiten, effizient und modular<br />
zu programmieren. Zudem können mit C/C++ und<br />
Matlab/Simulink weitere Sprachen genutzt werden.<br />
STETIGE FORSCHUNG FÜHRT ZU INNOVATION<br />
Zur Entwicklung von Industrie 4.0 haben beispielsweise<br />
frühe Forschungsarbeiten beigetragen. So etwa das<br />
im Jahr 2004 begonnene EU-Forschungsprojekt Eupass,<br />
bei dem Beckhoff für die Steuerungstechnik verantwortlich<br />
war. Ziel des Forschungsprojektes war die<br />
14<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
www.gwf-wasser-abwasser.de<br />
modulare Fertigungsmaschine, die mechanisch und<br />
softwaretechnisch standardisiert wurde. Damit<br />
konnte eine flexibel anpassbare Fertigungsumgebung<br />
realisiert werden.<br />
Nachdem das Projekt Industrie 4.0 im Jahr 2011 aus<br />
der Perspektive der Informations- und Kommunikationstechnologien<br />
konzipiert und in die Hightech-<br />
Strategie der Bundesregierung übernommen wurde,<br />
etablierte sich Ende 2011 auf Initiative der Forschungsunion<br />
Wirtschaft-Wissenschaft der Arbeitskreis<br />
‚Industrie 4.0‘. Im April 2012 veröffentlichte die<br />
Deutsche Akademie der Technikwissenschaften<br />
(Acatech) eine Forschungsagenda Cyber-Physical Systems,<br />
zu der unter anderem auch Beckhoff, in Zusammenarbeit<br />
mit Prof. Dr. Birgit Vogel-Heuser von der<br />
TU München, aus Sicht der Produktionstechnik und<br />
Automatisierung für das Scenario ‚Smart Factory‘<br />
beigetragen hat.<br />
Auf dem Weg von der Mechatronik hin zu den Intelligenten<br />
technischen Systemen im Sinne von Industrie<br />
4.0 leitet das Unternehmen als Konsortialführer<br />
zwei Projekte im Technologienetzwerk It’s OWL<br />
(Intelligente Technische Systeme Ostwestfalenlippe):<br />
Scaut (Scientific Automation) behandelt die Integration<br />
ingenieurwissenschaftlicher Erkenntnisse in die<br />
Standardautomatisierung; mit Efa (Extreme Fast Automation)<br />
soll das Potenzial der Mehrkernprozessoren<br />
bei Standardbearbeitungsmaschinen ausgeschöpft<br />
werden.<br />
Jetzt bestellen!<br />
Das führende Fachorgan<br />
für das Wasser- und<br />
Abwasserfach<br />
Mit der technisch-wissenschaftlichen Fachzeitschrift<br />
gwf-Wasser | Abwasser informieren Sie sich gezielt zu<br />
allen wichtigen Fragen rund um die Wasser versorgung<br />
und Abwasser behandlung.<br />
Jedes zweite Heft mit Sonderteil R+S - Recht und Steuern<br />
im Gas und Wasserfach.<br />
Wählen Sie einfach das Bezugsangebot, das Ihnen zusagt:<br />
als Heft, ePaper oder Heft + ePaper!<br />
FAZIT<br />
Bereits heute sind Industrie 4.0-Konzepte vielfach<br />
Realität, auch wenn die Vision für die Zukunft in 20<br />
bis 30 Jahren deutlich darüber hinausgeht. Die Entwicklung<br />
dahin wird evolutionär voranschreiten und<br />
von den aktuellen, sich ebenfalls weiterentwickelnden<br />
Automatisierungstechnologien begleitet werden.<br />
Die optimale Basis dafür bildet die PC-basierte Steuerungstechnik,<br />
mit der sich zentrale und dezentrale<br />
Konzepte realisieren lassen.<br />
AUTOR<br />
Beckhoff Automation GmbH,<br />
Eiserstraße 5, D-33415 Verl,<br />
Tel. +49 (0) 5246 96 30,<br />
E-Mail: info@beckhoff.de<br />
STEFAN ZIEGLER ist<br />
Technischer Redakteur<br />
im Bereich Marketing<br />
Communications bei<br />
Beckhoff Automation<br />
in Verl.<br />
gwf Wasser/Abwasser erscheint in der DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München
PRAXIS<br />
Elektromagnetische Verträglichkeit: Für industrielle<br />
Umgebungen ist sie besonders wichtig<br />
Praktische Tipps und Lösungen für die störfreie Verkabelung im Feld<br />
DAMIT IN DER INDUSTRIE keine elektromagnetischen<br />
Störungen entstehen, sollten störsichere Komponenten<br />
eingesetzt werden.<br />
TYPISCHE GERÄTE im Feld können im<br />
Hinblick auf Störempfindlichkeit und<br />
Störpotenzial klassifiziert werden.<br />
Aus der Lautsprecher-Anlage dringen merkwürdige<br />
Geräusche, der Computer-Monitor flackert und das<br />
Thermometer zeigt in der sonst kühlen Halle plötzlich<br />
75° C an. Was ist passiert? Falsch geplante und schlecht<br />
entstörte elektrische Anlagen könnten der Grund dafür<br />
sein. Abhilfe schafft eine störfeste Verkabelung. Der<br />
Beitrag erläutert die Herausforderungen hinsichtlich<br />
Störfestigkeit und gibt praktische Tipps zur richtigen<br />
Ausrüstung.<br />
PLANUNG UND NORMUNG<br />
Was genau ist eigentlich elektromagnetische Verträglichkeit<br />
– kurz EMV genannt? Der VDE definiert EMV<br />
als „Fähigkeit eines Geräts, in der elektromagnetischen<br />
Umwelt zufriedenstellend zu arbeiten, ohne dabei<br />
selbst elektromagnetische Störungen zu verursachen,<br />
die für andere in dieser Umwelt vorhandene Geräte unannehmbar<br />
wären“.<br />
Für manche Ingenieure treten EMV-Probleme im Feld<br />
völlig überraschend auf – entsprechend schwierig gestaltet<br />
sich dann die Suche nach einer Lösung. Daher<br />
sollte das Thema EMV schon bei der Planung berücksichtigt<br />
werden. So muss zunächst zwischen Industrie-,<br />
Wohn-, Geschäfts- und Gewerbebereich unterschieden<br />
werden, denn die Normen, Bedingungen und Anforderungen<br />
sind jeweils unterschiedlich. Für die Industrie<br />
gelten zwei Fachgrundnormen: die EN 61000-6-4 für<br />
die Störaussendung sowie die EN 61000-6-2 für die Störfestigkeit.<br />
Charakteristisch für den Industriebereich ist zum Beispiel<br />
die direkte Anbindung an das Mittelspannungsnetz<br />
über betriebseigene Umspannanlagen. So können sich<br />
Störungen über das Werksgelände hinaus bemerkbar<br />
machen. Auf der anderen Seite ist aber innerhalb industrieller<br />
Umgebungen mit einem erhöhten Maß an elektromagnetischen<br />
Störungen zu rechnen, da oft Schalthandlungen<br />
an großen elektrischen Verbrauchern durchgeführt<br />
werden, wie zum Beispiel im Fahrzeugbau oder<br />
in der Schwerindustrie. Geräte, die im Industriebereich<br />
eingesetzt werden, müssen daher eine erhöhte Störfestigkeit<br />
aufweisen.<br />
Im Gegensatz dazu erfolgt die Energieversorgung im<br />
Wohn-, Geschäfts- und Gewerbebereich über das öffentliche<br />
Niederspannungsnetz. Hier können sich Störungen<br />
leicht mit dem 230-V-Netz über die Grenzen der eigenen<br />
Wohnung oder des eigenen Hauses ausbreiten, da die<br />
Filterwirkung eines Mittelspannungs-Transformators<br />
hier entfällt. Außerdem stehen in jedem Haushalt auch<br />
Geräte aus dem Bereich der Unterhaltungselektronik, die<br />
schon vom Prinzip her eine erhöhte Empfindlichkeit gegenüber<br />
elektromagnetischen Störungen aufweisen. Aus<br />
diesem Grund sind im Wohn-, Geschäfts- und Gewerbe-<br />
16<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
Falls kein ordnungsgemäßes Potenzial-Ausgleichssystem<br />
besteht oder EMV-Einflüsse unzulässig hohe Störspannungen<br />
erzeugen, ist es ratsam, optische Verbindungen<br />
zu wählen.<br />
SCHWEISSROBOTER UND ANTRIEBE verursachen<br />
eine hohe Belastung der elektromagnetischen<br />
Verträglichkeit. (Bilder: Phoenix Contact)<br />
bereich die Grenzwerte für zulässige Störaussendungen<br />
schärfer gefasst.<br />
PASSIVE SICHERHEIT<br />
Daraus resultiert, dass die EMV-Problematik schon frühzeitig<br />
in der Planungs- und Entwicklungsphase einer<br />
Anlage berücksichtigt werden muss. Denn nur so können<br />
unnötige Kosten für eine aufwendige Fehlersuche im<br />
laufenden Betrieb vermieden werden. Was nützt eine auf<br />
den Energieverbrauch optimierte Maschine, wenn sie am<br />
Einbauort nicht erwartungsgemäß funktioniert und die<br />
umgebenden Systeme stört?<br />
Lösungen zur sicheren Verkabelung im industriellen<br />
Umfeld, zum Beispiel für eine EMV-sichere Profinetund<br />
Ethernet-Installation, setzen geeignete Komponenten<br />
voraus: Steckverbinder, Leitungen und Outlets. Die<br />
in einem Kupfer-Netzwerk eingesetzten RJ45-Steckverbinder,<br />
die häufig in Profinet- und Ethernet-basierten<br />
Systemen eingesetzt werden, müssen daher besonders<br />
gute Schirmeigenschaften besitzen, um die hohen Anforderungen<br />
zu erfüllen. Weitere zu beachtende Punkte<br />
bei der Installation sind die richtige und durchgängige<br />
Verkabelung des Schirmes sowie ein fachgerechter<br />
Potenzialausgleich in der Anlage. Diese Faktoren<br />
haben einen großen Einfluss auf die Zuverlässigkeit<br />
des Netzwerks.<br />
DIE RICHTIGE WAHL<br />
Lösungen für diese Problematik bietet beispielsweise<br />
Phoenix Contact mit einem großen Produktprogramm<br />
für passive Datenverkabelung – sowohl für kupferbasierte<br />
wie auch für optische Verkabelungssysteme. Für eine<br />
störfeste Verkabelung – etwa bei Roboter-Applikationen<br />
– kommt der Push-Pull-Steckverbinder der Variante 14<br />
zum Einsatz, der im Gegensatz zu marktüblichen Komponenten<br />
ein fundiertes Schutzkonzept bietet. Dieser<br />
Steckverbinder hat zwischen den einzelnen Metallteilen<br />
einen doppelt geführten 360 Grad-Schirm sowie einen<br />
nieder-ohmigen Potentialausgleich.<br />
Die idealen Gegenspieler auf der Anbauseite sind die<br />
Terminal-Outlets für den sicheren Aufbau einer Hallenverkabelung.<br />
Als Gegenstück dienen auch Multiport-<br />
Verteiler, welche die Installation und den Anschluss an<br />
Roboter-Systeme erheblich erleichtern. Diese Steckverbinder-Systeme<br />
haben aber nicht nur hervorragende<br />
EMV-Schutzeigenschaften – sie beherbergen auch eine<br />
sichere und schnelle Feldinstallationstechnik auf Basis<br />
der Schnellanschlusstechnik Quickon.<br />
FAZIT<br />
Findet der Einsatz innerhalb oder außerhalb des Schaltschranks<br />
statt? Welche Anforderungen gibt es hinsichtlich<br />
der Schirmung und des Potential-Ausgleichsystems?<br />
Nur wenn diese Fragen schon im Vorfeld richtig beantwortet<br />
und die Produkte gezielt danach ausgewählt werden,<br />
kann das Datennetzwerk im industriellen Umfeld<br />
sicher funktionieren.<br />
AUTOR<br />
Dipl.-Ing. ULF LEUCHNER<br />
ist im Bereich Produkt-<br />
Marketing Datensteckverbinder<br />
bei Phoenix<br />
Contact GmbH & Co. KG<br />
in Blomberg tätig.<br />
Phoenix Contact GmbH & Co. KG,<br />
Flachsmarktstraße 8,<br />
D-32825 Blomberg,<br />
E-Mail: uleuchner@phoenixcontact.com,<br />
Internet: www.phoenixcontact.de<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
17
PRAXIS<br />
Frequenzumrichter für den Bergbau erfüllen hohe<br />
Anforderungen bei unwirtlichen Bedingungen<br />
Master-Slave-Betrieb sorgt für gleichmäßige Auslastung aller Motoren<br />
Der Bergbau stellt an Mensch und Maschine hohe Anforderungen<br />
in Bezug auf Leistungsfähigkeit und<br />
Sicherheit, denn die Bedingungen unter Tage sind auch<br />
heute noch hart. Die moderne Technik erleichtert allerdings<br />
die Arbeit gegenüber früher enorm. Dazu müssen<br />
aber alle Komponenten extremen Anforderungen genügen.<br />
Speziell für den Bergbau entwickelte Frequenzumrichter<br />
tragen dem Rechnung. Sie trotzen Vibration und<br />
Schock, erlauben einen Master/Slave-Betrieb von Antrieben<br />
und punkten mit sehr hoher Verfügbarkeit bei langer<br />
Lebensdauer.<br />
Unter Tage gelten andere Bedingungen als in der übrigen<br />
Industrie. Für Anlagen und speziell Antriebe und<br />
deren Regelung ist daher bei der Auslegung einiges zu<br />
beachten. Refu Elektronik aus Pfullingen entwickelt daher<br />
speziell für Bergbauanwendungen ausgelegte Fre-<br />
VARIANTENREICHE FAMILIE der (Bergbau-)Frequenzumrichter.<br />
(Bild: REFU Elektronik)<br />
DER WALZENSCHRÄMLADER stellt<br />
hohe Anforderungen an die Frequenzumrichter.<br />
(Bild: Eickhoff Walzenlader,<br />
Typ SL 750, Eickhoff Bergbautechnik GmbH)<br />
PRINZIPSCHALTBILD<br />
der Umrichter im<br />
Walzenschrämlader.<br />
(Bild: REFU Elektronik)<br />
DIE EINSCHIENENHÄNGEBAHN arbeitet mit Umrichtern im Master/<br />
Slave-Betrieb besonders ruhig und wirtschaftlich. (Bild: SMT Scharf GmbH)<br />
18<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
quenzumrichter. Die Umrichter sind nicht nur auf die<br />
unwirtlichen Bedingungen im Bergbau ausgelegt, sie<br />
tragen auch den speziellen, dort geforderten Automatisierungsanforderungen<br />
Rechnung.<br />
KOMPLEXE VERNETZUNG ALLER KOMPONENTEN<br />
Nimmt man die Kohleförderung als Beispiel für den<br />
modernen Bergbau, so fallen als Erstes die Komplexität<br />
und Vernetzung aller Komponenten auf. Stollen müssen<br />
bewettert (belüftet) werden, der Abtransport von Kohle<br />
und Abraum koordiniert und vieles mehr. Das kostet<br />
Geld und ist nur bei hoher Förderleistung rentabel. Ein<br />
Stillstand, beispielsweise durch Ausfall eines Frequenzumrichters<br />
in einem Abbaugerät kann so in kurzer Zeit<br />
Zehntausende Euro kosten. Eine sehr hohe Verfügbarkeit<br />
aller Komponenten hat also oberste Priorität. Gleichzeitig<br />
ist auch Sicherheit ein hohes Gut, denn im Störfall<br />
sind die Arbeiter im Stollen recht unbeweglich. Mit Eigenintelligenz<br />
ausgestattete Frequenzumrichter helfen<br />
hier weiter, denn sie entlasten nicht nur die übergeordnete<br />
Steuerung, sondern können auch viel schneller,<br />
quasi in Echtzeit, auf geänderte Bedingungen beziehungsweise<br />
Belastungen reagieren. Das steigert die Fördermenge<br />
und schont die Mechanik sowie die Motoren<br />
der Maschine. Gleichzeitig wird die Verfügbarkeit erhöht.<br />
Die robusten Refu-Drive-Frequenzumrichter tragen<br />
diesen Anforderungen Rechnung. Die übergeordnete<br />
Steuerung (SPS oder PC mit Bussystem) gibt nur die<br />
Sollwertvorgabe, die interne Master/Slave-Regelung der<br />
Umrichter sorgt für eine konstante Aufteilung der Last<br />
auf alle angeschlossenen Motoren oder für einen absoluten<br />
Gleichlauf der Antriebe. Das reduziert den Steuerund<br />
Regelungsaufwand für die übergeordnete Steuerung,<br />
bei gleichzeitig reflexartigen Reaktionszeiten am<br />
Antrieb. Unterschiedliche Leistungsklassen von 40 bis<br />
200 kW bei Eingangsspannungen von 400 bis zu 1140 V<br />
bei einem Wirkungsgrad von 98 Prozent stehen zur Verfügung.<br />
Eine integrierte Netzrückspeisung vermindert<br />
die abzuführende Wärmemenge und spart gleichzeitig<br />
Kosten durch die Rückspeisung der Bremsenergie in das<br />
Versorgungsnetz. Eine Nutzung dieser Energie in anderen<br />
Anlagenteilen ist damit möglich. Entsprechend den<br />
Arbeitsbedingungen im Bergbau tolerieren die Umrichter<br />
problemlos 60 Sekunden lang anderthalb-fache Überlast.<br />
Alle Umrichter sind mit Coldplate-Kühlung ausgestattet,<br />
so lassen sie sich schnell und ohne Eingriffe in<br />
einen Wasserkühlkreislauf einsetzen. Die Beispiele<br />
Walzenschrämlader und Antrieb einer Einschienenbahn<br />
zeigen deutlich, dass moderne Komponenten für<br />
den Bergbau bei besonderer Sorgfalt in Entwicklung,<br />
Fertigung und Qualitätssicherung im wahrsten Wortsinn<br />
„Berge versetzen können“.<br />
BEISPIELE AUS DER PRAXIS: KOHLEFÖRDERUNG VOR ORT<br />
Zum Kohleabbau in größeren Flözen ab 1,8 Meter Höhe<br />
wird oft ein Walzenschrämlader eingesetzt. Schneidwalzen<br />
mit Asynchronmotoren, die direkt am Netz<br />
laufen, lösen dabei die Kohle aus dem Berg, ein Trans-
PRAXIS<br />
portband befördert sie anschließend aus dem Streb. Bis<br />
zu vier Antriebsmaschinen, die per Getriebe auf den<br />
Triebstock (eine Art Kette) wirken, übernehmen den<br />
Vortrieb des Schrämers. Auf diese Weise fördert ein<br />
Walzenschrämer Kohle im Wert von rund einer Million<br />
Euro im Monat. Die Forderung nach Verfügbarkeit von<br />
mindestens 98,5 Prozent ist daher leicht einzusehen.<br />
Damit dieser Wert erreicht werden kann, müssen die<br />
einzelnen Komponenten in dieser Kette deutlich höhere<br />
Verfügbarkeiten bieten. Die Frequenzumrichter aus<br />
dem Hause Refu Elektronik weisen eine Verfügbarkeit<br />
von 99,5 Prozent auf. Da die Kohle unterschiedlich hart<br />
beziehungsweise auch mit Felsen durchsetzt ist, treten<br />
Stöße, Vibration und Lastspitzen praktisch permanent<br />
auf. Der mechanischen Belastung wird durch einen besonders<br />
robusten Aufbau begegnet, den Lastspitzen auf<br />
zweierlei Weise: Zum einen können die Umrichter für<br />
60 Sekunden um das anderthalb-fache überlastet werden,<br />
zum andern sorgt der variable Master/Slave-Betrieb<br />
für eine gleichmäßige Auslastung aller Motoren.<br />
Dabei übernimmt automatisch der last- und bewegungsabhängig<br />
besser geeignete Umrichter die Master-Funktion<br />
und regelt die nachfolgenden Umrichter in wenigen<br />
Millisekunden entsprechend nach. Die SPS wird damit<br />
nicht belastet.<br />
Auch die Möglichkeit, Bremsenergie rückzuspeisen<br />
wird in dieser Anwendung genutzt: Bei schräg im Berg<br />
stehenden Flözen kann im Abwärtsbetrieb erhebliche<br />
Bremsenergie anfallen. Im generatorischen Betrieb wird<br />
per Netzrückspeisung die Energie ins Betriebsnetz zurückgespeist.<br />
Da die Umrichter an bis zu 1140 V angeschlossen<br />
werden können, entfallen dann die sonst nötigen<br />
Transformatoren.<br />
EINSATZ BEI „NAHVERKEHRSMITTEL“ UNTER TAGE<br />
Bei den meist langen Strecken vom Förderschacht zur<br />
Abbaustelle übernehmen oft Einschienenhängebahnen<br />
den Transport von Mensch und Material. Vorteil dieser<br />
Lösung, sie ist unempfindlich gegenüber Sohlenhebungen<br />
und flexibel. Als Kombination von Umrichter und<br />
Elektromotor aus dem Netz betrieben, bietet sie zudem<br />
einen hohen Wirkungsgrad und eine für den Maschinenhersteller<br />
einfache Regelung der Anlage. Diese Regelbarkeit<br />
wird durch die Zusammenstellung von einzelnen<br />
Zügen und Waggons im Zugverband beeinflusst. In der<br />
Praxis bedeutet das, wie bei der Eisenbahn, dass sich die<br />
einzelnen „Waggons“ beim Start auseinanderziehen und<br />
beim Bremsen zusammenschieben. Um dabei harte Stöße,<br />
Rucke oder sogar sich aufschwingende Züge zu vermeiden,<br />
übernimmt der vorderste Umrichter im Zug<br />
wiederum die Masterfunktion, die im ganzen Zugverband<br />
verteilten Slave-Antriebe folgen diesem und sorgen<br />
für die entsprechend optimale Funktion des Zuges. Ob<br />
Anfahren oder Bremsbetrieb, aufgrund der sehr schnellen<br />
Reaktion der Umrichter werden alle Antriebe gleichmäßig<br />
belastet, die Regelung sorgt für weiche beziehungsweise<br />
schwing-, stoß- und ruckfreie Übergänge.<br />
Unbestimmte Zustände sind damit ausgeschlossen; es<br />
kann also beispielsweise nicht sein, dass der vorderste<br />
Motor schon im Bremsbetrieb arbeitet, während der hintere<br />
noch für Vortrieb sorgt. Das schont die Antriebe und<br />
das Material der Hängebahn bei gleichzeitig verbessertem<br />
Fahrkomfort.<br />
Die Frequenzumrichter, die neben den obligatorischen<br />
Sicherheitsanforderungen konstruktiv auch weitere Eigenheiten<br />
der Antriebe im Bergbau berücksichtigen, tragen<br />
so wesentlich dazu bei, die Kosten zu reduzieren.<br />
AUTOREN<br />
PRINZIPSCHALTBILD<br />
der Umrichter in der<br />
Einschienenhängebahn<br />
(Bild: REFU Elektronik)<br />
STEFFEN NOTZ ist Leiter des Bereichs<br />
Applikation bei der Refu Elektronik GmbH<br />
in Pfullingen.<br />
Refu Elektronik GmbH,<br />
Marktstraße 185,<br />
D-72793 Pfullingen,<br />
Tel. +49 (0) 7121 433 20,<br />
E-Mail: mail@refu-elektronik.de<br />
Dipl. Chem. ANDREAS ZEIFF<br />
vom Redaktionsbüro Stutensee.<br />
Redaktionsbüro Stutensee,<br />
Am Hasenbiel 13-15,<br />
D-76297 Stutensee,<br />
Tel. +49 (0) 7244 73 96 90,<br />
E-Mail: azeif@rbsonline.de<br />
20<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
Die Referenzklasse für die<br />
Automatisierungstechnik<br />
www.<strong>atp</strong>-<strong>edition</strong>.de<br />
<strong>atp</strong> <strong>edition</strong> ist das Fachmagazin für die Automatisierungstechnik.<br />
Die Qualität der wissenschaftlichen Hauptbeiträge<br />
sichert ein strenges Peer-Review-Verfahren. Bezug<br />
zur automatisierungstechnischen Praxis nehmen außerdem<br />
die kurzen Journalbeiträge aus der Fertigungs- und<br />
Prozessautomatisierung.<br />
Sichern Sie sich jetzt diese erstklassige Lektüre! Als exklusiv<br />
ausgestattetes Heft oder als praktisches ePaper – ideal für<br />
unterwegs, auf mobilen Endgeräten oder zum Archivieren.<br />
Wählen Sie einfach das Bezugsangebot, das Ihnen zusagt:<br />
• Heft<br />
• ePaper<br />
• Heft + ePaper<br />
25% ersten Bezugsjahr<br />
Rabatt im<br />
<strong>atp</strong> <strong>edition</strong> erscheint in der DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München<br />
WISSEN FÜR DIE<br />
ZUKUNFT<br />
Vorteilsanforderung per Fax: +49 Deutscher 931 Industrieverlag / 4170-494 GmbH | Arnulfstr. oder 124 abtrennen | 80636 München und im Fensterumschlag einsenden<br />
Ja, ich möchte <strong>atp</strong> <strong>edition</strong> regelmäßig lesen und im ersten Bezugsjahr 25 % sparen.<br />
Bitte schicken Sie mir die Fachpublikation für zunächst ein Jahr (10 Ausgaben)<br />
als Heft für € 359,25 zzgl. Versand<br />
(Deutschland: € 30,- / Ausland: € 35,-).<br />
als ePaper (Einzellizenz) für € 359,25<br />
als Heft + ePaper für € 497,03<br />
inkl. Versand (Deutschland) / € 502,03 (Ausland).<br />
Alle Preise sind Jahrespreise und verstehen sich inklusive Mehrwertsteuer. Nur wenn ich nicht bis 8 Wochen<br />
vor Bezugsjahresende kündige, verlängert sich der Bezug zu regulären Konditionen um ein Jahr.<br />
Firma/Institution<br />
Vorname, Name des Empfängers<br />
Straße / Postfach, Nr.<br />
Land, PLZ, Ort<br />
Antwort<br />
Leserservice <strong>atp</strong><br />
Postfach 91 61<br />
97091 Würzburg<br />
Telefon<br />
E-Mail<br />
Branche / Wirtschaftszweig<br />
Telefax<br />
Widerrufsrecht: Sie können Ihre Vertragserklärung innerhalb von zwei Wochen ohne Angabe von Gründen in Textform (z.B.<br />
Brief, Fax, E-Mail) oder durch Rücksendung der Sache widerrufen. Die Frist beginnt nach Erhalt dieser Belehrung in Textform. Zur<br />
Wahrung der Widerrufsfrist genügt die rechtzeitige Absendung des Widerrufs oder der Sache an den Leserservice <strong>atp</strong>, Postfach<br />
9161, 97091 Würzburg.<br />
✘<br />
Ort, Datum, Unterschrift<br />
PAATPE2014<br />
Nutzung personenbezogener Daten: Für die Auftragsabwicklung und zur Pflege der laufenden Kommunikation werden personenbezogene Daten erfasst und gespeichert. Mit dieser Anforderung erkläre ich mich damit einverstanden,<br />
dass ich vom DIV Deutscher Industrieverlag oder vom Vulkan-Verlag per Post, per Telefon, per Telefax, per E-Mail, nicht über interessante, fachspezifische Medien und Informationsangebote informiert und beworben werde.<br />
Diese Erklärung kann ich mit Wirkung für die Zukunft jederzeit widerrufen.
PRAXIS<br />
Komplette Sicherheitslösung modernisiert größte<br />
Bowling-Anlage in Nordrhein-Westfalen<br />
Im Gelsenkirchener Firebowl wurde die Wartezeit verkürzt und das Spiel noch sicherer gemacht<br />
VEREINFACHT DIE SICHERHEIT:<br />
Die „All-Master“-Sicherheits-SPS Pluto<br />
S20 entspricht dem Performance Level<br />
PL e nach EN ISO 13849-1 sowie SIL 3<br />
nach IEC-62061.<br />
DANIELA KARRUKU (20) von<br />
Firebowl freut sich über kurze<br />
Wartezeiten und hohe Sicherheit<br />
beim Bowlen. (Bilder: ABB)<br />
DIE BOWLINGKEGEL werden in der<br />
Maschine über einen Arm vollautomatisch<br />
an die einzelnen Zellen verteilt.<br />
Für den sicheren Betrieb der vollautomatisierten Bowling-Anlage<br />
setzt der Betreiber Firebowl in Nordrhein-<br />
Westfalens größter Bowling-Halle die Sicherheitskomplettlösung<br />
von ABB Stotz Kontakt ein. Damit sollen<br />
in Gelsenkirchen seit März 2012 Mitarbeiter und Spielgäste<br />
geschützt werden. Die Lösung ermöglicht durchgängig<br />
den höchsten Performance Level PL e gemäß<br />
EN ISO 13849-1 und erfüllt so die hohen Anforderungen<br />
der für die Hotellerie und Gastronomie zuständigen Berufsgenossenschaft<br />
Nahrungsmittel BGN.<br />
Für den Personenschutz am Eingang der 30 Bahnen<br />
kommen 15 Unfallschutz-Lichtschranken Spot 35 und<br />
an der Kegel-Aufrichtvorrichtung hinter der Fassadenwand<br />
15 zweistrahlige Unfallschutz-Lichtgitter K1C-500<br />
zum Einsatz. Die Steuerung und Überwachung übernehmen<br />
acht Sicherheits-SPS Pluto S20. Der mobile Zustimmungstaster<br />
JSHD4 mit 15 zugehörigen Steckplätzen<br />
ermöglicht sichere und bequeme Wartungsarbeiten und<br />
Eingriffe bei Störungen im Verteilsystem. Bei Gefahreneintritt<br />
wird ein sofortiger Not-Halt ausgelöst.<br />
VERKÜRZTE WARTEZEITEN BEIM BOWLEN<br />
Das Gelsenkirchener Firebowl setzt Kegelaufsteller vom<br />
Typ MC-2 des chinesischen Herstellers VIA Bowling ein.<br />
Bälle und Kegel befinden sich hier in einem Kreislauf.<br />
Wird ein Ball von einem Spieler geworfen, rollt er zunächst<br />
die 18,3 m lange, mit Spezialöl geschützte Spielfläche<br />
entlang, bis er die auf dem Pindeck in Form eines<br />
gleichseitigen Dreiecks aufgestellten zehn Kegel erreicht.<br />
Das Öl reduziert die Reibung zwischen Bahnoberfläche<br />
und Bowlingball.<br />
Hat der Ball das Pindeck überquert, fällt er zusammen<br />
mit den umgefallenen Kegeln in die Grube und wird vom<br />
Ballheber über eine innerhalb der Maschine befindliche<br />
Rampe zum Spieler zurückgeführt. Hierbei rollt der Bowlingball<br />
unterhalb der Bahn auf Schienen bis zum Ballträger<br />
auf dem Anlauf. Die 20 Bowlingkegel in der Maschine<br />
werden über einen Verteilerarm (Distributor) an<br />
die einzelnen Zellen verteilt.<br />
Im ersten Arbeitsschritt wird ein voller Satz Kegel aufgestellt.<br />
Im zweiten Arbeitsschritt greifen die am Tisch<br />
angebrachten Finger die stehengebliebenen Kegel und<br />
ziehen diese nach oben. Der nach hinten fahrende Kegelrechen<br />
schiebt die umgeworfenen Kegel in die Grube.<br />
Sie werden von dort über das Pinrad wieder nach oben<br />
zum Distributor befördert. Die übrigen Kegel werden<br />
wieder auf das Pindeck gestellt und der Spieler kann den<br />
zweiten Wurf ausführen. Die zwei vollen Kegelsätze in<br />
der Maschine verkürzen die Wartezeit für ein Spiel auf<br />
etwa fünf Minuten.<br />
22<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
EMPFÄNGER DER<br />
UNFALLSCHUTZ-<br />
LICHTSCHRANKE<br />
SPOT 35 mit M12-<br />
Stecker. Die auch<br />
als Ausrichthilfe<br />
fungierende LED-<br />
Anzeige und die<br />
1-kanalige Verdrahtung<br />
sparen<br />
Zeit und Kosten.<br />
SASCHA NIEHAGE (40) und Michael Prebreza (31) haben die<br />
30 vollautomatisierten Bowling-Bahnen für den maximalen<br />
Personen- und Anlagenschutz nach PL e konzipiert. Links das<br />
2-strahlige, gelbe Unfallschutz-Lichtgitter Focus K1C-500.<br />
DER 3-STUFIGE<br />
ZUSTIMMUNGS-<br />
TASTER JSHD4 dient<br />
der sicheren Durchführung<br />
von Einricht-,<br />
Wartungs- und<br />
Servicearbeiten.<br />
Bei panikartigem<br />
Durchdrücken oder<br />
Loslassen schaltet<br />
die Anlage<br />
unverzögert ab.<br />
KOSTEN- UND PLATZEFFIZIENZ GESCHAFFEN<br />
Als sicherheitsgerichtete Logik wurde hier zentral für je<br />
zwei Doppelbahnen, also vier Einzelbahnen, eine Sicherheits-SPS<br />
Pluto S 20 eingesetzt. Sie basiert auf dem „Alles-Master“-Konzept,<br />
das den Entwurf von Sicherheitssystemen<br />
vereinfacht und den höchsten Performance<br />
Level PL e gemäß EN ISO 13849-1 sicherstellt. Aufgrund<br />
des verringerten Verdrahtungs-, Projektierungs- und<br />
Materialaufwands erzielte der Anlagenbetreiber Kosteneinsparungen.<br />
Viele Sicherheitsrelais entfallen und<br />
die kleine Baugröße der Sicherheits-SPS Pluto mit nur<br />
45 Millimeter Breite schaffen im Schaltschrank ausreichende<br />
Platzreserven.<br />
Pluto kann für einzelne Maschinen und für große<br />
Maschinenanlagen eine wirtschaftliche Lösung bieten.<br />
Von Plutos 20 E/A können acht als Eingänge oder Ausgänge<br />
konfiguriert werden, manchmal sogar gleichzeitig<br />
als Ein- und Ausgang, vier sind unabhängige, fehlersichere<br />
Sicherheitsausgänge. Alle Unfallschutzgeräte<br />
können an das Pluto-Gerät angeschlossen werden.<br />
Die doppelte Anzahl von Unfallschutzgeräten lässt sich<br />
anschließen, wenn man dynamische Sensoren von<br />
ABB einsetzt.<br />
Dank der dynamischen Taktsignale konnten die Vorteile<br />
der Sicherheits-SPS voll ausgenutzt werden. Nur ein<br />
Eingang an Pluto sichert die Spieler auf einer Doppelbahn<br />
gemäß dem höchstem Performance Level nach<br />
EN ISO 13849 PL e Kat. 4 ab.<br />
Geschützt werden die Besucher durch die Unfallschutz-Lichtschranke<br />
Spot 35, die nach EN 61496<br />
dem Sicherheitsniveau Typ 4 entspricht. Die einstrahligen<br />
Lichtschranken sind in zwei Ausführungen lieferbar:<br />
Spot 10 für Reichweiten bis zu zehn Meter und Spot<br />
35 für bis zu 35 Meter. Sie bestehen aus einem Sender<br />
und einem Empfänger. In Kombination mit dem Sicherheitscontroller<br />
Vital oder der Sicherheits-SPS Pluto erfüllt<br />
Spot die Anforderungen für Kategorie 4 gemäß<br />
EN ISO 13849-1 und Typ 4 gemäß EN 61496.<br />
Der Einsatz von 1, 2 oder 3 zusätzlichen Umlenkspiegeln<br />
ermöglicht eine Rundum-Absicherung von Gefahrenstellen<br />
wie Roboterbereichen. Jede Unterbrechung des<br />
Strahls führt zur Öffnung der Ausgangskontakte und<br />
somit zur Abschaltung der gefahrbringenden Bewegung.<br />
Mehrere Lichtschranken, berührungslose Schalter Eden<br />
und Not-Abschaltgeräte können in Serie angeschlossen<br />
werden und erreichen somit das hohe Sicherheitsniveau<br />
für die Steuerschaltung. Laut Sascha Niehage, dem technischen<br />
Leiter von Firebowl, war es durch die auch als<br />
Ausrichthilfe fungierende LED-Anzeige, den M12-Anschluss<br />
und die hardwaretechnische 1-kanalige Verdrah-<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
23
PRAXIS<br />
tung einfach, die Sicherheitstechnik von ABB in die<br />
vorhandene Anlage zu integrieren.<br />
ZUVERLÄSSIG BEI STARKEN VIBRATIONEN<br />
Selbst die hohen Vibrationen, die bei einem Volltreffer<br />
entstehen, lösten an den Anfang 2012 installierten Unfallschutz-Lichtschranken<br />
bislang keine einzige Fehlauslösung<br />
aus. Da der Anlagenbetreiber wünschte, dass<br />
Doppelbahnen autark abschalten können, wurde hier für<br />
eine Doppelbahn eine Spot-Lichtschranke integriert, was<br />
wiederum zwei Eingänge an Pluto bedeutet. Der sogenannte<br />
„Catwalk“ dient als Zugang zum Maschinenpark<br />
und als Verbindung zwischen den einzelnen Maschinen.<br />
Zum Schutz des Mitarbeiters wurden die einzelnen<br />
Maschinen mit einem Lichtgitter Focus K1C-500 ausgerüstet.<br />
Das 2-strahlige Unfallschutz-Lichtgitter hat einen<br />
Querschnitt von nur 37 Millimeter x 48 Millimeter und<br />
eine Auflösung beziehungsweise Schutzfeldhöhe von<br />
500 Millimetern. Die in einer Höhe von 400 Millimetern<br />
und 900 Millimetern angeordneten Infrarotstrahlen mit<br />
Reichweiten von 0,2 bis 12 Metern lösen beim Eindringen<br />
in den Gefahrenbereich den Abschaltbefehl aus. Das<br />
vom TÜV nach der Sicherheitsnorm EN/IEC 61496-1/2<br />
zertifizierte Lichtgitter vom Typ 4 lässt sich leicht ausrichten<br />
und installieren. Zu den besonderen Merkmalen<br />
zählen außerdem die Pre-Reset-Funktion, manuelle,<br />
überwachte oder automatische Rückstellung, zwei überwachte<br />
PNP Sicherheits-Ausgänge mit Querschluss-<br />
Überwachung (OSSD) und M12 Anschlüsse. LEDs sorgen<br />
für einfache Ausrichtung und Anzeige von Verschmutzung,<br />
Betriebsspannung (24 VDC) und Ausgangszustand.<br />
EINGRIFF IM LAUFENDEN BETRIEB MÖGLICH<br />
Manchmal ist es notwendig, bei laufendem Betrieb Eingriffe<br />
in die Maschine vorzunehmen. Für diesen Fall<br />
führt der Mitarbeiter einen Dreistufen-Zustimmungstaster<br />
JSHD4 mit sich und steckt diesen an der Stelle der<br />
Anlage ein, an der der Zugriff erfolgt. Das Drücken des<br />
Tasters in die Mittelstellung überbrückt nur das Lichtgitter<br />
der Doppelbahn. Der 3-stufige JSHD4 sichert mit<br />
seinen 15 zugehörigen Steckplätzen Einricht-, Wartungsund<br />
Servicearbeiten an den Kegel-Aufrichtvorrichtungen<br />
der 30 Bahnen. Sollte der Wartungstechniker aufgrund<br />
einer drohenden Gefahr den 2-kanaligen Zustimmungstaster<br />
panikartig durchdrücken oder loslassen,<br />
schaltet die Anlage sofort ab.<br />
Der Zustimmungstaster erteilt in der oberen und unteren<br />
Stellung einen Abschaltbefehl, und in der Mittelstellung<br />
ein Start- oder Bereitschaftssignal. Nach Abschaltung<br />
in der unteren Stellung ist ein Start- oder<br />
Bereitschaftssignal nicht möglich. Erst nachdem der<br />
Griff des Dreistufen-Tasters völlig losgelassen und anschließend<br />
wieder in die Mittelstellung gedrückt worden<br />
ist, erfolgt die Freigabe. Wenn man den Taster an ein<br />
2-kanaliges Sicherheitsrelais (RT6) oder an eine Sicherheits-SPS<br />
Pluto anschließt, werden Kurzschlüsse im<br />
Kabel sowie Fehler an den Eingängen und an den Ausgangsschützen<br />
sofort erkannt.<br />
Die Lichtschranke Spot im vorderen Bereich der Kunden<br />
bleibt aktiv und kann nicht überbrückt werden. Nun<br />
kann der Mitarbeiter mit dem Zustimmungstaster die<br />
Anlage bei laufendem Betrieb betreten und Arbeiten an<br />
Abräumer, Ballheber oder Pinaufzug vornehmen. Zwei<br />
optionale Zusatztasten realisieren Hilfsfunktionen. Bei<br />
Robotern werden Dreistufen-Taster häufig an Einricht-<br />
Panels für Fehlersuche, Programmierung und Probebetrieb<br />
eingesetzt.<br />
INSPEKTEURE EMPFEHLEN DIE LÖSUNG WEITER<br />
Der bei Firebowl in Gelsenkirchen mit der Planung,<br />
Installation und Wartung betraute Technische Leiter,<br />
Sascha Niehage ist mit der von Michael Prebreza entworfenen<br />
Sicherheits-Komplettlösung sowie dem<br />
durchgängigen Erreichen des höchsten Performance<br />
Levels PL e zufrieden.<br />
Nachdem er sich anfangs mit Sicherheitslichtschranken<br />
anderer Marken häufige Ausfälle und viel Kundenärger<br />
eingeholt hatte, wechselte er auf vibrationsfeste<br />
Unfallschutz-Komponenten von ABB um. Seitdem funktioniert<br />
die Bowling-Anlage so zuverlässig und sicher,<br />
dass die Inspekteure der Berufsgenossenschaft BGN die<br />
Sicherheitslösung weiterempfehlen.<br />
Neben den Preisvorteilen lobt Niehage die hohe Fachkompetenz<br />
von ABB beim Projektieren, Installieren und<br />
Programmieren mit der zugehörigen kostenlosen Software<br />
Pluto Manager sowie beim Durchführen der umfangreichen<br />
Funktionstests. Zudem ist der Kunde vom<br />
kurzfristig verfügbaren Service und der ausführlichen<br />
Beratung überzeugt. Die einfache Bedienung und der<br />
problemlose Einbau der schwedischen Unfallschutzgeräte<br />
ersparten ihm viel Zeit und Kosten.<br />
AUTOR<br />
Dipl.-Wirtsch.-Ing<br />
MICHAEL PREBREZA<br />
ist Vertriebsbeauftragter<br />
für Nordrhein-Westfalen<br />
bei ABB Stotz-Kontakt in<br />
D-78549 Spaichingen.<br />
ABB Stotz-Kontakt GmbH,<br />
Max-Planck-Straße 21, D-78549 Spaichingen,<br />
Tel. +49 (0) 7424 95 86 50,<br />
E-Mail: michael.prebreza@de.abb.com<br />
24<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
IT-Security in der Praxis<br />
Industrielle Informationssicherheit<br />
Gereviewte Beiträge aus dem Automatisierungsfachtitel <strong>atp</strong> <strong>edition</strong><br />
sind unter dem Schwerpunkt „Industrielle Informationssicherheit“ neu<br />
zusammen gestellt worden. Praxisrelevante Maßnahmen zur Umsetzung<br />
aktueller Normen und Leitfäden sicherer Kommunikation in der<br />
Industrie geben den aktuellen Stand der Wissenschaft wieder.<br />
Hrsg.: Leon Urbas<br />
1. Auflage 2014<br />
96 Seiten, farbig, Broschur<br />
ISBN: 978-3-8356-7113-3<br />
Preis: € 59,–<br />
www.di-verlag.de<br />
Das Buch erscheint im DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München<br />
Jetzt bestellen!<br />
WISSEN FÜR DIE<br />
ZUKUNFT<br />
Bestellung per Fax: +49 201 / 820 Deutscher 02-34 Industrieverlag oder GmbH abtrennen | Arnulfstr. und 124 im | Fensterumschlag 80636 München einsenden<br />
Ja, ich bestelle gegen Rechnung 3 Wochen zur Ansicht<br />
___Ex.<br />
Industrielle Informationssicherheit<br />
1. Auflage 2014 – ISBN: 978-3-8356-7113-3 für € 59,– (zzgl. Versand)<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 />
Vulkan-Verlag GmbH<br />
Versandbuchhandlung<br />
Postfach 10 39 62<br />
45039 Essen<br />
E-Mail<br />
Branche / Wirtschaftszweig<br />
Bevorzugte Zahlungsweise Bankabbuchung Rechnung<br />
Bank, Ort<br />
Widerrufsrecht: Sie können Ihre Vertragserklärung innerhalb von zwei Wochen ohne Angabe von Gründen in Textform (z.B.<br />
Brief, Fax, E-Mail) oder durch Rücksendung der Sache widerrufen. Die Frist beginnt nach Erhalt dieser Belehrung in Textform.<br />
Zur Wahrung der Widerrufsfrist genügt die rechtzeitige Absendung des Widerrufs oder der Sache an die Vulkan-Verlag GmbH,<br />
Versandbuchhandlung, Postfach 10 39 62, 45039 Essen.<br />
Bankleitzahl<br />
Ort, Datum, Unterschrift<br />
Kontonummer<br />
PAATP52013<br />
Nutzung personenbezogener Daten: Für die Auftragsabwicklung und zur Pflege der laufenden Kommunikation werden personenbezogene Daten erfasst und gespeichert. Mit dieser Anforderung erkläre ich mich damit einverstanden, dass ich<br />
vom DIV Deutscher Industrieverlag oder vom Vulkan-Verlag per Post, per Telefon, per Telefax, per E-Mail, nicht über interessante, fachspezifische Medien und Informationsangebote informiert und beworben werde.<br />
Diese Erklärung kann ich mit Wirkung für die Zukunft jederzeit widerrufen.
HAUPTBEITRAG<br />
<strong>Datenkopplung</strong> <strong>mittels</strong><br />
<strong>UML</strong>-<strong>Modellen</strong><br />
Engineering- und IT-Systeme für Industrie 4.0 vernetzen<br />
Für Industrie 4.0 ist die Kopplung der Daten aus Engineeringsystemen, Laufzeitsystemen<br />
sowie übergeordneten IT-Systemen eine Voraussetzung, um flexibel auf Änderungen im<br />
Produktionsprozess aber auch in der Ablösung von IT-Systemen reagieren zu können. In<br />
dem Beitrag werden zunächst Anforderungen an die Modellierung der <strong>Datenkopplung</strong><br />
verschiedener Engineering-, Produktions- sowie ERP-Systeme aufgestellt und die Auswahl<br />
von <strong>UML</strong> als Modellierungssprache entlang eines Kriterienkatalogs begründet. Anschließend<br />
wird die Information, die für die Durchführung der <strong>Datenkopplung</strong> notwendig ist,<br />
modellbasiert und aufgabenorientiert in sieben Untermodelle gegliedert und mit unterschiedlichen<br />
<strong>UML</strong>-Diagrammen modelliert. Der Ansatz ist im Rahmen eines Forschungsprojektes<br />
für einen Produktionsbetrieb erarbeitet und implementiert worden.<br />
SCHLAGWÖRTER Datenintegration / <strong>UML</strong>-Modell / Daten-Backbone<br />
Data Coupling using <strong>UML</strong> Models –<br />
Coupling Engineering and IT Systems as Basis for Industry 4.0<br />
For Industry 4.0, the coupling of data from engineering systems, run-time systems, and<br />
higher level IT systems forms a basis for flexible reactions to changes in the production<br />
process or to the replacement of IT systems. This article explains the selection of <strong>UML</strong> as<br />
a notation for modelling the data coupling of engineering systems, run-time systems on the<br />
control level, as well as MES, ERP or other IT systems. The information needed for the data<br />
coupling is structured in seven sub-models with differing <strong>UML</strong>-diagrams. The approach<br />
has been developed and implemented for a production plant as part of a research project.<br />
KEYWORDS data coupling / <strong>UML</strong> model / data backbone<br />
26<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
BIRGIT VOGEL-HEUSER, Technische Universität München<br />
BAGHER FEIZ-MARZOUGHI, Siemens<br />
Es ist illusionär, zu glauben, es ließe sich ein System<br />
bauen, das alle Daten der realen Welt enthält,<br />
und sei es auch nur eines realen Produktionsstandorts,<br />
und damit alle gewünschten<br />
Funktionen versorgt. Die Komplexität der realen<br />
Welt kann nicht reduziert werden; die Aufgabe ist es, sie<br />
beherrschbar zu machen.<br />
Der Grundgedanke des vorgestellten Ansatzes ist es,<br />
einen Mechanismus zu finden, der möglichst automatisch<br />
und generisch die Durchgängigkeit der Daten und<br />
Datenstrukturen – im Folgenden als Transparenz bezeichnet<br />
– zur Verfügung stellt, mit dem sich unter anderem<br />
die unterschiedlichen IT-Systeme, die diese Daten<br />
manipulieren, kombinieren lassen.<br />
Daten überdauern schon allein aufgrund der notwendigen<br />
Datenarchivierung im Zusammenhang mit Validierung<br />
oder Zertifizierungsprozessen. Die Funktionen,<br />
die auf diesen Daten ausgeführt werden müssen oder<br />
die zwischen diesen Daten bestehen, ändern sich hauptsächlich<br />
wegen Änderungen im Produktionsablauf. Zur<br />
Ablösung existierender monolithischer, starrer Systeme<br />
durch neue muss eine solche Transparenz zu Grunde<br />
gelegt werden. Für die Innovation beziehungsweise Änderungen<br />
aufgrund technologischer Umgestaltung der<br />
Schnittstellen solcher Systeme ist eine derartige Transparenz<br />
notwendig, um die Migration und Implementierung<br />
von Standard-Software-Produkten zu erlauben,<br />
vor allem im produktionsnahen Umfeld. Hier ist die<br />
Dynamik der Datenänderung sehr hoch und in der Regel<br />
nicht vorhersehbar.<br />
Das Prinzip des Daten-Backbone, der sich aus einer<br />
zentralen Datenstruktur (und nicht Datenhaltung à la<br />
Data Warehouse), <strong>Modellen</strong> und Codegeneratoren zusammensetzt,<br />
stellt das Realisierungskonzept dieser Transparenz<br />
dar, siehe Bild 1.<br />
Im zentralen Daten-Backbone werden die unterschiedlichen<br />
Datenaspekte eines Unternehmens (Geschäfts-,<br />
Prozess-, Daten-, Modell-, Anwendungs-,…-Sicht) im Datenmodell<br />
abgebildet und miteinander in Verbindung<br />
gesetzt und gepflegt. Diese Datentransparenz soll die<br />
Grundlage einer beispielhaften Realisierung von Industrie<br />
4.0 werden, bei der darüber hinaus die Aspekte<br />
Cloud-Computing und serviceorientierte Architektur<br />
(SOA) berücksichtigt werden müssen.<br />
1. MODELL DER AUTOMATISIERUNGSTECHNIK:<br />
VON DER PYRAMIDE ZUM DIABOLO<br />
Über Jahrzehnte hinweg war die Automatisierungspyramide,<br />
siehe Bild 2, das Modell zur Einordnung von<br />
Automatisierungsaufgaben und -geräten. Auf unterster<br />
Ebene werden die vielen kleinen echtzeitfähigen Datenpakete<br />
der Feldgeräte (Sensoren und Aktoren) gesammelt<br />
und zur übergeordneten Kontrollebene geleitet,<br />
wo diese zur Steuerung des Produktionsprozesses<br />
verwendet werden. Zur nächsthöheren Ebene der<br />
Mensch-Maschinen-Schnittstellen wird nur noch die<br />
Information weitergeleitet, die für den Operator einer<br />
Anlage wichtig ist. Diese Datenübertragungen sind<br />
typischerweise umfangreicher, treten jedoch in geringerer<br />
Häufigkeit auf. Zur Spitze der Pyramide hin werden<br />
nur noch Leistungskennzahlen und Produktionszahlen<br />
an die Betriebsplanung der Produktionsanlage<br />
übermittelt.<br />
Für die Hersteller von Automatisierungssystemen erwies<br />
sich die Einteilung der Automatisierungstechnik<br />
in Automatisierungsebenen lange Zeit als vorteilhaft,<br />
da die Hersteller mit ihren Systemen lediglich die Anforderungen<br />
einer Ebene erfüllen mussten. Ein Anbieter<br />
von Feldgeräten, die für den Einsatz in der untersten<br />
Ebene bestimmt sind, musste mit seinen Systemen all<br />
diejenigen Funktionen bereitstellen, die von der übergeordneten<br />
Automatisierungsebene benötigt wurden.<br />
Jedes System innerhalb der Informationspyramide muss<br />
nur die Schnittstelle zur direkt über- beziehungsweise<br />
unterlagerten Ebene bedienen, sodass Hersteller sich bei<br />
der Entwicklung ihrer Produkte auf eben diese fokussieren<br />
konnten.<br />
Immer intelligentere Feldgeräte mit leistungsfähigeren<br />
Prozessoren und Diagnosefähigkeiten (Self-X-Fähigkeit)<br />
führen ebenso zu einem Zusammenfallen der unteren<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
27
HAUPTBEITRAG<br />
Ebenen der Pyramide wie die Einführung von echtzeitfähigen<br />
Ethernet-Derivaten für Feldgeräte-, Steuerungsund<br />
HMI-Systeme. Daraus entstand der Diabolo [1], siehe<br />
Bild 3. Das Akronym Diabolo kann als Distributed Information<br />
Architecture to Bolster Lifecycle Optimization,<br />
also als eine verteilte Datenarchitektur zur Unterstützung<br />
der Lebenszyklusoptimierung verstanden werden.<br />
Der untere Konus beinhaltet die Funktionalitäten der<br />
Feldgeräte und der Steuerungs- und Visualisierungsebene.<br />
Der obere Konus repräsentiert die MES-Ebene mit der<br />
Schnittstelle zum ERP, die durch die Abbildung des<br />
MESA-Modells repräsentiert wird.<br />
1.1 Module und Schnittstellen<br />
Um Plug-and-produce zu ermöglichen, siehe Bild 3, müssen<br />
die Schnittstellen zwischen den Systemen im Hinblick<br />
auf eine unternehmensweite Datenintegration modelliert<br />
werden. Mit der Einführung der Datenmodellschicht<br />
(Informationsmodell) als übergreifende Schnittstelle<br />
aller Informationsflüsse lässt sich dieses Ziel<br />
erreichen. Die Platzierung als Ebene zwischen den beiden<br />
Teilsystemen (Konussen) ermöglicht, dass ein effizienter<br />
vertikaler und horizontaler Datenaustausch entweder<br />
mit Hilfe der Einführung standardisierter Datenformate<br />
oder einem einheitlichen Vorgehen zur Datenmodellierung<br />
samt Notation erreicht werden kann,<br />
beziehungsweise durch sich selbst organisierende serviceorientierte<br />
Komponenten.<br />
Der Lebenszyklus wurde beim Diabolo in X-Richtung<br />
dargestellt: Die Daten werden während der Phasen des<br />
Lebenszyklus immer weiter verfeinert und gehen von<br />
den Engineeringsystemen in die Laufzeitsysteme wie<br />
speicherprogrammierbare Steuerungen, Prozessleitsysteme<br />
oder CNC über, während im oberen Teil des Konus<br />
die IT-Systeme repräsentiert sind.<br />
Aus informationstechnischer Sicht werden die Prozessdaten<br />
und die Produktionsdaten initial durch Feldgeräte<br />
oder deren Kombination geliefert, die im Anschluss<br />
verknüpft und somit durch weitere Information<br />
angereichert werden, die unter Zuhilfenahme von intelligenten<br />
Vorverarbeitungssystemen innerhalb des unteren<br />
Konus erzeugt werden. Das Generieren der Daten<br />
kann dementsprechend als Zusammenspiel einer Vielzahl<br />
unterschiedlicher Systeme gesehen werden, die ihre<br />
angereicherten Daten über eine neutrale Datenmodellschicht<br />
oder modellierte <strong>Datenkopplung</strong>en den Systemen<br />
des oberen Konus zur Verfügung stellen.<br />
Prinzipiell handelt es sich um Informationsdienste.<br />
Die Weitergabe der Daten von den Informationsdiensten<br />
an die Datenmodellschicht erfolgt auf der Basis eines<br />
definierten Satzes an Diensten oder Services. Die Architektur<br />
der Datenmodellschicht lässt sich daher als serviceorientierte<br />
Architektur bezeichnen.<br />
Bei den zeitlichen Anforderungen kann die Datenmodellschicht<br />
Prozessdaten mit sehr eingeschränkten Echtzeitanforderungen<br />
an den oberen Konus bereitstellen, da<br />
die hier enthaltenen Systeme an den zeitlichen Bedürfnissen<br />
ihrer menschlichen Anwender orientiert sind. Die<br />
Kommunikation innerhalb des unteren Konus hingegen<br />
ist bestimmt durch Echtzeitanforderungen und muss<br />
Abtastraten von mehreren kHz gewährleisten. Für das<br />
Informationsmodell sollen eine serviceorientierte Archi-<br />
BILD 2: Informationspyramide der Automatisierungstechnik [1]<br />
BILD 1: Daten-Backbone zwischen<br />
PLM, ERP, MES und Prozess-Ebene<br />
28<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
tektur unterstützt und gleichzeitig auch Echtzeitbedingungen<br />
eingehalten werden.<br />
Um die Komplexität des Produktionsprozessmodells<br />
beherrschbar zu machen, empfiehlt es sich, den Gesamtprozess<br />
in aufgabenspezifische Module zu unterteilen.<br />
Mit der Einführung des Diabolo lassen sich komplexe<br />
Produktionsprozesse in eine Kombination verschiedener<br />
Teilprozessdiabolo überführen, die in horizontaler Richtung<br />
über ihre Informationsschichten gekoppelt werden.<br />
Um die beschriebenen Ebenen der unterschiedlichen<br />
Diabolos miteinander verknüpfen und damit einen Datenaustausch<br />
realisieren zu können, ist eine systemübergreifende<br />
<strong>Datenkopplung</strong> notwendig. Diese <strong>Datenkopplung</strong><br />
ist ohne ein geeignetes Modellierungskonzept kaum<br />
beherrschbar. Im Folgenden werden die Anforderungen<br />
an ein solches Konzept zur Beschreibung der System-<br />
Datenverknüpfung erläutert.<br />
2. ANFORDERUNGEN AN DEN MODELLIERUNGSANSATZ<br />
Die hohe Dynamik der Veränderungen von Produktionsanlagen<br />
und die Mehrdimensionalität der Einflussfaktoren<br />
zwingen Anlagenbetreiber, über den Tellerrand zu<br />
schauen und die Schnittstellen der eigenen Bereiche mit<br />
den benachbarten zu berücksichtigen, um mehr Flexibilität,<br />
hohen Automatisierungsgrad, hohe Qualität und<br />
gesicherte Lieferfähigkeit zu gewährleisten.<br />
Das betrifft die komplette Lieferkette und interdisziplinäre<br />
Aspekte, wie IT-Innovationen und -Trends, Informationssicherheit,<br />
Produkthaftung, globale Rückverfolgbarkeit,<br />
Eingliederung beziehungsweise Ausgliederung bestimmter<br />
Unternehmenseinheiten (Carve-In, Carve-Out).<br />
Als eine mögliche Lösung bietet sich ein generischer Modellierungsansatz<br />
an, der in der realen Welt des Produktionsstandortes<br />
implementiert und überprüft werden<br />
muss. Dies führt in der Regel wiederum zu einer Anpassung<br />
der Modelle. Je öfter diese Erprobung und anschließende<br />
Anpassung geschieht, desto globaler sollte die Einsetzbarkeit<br />
dieser Modelle werden. Die Idee ist also, anstatt<br />
bei jeder Veränderung, wie beispielsweise der Einführung<br />
eines neuen IT-Systems beziehungsweise dessen Ablösung<br />
oder des Abbaus einer alten Produktionslinie und des Ersatzes<br />
durch eine neue, ein neues Vorhaben (Projekt) zu<br />
starten, die zu betrachtende Welt (zum Beispiel Control<br />
mit allen IT-Systemen und Produktionslinien) einmalig<br />
modellbasiert abzubilden und die laufenden Veränderungen<br />
durch die Etablierung von definierten Geschäftsprozessen<br />
zeitnah durch Anpassung des Modells aufnehmen<br />
zu können. Dadurch lassen sich diverse Prozesse simulieren,<br />
bevor die eigentliche Umsetzung gestartet wird.<br />
Die durch Modelle abgebildete Information beinhaltet<br />
dadurch die Struktur der Produktionsinfrastruktur und<br />
die Information zur Anbindung relevanter IT-Systeme<br />
und deren Schnittstellen. Wird ein IT-System abgelöst,<br />
kann anhand von transparenten Datenstrukturen und<br />
Funktionen, die durch generische und spezifische Modelle<br />
geschaffen wurden, eine Ablösestrategie gefunden<br />
werden, bevor eine Zeile Code geschrieben wurde. Zur<br />
Abgrenzung der unterschiedlichen Unternehmensebenen<br />
(MES, ERP, PLM) dienen diese Modelle ebenso wie<br />
zur Sicherstellung ihrer Interoperabilität.<br />
Durch das Ablegen von definierten Zuordnungen zwischen<br />
Systemen und einzelner Informationsobjekte und<br />
Toolkopplung<br />
Modulkopplung<br />
Lebenszyklus<br />
Informationsmodell<br />
Kopplung Modul<br />
zu Modul<br />
Enterprise Resource Planning (ERP)<br />
1) 2)<br />
Informationsmodell<br />
1) 2)<br />
Kopplung Modul<br />
zu Modul<br />
Informationsmodell<br />
1) 2)<br />
BILD 3: Diabolo der<br />
Automatisierungstechnik [1]<br />
1) 2)<br />
Prozessmodul (n)<br />
Prozessmodul (2)<br />
Prozessmodul (1)<br />
Produktionsprozess<br />
Design<br />
Inbetriebsetzung<br />
und Abnahme<br />
Betrieb/<br />
Wartung<br />
Anforderungsermittlung<br />
Komponentenentwicklung<br />
Komponententest<br />
Re-<br />
Engineering<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
29
HAUPTBEITRAG<br />
Beschreibungsmittel<br />
Nicht deterministisch<br />
Statisch<br />
Entity-Relationship-Model (ERM) x x x x<br />
<strong>UML</strong> 2.0 [02] x x x x x x x x x x x x x x x x x x<br />
SysML [02] x x x x x x x x x x x x x x x x x x x<br />
BPMN 2.0 [02] x x x x x x x x x x x x<br />
AutomationML x x x x x x x x<br />
Objektzuordnung<br />
Verhaltensbeschreibung<br />
Explizite<br />
Zeitdarstellung<br />
Formal<br />
Semi-formal<br />
Informal<br />
Deterministisch<br />
Dynamisch<br />
Ereignisgetrieben diskret<br />
Zeitdiskret (taktgetrieben)<br />
Zeitkontinuierlich<br />
Hierarchie<br />
Komposition / Dekomposition<br />
Textuell<br />
Formale Basis<br />
Struktur<br />
Synchronisation<br />
(falls verteilte<br />
Prozesse möglich)<br />
Darstellung<br />
Kriterium<br />
Strukturveränderung<br />
Synchron<br />
Asynchron<br />
Nebenläufig<br />
Mathematisch-symbolisch<br />
Grafisch<br />
Datenstruktur<br />
Regelbeschreibung<br />
Ablaufsteuerung<br />
Sichten<br />
Instanziierung<br />
<strong>Datenkopplung</strong><br />
Verschachtelung<br />
TABELLE 1: Erfüllung der erweiterten Einordnungskriterien durch ausgewählte Beschreibungsmittel<br />
in Anlehnung an VDI/VDE 3681 [13]<br />
deren Attribute wird eine Analyse der aktuellen Systemlandschaft<br />
möglich und die Erarbeitung neuer Produktions-<br />
beziehungsweise IT-Konzepte effizient. Sind<br />
beispielsweise die Bestandteile eines Fertigungsauftrags<br />
(Key, Eigenschaft, Attribute) sowie die Ebene für<br />
die Manipulation von Attributen bekannt, kann nach<br />
der Zuordnung der jeweiligen IT-Systeme zu den Ebenen<br />
bei der nächsten Anforderung eine generische Lösung<br />
erzeugt werden.<br />
Als Basis für die Erläuterung der Anforderungen<br />
dient das im Folgenden beschriebene Beispiel. Zwischen<br />
zwei Systemen soll technische Information zu<br />
einem Produkt ausgetauscht werden. Diese Information<br />
lässt sich in einem Datenelement zusammenfassen. Das<br />
Datenelement kann hierarchisch in Objekte zerlegt werden.<br />
Ein ERP-System gibt eine vollständige Produktinformation<br />
an ein MES weiter, das dieses Datenelement<br />
benötigt, um die Produktionsanlagen zu parametrieren.<br />
Um das Element im Datenverkehr eindeutig wiederzuerkennen,<br />
sind Identifikationsdaten nötig. Das wichtigste<br />
Objekt des Elements bilden dafür die Kopfdaten<br />
mit dem Unterobjekt Identifikationsbezeichnung. Beispielhaft<br />
sind dies ein alphanumerisches Präfix, welches<br />
im ERP-System dem Identifier vorangestellt ist; es<br />
muss für das MES entfernt werden. Anhand dieses<br />
Beispiels können bereits die wichtigsten Anforderungen<br />
an eine Modellierungssprache zur <strong>Datenkopplung</strong><br />
abgeleitet werden.<br />
Die Basis des Datenaustausches bildet das zu übertragende<br />
Element mit dem hierarchischen Aufbau von Objekten,<br />
Unterobjekten und Attributen. Dabei stellen Attribute die<br />
unterste Einheit eines Datenelements dar. Für den Übertrag<br />
vom ERP-System ins MES müssen die Objekte des Ausgangssystems<br />
entweder ganz oder basierend auf ihre Unterobjekte/Attribute<br />
teilweise den entsprechenden Objekten<br />
des MES zugeordnet werden. Die dabei notwendigen Anpassungen<br />
der Objekte, wie die im Beispiel erwähnte Reduktion<br />
um das Präfix, müssen in der Abbildung der <strong>Datenkopplung</strong><br />
beschreibbar sein. Für die Übermittlung des<br />
Datenelements vom ERP zum MES sind meist systemspezifische<br />
Abfolgen von Befehlen notwendig. Zusätzlich erfordert<br />
es im Allgemeinen komplexe Anfrage- und Anmeldesequenzen,<br />
um die Kommunikation mit einem System<br />
zu initialisieren. Der gesamte Vorgang des Austauschs eines<br />
Datenelements findet im Kontext eines unternehmensinternen<br />
Prozesses eines Geschäftsprozesses statt.<br />
Zusammenfassend ergeben sich folgende Anforderungen<br />
an die Modellierung einer systemübergreifenden<br />
<strong>Datenkopplung</strong>:<br />
Der Modellierungsansatz muss die Abbildung statischer<br />
Datenstrukturen, deren Zusammenhänge und<br />
30<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
Eigenschaften sowie die Modellierung systemübergreifender<br />
Objektzuordnungen ermöglichen.<br />
Transformationen und eine Möglichkeit der Ablaufsteuerung<br />
müssen modellierbar und in die Datenzuordnung<br />
integrierbar sein.<br />
Modelle können nicht nur zur Entwurfsplanung genutzt<br />
sondern durch die Einhaltung formalisierter<br />
Kriterien direkt von einer Ablaufumgebung interpretiert<br />
und ausgeführt werden.<br />
Systemspezifische Abläufe sind abzubilden, ebenso<br />
wie übergeordnete Geschäftsprozesse.<br />
Anforderungen an die Modellierungsnotation:<br />
Die Modellelemente sollen möglichst reduziert und<br />
an die Modellierungsaufgabe angepasst sein.<br />
Modulbildung, Schachtelung und Instanziierung<br />
müssen möglich sein.<br />
Im Hinblick auf ein unternehmensweites Netzwerk<br />
mit vielen angeschlossenen IT- und Produktionssystemen<br />
ist es essenziell, eine geeignete Semantik und<br />
darauf aufbauend eine neutrale, systemunabhängige<br />
Datenstruktur zu definieren. Alle Anpassungen an<br />
Datenelemente und die Zuordnungen der Objekte zwischen<br />
den Systemen (ERP und MES) sollen basierend<br />
auf dieser Struktur formuliert werden können. Ferner<br />
kann diese Datenstruktur als zentrale Schnittstelle<br />
eingesetzt werden, an die alle Systeme eines Netzwerks<br />
verbunden werden. Eine zusätzliche zentrale<br />
Datenhaltung soll dabei entgegen vielen aktuellen<br />
Ansätzen nicht erforderlich sein, um Konsistenzprobleme<br />
zu vermeiden. Wird ein System ausgetauscht<br />
oder kommt ein neues hinzu, müssen nur die Zuordnungen<br />
der Objekte im zentralen Datenmodell definiert<br />
oder angepasst werden.<br />
3. DATENKOPPLUNG VON ENGINEERINGWERKZEUGEN<br />
Eine derzeit verbreitet eingesetzte Möglichkeit zur <strong>Datenkopplung</strong><br />
stellen die Enterprise-Service-Busse (ESB)<br />
verschiedener Hersteller dar [2]. Durch die Verwendung<br />
eines ESB können unterschiedliche Systeme miteinander<br />
verknüpft werden, ohne dass die Datenelemente<br />
zentral gespeichert werden müssen. ESB verwenden<br />
eigene interne (neutrale) Datenformate für den Austausch<br />
und bieten eine Vielzahl an Schnittstellen (Adapter),<br />
um IT-Systeme anbinden zu können. Durch die<br />
Auswahl eines ESB-Anbieters wird gleichzeitig die anbieterspezifische<br />
Beschreibungssprache ausgewählt. Die<br />
Beschreibung der Zusammenhänge findet hier jedoch<br />
meist auf Basis von Code statt und lässt sich nur mit viel<br />
Aufwand von einem ESB auf einen anderen übertragen.<br />
Es müssen andere Funktionen oder schlimmstenfalls<br />
andere Programmiersprachen verwendet werden. Für<br />
das zu erarbeitende Konzept gilt die Anforderung, die<br />
Systemkopplung ESB-neutral zu beschreiben, um dieses<br />
Wissen anbieterunabhängig und damit dauerhaft, im<br />
Sinne von auf verschiedene Anbieter adaptierbar, zur<br />
Verfügung zu stellen. Als Basis für die <strong>Datenkopplung</strong><br />
wird ein zentrales Datenmodell erarbeitet und in Abschnitt<br />
5 vorgestellt.<br />
3.1 Datenaustauschformate<br />
Bereits existent sind hierfür unter anderem die Electronic<br />
Device Description Language (EDDL) [3], Computer<br />
Aided Engineering Exchange (CAEX) [4], eClass [5]<br />
und AutomationML [6]. Diese Datenmodelle beschränken<br />
sich auf eine bestimmte Ebene der Automatisierungspyramide.<br />
Sie stellen daher nicht jede für den<br />
unternehmensübergreifenden Datenaustausch benötigte<br />
Meta-Information bereit (wie beispielsweise die Zuordnung<br />
oder Dimension). Für den Datenaustausch<br />
zwischen IT-Systemen, abgesehen von ESB-Lösungen,<br />
wurde der Industriestandard OLE for Process Control<br />
Data Access (OPC DA) [7] und OPC Unified Architecture<br />
(UA) [8] entwickelt. Beide Standards sind für den<br />
Austausch von Prozessdaten gedacht, nicht für beliebige<br />
Daten aus beliebigen IT-Systemen. Eine weitere<br />
Entwicklung ist der Automation Service Bus (ASB) [9].<br />
Ein ASB ist stark auf das Engineering von Anlagen<br />
zugeschnitten, nicht auf die Kopplung von im Betrieb<br />
eingesetzten IT-Systemen. Des Weiteren wurde im SFB<br />
476 [10] die Optimierung von Engineeringprozessen<br />
und des -workflows sowie die Integration der disziplinspezifischen<br />
Engineeringsysteme entlang des Lebenszyklus<br />
der Prozessindustrie untersucht [11]. Die<br />
Integration fokussiert auf das Engineering mit einem<br />
datei- und segmentbasierten Ansatz und vernachlässigt<br />
die Laufzeit und die Leit- und Steuerungssysteme. Um<br />
die Datenelemente in der Automatisierungstechnik<br />
abbilden zu können, sind von den bestehenden Formaten<br />
beispielsweise die XML-basierten interessant. Diese<br />
sind systemunabhängig und lassen sich einfach als<br />
Ausgangsbasis für eine Anpassung nutzen.<br />
Ein Schwachpunkt vieler Kopplungskonzepte besteht<br />
darin, dass eine Referenzstruktur zur Speicherung komplex<br />
strukturierter Anlagendaten fehlt, auf die alle weiteren<br />
statischen wie dynamischen Modellierungen zurückgreifen<br />
können. Die AutomationML schließt diese<br />
Lücke, indem sie das etablierte, objektorientierte Austauschformat<br />
der CAEX für den automatisierungstechnischen<br />
Einsatz weiterentwickelt. Das XML-basierte<br />
Datenformat unterstützt Konzepte wie Klassen, Instanzen<br />
und Vererbung. Ausgehend von der Darstellung rein<br />
hierarchischer Objektinformationen mit CAEX wird die<br />
AutomationML sukzessive um Speicherformate für Geometrie-<br />
und Kinematikdaten erweitert, basierend auf der<br />
Spezifikation COLLADA (COLLAborative Design Activity)<br />
[12] und für Verhaltensbeschreibungen <strong>mittels</strong><br />
PLCopen [13]. Durch die Kombination dieser etablierten<br />
Standards und Spezifikationen entsteht ein gewerkeübergreifendes<br />
Austauschformat.<br />
Obwohl die AutomationML für den Datenaustausch<br />
entwickelt wurde, beschränkt sie sich auf den sehr<br />
engen Bereich der Datenstrukturierung. Die Semantik<br />
der Daten wird jedoch nur eingeschränkt betrachtet.<br />
Abläufe, die für den Datenaustausch notwendig sind,<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
31
HAUPTBEITRAG<br />
bleiben ebenfalls unbeachtet. So eignet sich die AutomationML<br />
vor allem für den Bereich der Modellierung<br />
von Datenstrukturen, kann jedoch auch zur Darstellung<br />
bei der Zuordnung von Objekten eingesetzt werden.<br />
Ist ein anbieterunabhängiges Austauschformat<br />
definiert, muss der für die <strong>Datenkopplung</strong> notwendige<br />
Ablauf und der benötigte Adapter beschrieben werden.<br />
Grundsätzlich stellt sich die Frage, ob eine bestehende<br />
Modellierungssprache mit ihren Diagrammen<br />
und Notationselementen für den Einsatz zur Beschreibung<br />
einer systemübergreifenden <strong>Datenkopplung</strong> geeignet<br />
ist.<br />
3.2 Kriterien zur Bewertung von Modellierungssprachen<br />
In diesem Abschnitt wird für die Bewertung der Modellierungssprachen<br />
die Richtlinie VDI/VDE 3681 [14] um<br />
die Anforderungen zur systemübergreifenden <strong>Datenkopplung</strong><br />
ergänzt, um existierende Modellierungssprachen<br />
im Anschluss zu bewerten, vergleiche Tabelle 1.<br />
Die erste der kopplungsspezifischen Kriterien adressiert<br />
die Darstellung der Datenstrukturen der an ein Unternehmensnetzwerk<br />
angeschlossenen Systeme. Die<br />
Modellierungssprache muss zur Darstellung von Hierarchien,<br />
Kompositionen und Zusammenhängen von Klassen<br />
und Attributen eine neutrale Struktur bereitstellen.<br />
Die Modellierung einer neutralen Datenstruktur, in die<br />
alle Systeme abgebildet werden, ebenso wie die Darstellung<br />
der spezifischen Strukturen der anzukoppelnden<br />
Systeme stellt den Kern eines modellbasierten Kopplungskonzeptes<br />
dar.<br />
Um die Zuordnung zweier Datenobjekte aus zwei zu<br />
koppelnden Systemen zu ermöglichen, ist die notwendige<br />
Datentransformation in das Datenmodell zu integrieren.<br />
In die Modellierung müssen die Anpassungen<br />
der Daten eingebettet werden können, um ein Datenobjekt<br />
eines Quellsystems an die Datenstruktur des Ziel-<br />
BILD 4:<br />
Daten-Backbone:<br />
Modelllandschaft<br />
und Anwendung<br />
auf Runtime<br />
DataModel MappingModel Transformation -<br />
Model<br />
Objekt- und<br />
Attribut-<br />
Beziehungen<br />
Systemübergreifende<br />
Attribut-<br />
Zuordnung<br />
Transformationen<br />
IMIP-Databackbone<br />
AdapterModel<br />
Interoperability-<br />
Model<br />
SystemLand -<br />
scapeModel<br />
Protokollanpassung<br />
Ablaufsteuerung<br />
Systemzuordnung<br />
BusinessRule -<br />
Model<br />
Geschäftsregeln<br />
Code -Generatoren<br />
xsd wsdl xslt btm<br />
…<br />
Development Environment<br />
Databackbone -Runtime<br />
Austauschbar!<br />
BizTalk<br />
JBoss<br />
Modell-Bezeichnung Anforderung/Einsatzzweck <strong>UML</strong>-Diagramm-<br />
Komponente<br />
DataModel Abbildung der Datenstrukturen einzelner Systeme Klassendiagramm<br />
MappingModel Mapping von unterschiedlichen Systemattributen Klassendiagramm<br />
TransformationModel Vorschriften und Logik zur Transformation unterschiedlicher Daten Aktivitätsdiagramm<br />
AdapterModel Anpassung und Konvertierung von Übermittlungsprotokollen Sequenzdiagramm<br />
InteroperabilityModel Ablaufsteuerung, Vorschriften zur Verarbeitungsfolgen Aktivitätsdiagramm<br />
-<br />
Abbildung der realen beziehungsweise physischen/physikalischen<br />
SystemLandscapeModell<br />
<strong>UML</strong>- Diagramm-<br />
Modell-Bezeichnung<br />
Anforderung/Einsatzzweck<br />
Klassendiagramm<br />
Systeme, die in der Systemlandschaft miteinander kommunizieren Komponente<br />
DataModel Abbildung der Datenstrukturen einzelner Systeme Klassendiagramm<br />
MappingModel Mapping von unterschiedlichen Systemattributen Klassendiagramm<br />
TransformationModel Vorschriften und Logik zur Transformation unterschiedlicher Daten Aktivitätsdiagramm<br />
AdapterModel Anpassung und Konvertierung von Übermittlungsprotokollen Sequenzdiagramm<br />
InteroperabilityModel Ablaufsteuerung, Vorschriften zur Verarbeitungsfolgen Aktivitätsdiagramm<br />
SystemLandscapeModel<br />
Abbildung der realen bzw. physischen/physikalischen Systeme,<br />
die in der Systemlandschaft mit einander kommunizieren<br />
Klassendiagramm<br />
TABELLE 2: Datenmodelle, Einsatzzweck und verwendete <strong>UML</strong>-Diagramme<br />
32<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
systems anzupassen. Eine Modellierungssprache muss<br />
die grundlegenden Elemente zur Datenmanipulation<br />
bereitstellen und hierfür eine formalisierte Spezifikation<br />
aufweisen.<br />
Für die unternehmensweite Kopplung aller IT-Systeme<br />
ist die Menge an Information kaum beherrschbar.<br />
Auch für einen modellbasierten Kopplungsansatz wird<br />
eine Vielzahl von <strong>Modellen</strong> benötigt, die miteinander<br />
in Verbindung stehen. Die Modellierungssprache muss<br />
Sichten (views) unterstützten, um die Komplexität für<br />
die unterschiedlichen Anwender reduziert darzustellen.<br />
Die Komplexität wird ebenfalls durch die beiden<br />
Kriterien Instanziierung und Verschachtelung reduziert.<br />
Sie muss eine Klassenbildung und deren Instanziierung<br />
unterstützen, wodurch der Aufbau einer<br />
Klasse und ihr projektspezifischer Einsatz getrennt<br />
werden kann.<br />
Zusätzlich muss eine Modellierungssprache die<br />
Schachtelung (nesting) unterstützen. Während in der<br />
Entwurfsphase übergeordnete Prozesse und Klassen betrachtet<br />
werden, müssen diese um die Generierung von<br />
Code, der später in einem ESB ausgeführt wird, ergänzt<br />
werden. Die einzelnen Detaillierungsstufen werden in<br />
übergeordnete Elemente geschachtelt und ergänzen die<br />
anfänglichen abstrakten Modelle so zum Gesamtmodell<br />
einer unternehmensweiten <strong>Datenkopplung</strong>.<br />
Außerdem muss sich der Ablauf innerhalb eines Datenaustauschprozesses<br />
abbilden lassen. Für Datenmanipulationen<br />
oder komplexe Anmeldevorgänge zum Aufbau<br />
einer Kommunikation zwischen IT-Systemen werden<br />
Möglichkeiten benötigt, um diese in der Modellierungssprache<br />
darstellen zu können. Im Folgenden<br />
werden die Modellierungsnotationen entsprechend der<br />
Anforderungen bewertet.<br />
4. BEWERTUNG BESTEHENDER<br />
MODELLIERUNGSSPRACHEN<br />
4.1 Entity Relationship Model (ERM)<br />
BILD 5: Daten-Backbone: DataModel PLM [24]<br />
Die <strong>UML</strong> [15] entstand als objektorientierte Modellierungssprache<br />
für die Softwareentwicklung. Sie basiert<br />
auf dem ERM und entwickelt dessen Konzept von<br />
Klassen, Beziehungen und Attributen weiter. Gegenüber<br />
Programmiersprachen ist in der <strong>UML</strong> die Darstellung<br />
übergeordneter Zusammenhänge auf einer abstrakten<br />
Ebene möglich. Mit der Version 2.0 baut die<br />
<strong>UML</strong> die Möglichkeit der redundanten Modellierung<br />
gleicher Zusammenhänge mit unterschiedlichen Diagrammtypen<br />
aus und ermöglicht so benutzergruppenorientierte<br />
Modellierungssichten. Dies wird oft als<br />
großer Kritikpunkt gegenüber vorhergehenden Versiclass<br />
DataModel PLM extended<br />
BOM<br />
Header<br />
BOM counter<br />
- DataType :integer<br />
BOM category<br />
- DataType :bom_category<br />
Material<br />
- DataType :string<br />
Plant<br />
- DataType :string<br />
Item<br />
Item number<br />
- DataType :string<br />
Component quantity<br />
- DataType :integer<br />
Unit of measure<br />
Das Entity Relationship Model (ERM) [25] stellt das akzeptierte<br />
Spezifikationshilfsmittel für relationale Datenbanken<br />
dar. Es flossen Erweiterungen aus der Objektorientierung,<br />
wie Generalisierung und Aggregation, in die<br />
Entwicklung der ERM ein. Das Konzept des ERM basiert<br />
auf der Verknüpfung von Entitäten (Gegenständen), Attributen<br />
der Entitäten und Beziehungen zwischen Entitäten<br />
(Relationen), die durch die Angabe von Beziehungstypen<br />
spezifiziert werden.<br />
Für den Einsatz in der Automatisierungstechnik kann<br />
das ERM nur bedingt eingesetzt werden. Das Grundkonzept<br />
des ERM mit den drei Basiselementen ist formal<br />
spezifiziert, ermöglicht jedoch nur die Darstellung statischer<br />
Beziehungen ohne dabei die angegebene Beziehungsart<br />
vollständig auswerten zu können. Strukturierungen<br />
sind nur durch Benennungen der Modellierungselemente<br />
möglich, können jedoch mit der reinen ERM<br />
nicht formal abgebildet werden. Die Voraussetzung für<br />
den speziellen Einsatz zur Kopplung von IT-Systemen<br />
bilden die Möglichkeiten zur formalen Abbildung von<br />
Beziehungen und deren Bedeutung.<br />
- DataType :unit_quant<br />
Item ID<br />
- DataType :string<br />
Component description<br />
- DataType :string<br />
Item category<br />
- DataType :item_category<br />
Assembly<br />
- DataType :boolean<br />
Sub-Items<br />
- DataType :boolean<br />
4.2 Unified Modelling Language (<strong>UML</strong>)<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
33
Plant<br />
- DataType :string<br />
HAUPTBEITRAG<br />
Item<br />
Item number<br />
- DataType :string<br />
Component quantity<br />
- DataType :integer<br />
Unit of measure<br />
- DataType :unit_quant<br />
Item ID<br />
- DataType :string<br />
Component description<br />
- DataType :string<br />
Item category<br />
- DataType :item_category<br />
onen gesehen. Die Vielzahl der Modelle muss für<br />
Assembly<br />
eine<br />
zielgerichtete Anwendung reduziert und - angepasst<br />
DataType :boolean<br />
werden. Dafür stellt die <strong>UML</strong> Erweiterungsmechanismen<br />
zur Verfügung.<br />
- DataType :boolean<br />
Sub-Items<br />
Bei der Bewertung der <strong>UML</strong> 2.0 zeigt sich die fehlende<br />
formale Beschreibung dieser Sprache. Die Erweiterungsmechanismen<br />
stellen die Mechanismen zur Formalisierung<br />
bereit. Dadurch entsteht ein domänen-spezifisches<br />
Profil wie die <strong>UML</strong>-PA [16] beziehungsweise die PLCML<br />
[17] mit einer begrenzten Gültigkeit.<br />
Die <strong>UML</strong> unterstützt statische wie auch dynamische<br />
Beschreibungen, letztere weisen jedoch durch die Vielzahl<br />
nicht festgelegter Verhaltensinterpretationen kein<br />
eindeutiges Verhalten auf. Für den Einsatz in der <strong>Datenkopplung</strong><br />
ist eindeutiges Verhalten essenziell. Die Darstellung<br />
gleichläufiger Prozesse ist mit den Mitteln der <strong>UML</strong><br />
möglich, jedoch fehlt eine Unterstützung zur Synchronisation<br />
der Prozesse. Bei der <strong>Datenkopplung</strong> treten vorrangig<br />
asynchrone und nebenläufige Prozesse auf, die über<br />
Ereignisse und Übergabewerte miteinander synchronisiert<br />
werden müssen. Das Fehlen der Synchronisationsmechanismen,<br />
die mit dem Profil MARTE [18] abbildbar<br />
sind, hat daher keine negative Auswirkung auf die Eignung<br />
der <strong>UML</strong> für die Modellierung der <strong>Datenkopplung</strong>.<br />
Die Anforderung an die Darstellung von Regeln wird<br />
nur teilweise erfüllt. Zum einen ist die <strong>UML</strong> nicht voll-<br />
class MappingModel PLM-DBB<br />
DataModel<br />
PLM::BOM<br />
DataModel<br />
PLM::Header<br />
DataModel PLM::BOM counter<br />
DataModel PLM::BOM category<br />
Transformation<br />
BOM-PartList<br />
BOM<br />
counter<br />
BOM<br />
category<br />
List<br />
t<br />
reference<br />
DataModel DBB::List name<br />
DataModel DBB::List reference<br />
DataModel<br />
DBB::Title<br />
block<br />
DataModel<br />
DBB::Part list<br />
DataModel<br />
PLM::Item<br />
DataModel PLM::Item number<br />
DataModel DBB::Part reference<br />
DataModel<br />
DBB::Part<br />
DataModel PLM::Component<br />
quantity<br />
DataModel DBB::Quantity<br />
DataModel PLM::Unit of measure<br />
DataModel DBB::Unit<br />
DataModel PLM::Item ID<br />
DataModel DBB::Part number<br />
DataModel PLM::Component<br />
description<br />
DataModel DBB::Remarks<br />
BILD 6: Daten-Backbone: MappingModel PLM – DBB [24]<br />
act Transformation BOM-PartList<br />
DBB PLM<br />
add_BOM<br />
:BOM counter<br />
:BOM category<br />
«flow»<br />
«flow»<br />
input_01<br />
input_02<br />
string together<br />
part_list_added<br />
output_01<br />
:List reference<br />
«flow»<br />
BILD 7:<br />
Daten-Backbone:<br />
TransformationModel<br />
[24]<br />
34<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
ständig formal spezifiziert. Zum anderen können zwar<br />
Entscheidungen, beispielsweise im Aktivitätsdiagramm,<br />
modelliert werden, Grundbausteine zur Datenmanipulation<br />
fehlen jedoch.<br />
Die <strong>UML</strong> besitzt eine Vielzahl unterschiedlicher Teilmodelle,<br />
die bei ihrer Darstellungsweise auf spezielle<br />
Fokusse optimiert sind, sich jedoch in ihrem Umfang<br />
der darstellbaren Information oft überschneiden. Dies<br />
ermöglicht es dem Benutzer, Zusammenhänge unter<br />
verschiedenen Gesichtspunkten zu betrachten und zu<br />
bearbeiten, und unterstützt so das für die <strong>Datenkopplung</strong><br />
wichtige Kriterium der Sichtenbildung. Zur Reduktion<br />
der Komplexität kann in der <strong>UML</strong> das geforderte<br />
Konzept der Instanziierung und der Schachtelung verwendet<br />
werden.<br />
4.3 System Modelling Language (SysML)<br />
Um das Konzept der <strong>UML</strong> abseits der Softwareentwicklung<br />
für die Systementwicklung und den Einsatz in unterschiedlichen<br />
Domänen einsetzbar zu machen, wurde<br />
die <strong>UML</strong> für das Systems Engineering zur SysML [19]<br />
erweitert. Die SysML beinhaltet als neue Diagramme einerseits<br />
die Anforderungsdiagramme zur integrierten<br />
Modellierung von Anforderungen und deren Erfüllung<br />
REFERENZEN<br />
[1] Vogel-Heuser, B., Kegel, G., Bender, K.,Wucherer, K.:Global<br />
Information Architecture for Industrial Automation. <strong>atp</strong> - Automatisierungstechnische<br />
Praxis 51(1), S. 108–115, 2009<br />
[2] De Leusse, P., Periorellis, P., Watson, P.: Enterprise service<br />
bus: an overview. Technical Report CS-TR-1037, University of<br />
Newcastle upon Tyne, 2007. (http://www.cs.newcastle.ac.uk/<br />
publications/trs/papers/1037.pdf)<br />
[3] IEC 61804-3: Funktionsbausteine für die Prozessautomation<br />
- Teil 3: Elektronische Gerätebeschreibungssprache (EDDL).<br />
September 2011<br />
[4] IEC 62424: Darstellung von Aufgaben der Prozessleittechnik<br />
- Fließbilder und Datenaustausch zwischen<br />
EDV-Werkzeugen zur Fließbilderstellung und CAE-Systemen.<br />
August 2008<br />
[5] eCl@ss e. V.: eCl@ss. (http://www.eclass.de/eclasscontent/<br />
index.html.de)<br />
[6] AutomationML consortium: AutomationML– The Glue for<br />
Seamless Automation Engineering (Version 2.0, Mai 2012).<br />
(https://www.automationml.org/o.red/uploads/dateien/<br />
1338989640-AutomationML%20Whitepaper%20Part%204%20<br />
-%20AutomationML%20Logic%20Description%20v2.pdf)<br />
[7] OPC Foundation: OPC DA 3.00 Specification (Version 3.00.1.00,<br />
März 2003). (http://www.opcfoundation.org/)<br />
[8] OPC Foundation: OPC UA 1.02 Specification (Version 1.02,<br />
August 2012). (http://www.opcfoundation.org/)<br />
[9] Biffl, S., Mordinyi, R., Moser, T.: Integriertes Engineering mit<br />
Automation Service Bus. <strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische<br />
Praxis 54(12), S. 36-43, 2012<br />
[10] Collaborative Research Center IMPROVE (SFB 476).<br />
(http://www.se.rwth-aachen.de/research/sfb476/index.html)<br />
[11] Nagl, M.,Marquardt, W.: Collaborative and Distributed<br />
Chemical Engineering. From Understanding to Substantial<br />
Design Process Support – Results of the IMPROVE Project,<br />
Lecture Notes in Computer Science 4970.Springer-Verlag,<br />
Berlin 2008<br />
[12] The Khronos Group Inc.: COLLADA – Digital Asset Schema<br />
(Version 1.5.0, Oktober 2008).<br />
(http://www.khronos.org/collada/)<br />
[13] van der Wal, E.: PLCopen. IEEE Industrial Electronics<br />
Magazine 3 (4), S. 25, 2009<br />
[14] VDE/VDI 3681: Einordnung und Bewertung von Beschreibungsmittel<br />
aus der Automatisierungstechnik. Oktober 2005<br />
[15] Object Management Group, Inc.: Unified Modeling<br />
Language (<strong>UML</strong>) (Version 2.4.1, August 2011).<br />
(http://www.omg.org/spec/<strong>UML</strong>/2.4.1/)<br />
[16] Katzke, U., Vogel-Heuser, B.: Vergleich der Anwendbarkeit<br />
von <strong>UML</strong> und <strong>UML</strong>-PA in der anlagennahen Softwareentwicklung<br />
der Automatisierungstechnik. at - Automatisierungstechnik<br />
57 (7), S. 332–340, 2009<br />
[17] Witsch, D.: Modellgetriebene Entwicklung von Steuerungssoftware<br />
auf Basis der <strong>UML</strong> unter Berücksichtigung der<br />
domänenspezifischen Anforderungen des Maschinen- und<br />
Anlagenbaus. Sierke-Verlag, Göttingen 2013<br />
[18] Object Management Group, Inc.: <strong>UML</strong> Profile for MARTE:<br />
Modeling and Analysis of Real-Time Embedded Systems<br />
(Version 1.1, Juni 2011).<br />
(http://www.omg.org/spec/MARTE/)<br />
[19] Object Management Group, Inc.: Systems Modeling<br />
Language (SysML) (Version 1.3,Juni 2012).<br />
(http://www.omg.org/spec/SysML/1.3/)<br />
[20] Object Management Group, Inc.: Business Process Model<br />
and Notation (BPMN) (Version 2.0,Januar 2011).<br />
(http://www.omg.org/spec/BPMN/2.0/)<br />
[21] Witsch, M., Vogel-Heuser, B.: Modeling of Manufacturing<br />
Execution Systems - an Interdisciplinary Challenge.<br />
Proceedings 15th IEEE Int. Conf. Emerging Technologies<br />
and Factory Automation (ETFA), [CD]. IEEE 2010<br />
[22] OASIS Standard: Web Services Business Process Execution<br />
Language (Version 2.0, April 2007). (http://docs.oasisopen.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html)<br />
[23] Workflow Management Coalition: Process Definition<br />
Interface-- XML Process Definition Language (Version 2.1,<br />
August 2010). (http://www.wfmc.org/xpdl.html)<br />
[24] Hufnagel, J.; Frank, T.; Vogel-Heuser, B.: Framework for a<br />
Model-Based, Cross-Domain System Interconnection in<br />
Automation Technology. In: Proc. 18th IEEE Int. Conf.<br />
Emerging Technologies and Factory Automation (ETFA),<br />
[CD]. IEEE 2013<br />
[25] Vossen, G.: Datenbankmodelle, Datenbanksprachen und<br />
Datenbank-Management-Systeme, Addison-Wesley, 1994<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
35
HAUPTBEITRAG<br />
durch Systemelemente und andererseits die Parameterdiagramme<br />
zur Modellierung von Gleichungssystemen,<br />
die besonders für die Modellierung regelungstechnischer<br />
Aufgaben beziehungsweise kontinuierlicher Prozesse<br />
interessant sind.<br />
Bei der Bewertung der Einsatzmöglichkeiten der Sys-<br />
ML im Bereich der <strong>Datenkopplung</strong> wird die Verwandtschaft<br />
zur <strong>UML</strong> deutlich. Die SysML unterscheidet sich<br />
lediglich in einem Punkt: Im Vergleich zur <strong>UML</strong> wurde<br />
die Möglichkeit zur Modellierung kontinuierlicher Prozesse<br />
integriert. Bei den erweiterten Kriterien zur <strong>Datenkopplung</strong><br />
einer Systemlandschaft erweisen sich<br />
SysML und <strong>UML</strong> in identischem Maße als geeignet.<br />
Durch die Erweiterungsmechanismen der beiden Sprachen<br />
lassen sich diese so optimieren, dass auch zunächst<br />
nicht erfüllte Anforderungen berücksichtigt<br />
werden können.<br />
4.4 Business Process Model und Notation (BPMN)<br />
Während sich die ERM auf statische Zusammenhänge<br />
beschränkt, fokussiert sich die BPMN [20] auf die Darstellung<br />
von Abläufen und das Zusammenwirken der<br />
einzelnen Geschäftsprozesse innerhalb eines Unternehmens.<br />
Zur Modellierung stehen drei dynamische Diagrammtypen<br />
und fünf Elementkategorien zur Verfügung,<br />
die mit dem Schwerpunkt auf ihrer grafischen Repräsentation<br />
spezifisch auf die Modellierung von Geschäftsprozessen<br />
ausgerichtet sind.<br />
Aufbauend auf [21] können für die Bewertung der<br />
BPMN bezüglich der Richtlinie VDI/VDE 3681 die Kriterien<br />
auf die Analyse der dynamischen Darstellungen<br />
beschränkt werden, da Beschreibungsmittel für statische<br />
Zusammenhänge fehlen. Mit der Version 2.0 wurde<br />
die formale Spezifikation der BPMN vorangetrieben,<br />
jedoch weist diese noch Lücken auf und kann so nur als<br />
semiformal eingestuft werden. Im industriellen Einsatz<br />
werden diese beiden Schwachpunkte durch die Kombination<br />
der BPMN mit den Beschreibungen der Sprachen<br />
Business Process Execution Language (BPEL) [22] und<br />
XML Process Definition Language (XPDL) [23] behoben.<br />
Die Darstellung verteilter Prozesse ist möglich, eine zeitliche<br />
Synchronisationsmöglichkeit fehlt jedoch.<br />
Die eigentliche Stärke der BPMN für den Einsatz zur<br />
<strong>Datenkopplung</strong> liegt im Bereich der Geschäftsprozesssteuerung.<br />
Während ihr statische Beschreibungsmittel<br />
fehlen, bietet die BPMN speziell angepasste Modellierungselemente<br />
für die Steuerung und Koordination von<br />
Geschäftsprozessen. Mit der Unterstützung von Datenobjekten<br />
kann die Schnittstelle zur statischen Datenmodellierung<br />
hergestellt und die BPMN somit zur Prozesssteuerung<br />
in andere Modellierungssprachen integriert<br />
werden.<br />
4.5 Begründung der Auswahl der <strong>UML</strong><br />
ERM ist für die Beschreibung von Datenbanken entwickelt<br />
worden. Der Sprache fehlen die Möglichkeiten,<br />
Zusammenhänge über einfache Relationen hinaus darzustellen.<br />
Die <strong>UML</strong> bietet umfangreiche Möglichkeiten<br />
zur Anpassung und Erweiterung auf den jeweiligen<br />
Einsatzzweck. Zur Modellierung von hardwarelastigeren<br />
Systemen wurde die <strong>UML</strong> zur SysML um verschiedene<br />
Punkte erweitert, die jedoch keine weiteren Vorteile<br />
für die Beschreibung von <strong>Datenkopplung</strong> mit sich<br />
bringen. Zur Beschreibung von Prozessen wurde die<br />
BPMN entwickelt. Andere für die <strong>Datenkopplung</strong> essenzielle<br />
Aspekte, wie die Darstellung von Datenstrukturen,<br />
fehlen jedoch.<br />
Die <strong>UML</strong> erscheint aufgrund ihrer Ausrichtung und<br />
der Erweiterbarkeit am besten für die <strong>Datenkopplung</strong><br />
und die Datenmodellierung geeignet, muss jedoch angepasst<br />
werden. Die <strong>UML</strong> kann gemeinsam mit BPMN in<br />
einem neuen Konzept zur Beschreibung von <strong>Datenkopplung</strong>en<br />
in der Automatisierungstechnik verwendet werden.<br />
Die AutomationML kann darüber hinaus für die<br />
Beschreibung einer neutralen Datenstruktur genutzt<br />
werden. Im Folgenden wird dieses neue Konzept beschrieben.<br />
5. MODELLIERUNG DER DATENKOPPLUNG MIT <strong>UML</strong><br />
In den vorangehenden Abschnitten wurden die Anforderungen<br />
identifiziert, anhand derer sich eine Modellierungssprache<br />
für die <strong>Datenkopplung</strong> bewerten lässt. Für<br />
diesen Ansatz wurden aus diesen Anforderungen konkrete<br />
Aufgaben formuliert, die das zu entwickelnde Konzept<br />
eines Daten-Backbone (DBB) erfüllen muss. Die Information,<br />
die für die Durchführung der <strong>Datenkopplung</strong><br />
notwendig ist, wird modellbasiert und aufgabenorientiert<br />
in sieben Untermodelle gegliedert, siehe Bild 4 und<br />
Bild 5, die unterschiedliche Anforderungen erfüllen und<br />
mit unterschiedlichen <strong>UML</strong>-Diagrammen modelliert<br />
werden, vergleiche Tabelle 2.<br />
Den Grundbaustein der <strong>Datenkopplung</strong> bilden die auszutauschenden<br />
Daten. Diese Daten werden von den IT-<br />
Systemen nicht als einzelne Werte, sondern eingebettet<br />
in eine Datenstruktur mit hierarchischer Gliederung in<br />
Datenstrukturbezeichnung, Unterkategorien und Attributnamen<br />
übertragen, siehe Bild 5. Für den Austausch<br />
von Daten ist jedoch lediglich der Wert, der diesen Strukturierungselementen<br />
zugeordnet ist, von Bedeutung. Um<br />
diese Datenstrukturen, die von den IT-Systemen verschickt<br />
werden, zu verstehen und nach den eigentlichen<br />
Dateninhalten untersuchen zu können, muss die Struktur<br />
eines Systems bekannt und für die <strong>Datenkopplung</strong><br />
hinterlegt sein.<br />
Das Datenmodell weist eine allgemeingültige und neutrale<br />
Datenstruktur auf und wird als Referenz oder Bezugspunkt<br />
für alle systemspezifischen Datenstrukturen<br />
verwendet. Alle Modellierungen beziehen sich somit auf<br />
die Kopplung der spezifischen Datenstruktur eines anzukoppelnden<br />
Systems mit der kanonischen Datenstruktur<br />
des DBB, siehe Bild 6. Durch die so entstehende sternförmige<br />
Kopplungsarchitektur ist es möglich, in der<br />
Modellierung die Anzahl der Schnittstellen pro anzuschließendem<br />
System auf je eine Kopplung zwischen<br />
36<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
DBB und System zu reduzieren. Für den Einsatz in einer<br />
Laufzeitumgebung wird die modellbasierte Information<br />
kombiniert und in einzelne systembezogene Schnittstellen<br />
gegliedert. Die Information des zentralen Datenmodells<br />
wird dabei für jede Schnittstelle interpretiert und<br />
in diese integriert.<br />
Für die Übertragung von einem Datenelement sind<br />
möglicherweise Transformationen notwendig (Bild 7).<br />
Diese Transformationen können beliebig komplexe Kombinationen<br />
von Grundoperationen umfassen. Die Grundoperationen<br />
können in die jeweilige Laufzeitumgebung<br />
überführt werden.<br />
Zu diesem Zweck werden Codegeneratoren eingesetzt,<br />
die die Modelle in die jeweilige programmspezifische<br />
Sprache übersetzen. Je nach Hersteller sind mehrere unterschiedliche<br />
Dateien nötig, um eine Systemkopplung<br />
vornehmen zu können, siehe Bild 4.<br />
Das beschriebene Konzept wird derzeit in einem Prototypen<br />
umgesetzt, sodass ein Datenaustausch zwischen<br />
einem ERP-System und einem MES möglich ist. Hierfür<br />
werden alle nötigen Dateien für die Laufzeitumgebung<br />
(EAI) ausgeleitet.<br />
ZUSAMMENFASSUNG UND AUSBLICK<br />
Im Rahmen von Industrie 4.0 und der vertikalen Integration<br />
im Sinne des Diabolo entlang des Lebenszyklus<br />
zeigt das im Beitrag vorgestellte Konzept einen Ansatz,<br />
in einem realen Produktionswerk verteilte Daten modellbasiert<br />
und systemübergreifend zu koppeln und so eine<br />
durchgängige Datenbasis für IT-Systeme zu schaffen.<br />
Verschiedene Modellierungsansätze wurden auf ihre<br />
Eignung zur Modellierung des Datenmodells für den<br />
Daten-Backbone bewertet und die <strong>UML</strong> ausgewählt. Der<br />
entwickelte Ansatz basiert auf einer systemübergreifenden<br />
Datenzuordnung, bei der die Daten nicht <strong>mittels</strong><br />
eines zentralen Datenspeichers, sondern durch modellbasierte<br />
Zuordnungen der Daten über alle IT-Systeme<br />
eines Unternehmens hinweg in einem Daten-Backbone<br />
gekoppelt werden.<br />
Es sind vier Pilotanwendungen in einem realen Unternehmen<br />
angestrebt. Die Auswertung der Umsetzungsphase<br />
wie auch der Kopplungsqualität wird wichtige<br />
Hinweise über die Anwendbarkeit dieses Ansatzes geben.<br />
Mit der Schaffung einer einheitlichen, unternehmensweiten<br />
<strong>Datenkopplung</strong> wäre ein entscheidender<br />
Schritt in Richtung Industrie 4.0 und der vertikalen Integration<br />
entlang des Lebenszyklus gelungen. Aufbauend<br />
auf diesem Kopplungsansatz könnten Unternehmen zukünftig<br />
alle Funktionen ihrer sich stets wandelnden IT-<br />
Systemlandschaft auf einer unternehmensweit verfügbaren<br />
und vollständigen Datenbasis ausführen, während<br />
die darunterliegende <strong>Datenkopplung</strong> im gesamten Unternehmen<br />
und über alle eingesetzten Systeme hinweg<br />
konstant bleibt.<br />
MANUSKRIPTEINGANG<br />
08.08.2013<br />
Im Peer-Review-Verfahren begutachtet<br />
AUTOREN<br />
Prof. Dr.-Ing. BIRGIT<br />
VOGEL-HEUSER (geb. 1961),<br />
Ordinaria des Lehrstuhls<br />
für Automatisierung und<br />
Informationssysteme an der<br />
Technischen Universität<br />
München (seit 2009), forscht<br />
an der Entwicklung und<br />
Systemevolution verteilter<br />
intelligenter eingebetteter Systeme in mechatronischen<br />
Produkten und Produktionsanlagen,<br />
um die Qualität der Produkte und die Effizienz<br />
und Durchgängigkeit im Engineering zu<br />
verbessern.<br />
Lehrstuhl für Automatisierung<br />
und Informationssysteme,<br />
Boltzmannstraße 15,<br />
D-85748 Garching bei München,<br />
Tel. +49 (0) 89 28 91 64 00,<br />
E-Mail: vogel-heuser@ais.mw.tum.de<br />
Dipl.-Ing. BAGHER FEIZ-MARZOUGHI (geb. 1958)<br />
studierte Nachrichtentechnik und ist seit 1989 bei<br />
der Siemens AG tätig. Er leitet die Abteilung I IA IT<br />
MES an mehreren Produktionsstandorten für die<br />
Division Industry Automation. Er verantwortet die<br />
Konzeption, Realisierung und Implementierung von<br />
Standard IT-Lösungen im Bereich Manufacturing<br />
und leitet das Programm MES for Industry Automation<br />
mit dem Ziel, Standardsoftware als Bestandteil<br />
der Digital Enterprise Platform im Bereich Product Manufacturing in<br />
den Siemens-Werken einzuführen, um die Basis der Industrie 4.0 zu<br />
bilden. Ein wesentlicher Baustein hierzu ist die Integration der funktionalen<br />
Unternehmenslayer PLM und MES und die Herstellung einer<br />
modellbasierten Interoperabilität der Systeme in diesen Layern.<br />
Siemens AG,<br />
IndustrySector, Industry Automation Division, I IA IT MES,<br />
Werner-von-Siemens-Straße 50,<br />
D-92224 Amberg,<br />
Tel. +49 (0) 9621 80 32 00,<br />
E-Mail: bagher.feiz-marzoughi@siemens.com<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
37
HAUPTBEITRAG<br />
Modell zur Beschreibung<br />
cyber-physischer Systeme<br />
Modellierung mit Merkmalen unterstützt Industrie 4.0<br />
Im Rahmen der Aktivitäten zu Industrie 4.0 gewinnen cyber-physische Systeme an Bedeutung.<br />
In IEC TC 65 WG 16 wird ein Modell entwickelt, mit dem sich solche Systeme<br />
auf Basis einer merkmalsorientierten Methodik beschreiben lassen. Das Modell basiert<br />
auf nach IEC 61360 [2] definierten Merkmalen und wird in dem seit Herbst 2012 vorliegenden<br />
Dokument IEC TR 62794 [1] behandelt. Im Beitrag werden Fragen zum Anlagenentwurf<br />
mit cyber-physischen Systemen auf Basis von Merkmalen erörtert. Die Anwendung<br />
der Methodik zur Speicherung informatischer Abbilder realer Anlagen in Data<br />
Repositories und deren Nutzung in beliebigen anlagenrelevanten Prozessen wird erläutert,<br />
und das Verbinden einzelner Komponenten (Assets) zu einer Anlage auf Basis ihrer Merkmale<br />
betrachtet. Cyber-physische Systeme stellen dabei einen Assettyp dar. Es wird erklärt,<br />
wie sich durch die beschriebene Methodik die Zahl semantischer Umsetzungen in<br />
einem System signifikant senken lässt.<br />
SCHLAGWÖRTER Cyber-physische Systeme / Industrie 4.0 / Merkmale / Merkmalstypen /<br />
IEC TR 62794 / Digitale Fabrik / Modell / IEC 61360 / Common Data<br />
Dictionary<br />
Model for the Description of Cyber-Physical Systems –<br />
Modelling with Properties Supports Industry 4.0<br />
Cyber-Physical Systems (CPS) will play an increasingly important role in the course of<br />
activities relating to the recently started German Industry 4.0 initiative. In autumn 2012<br />
the IEC TR 62794 document [1] was released by the IEC TC65 Working Group 16 which<br />
shows how to describe “assets” using the property oriented methodology (Property Principle)<br />
in accordance with IEC 61360 [2]. A virtual plant stored in a data repository and<br />
containing the applied products as lists of their properties represents a real plant. The<br />
creation of a CPS as one asset type by specifying its semantically unique properties is<br />
shown. A side effect of this methodology is a significant reduction in the number of semantic<br />
conversions in a system. A brief overview of the international standardization<br />
efforts is included.<br />
KEYWORDS cyber-physical systems / Industry 4.0 / properties / property types /<br />
IEC TR 62794 / Digital Factory / IEC 61360 / Common Data Dictionary<br />
38<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
UDO DÖBRICH, Convenor IEC TC 65 WG16 Digital Factory<br />
ROLAND HEIDEL, Chairman IEC TC 65<br />
Seit mehr als einem Jahrzehnt wird der herstellerneutrale<br />
aufwandsarme Entwurf automatisierungstechnischer<br />
Anlagen diskutiert. Mehrere<br />
Ansätze, zum Beispiel in der Namur in den<br />
1980er-Jahren kamen über Anfangserfolge<br />
nicht hinaus. Die Gründe waren unter anderem nicht<br />
ausreichender Speicher und fehlende Rechenleistung,<br />
aber auch der unausgereifte Stand der Informatik. Er<br />
bestand vor allem aus Paradigmen zu ablauffähigem<br />
Code verbunden mit der Spezifikation von rein datenorientierten<br />
Schnittstellen und er verstand Daten allenfalls<br />
in Form von Deklarationen beziehungsweise als<br />
Datenbankablagen.<br />
Im Rahmen der Initiative Industrie 4.0 werden cyberphysische<br />
Systeme (CPS) diskutiert, die Realität und<br />
deren virtuelle datentechnische Darstellung repräsentieren.<br />
Der VDI/VDE GMA-Fachausschuss 7.20 Cyber<br />
Physical Systems befasst sich mit der Definition cyberphysischer<br />
Systeme in Abstimmung mit dem VDI/VDE<br />
GMA-Fachausschuss 7.21 Industrie 4.0. Der Fachausschuss<br />
7.20 zitiert in seiner Druckschrift vom April<br />
2013 [5] die Forschungsagenda CPS [6] wie folgt: „Cyber-Physical<br />
Systems (CPS) sind gekennzeichnet durch<br />
eine Verknüpfung von realen (physischen) Objekten<br />
und Prozessen mit informationsverarbeitenden (virtuellen)<br />
Objekten und Prozessen über offene, teilweise<br />
globale und jederzeit miteinander verbundene Informationsnetze“.<br />
Diese Sichtweise eröffnet neue Perspektiven im Hinblick<br />
auf Transparenz und Implementierung automatisierungstechnischer<br />
Anwendungen. Der Beitrag befasst<br />
sich mit der im Dokument IEC TR 62794 [1] aufgezeigten<br />
Möglichkeit, den virtuellen Teil eines CPS als Typ von<br />
in IEC TR 62794 Assets genannten Anlagenkomponenten<br />
zu erzeugen.<br />
Etwa seit dem Jahr 2000 geht es bei mehreren Projekten<br />
um die Normung von Produktdaten mit dem Ziel, elektronisch<br />
verarbeitbare Datenblätter zu generieren. Bei<br />
elektronischen Bauelementen (wie Widerstände, Kondensatoren)<br />
ergab sich aufgrund von Anforderungen bei<br />
den Bestückungsautomaten früh die Notwendigkeit für<br />
solche Daten, da Bestückungsautomaten <strong>mittels</strong> maschinenlesbarer<br />
Datenblätter mit der erforderlichen Information<br />
über die Eigenschaften der Bauelemente zur Bestückung<br />
der Leiterplatten versorgt werden. Das Ergebnis<br />
in IEC war die Basisnorm IEC 61360-1/2 [2] mit ihrem<br />
inhaltlich identischen Pendant ISO 13489-42, beide als<br />
Ableitung aus ISO 10303 (STEP) [15].<br />
Die Entwicklung hin zu Produktdaten wurde durch<br />
den E-Business-Hype weiter beschleunigt. In Deutschland<br />
entstand eClass [3], in USA auf Basis von UNSPSC-<br />
Inhalten ECCMA. Schnell wurde klar, dass die damals<br />
auf den Einkauf ausgerichtete Produkttypenklassifikation<br />
die Kundenerfordernisse allein nicht abdecken<br />
konnte. Deshalb startete die chemische Industrie im Jahr<br />
2004 in ihrem Verband Namur [4] das Projekt Prolist mit<br />
dem Ziel, Produktdaten für das Engineering zu erzeugen.<br />
Das Ergebnis war die Namur-Empfehlung NE 100,<br />
die in der Version 3.2 vorliegt [12] und in die IEC-Normung<br />
eingeflossen ist (siehe Abschnitt 4). Damit ist die<br />
Grundlage zur Beschreibung cyber-physischer Systeme<br />
geschaffen.<br />
Um die Arbeiten zu Produktdaten besser bündeln zu<br />
können hat sich Prolist International e.V. zum 1. Januar<br />
2013 mit eClass vereinigt. Nun steht zum Beispiel in der<br />
eClass-Sachgruppe 27 (Elektro-, Automatisierungs- und<br />
Prozessleittechnik) [3] eine tragfähige Lösung zur Klassifikation<br />
und Beschreibung automatisierungstechnischer<br />
Produkte <strong>mittels</strong> Merkmalen zur Verfügung, deren<br />
Ergebnis die neue eClass-Version 8.0 advanced darstellt.<br />
Auch dieses Ergebnis ist in die internationale Normung<br />
eingeflossen.<br />
1. PRODUKTDATEN IN DATENBLÄTTERN SIND MERKMALE<br />
2. MODELLIERUNG EINER ANLAGE MIT CPS<br />
Die Frage ist, ob und wie sich mit Merkmalen der virtuelle<br />
Teil eines CPS als Spiegel der Realität hinreichend<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
39
HAUPTBEITRAG<br />
genau beschreiben lässt und welche Forderungen bezüglich<br />
des Anlagenentwurfs damit erfüllt werden können.<br />
Schon länger gibt es seitens der Anwender folgende Forderungen:<br />
1 | Ein produktneutraler Entwurf einer Anlage soll<br />
möglich sein (Typ-Perspektive).<br />
2 | Der produktneutrale Entwurf soll später in einen<br />
produktspezifischen Entwurf überführt werden<br />
können (Instanz-Perspektive).<br />
3 | Die durch die Komplexität einer Anwendung<br />
bedingten Entwurfsaufgaben sollen so strukturiert<br />
werden können, dass sie datentechnisch mit<br />
möglichst geringem Aufwand gelöst werden und<br />
der Mensch einbezogen ist.<br />
4 | Information soll über die oft lange Lebenszeit<br />
einer Anlage während aller Lebensphasen<br />
genutzt und jederzeit abgerufen werden können.<br />
Im Folgenden wird erläutert, wie sich diese Forderungen<br />
durch die Beschreibung von cyber-physischen Systemen<br />
mit dem in IEC TR 62794 [1] vorgeschlagenen Verfahren<br />
erfüllen lassen, und wie durch die Verbindung mehrerer<br />
CPS ein Anlagen-CPS entsteht. Konkrete Implementierungen<br />
der CPS könnten dann unter anderem auf Normen<br />
wie IEC 61346 (Structuring Principles and Reference<br />
Designations), IEC 62424 (CAEX), IEC 62714 (AutomationML)<br />
basieren.<br />
2.1 Modellierung mit IEC TR 62794 und IEC 61360<br />
In IEC TR 62794 wird jede Komponente einer Anlage<br />
Asset genannt. Es wird vorausgesetzt, dass alle Komponenten,<br />
also auch cyber-physische Systeme, <strong>mittels</strong><br />
Merkmalen, zum Beispiel nach IEC 61360 hinreichend<br />
beschrieben sind. Im Prinzip lassen sich maschinenverarbeitbare<br />
Merkmale von Komponenten<br />
vergleichen mit den Pixeln eines Digitalfotos – sie<br />
stellen Information zur Verfügung, die völlig neue<br />
Möglichkeiten eröffnet.<br />
Für die umgangssprachlich unscharfe Benennung<br />
Merkmal wird von den Autoren deshalb die informatisch<br />
korrekte Benennung Merkmalstyp benutzt, das heißt ein<br />
Merkmalstyp besitzt keinen konkreten Wert. Erst mit<br />
Zuweisung eines konkreten Wertes wird aus dem Merkmalstyp<br />
ein Merkmal. Für die Anlagenplanung bedeutet<br />
dies, dass zunächst ein produktneutraler Anlagentyp<br />
<strong>mittels</strong> Verbindung von Merkmalstypen aller Assets (also<br />
auch aller CPS) einer Anlage erzeugt wird.<br />
Die konkrete Anlage mit ihren konkreten Produktkomponenten<br />
entsteht in einem zweiten Schritt anhand von<br />
Datenblättern aus dem Anlagentyp durch Zuweisung<br />
produktspezifischer Werte an die Merkmalstypen der<br />
Assets beziehungsweise CPS.<br />
Wenn eine Anlage allgemein als System aufgefasst<br />
wird, lässt sich aus diesem Sachverhalt ein Systembegriff<br />
definieren:<br />
BILD 1: Schematische Darstellung der Repräsentation<br />
von Assets <strong>mittels</strong> Merkmalstypen.<br />
described<br />
by its<br />
properties<br />
described<br />
by its<br />
properties<br />
# 5013; Diameter of the Sensor Cell<br />
# 2004 ; Sensor Cell Material<br />
# 7030 ; Weight of the Sensor<br />
# 8544 ; Dimension of the Housing<br />
# 723 ; Material of the Housing<br />
# 1234 ; Local Operator Panel<br />
# 2354 ; Threshold Level and Signalling<br />
# 5673 ; Linearization Curve<br />
# 7758 ; Time Stamp Function<br />
# 5563 ; Self Calibration<br />
etc.<br />
# 7713 : Size of the Housing<br />
# 2354 ; 230 Voltage<br />
# 9030 ; maximum Power<br />
# 8344 ; Star Start<br />
# 7239 ; Multiswitch<br />
# 3456 ; Rack Assembly<br />
# 2354 ; Overloading Protection<br />
etc.<br />
Classification of the Properties and<br />
the Principle Relationships<br />
Construction<br />
Konstruktion<br />
e Business<br />
- business<br />
Performance<br />
(Mechanik, (Mechanical & Elektrik) Electrical<br />
Equipment)<br />
Ortsinformatio<br />
Location<br />
nen<br />
Function<br />
Functions<br />
(Software)<br />
(Software)<br />
described<br />
by its<br />
properties<br />
# 7713 : Size of the Housing<br />
# 2354 ; 230 Voltage<br />
# 9030 ; maximum Power<br />
# 7344 ; maximum rpm<br />
# 7239 ; maximum newton meter<br />
# 3456 ; 8 screw fixing<br />
etc.<br />
BILD 2: In IEC TR 62794 werden Merkmalstypen<br />
in fünf Basic Elements klassifiziert, die im<br />
Verbund Eigenschaften eines Assets oder einer<br />
ganzen Anlage repräsentieren (Prinzip).<br />
40<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
Ein System ist dadurch gekennzeichnet, dass mindestens<br />
ein Merkmal einer Komponente mit einem<br />
Merkmal einer anderen Komponente verbunden ist.<br />
Ein Merkmal besteht mindestens aus einer eindeutigen<br />
Benennung und einem Wert.<br />
Hinweis: Komponenten werden in IEC TR 62794 neutral<br />
Assets genannt<br />
Das Prinzip der Abbildung realer Dinge <strong>mittels</strong> Merkmalstypen<br />
wird Property Principle (PP) beziehungsweise<br />
Merkmalsprinzip [9] genannt. Ein CPS stellt dabei<br />
einen speziellen Assettyp dar. Dabei erscheint es zweckmäßig,<br />
dass die Semantik der Merkmalstypen eineindeutig<br />
definiert, mögliche Wertebereiche einschließlich<br />
dazu gehörender Formate festgelegt sind und dies in<br />
Normen hinterlegt ist. Wie noch gezeigt wird, werden<br />
damit semantische Schnittstellenprobleme in beliebigen<br />
Installationen weitgehend nebenbei gelöst.<br />
Die Normung der Merkmalstypen erfolgt zweckmäßigerweise<br />
über die internationalen Normungsgremien.<br />
Die Regeln zur Erstellung von Merkmalstypen sind in<br />
IEC 61360 [2] beziehungsweise ISO 13584-42 [13] enthalten.<br />
In [7] wird hierauf näher eingegangen. Konkrete<br />
Produkttypen, zum Beispiel Messumformer werden in<br />
der Normenreihe IEC 61387-ff [8] <strong>mittels</strong> Merkmalstyplisten<br />
(Templates) beschrieben. Die Kerngedanken der<br />
Modellierung werden nachfolgend vorgestellt.<br />
2.2 Mit Merkmalstypen charakterisierte Assets<br />
Zur Verarbeitung in Rechnern besitzt jeder Merkmalstyp<br />
einer Anlagenkomponente einen eindeutigen Identifier<br />
(ID=#xxxx) und eine bevorzugte Benennung, siehe<br />
Bild 1. Ein Merkmalstyp wird durch Zuweisung eines<br />
konkreten Werts zu einem konkreten Merkmal; Lesebeispiel:<br />
ID=#5013, bevorzugte Benennung=Diameter of the<br />
Sensor Cell, Wert=17cm.<br />
2.3 Klassifikation von Merkmalstypen<br />
Die Klassifikation von Merkmalstypen bildet einen Teil<br />
eines künftigen Merkmalmanagements und dient der<br />
thematischen und fachlichen Zuordnung der vielen tausend<br />
Asset-Merkmale, aber ebenso im Hinblick auf Gewerke<br />
und Verantwortlichkeiten von Personen. Das<br />
Prinzip zeigt Bild 2. In IEC TR 62794 werden Merkmalstypen<br />
in fünf Basic Elements klassifiziert, die spezifische<br />
Eigenschaften eines Assets repräsentieren. Der<br />
Vorteil dieser Vorgehensweise ist, dass sich jede Merkmalstypklasse<br />
beim Anlagenentwurf einerseits weitgehend<br />
getrennt behandeln lässt, andererseits die Anlage<br />
aber <strong>mittels</strong> Verbindung der Klassen-Merkmalstypen<br />
entworfen werden kann. Denn im Merkmalstypverbund<br />
repräsentieren die Merkmalstypen die Eigenschaften<br />
der ganzen Anlage. Klassifiziert werden dabei jeweils<br />
BILD 3: Beispiel für einen Assettyp CPS Programmable Logical<br />
Controller, erzeugt durch Verbindung von Basic Elements.<br />
Programmable Logical Controller<br />
P1<br />
Sensor Controller Actuator<br />
P2 P2<br />
P3 P3<br />
P4 P4<br />
L2 L3 L4<br />
L1<br />
C2 C2<br />
C3 C3<br />
C4 C4<br />
C1<br />
Ccom<br />
B2 B2<br />
B3 B3<br />
B4 B4<br />
B1<br />
F1<br />
d<br />
F2<br />
d<br />
F3<br />
F1<br />
F2<br />
BILD 4: Erzeugung eines Anlagenteils durch<br />
Verschaltung mehrerer <strong>mittels</strong> Basic Elements<br />
strukturierter Assettypen. Die Verbindung zwischen<br />
F1, F2 und F3 stellt eine Datenverbindung dar.<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
41
HAUPTBEITRAG<br />
nur die relevanten Merkmalstypen der Assets; folgende<br />
Basic Elements ergeben das BCFLP-Modell:<br />
Business<br />
Construction<br />
Function<br />
Location<br />
Performance<br />
In IEC TR 62794 werden Merkmalstypen in fünf Basic<br />
Elements klassifiziert (siehe Bild 2), die im Verbund Eigenschaften<br />
eines Assets oder einer ganzen Anlage repräsentieren<br />
(Prinzip).<br />
Das Basic Element Business (B) steht stellvertretend<br />
für alle geschäftsrelevanten Eigenschaften der Assets.<br />
Hierzu gehören unter anderem Preis, Lieferzeit<br />
und Anzahl der in einer Liefereinheit enthaltenen<br />
Assets.<br />
Das Basic Element Construction (C) repräsentiert die<br />
mechanischen und konstruktiven Eigenschaften<br />
eines Assets. Dies können sein: Abmessungen, Gehäusebeschaffenheit<br />
oder Steckertyp.<br />
Das Basic Element Function (F) beschreibt alle funktionalen<br />
Aspekte eines Assets. Hierzu zählen zum<br />
Beispiel Anwendungsfunktionen und Eigenschaften<br />
im operationalen Betrieb.<br />
Das Basic Element Location (L) beschreibt den Ort<br />
eines Assets innerhalb einer Anlage. Mögliche Angaben<br />
sind absolute oder relative Koordinaten oder<br />
Wertelisten bei mobilen Assets.<br />
Das Basic Element Performance (P) steht stellvertretend<br />
für komplexere Merkmale, wie Verarbeitungsgeschwindigkeit,<br />
Zykluszeiten, Startzeit, aber auch<br />
für Schwellwerte und Energiebedarf.<br />
IEC TR 62794 enthält keine Vorschriften, welcher Merkmalstyp<br />
welchem Basic Element zugeordnet werden soll,<br />
und lässt damit den Anlagenplanern ihre Freiheiten. Die<br />
einmal getroffene Entscheidung ist dann im Normalfall<br />
aber während der gesamten Anlagenlaufzeit bindend.<br />
Da alle Assetmerkmalstypen als Basic Elements klassifiziert<br />
sind, stellt die Anlage in ihrer Gesamtheit ebenfalls<br />
ein klassifiziertes Asset beziehungsweise CPS als<br />
spezifischen Assettyp dar.<br />
2.4 Datentechnische Strukturierung mit Basic Elements<br />
Die in verschiedenen Normen, zum Beispiel IEC 61987-<br />
ff [8], enthaltenen Merkmalstyplisten erleichtern in<br />
Form von Templates die Erzeugung produktspezifischer<br />
Merkmalstypstrukturen für die jeweiligen Assettypen,<br />
im Fall von IEC 61987-12 für Messumformer, bei<br />
IEC 62693 für Niederspannungsschaltgeräte. Allerdings<br />
handelt es sich um eine sehr große Zahl von Merkmalstypen<br />
pro Asset, sodass der Überblick schnell verloren<br />
gehen kann. Hier hilft sehr gut die Klassifikation in<br />
Form der Basic Elements, ermöglicht sie doch die Konzentration<br />
auf das Wesentliche mit der Möglichkeit zur<br />
stufenweisen Verfeinerung. Zur Veranschaulichung dieses<br />
Sachverhalts ist in Bild 3 die prinzipielle Struktur<br />
des Assets Programmable Logical Controller unter Anwendung<br />
der Basic Elements gezeigt. Es lässt sich erkennen,<br />
dass dieses Asset aus einer mechanischen Komponente<br />
(Hardware) C1 mit einer Kommunikationshardware<br />
C com besteht. Auf der Hardware C1 laufen zwei<br />
Funktionen ab. Natürlich hat auch dieses Asset einen<br />
Preis B1, eine Performance P1 und einen Einbauort L1.<br />
Der Informationsgehalt jeder Basic-Element-Klasse<br />
kann durch Hinzufügen weiterer gleichartiger Elemente<br />
beliebig angereichert und unterstrukturiert werden,<br />
was zum Beispiel bei C1 mit der Unterstrukturierung<br />
C com schon der Fall ist. Genauso ist es möglich, durch<br />
Hinzufügen von F1.1 an F1 die Funktion F1 verfeinert<br />
darzustellen.<br />
Hinter Basic Element F2 verbirgt sich ein Merkmalstyp<br />
Function, der mit einem Merkmalstyp eines anderen Assets<br />
vom Typ Function verschaltet werden könnte, siehe<br />
hierzu Bild 4.<br />
2.5 Verschaltung zu einer virtuellen Installation (VI)<br />
Bild 4 zeigt den Entwurf einer Anlage beziehungsweise<br />
eines Anlagenteils im Hinblick auf den statischen wie den<br />
dynamischen Aspekt. Eine in einem Rechnersystem als<br />
Abbild einer realen Installation (RI) gespeicherte virtuelle<br />
Installation (VI) entsteht durch das Verbinden von<br />
Merkmalstypen zweier Assets (CPS) mit demselben Merkmalstyp-Identifier<br />
(statischer Teil). Das zeitliche Verhalten<br />
von Verbindungen wird in IEC TR 62794 durch folgende<br />
Verbindungstypen charakterisiert (dynamischer Teil):<br />
Permanently connected/related/located<br />
Temporarily connected/related/located<br />
Folgende Attribute können unter anderem den Verbindungen<br />
zugewiesen werden:<br />
st = starting<br />
d = sending data<br />
2.6 Speichern von VI im Digital Factory Repository<br />
Ein Repository mit den Assets der Anlage enthält alle<br />
Merkmalstypen, einschließlich ihrer die jeweilige Anlage<br />
charakterisierenden Verbindungen. Diese Information<br />
stellt die Informationsplattform für alle Prozesse einer<br />
Anlage innerhalb ihrer gesamten Laufzeit dar. Im Kontext<br />
von IEC TR 62794 repräsentiert das Repository die Digitale<br />
Fabrik, siehe Bild 5, und wird daher Digital Factory<br />
Repository (DFR) genannt. Dieses kann datentechnisch<br />
beliebig zentral oder dezentral organisiert sein. Grenzen,<br />
wie fehlender Speicherplatz und zu geringe Verarbeitungsgeschwindigkeit,<br />
die früher eine Realisierung eines Repository<br />
behinderten, sind heute nicht mehr vorhanden.<br />
42<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
BILD 5: Ein Beispiel für ein Repository mit dem<br />
datentechnischen Abbild eines Anlagenteils als<br />
Verbindung von klassifizierten Asset-Merkmalstypen.<br />
Verbindungen können statische und<br />
dynamische (d) Eigenschaften repräsentieren.<br />
Legacy Systems Activities<br />
Engineerinration<br />
Configu-<br />
Operation<br />
Maintenance<br />
Security<br />
Upcoming new topics<br />
Condition<br />
Power<br />
Handling<br />
Monitoring<br />
::<br />
(Smart Grid)<br />
Simulation<br />
Direct Information Access<br />
digital factory repository<br />
d<br />
d<br />
d<br />
Program/<br />
Software<br />
BILD 6: Die prozessunterstützenden Werkzeuge<br />
arbeiten alle auf das Digital Factory Repository (DFR).<br />
BILD 7: Die Zahl der semantischen Gateways<br />
wächst quadratisch mit der Zahl der Werkzeuge<br />
mit unterschiedlichem Datenmodell.<br />
Measuring Devices<br />
IEC 61987-<br />
Actuators<br />
IEC 61987-<br />
Signal<br />
adjustment<br />
IEC 61987-<br />
Low Voltage – Control and<br />
Switch Gear<br />
IEC 62683<br />
Drives Converters I/O PLC<br />
Tool 1<br />
Data Model 1<br />
Tool 3<br />
Data Model 3<br />
Flow -12<br />
Pressure -13<br />
-14<br />
Temperature<br />
-15<br />
Level<br />
Common for all<br />
Measuring equip.<br />
-16<br />
Density<br />
Control Valve -22<br />
Common for<br />
Actuators<br />
Signal adj. -32<br />
Common for<br />
Signal adj.<br />
Contactors, Starters<br />
Control, Switches<br />
Circuit Breakers<br />
Switches, Disconnectors<br />
Terminal Blocks<br />
IEC 61987-11<br />
IEC 61987-21<br />
IEC 61987-31<br />
Tool 2<br />
Data Model 2<br />
= Semantical Gateway<br />
Tool 4<br />
Data Model 4<br />
General Structures: Horizontal Standard for Automation Devices<br />
IEC 61987-10<br />
BILD 8: IEC arbeitet an der Spezifikation von Merkmalstyplisten<br />
für unterschiedliche automatisierungstechnische Produktgruppen<br />
(grün: verfügbar, gelb: in Arbeit, weiß: geplant).<br />
:<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
43
HAUPTBEITRAG<br />
2.7 Erzeugung einer realen Installation<br />
Anhand der von Herstellern zur Verfügung gestellten<br />
konkreten Werte aus elektronisch verarbeitbaren Produktdatenblättern<br />
kann eine konkrete Anlage (reale<br />
Installation, RI) erzeugt werden. Prozessunterstützende<br />
Werkzeuge können auf das datentechnische Abbild<br />
einer Installation wahlfrei zugreifen, siehe Bild 6. Mit<br />
informatischen Standardfunktionen wird das koordinierte<br />
Verändern, Erstellen und Löschen von Information<br />
sichergestellt. Jedes Werkzeug kommuniziert <strong>mittels</strong><br />
eines Protokolls mit dem DFR über eine Schnittstelle.<br />
Es sind verschiedene Protokolle möglich, soweit<br />
die Implementierung des DFR diese unterstützt. Das<br />
Repository enthält nur semantisch eineindeutige<br />
Merkmale. Daher reduziert sich bei der Lösung nach<br />
Bild 6 die Anzahl der semantischen Informationsumsetzungen,<br />
oft semantische Gateways genannt, auf<br />
Null, wenn die mit dem Repository kommunizierenden<br />
Systeme (zum Beispiel Werkzeugketten) die eineindeutige<br />
Semantik der im DFR gespeicherten Merkmale<br />
übernehmen. Denn damit ist die Interoperabilität<br />
der Werkzeuge durch das von den Merkmalstypen<br />
vorgegebene Datenmodell implizit gegeben. Näheres<br />
hierzu in [9].<br />
Zum Vergleich wird die Situation bei heutigen vermaschten<br />
Werkzeuglösungen dargestellt, siehe Bild 7.<br />
Hier sind im schlechtesten Fall an jeder Schnittstelle<br />
wegen der unterschiedlichen Datenmodelle Bedeutungsumsetzungen,<br />
also zwei semantische Gateways<br />
erforderlich (Hin- und Rückweg). Die Anzahl N der semantischen<br />
Gateways n beträgt damit im schlechtesten<br />
Fall N = n * (n-1), wächst also annähernd quadratisch<br />
mit der Zahl der Werkzeuge. Folgen hingegen die Gewerke<br />
und deren Werkzeuge in einer Anlage den einheitlichen<br />
Regeln des Modells der IEC TR 62794 und den<br />
Beschreibungsregeln nach IEC 61360 wird es sogar erstmalig<br />
möglich, ohne semantische Brüche auch gewerke<br />
übergreifend zu planen und damit viele Planungsfehler<br />
bereits in frühen Phasen zu erkennen.<br />
3. NORMUNG VON MERKMALSTYPEN<br />
FÜR PRODUKTTYPEN<br />
Die Erarbeitung von Templates mit eineindeutigen<br />
Merkmalstypen ist für die verschiedenen automatisierungstechnischen<br />
Produkttypen in vollem Gang. Während<br />
IEC SC 3D für die Grundlagen zur Erstellung von<br />
Produktdaten, also für die Regeln zur Erstellung einzelner<br />
Produktmerkmalstypen zuständig ist, werden<br />
koordiniert reale Produkttypen mit ihren Merkmalstypen<br />
in IEC TC 65 [8] und seit einiger Zeit auch in<br />
IEC TC 17B [11] spezifiziert. Die Merkmalstyplisten<br />
(Produkttypen-Templates) für automatisierungstechnische<br />
Produkte sind demnächst online in der IEC-<br />
Datenbank Common Data Dictionary (CDD) verfügbar,<br />
bei elektronischen Bauelementen ist dies schon heute<br />
der Fall [10]. Das CDD wird schrittweise mit den in der<br />
Normung erarbeiteten Merkmalstyplisten gefüllt. Der<br />
in der bereits erwähnten eClass- Sachgruppe 27 für die<br />
Automatisierungstechnik verfügbare Inhalt der Version<br />
8.0 advanced ist in weiten Teilen identisch mit den<br />
Inhalten des IEC CDD. Bild 8 zeigt die im Fokus der<br />
Arbeiten stehenden Gerätetypen. Eine grüne Ampel<br />
signalisiert entweder schon verfügbare oder demnächst<br />
erscheinende Normen. Die Arbeiten beschränken<br />
sich in IEC bislang auf Automatisierungskomponenten.<br />
Auch in der International Standardisation<br />
Organisation (ISO) sind vereinzelte aber noch nicht<br />
koordinierte Projekte zur Merkmalstypspezifikation<br />
vorhanden. In eClass wird intensiv, ebenfalls auf Basis<br />
der IEC 61360, an der Spezifikation von Merkmalen<br />
gearbeitet, zum Beispiel für das Gesundheitswesen<br />
und in inhaltlicher Abstimmung mit IEC TC65 für die<br />
Automatisierungstechnik.<br />
AUTOREN<br />
Dipl. Inf. UDO DÖBRICH<br />
(geb. 1954) ist Obmann<br />
der Arbeitsgruppe<br />
IEC TC 65 WG16<br />
(Digital Factory).<br />
Dipl.-Ing. ROLAND HEIDEL<br />
(geb. 1952) ist Chairman<br />
des in der IEC für automatisierungstechnische<br />
System themen zuständigen<br />
Komitees TC 65.<br />
Siemens AG,<br />
Industry, I IA ATS SR,<br />
Rheinbrückenstraße 50, D-76181 Karlsruhe,<br />
Tel. +49 (0) 721 595 25 50,<br />
E-Mail: udo.doebrich@siemens.com<br />
Siemens AG,<br />
Industry, I IA ATS SR,<br />
Rheinbrückenstraße 50, D-76181 Karlsruhe,<br />
Tel. +49 (0) 721 595 46 32,<br />
E-Mail: roland.heidel@siemens.com<br />
44<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
ZUSAMMENFASSUNG<br />
Mit dem beschriebenen Ansatz werden die eingangs angeführten<br />
Forderungen an den Anlagenentwurf folgendermaßen<br />
erfüllt:<br />
1 | Die Einigung auf einen Satz von Merkmalstypen<br />
mit genormter weltweit gültiger Semantik und eineindeutigem<br />
Identifier für jedes Asset erlaubt einen<br />
produktneutralen Anlagenentwurf (Typebene).<br />
Dies gilt auch für den Assettyp CPS.<br />
2 | Durch Zuweisung von Werten an die Merkmalstypen<br />
auf Basis konkreter Produkte kann der produktneutrale<br />
Entwurf in einen produktspezifischen<br />
Entwurf überführt werden (Instanzebene).<br />
3 | Die Klassifikation der Merkmalstypen erlaubt eine<br />
klare Abgrenzung von Zuständigkeiten der handelnden<br />
Personen und die gewerkeübergreifende<br />
Nutzung und Verarbeitung von Information in<br />
den zugehörigen Werkzeugen. Der informationsorientierte<br />
Ansatz <strong>mittels</strong> Merkmalstypen erhöht<br />
in Verbindung mit deren eineindeutiger Semantik<br />
deutlich die Transparenz einer Installation und<br />
hilft so, die Komplexität der Anlage besser zu beherrschen.<br />
4 | Die Information über eine Anlage kann aufgrund<br />
der genormten Semantik der Merkmalstypen während<br />
allen Lebensphasen der Anlage, also über lange<br />
Zeit, genutzt werden.<br />
IEC TR 62794 beschreibt anhand von Beispielen, wie<br />
mit dem behandelten Modell beliebige Installationen<br />
beziehungsweise Anlagen geplant werden können. Dabei<br />
wird auf viel Bekanntes, aber bislang aufgrund fehlender<br />
Erfordernisse nicht Systematisiertes, zurückgegriffen.<br />
IEC TR62794 impliziert einen merkmalsorientierten<br />
Systembegriff. Mit so beschriebenen cyber-physischen<br />
Systemen dürften sich wesentliche Forderungen<br />
zur Planung, Inbetriebnahme, zum laufenden Betrieb<br />
und zur Wartung auf deutlich bessere Weise erfüllen<br />
lassen als bisher. Aufgrund der semantischen Eineindeutigkeit<br />
der Merkmale, verbunden mit der Speicherung<br />
der virtuellen Installation in einem Digital Factory<br />
Repository DFR, reduziert sich die Zahl der erforderlichen<br />
semantischen Umsetzungen zwischen einzelnen<br />
Instanzen deutlich: ein wesentlicher Beitrag zur Verbesserung<br />
der Interoperabilität und der Transparenz.<br />
Die vorgeschlagene Methodik zur Realisierung von<br />
Anlagen auf Basis von IEC TR 62794 ist im Prinzip für<br />
jede Installation anwendbar.<br />
REFERENZEN<br />
[1] IEC, Genf, IEC TR 62794, Industrial-process measurement,<br />
control and automation; Generic reference<br />
model for the Digital Factory and automation assets<br />
[2] IEC, Genf: IEC 61360 -1 to 4 - Standard data element<br />
types with associated classification scheme for<br />
electric components.<br />
[3] eCl@ss e.V. 2013, Klassifikation und Datenbank<br />
Version 8.0 / Alle Klassen und Merkmale,<br />
http://www.eclass.eu.<br />
[4] NAMUR 2013,: http://www.namur.de<br />
[5] VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik,<br />
Druckschrift Thesen und Handlungsfelder,<br />
“Cyber-Physical Systems: Chancen und Nutzen aus<br />
Sicht der Automation“; April 2013<br />
[6] Integrierte Forschungsagenda Cyber-Physical<br />
Systems, Acatech 2012;<br />
http://www.acatech.de/?id=1405<br />
[7] Springer-Verlag 2012, Informatik Spektrum,<br />
Daten getriebene Programmsysteme, Band 35, 2012,<br />
Heft 3, S.190-203, Udo Döbrich, Roland Heidel<br />
[8] IEC, Genf, IEC 61987-10, Industrial-process measurement<br />
and control - Data structures and elements in<br />
process equipment catalogues - Part 10: Lists of<br />
Properties for Industrial-Process Measurement and<br />
Control for Electronic Data Exchange. Fundamentals,<br />
Part 11, Part 12<br />
[9] Oldenburg Wissenschaftsverlag 2011, Automatisierungstechnik<br />
(AT), Merkmale als Grundlage der<br />
Interoperabilität technischer Systeme, Band 59<br />
Heft 7, S.440-450, Ulrich Epple (RWTH Aachen),<br />
[10] IEC CDD 2013, http://std.iec.ch/iec61360<br />
[11] IEC 2013; Genf, IEC 62683, Low-voltage switchgear<br />
and controlgear - Product data and properties for<br />
information exchange<br />
[12] NAMUR/ PROLIST International e.V. 2006,<br />
NE 100 V3.2 Specification of Device Properties<br />
[13] ISO 1998, Genf, ISO 13584-42, Industrial automation<br />
systems and integration -- Parts library -- Part 42:<br />
Description methodology: Methodology for<br />
structuring part families<br />
[14] VDI/VDE GMA-Kongress, VDI-Berichte 2209, VDI<br />
Verlag GmbH, Düsseldorf 2013, Automation 2013,<br />
ISBN 978-3-18-092209-6, Seite 321- Seite 325,<br />
Ein Modell zur Beschreibung Cyber-Physikalischer<br />
Systeme – Ein Beitrag zu Industrie 4.0<br />
[15] ISO 10303, Genf, Standard for the Exchange of<br />
Product model data (STEP)<br />
Dieser Artikel erschien in seiner Urfassung im Tagungsband<br />
zum VDI/VDE GMA-Kongress Automation 2013,<br />
der am 25./26.6.2013 in Baden-Baden stattfand [14].<br />
MANUSKRIPTEINGANG<br />
30.07.2013<br />
Im Peer-Review-Verfahren begutachtet<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
45
HAUPTBEITRAG<br />
Nur Befehle befolgt<br />
CPS erfordern sichere Identitäten<br />
Die Ad-hoc-Kommunikation der Komponenten von cyber-physischen Systemen wirft Fragen<br />
der Angriffssicherheit auf. Es bedarf sicherer Identitäten und semantische Aspekte<br />
müssen geklärt werden, damit die Komponenten in den gleichen Begriffen für Rollen,<br />
Rechte und vor allem Funktionen kommunizieren. Der Beitrag beschreibt die Brisanz<br />
dieser Problematik und erklärt die Notwendigkeit, dass sie auch für Komponenten gelöst<br />
sein muss, die erst später und von Dritten hergestellt werden.<br />
SCHLAGWÖRTER Cyber-physische Systeme / Identitätsnachweise / Zertifikate / Trusted<br />
Platform Module / Ad-hoc-Kommunikation<br />
We were only Following Orders –<br />
CPS Requires Secure Identities<br />
The ad hoc communication of components of cyber physical systems raises various security<br />
issues, for example regarding potential identity theft. Machine to machine communication<br />
also requires globally defined semantics so that components can use the same<br />
concepts for functions, roles and rights. The difficulties are described as well as the importance<br />
of solutions for components which will be produced in future or by third parties.<br />
KEYWORDS plug and produce / identification / trusted platform modules / ad-hoc<br />
communication<br />
46<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
WALTER SPETH, Bayer Technology Services<br />
Massenkarambolage auf der Autobahn: Etliche<br />
Fahrzeuge haben spontan eine Vollbremsung<br />
durchgeführt. In der Analyse der Aufzeichnungen<br />
von digitalen Systemen, die in<br />
den Fahrzeugen zur Verbesserung der Sicherheit<br />
verbaut waren, zeigt sich, dass jeweils ordnungsgemäß<br />
ein Kommando abgearbeitet wurde. Dieses<br />
spezielle Kommando ist vorgesehen, vom Navigationssystem<br />
nach Auswertung des Traffic Message Channels<br />
ausgegeben zu werden, um das Auffahren auf ein Stauende<br />
zu verhindern. Nur, dass diesmal gar keine Staunachricht<br />
eingegangen war. Das Kommando wurde vermutlich<br />
von einer Schadsoftware aus einem überholenden<br />
Fahrzeug ausgesandt und diese benutzte Car-to-Car-<br />
Kommunikation, um ihre Opfer zu befallen.<br />
Ein konstruiertes Horrorszenario, mit heutiger Technik<br />
angesichts der Kommunikationswege in den Fahrzeugen<br />
nicht denkbar, jedoch geeignet, die Gefahren<br />
aufzuzeigen, die ein Verbund technischer Komponenten<br />
mit mechanischen und elektronischen Teilen birgt, die<br />
über eine Infrastruktur kommunizieren, wenn Schadsoftware<br />
über diese Infrastruktur angreift. Im Umfeld<br />
Industrie 4.0 wird solch ein Verbund als cyber-physisches<br />
System (CPS) bezeichnet.<br />
Neben dem intelligenten Produkt sind solche ad hoc<br />
miteinander kommunizierenden Komponenten in der<br />
– nach Dampfkraft/Wasserkraft, Elektrifizierung/Massenfertigung<br />
und der Digitalisierung/Automatisierung<br />
– vierten industriellen Revolution eine tragende Strategie,<br />
um die wandlungsfähige, kundenintegrierende und<br />
oft konsumentennahe Smart Factory zu realisieren.<br />
Nicht zuletzt ist es aufgrund der Komplexität der zu erwartenden<br />
Strukturen und Kommunikationsbeziehungen<br />
zwischen den teilweise autonom agierenden technischen<br />
Systemkomponenten ratsam, die Sicherheitsaspekte<br />
frühzeitig in die Lösungen hinein zu konstruieren.<br />
Die folgenden Betrachtungen zeigen den Bedarf an technischer<br />
Absicherung und semantischer Vereinbarung in<br />
der Sicherheit von Ad-hoc-Kommunikation auf, ebenso<br />
Technologien, die hierfür einsetzbar sind und die Erfordernisse,<br />
diese zu adaptieren. Damit ist noch kein Lösungskonzept<br />
aufgezeigt. Der Beitrag weist aber auf nutzbare<br />
existierende Konzepte und Technologien hin, die<br />
eingearbeitet werden können, um die funktionale Ausgestaltung<br />
von Ad-hoc-CPS-Kommunikation gegen Angriffe<br />
abzusichern.<br />
1. SICHERHEIT 4.0<br />
Einige der möglichen Angriffe auf CPS werden in [7] mit<br />
Fokus auf Embedded-Systeme beschrieben und dort werden<br />
konkrete Integritätsschutzmaßnahmen im Hinblick<br />
auf Industrie 4.0 aufgezeigt. Die Standards hinken wieder<br />
mal hinterher: Wie die Zeitschrift für Informations-<br />
Sicherheit kes [1] berichtet, besteht Bedarf, die Risiken<br />
zu erkennen, die sich durch die neu entstehenden Angriffsvektoren<br />
ergeben und die notwendigen Sicherheitsstandards<br />
erst noch zu schaffen. Die Umsetzungsempfehlungen<br />
für das Zukunftsprojekt Industrie 4.0 [2] bezeichnen<br />
Sicherheit als erfolgskritischen Faktor für Industrie<br />
4.0, denn produktionstechnische Anlagen<br />
müssen betriebssicher sein, was bedeutet, dass von ihnen<br />
keine Gefährdung für Menschen, andere Anlagen oder<br />
die Umwelt ausgehen darf, und sie sollten angriffssicher<br />
sein, denn die Bedrohungen nehmen zu und erreichen<br />
teils nationales Interesse [8]. Dort wird betont, dass noch<br />
nicht vollständig gelöste Sicherheitsfragen aus Industrie<br />
3.0 fortbestehen. In CPS-basierten Produktionssystemen<br />
kommen neue Sicherheitsanforderungen hinzu und eine<br />
nachträgliche Anreicherung der Systeme um Security-<br />
Funktionen reicht nicht aus. Alle Aspekte der Sicherheit<br />
müssen von Anfang an einbezogen werden.<br />
Die spezifische Herausforderung in der Ad-hoc-Kommunikation<br />
besteht im Ansatz in der Vorstellung, dass<br />
die Komponenten die Kommunikation selbständig aufnehmen,<br />
ohne zuvor von einem Administrator in die<br />
Infrastruktur aufgenommen worden und ab dann der<br />
hierfür geltenden Sicherheits-Policy unterworfen zu<br />
sein. Es wird oft unterstellt, dass diese Komponenten<br />
nomadisieren (was Lokation und Besitz betrifft) und sich<br />
dabei wechselnden Infrastrukturen unterwerfen.<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
47
HAUPTBEITRAG<br />
Damit sind die wesentlichen Sicherheitsanforderungen<br />
bezüglich ihrer Identitätsnachweise: Unterscheidbarkeit,<br />
Wiedererkennung, Fälschungssicherheit und<br />
Integrität (Bindung an die Funktion) bei einem semantisch<br />
scharfen gemeinsamen Verständnis über die<br />
Funktion, ihrer Parameter und der erforderlichen und<br />
zugestandenen Berechtigungen. Abgebildet auf Beispiele<br />
aus der industriellen Produktion bedeutet das, dass<br />
sich die Schranke nur und immer wieder für den richtigen<br />
Kesselwagen öffnet, dass die Waage das ermittelte<br />
Gewicht an den Lkw – und nur an diesen – überträgt,<br />
dass der Gabelstapler die richtigen Paletten an der Verpackungslinie<br />
abholt und der Roboter nur die bestellten<br />
Bauteile auf das Endprodukt montiert. In funktionaler<br />
Betrachtung werden diese Themen traditionell mit<br />
Sorgfalt behandelt. In diesem Beitrag gilt das Augenmerk<br />
der Manipulationssicherheit. Nicht nur die referenzierten<br />
Publikationen lassen erkennen, dass die<br />
Erfüllung der Sicherheitsanforderungen für Industrie<br />
4.0 wesentlicher Erfolgsfaktor sein wird. Erfreulicherweise<br />
werden bereits unternehmensübergreifend in der<br />
Gremienarbeit Anstrengungen unternommen, Strategien<br />
und Lösungen zu erarbeiten.<br />
Die folgenden Überlegungen richten sich auch an Planer<br />
und Betreiber, denn Sicherheit lebt vom Verständnis<br />
der Zusammenhänge, das gleichermaßen in Kaufentscheidungen,<br />
Lösungskonzepte und Architekturfragen<br />
einfließen muss. Es gilt zu verhindern, dass sich die<br />
Schranke für falsche Kesselwagen öffnet, der Lkw der<br />
Waage ein falsches Leergewicht mitteilt, der Gabelstapler<br />
zu viele Erzeugnisse übergibt und der Roboter nichtbestellte<br />
Komponenten montiert – Aktionen, die Wirkung<br />
von Schadprogrammen sein können, wo Sicherheitsmängel<br />
Angriffsflächen bieten. Es muss sichergestellt<br />
sein, dass eine Komponente weiß, mit wem sie<br />
kommuniziert, dass also ihre Kommunikationspartner<br />
unterscheidbar, wiedererkennbar, verifizierbar und in<br />
der übermittelten Information und den Kommandos<br />
kompatibel sind.<br />
2. SAG MIR, WER DU BIST<br />
Natürlich soll eine Komponente innerhalb eines CPS nur<br />
auf ordnungsgemäße Kommandos reagieren, und ordnungsgemäß<br />
bezieht sich auf die Korrektheit und auf<br />
den Absender des Kommandos. Bevor die Zuständigen<br />
sich über Authentifizierung Gedanken machen, muss<br />
eine Betrachtung von Identitäten angestrengt werden,<br />
denn Authentifizierung ist nichts anderes als die Verifikation,<br />
dass eine behauptete Identität auch die faktische<br />
ist. Dabei sind in heutigen digitalen Systemen vielfältige<br />
Arten von Identitätsnachweisen üblich, sowohl<br />
für Anwender (Benutzerkonten im Sinne von Aliasse<br />
oder SID), als auch für Systeme (IP-Adressen, MAC-<br />
Adressen, SSID von WLAN). Es ist offensichtlich, dass<br />
Identitätsnachweise oft dazu dienen, einen Kommunikationspartner<br />
zu erklären und eben nicht nur, den Eigentümer<br />
von Objekten wie etwa Dateien auszuweisen.<br />
Aber in der Kommunikation geht es letztlich ebenso um<br />
den kontrollierten Zugang zu teils entfernten Objekten<br />
und die Ausführung von Funktionen.<br />
Für Industrie 4.0 wird es wesentlich sein, Verfahren<br />
zur Erzeugung und zum Diebstahlschutz solcher Identitätsnachweise<br />
zu implementieren. Erfunden werden<br />
müssen sie nicht: Die Technik ist verfügbar. Es ist nur<br />
der Besonderheit Rechnung zu tragen, dass der Besitz<br />
der Komponenten wechselt und daher die Komponente<br />
selbst für ihre Eigensicherheit verantwortlich ist und<br />
deshalb über ihre Schlüssel wachen muss. Technisch<br />
gibt es hier mehrere Ansätze und Integratoren wie Betreiber<br />
von CPS müssen vor dem Hintergrund denkbarer<br />
Angriffe ein Konzept zur Network Access Control (NAC)<br />
wählen, das die Identität des Kommunikationspartners<br />
hinreichend absichert, bevor dieser autorisiert und ihm<br />
Zugriff auf die Ressourcen gewährt wird. NAC-Systeme<br />
werden von diversen Unternehmen vermarktet, aber im<br />
Hinblick auf Identitätsschutz besteht für die Ad-hoc-<br />
Vernetzung Bedarf an ergänzenden Technologien. Ein<br />
vielversprechendes Beispiel – aber noch im Forschungsstadium<br />
– sind Physical Unclonable Functions (PUF),<br />
oder das von Microsoft dominierte Network Access Protection<br />
(NAP) und Trusted Network Connect (TNC) von<br />
der Trusting Computing Group. Die Technik, die unter<br />
der Bezeichnung Trusted Platform Module (TPM) kursiert,<br />
wird von verschiedenen Herstellern mit Produkten<br />
hinterlegt und scheint den Anforderungen eines CPS am<br />
ehesten gerecht zu werden.<br />
3. TRUSTED PLATFORM MODULES<br />
Angreifer dürfen nicht in der Lage sein, den geheimen<br />
Schlüssel, auf dem die Sicherheit des Identitätsnachweises<br />
einer CPS-Komponente basiert, zu extrahieren oder<br />
den Identitätsnachweis oder den Programm-Code zu<br />
ändern. Deswegen wird der Code fest eingebrannt und<br />
der geheime Schlüssel wird in der Hardware erzeugt und<br />
nie übertragen: Das leistet beispielsweise ein CodeMeter<br />
[7], der als Software-Kopierschutzstecker (Dongle) einen<br />
fälschungssicheren Identitätsnachweis enthält, mit Zusatzssoftware<br />
zum Smartcard-Token wird und in einer<br />
einlötbaren Bauform erhältlich ist. Diese Eigenschaften<br />
hat er mit den TPM gemeinsam. Ein TPM ist ein Chip,<br />
der sich in der Elektronik einer CPS-Komponente verbauen<br />
lässt. Der Chip verhält sich in einigen Punkten<br />
wie eine fest eingebaute Smartcard, das Kryptoverfahren<br />
ist RSA und die Schlüssellänge 2048 Bits. Das ist nach<br />
heutigen Maßstäben sicher gegen Fälschungen. Auf dieser<br />
Basis lassen sich Verfahren für Remote Attestation<br />
implementieren, die es autorisierten Stellen erlauben,<br />
Änderungen in der Hardware und der Software der CPS-<br />
Komponenten zu erkennen, insbesondere solche, die<br />
darauf angelegt sind, Schutzmaßnahmen zu umgehen.<br />
Es gibt bereits Konzepte, um Identitätsnachweise in<br />
der Form von Certified Migratable Keys von einem TPM<br />
auf ein anderes TPM zu transferieren. Die Sicherheit<br />
wird dadurch aufrecht erhalten, dass das Zielsystem<br />
oder aber eine Migration Authority im TPM von Anfang<br />
an festgelegt war und nicht änderbar ist.<br />
48<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
4. PSEUDONYME REICHEN NICHT<br />
Die Identifizierung erfolgt ad hoc nicht notwendigerweise<br />
gegen ein Verzeichnis, das im Rahmen eines Identity-<br />
Managements von Administratoren aufgebaut wurde.<br />
Die Identitätsnachweise dienen also zunächst nur der<br />
Wiedererkennung und haben die Qualität von Pseudonymen<br />
wie wir sie im Web-Kontext etwa von dem Cookie-Mechanismus<br />
kennen. Fälschungssichere Identitätsnachweise<br />
schützen eine Komponente vor einem Austausch<br />
des Komunikationspartners durch einen Identitätsdieb.<br />
Dies verhindert damit auch viele Varianten<br />
(nicht zum Beispiel eine Wiedereinspielung) des Janus-<br />
Angriffes (man in the middle attack), aber es sind weitere<br />
Strukturen erforderlich, um die Rechtmäßigkeit<br />
eines Kommandos abzusichern. Denn dass eine Folge<br />
von Befehlen immer von der derselben Quelle kommt<br />
und keine Fremdkomponente mit gestohlenem Identitätsnachweis<br />
unlautere Ziele in der Aussendung ihrer<br />
Befehle verfolgen kann, hält das Sicherheitsniveau nach<br />
der ersten Kontaktaufnahme aufrecht und behandelt die<br />
Identitätsnachweise eben als Pseudonyme: Sie verweisen<br />
immer auf dasselbe, aber es muss ja irgendwann<br />
geklärt werden, welche konkrete Komponente zugelassen<br />
wird.<br />
Bevor CPS-Komponenten erstmals miteinander kommunizieren,<br />
müssen Sie voneinander wissen. Dazu muss<br />
ein Kommunikationspartner den anderen entdecken.<br />
Dieser übt dann die Funktion eines Access-Point für sich<br />
und gegebenenfalls nachgeschaltete Komponenten aus.<br />
Solche Discovery-Mechanismen kennen wir von WLAN-<br />
Clients oder von SOA-Clients, die über UDDI eine Auswahl<br />
an Service Providern ermitteln können, aber auch<br />
von UPnP im Home-Entertainment-Bereich.<br />
Als nächstes baut der Client die bilaterale Kommunikation<br />
auf. Das Bus-Paradigma und Broadcast-Aktivitäten<br />
sind hier ungeeignet. Der Access-Point stellt sich<br />
transparent dar. Dem oft in der gleichen Komponente<br />
eingebauten Server obliegt das Access-Management auf<br />
vorhandene Ressourcen beziehungsweise Services, jedenfalls<br />
insofern der Zugriff client-agnostisch oder offen<br />
ist. Andernfalls ist eine Paarung erforderlich, wie<br />
wir sie von WPS (Wi-Fi Protected Setup) oder Bluetooth<br />
kennen. Bei der Push Button Configuration (PBC) von<br />
WPS können Geräte dem Netzwerk während einer zweiminütigen<br />
Phase beitreten, was die Paarung vereinfacht,<br />
allerdings weitergehenden Sicherheitsüberlegungen<br />
nicht standhält. Alternativ ist nach dem Knopfdruck<br />
die Übertragung eines Geheimnisses erforderlich,<br />
wie wir es von der Paarung von Bluetooth-Geräten<br />
kennen. Dazu kann ein Kommunikationspartner eine<br />
Information generieren (Display), die ein Administrator<br />
dem anderen Kommunikationspartner mitteilt (Input),<br />
ohne dass das Geheimnis über den Kommunikationskanal<br />
transportiert wird – erforderlich ist der Umweg<br />
über eine vertrauenswürdige dritte Instanz: den Besitzer<br />
beziehungsweise den Bediener. Ihm obliegt die Verantwortung,<br />
über die Rechtmäßigkeit der Verbindung<br />
zu entscheiden. Das mag oft hinreichend sein, erzielt<br />
aber nicht die Qualität in Punkto Flexibilität der Adhoc-Kommunikation,<br />
wie sie für CPS postuliert wird.<br />
Im übrigen ist dieses Vorgehen nur dann geeignet, wenn<br />
die zu koppelnden Komponenten zumindest temporär<br />
denselben Besitzer haben und sich beide physisch in<br />
dessen Reichweite befinden. Mit Besitz ist nicht notwendig<br />
die Eigentümerschaft gemeint, sondern die Verfügungsgewalt,<br />
die in der Kopplung der Komponenten<br />
ausgeübt wird. Nach heutigem Expertenverständnis ist<br />
eine Zero-Touch-Konfiguration – also eine solche, die<br />
ohne Bediener-Aktion rein auf der Kommunikation basieren<br />
würde – nicht denkbar, ohne die Sicherheit zu<br />
kompromittieren.<br />
5. BERECHTIGUNGSERFORDERNISSE AD HOC<br />
Auch wenn eine Signaturprüfung des Clients durch den<br />
Server und umgekehrt (mutual) stattfindet, beschränkt<br />
sich Identifizieren auf Wiedererkennen und die Attributierung<br />
der Funktionsanforderung. Authentifizierung ist<br />
die Überprüfung, dass die Identität ursprünglich ist und<br />
nicht gefälscht oder gestohlen. Aus dem täglichen Leben<br />
wissen wir, dass Identitätsnachweise – die beiden gebräuchlichsten<br />
sind der Personalausweis und der Führerschein<br />
– durch Sicherheitsmerkmale vor Fälschbarkeit<br />
gesichert werden, da sonst leicht Handlungen im<br />
Namen einer gestohlenen Identität und zu deren Schaden<br />
durchgeführt werden können. Wir authentisieren<br />
uns durch einen oder mehrere Faktoren: durch ein Besitztum<br />
(einen Schlüssel), eine immanente Eigenschaft<br />
(Biometrie) oder durch ein Wissen (Parole, Kennwort).<br />
In der Maschine-Maschine-Kommuniation eines CPS<br />
sind die Schlüssel das geeignete Mittel, weil sich digitale<br />
Nachrichten mit heute verfügbaren Verfahren verund<br />
entschlüsseln lassen und asymmetrische Kryptoverfahren<br />
zum Einsatz kommen, wo ein Schlüsselaustausch<br />
über den Kommunikationsweg als Schwachstelle<br />
erkannt wurde. Eine Anzahl Ausstellerzertifikate<br />
sind der Komponente bei der Herstellung (fälschungssicher)<br />
eingebrannt worden – genauer: dem TPM; ähnlich<br />
wie ein Web-Browser bei der Installation bereits<br />
über die Zertifikate der wichtigen Stammzertifizierungsstellen<br />
verfügt, um beim Aufbau von SSL-Verbindungen<br />
die Zertifikatskette zu schließen. Der Zugriff auf<br />
Zertifikatsrückruflisten ist kaum praktikabel; das ist die<br />
Archillesverse des Verfahrens. Bei gewissen CPS-Szenarien<br />
ist es aber denkbar, dass eine dienstleistende<br />
Komponente über das RADIUS-Protokoll [9] einen Authentifizierungs-Server<br />
anspricht, der <strong>mittels</strong> eigener<br />
Konfigurationsdateien, eigener Konfigurationsdatenbanken<br />
oder durch Anfragen an weitere Datenbanken oder<br />
Verzeichnisdienste (etwa Active Directory) über die<br />
Akzeptanz des Kommunikationspartners und seiner<br />
Berechtigungen Auskunft erteilt.<br />
Kommt es zur Autorisierung, wäre ein Verzeichnis von<br />
Rollen und Rechten eine zentrale Funktion, die dem<br />
Ansatz der Ad-hoc-Vernetzung von CPS nicht angemessen<br />
ist, zumal verschiedene Hersteller verschiedene<br />
Baureihen zu unterschiedlichen Zeiten fertigen werden.<br />
Ersatzweise müssen die möglichen Rechte durch Nor-<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
49
HAUPTBEITRAG<br />
mung in ihrer Semantik vereinbart sein, während sich<br />
das Ausmaß an entgegen zu bringendem Vertrauen für<br />
eine ordnungsgemäße Funktionsausführung in der Rolle<br />
manifestiert, die sich zum Beispiel aus einem Attribut<br />
im Zertifikatssubjekt ableiten lässt. Dementsprechend<br />
müssen Trustcenter, die die Zertifkate für die TPM ausstellen,<br />
für Industrie 4.0 ihre Produktpalette erweitern.<br />
Heute können sie der Anforderung meist nur mit der<br />
Einstufung über Zertifikatsklassen begegnen, was nicht<br />
die erforderliche Flexibilität birgt; jeder Klasse ist eine<br />
Policy zugeordnet. Aber auch hier ist zunächst die Normung<br />
erforderlich, um die Semantik zu definieren. Diese<br />
Thematik veranschaulicht Tabelle 1.<br />
Es ist offensichtlich, dass es eines Vergabe- und Normierungsgremiums<br />
bedarf, um eine Notation für die<br />
Funktionen und die Rechte und Rollen durchzusetzen<br />
und entsprechende Codes (ID) zu vergeben. Die Notation<br />
kann Abstract Syntax Notation One (ASN.1) sein, das in<br />
der Kommunikation über LDAP, SNMP oder GSM sehr<br />
verbreitet ist. Eine technische Bearbeitung ist damit<br />
leicht möglich: sprachen-neutral, syntaktisch eindeutig<br />
und für die Maschine-Maschine-Kommunikation ohne<br />
Erfordernis einer Bediener-Interpretation geeignet. Das<br />
Internet hat die Notwendigkeit, die Vielzahl von Nummern<br />
und Namen und deren Zuordnung und Bedeutung<br />
zu koordinieren, bereits in seinen Anfängen erkannt. Mit<br />
der Internet Assigned Numbers Authority (IANA) entstand<br />
eine der ältesten Institutionen im Internet, die für<br />
Zuordnung von Nummern und Namen im Internet zuständig<br />
ist. Etwas Vergleichbares ist für CPS erforderlich.<br />
6. ACHILLES UND DIE SCHILDKRÖTE<br />
Das klassische Paradoxon bewirkt Erstaunen und Verwirrung,<br />
weil der Zeitfaktor unberücksichtigt bleibt.<br />
Ebenso steht die Zeitfrage an, wenn die oben genannten<br />
Schritte im Kommunikationsaufbau abgearbeitet sind<br />
und eine Kommunikationssitzung besteht: Wie hält der<br />
angesprochene Dienst den Vertrauensstatus des Anfragers<br />
aufrecht? Eine drahtlose Verbindung kann einer<br />
Unterbrechung unterliegen und Komponenten, die einen<br />
Vertrauensstatus genießen, sollten ihn nicht notgedrungen<br />
bei jeder späteren Zusammenarbeit neu erwerben<br />
müssen, was zeitlichen Aufwand erfordern würde. Technisch<br />
gesehen braucht eine Komponente ein Gedächtnis<br />
(Memory), um sich ihre Kommunikationspartner und<br />
deren Vertrauensstatus zu merken. Das Gedächtnis muss<br />
sicher gegen Manipulation und hinreichend groß sein,<br />
um eine sinnvolle Anzahl von Identitätsnachweisen zu<br />
enthalten. Darüber hinaus braucht es einen Algorithmus,<br />
wie im Falle eines vollgelaufenen Speichers zu verfahren<br />
ist – etwa: keinen weiteren Kommunikationspartner akzeptieren<br />
oder: den ältesten verwerfen.<br />
7. ES MUSS NICHT IMMER ETHERNET SEIN<br />
Mobile drahtlose Kommunikationstechnik, die bei CPS<br />
in der Regel unterstellt wird, hat viele Formen. Die neben<br />
dem WLAN nach dem Standard der IEEE-802.11-<br />
Familie verbreitetste ist der Mobilfunk mit den Protokollen<br />
GSM, UMTS oder LTE, in dem die Erreichbarkeit<br />
durch Roamingverfahren weltweit gegeben ist. Die Identität<br />
wird hier an der SIM-Karte festgemacht, dem “Tresor<br />
unserer Identität“ wie sie in [4] bezeichnet wird.<br />
Während die Mobilfunkübertragung für CPS geeignet<br />
ist, muss auch hier für die Authentifizierung eine Zusatztechnik<br />
im Sinne eines TPM zum Einsatz kommen,<br />
schon deswegen, weil SIM-Karten aus CPS-Komponenten<br />
entfernt und physisch in andere übertragen werden<br />
können. Dabei darf nicht die Identität transferiert werden<br />
können. Nicht zuletzt wäre im Falle eines bekannt<br />
gewordenen Sicherheitseinbruchs in die SIM-Karte deren<br />
Sperrung beim Mobilfunkbetreiber und der Austausch<br />
von SIM-Karten durch den Besitzer oder CPS-<br />
Bediener logistisch und organisatorisch kaum zu bewältigen.<br />
Dass solche Sicherheitseinbrüche möglich sind,<br />
berichtet [4]. Danach können SIM-Karten von beliebig<br />
entfernten Orten geklont werden. Immerhin bietet der<br />
Mobilfunk das technische Potenzial, CPS mit weltumspannenden<br />
Dimensionen zu bauen.<br />
8. PATENSCHAFT BLUETOOTH<br />
Von den Bluetooth-Konzepten lässt sich eine Menge lernen<br />
und übernehmen, allen voran die vier Betriebsmodi,<br />
was nicht heißt, dass die Ad-hoc-Kommunikation von<br />
CPS Bluetooth nutzen muss. Die Betriebsmodi sind in<br />
Tabelle 2 nachzulesen. Auch wenn die technischen Beschränkungen<br />
ihren Ursprung in technischer Effizienz<br />
haben, erhöhen sie das Sicherheitsniveau der Kommunikation.<br />
Die Komponenten befinden sich in einer Nachbarschaft,<br />
dem Piconet. Entfernte Kommunikationspartner<br />
können nicht zugelassen werden, nahe Kommunikationspartner<br />
sind in der Anzahl limitiert, ein Gerät, das<br />
seine Funktion einstellt, stellt die Kommunikation ein<br />
oder reduziert sie und damit die Angriffsfläche für<br />
Schadkomponenten auf kurze Intervalle.<br />
Obwohl Geräte ohne Eingabemöglichkeit (Headsets,<br />
Mäuse) meist mit der PIN 0000 in jedes Piconet aufgenommen<br />
werden – aus Sicherheitsbetrachtung unzulänglich,<br />
verfügt Bluetooth über mehr Sicherheitsmechanismen als<br />
WLAN nach IEEE 802.11b. So ist der Hauptschlüssel fest<br />
in der Hardware des Gerätes hinterlegt oder das Gerät verfügt<br />
über Eingabemöglichkeiten. Dieser Passkey wird nie<br />
über die Kommunikationsstrecke übertragen. Er wird<br />
dazu genutzt, einen Initialisierungsschlüssel zu erzeugen<br />
mit dem der Unit Key für die Sitzung erstellt wird, der<br />
nach Abbau der Sitzung wieder verworfen wird. Bei diesem<br />
handelt es sich um die Information, die zur Wiedererkennung<br />
des Kommunikationspartners gespeichert werden<br />
muss. Teilnehmer im Piconet ignorieren Nachrichten,<br />
die nicht über den richtigen Zugriffscode verfügen, der<br />
eine flexiblere Identifikation als eine reine Geräteadresse<br />
ermöglicht und außerdem eine Kennung des Piconets enthält,<br />
bei dem der Sender als Mitglied registriert ist.<br />
Neben den Konzepten lässt sich auch aus den Angriffen<br />
auf Implementierungsschwächen ein reichhaltiger<br />
50<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
Erfahrungsschatz ableiten. Bezeichnungen für solche<br />
Methoden sind unter anderem BlueJacking (das Senden<br />
unangeforderter Nachrichten, in Guerilla-Marketing-<br />
Kampagnen genutzt, normalerweise harmlos, kann aber<br />
für eine Fehlfunktion des Gerätes gehalten werden),<br />
BlueSnarfing (Zugang auf Kalender, Adressbuch, E-Mails<br />
und Textmitteilungen), BlueStumbling (Gerät lokalisieren<br />
und Nutzer auf der Grundlage ihrer Bluetooth-Geräte-Adressen<br />
identifizieren).<br />
9. KOMPOSITION À LA CARTE<br />
Wenn sich Komponenten zu einem CPS zusammenschließen,<br />
stellt sich die Frage, wie sich der Verbund in<br />
der Kommunikation nach außen verhält. Sofern er nach<br />
Extern kommuniziert, kann er sich offenbar wie eine<br />
einzige Komponente geben, die aus Subkomponenten<br />
besteht, was für den Kommunikationspartner möglicherweise<br />
transparent ist. Daraus ergeben sich neue Fragen<br />
zur Sicherheit. Angenommen, eine Subkomponente übt<br />
die Sprecherfunktion für den Verbund nach Extern aus,<br />
in dem sie einen Proxy (Stellvertreter für den Verbund)<br />
darstellt, der die Funktionen der Subkomponenten aggregiert.<br />
Da das Kompositionsverhalten kaskadierbar ist<br />
(ein CPS verhält sich nach Extern wie eine einzige Komponente,<br />
was im Verbund mit weiteren Komponenten zu<br />
einem komplexeren CPS führt), ist es angemessen, von<br />
Stufen als Detaillierungsgrad zu sprechen. Eine physische<br />
Komponente ist dann zum Beipiel ein CPS der Stufe<br />
0, der Verbund, den sie eingeht, ein CPS der Stufe 1,<br />
der Verbund dieses mit weiteren Komponenten oder<br />
Verbunden ein CPS der Stufe 2 und so weiter.<br />
Ein Proxy kann keine neue Identität darstellen, denn<br />
die darf nicht von der Komponente oder der Komposition<br />
dynamisch erzeugt werden. Das würde sonst einen Ansatz<br />
für Manipulation bieten. Identitätsnachweise müssen<br />
fest eingebrannt sein. Ebenso ist die Menge der Rollen und<br />
Funktionen des Proxy fest. Ein Proxy kann über seine<br />
Stellvertreter-Funktion hinaus auch eine gewöhnliche<br />
funktionale Komponente sein, und manchmal mangelt es<br />
einem vereinsamten Proxy an weiteren Subkomponenten<br />
und deren Funktionen. Die Vereinsamung ist einer von<br />
vielen denkbaren Betriebszuständen der Komposition, die<br />
der Proxy repräsentiert. Die nach außen deklarierten<br />
Funktionen lassen sich dann nicht ausführen. Eine Beschränkung<br />
des funktionalen Umfangs ist nicht sicherheitsrelevant,<br />
eine Erweiterung hingegen schon.<br />
Der Betriebszustand, das heißt die Betriebsfähigkeit<br />
eines CPS, ist eine Zustandsgröße, die von außen abfragbar<br />
sein muss. Die Frage ist, ob ein Proxy nur für Komponententypen<br />
agieren darf, deren funktionaler Umfang<br />
Roles<br />
Rights<br />
(Functions)<br />
1.1<br />
1.2<br />
1.3<br />
1.4<br />
1.5<br />
1.6<br />
2.1.1<br />
2.1.2<br />
2.2<br />
2.1.2.1<br />
2.1.2.2.1<br />
2.1.2.2.2<br />
2.3<br />
2.4<br />
Paired by human (pw entry both sides)<br />
Friends & family (pre installed certs)<br />
Trusted third party (manfacturer)<br />
Verified identity (email verified)<br />
Unverified identity (pseudonym)<br />
Anonymous (identity agnostic)<br />
List functions<br />
Execute function<br />
Administer Component<br />
File transfer<br />
Question Identity<br />
Question Location<br />
Allocate Interface<br />
Move/turn…<br />
TABELLE 1:<br />
Beispiele für festzulegende<br />
Rollen, Rechte und Funktionen.<br />
Eine vollständige Auflistung<br />
würde nahezu endlos werden.<br />
Active Mode<br />
Hold Mode<br />
Sniff Mode<br />
Park Mode<br />
maximal 7 Slaves sind gleichzeitig aktiv<br />
(Daten senden und empfangen)<br />
bis zu 250 Slaves können ohne Aktivität Teilnehmer<br />
im Netz sein<br />
für ein zwischen Master und Slave vereinbartes<br />
Invervall lauscht der Slave, ob er eine Meldung erhält,<br />
die ihn zu aktiver Kommunikation auffordert<br />
im Zustand geringsten Stromverbrauchs kann der<br />
Slave von einem Programm oder einem Master<br />
geweckt werden.<br />
TABELLE 2:<br />
Betriebsmodi von<br />
Bluetooth-Geräten.<br />
Ähnlich könnten die Modi<br />
von CPS-Komponenten<br />
hinsichtlich der<br />
Kommunikation aussehen.<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
51
HAUPTBEITRAG<br />
bei seiner eigenen Erstellung/Programmierung bereits<br />
vorgesehen war und ob es mehr als eine Proxykomponente<br />
im Verbund geben darf. Beide Eigenschaften bieten<br />
Angriffsmöglichkeiten für Manipulation des Gesamtverhaltens,<br />
mindestens im Sinne von Trojanern,<br />
und sollten konzeptionell ausgegrenzt werden.<br />
Was aber, wenn eine CPS-Komponente von Schadsoftware<br />
angegriffen wurde? Nach einem Konzept der<br />
Fraunhofer SIT [3] für mobile Geräte und dynamische<br />
Netze (Mobile Ad hoc Network, MANET) entscheiden<br />
die anderen Komponenten über die Vertrauenswürdigkeit<br />
und sind in der Lage, die befallene Komponente<br />
von der weiteren Kommunikation auszuschließen. Alternativ<br />
wäre eine menschliche Interaktion erforderlich,<br />
die aber nicht den Kommunikationskanal nutzen<br />
darf. Dieser ist ja potenziell unter der Kontrolle des<br />
Schadprogramms.<br />
REFERENZEN<br />
[1] Humpert-Vrielink, F.: Neue Herausforderungen für<br />
CISOs. 2013(3), Seite 56, 2013<br />
[2] Promotorengruppe Kommunikation der Forschungsunion<br />
Wirtschaft – Wissenschaft: Umsetzungsempfehlungen<br />
für das Zukunftsprojekt Industrie 4.0: Abschluss bericht<br />
des Arbeitskreises Industrie 4.0, April 2013, online:<br />
http://www.plattform-i40.de/sites/default/files/<br />
Abschlussbericht_Industrie4%200_barrierefrei.pdf<br />
[3] Rein, A.: TrustMANET - Development and Evaluation<br />
of a Trusted Mobile Ad-hoc Network, Technischen<br />
Hochschule Mittelhessen, Fraunhofer-Institut für<br />
Sichere Informationstechnologie (SIT), März 2012,<br />
http://sit.sit.fraunhofer.de/smv/publications/<br />
download/ArThesisFinal12.pdf<br />
[4] Biermann, K.: Millionen SIM-Karten sind nicht sicher.<br />
Zeit Online 21.07.2013, http://www.zeit.de/digital/<br />
mobil/2013-07/sim-karte-hack-nohl<br />
[5] Kunschert, S.: Unser Beitrag zur Sicherheitsbetrachtung<br />
bei Industrie 4.0, Sicherheit im Sinne von Security<br />
als erfolgskritischer Faktor. CONNECTED 2013(1)<br />
S. 6-BIS<br />
[6] Streib, J.: Industrie 4.0 erfordert sichere Identität.<br />
Markt und Technik 2013(28), S. 28-BIS, v. 12.7.2013<br />
[7] Winzenried, O.: Integritätsschutz für Embedded-Systeme.<br />
Elektronik industrial 2012(November), S. 28-BIS.<br />
http://www.elektroniknet.de/embedded/hardware/<br />
artikel/93004/<br />
[8] Reißmann, O., Lischka, K.: Bericht der Bundesregierung:<br />
Bomben gegen Cyber-Krieger. Spiegel online<br />
12. Oktober 2012: http://www.spiegel.de/netzwelt/<br />
netzpolitik/cyberkrieg-bomben-gegen-cyberkriegera-861002.html<br />
[9] Topf, J.: Authentifizierung bei temporärem Netzzugang<br />
– Einwahlbeschränkung. In: iX Magazin 10 (2000),<br />
S. 122. Heise Verlag 2000<br />
FAZIT<br />
Ad-hoc-Kommunikation ist die Büchse der Pandora für<br />
die Angriffssicherheit eines CPS, und die schwächste<br />
Stelle ist der Aufbau der Kommunikation, der noch dazu<br />
zeitaufwendig ist. Sichere Identitäten können nur durch<br />
fälschungssichere Identitätsnachweise erreicht werden<br />
und Technolgien wie TPM sollten vereinbart und durch<br />
Standards von den Komponentenanbietern eingefordert<br />
werden. Aber auch ohne Berücksichtigung der Sicherheitsproblematik<br />
ist der funktionale Mehrwert für CPS<br />
in Industrie 4.0 erst erreichbar, wenn die semantischen<br />
Fragen geklärt sind und die Komponenten verschiedener<br />
Hersteller und Baureihen in den gleichen Begriffen für<br />
Rollen, Rechte und vor allem Funktionen kommunizieren.<br />
Die Brisanz dieser Problematik liegt in der Erfordernis,<br />
dass sie auch für Komponenten gelöst sein muss, die<br />
erst später und von Dritten hergestellt werden. Technologisch<br />
bestehen viele Entwicklungen, auf die zurückgegriffen<br />
werden kann, was zu Diversität und damit zu<br />
Inkompatibilitäten führen wird. Hier ist Gremienarbeit<br />
zwecks Standardisierung und Normung erforderlich, um<br />
die Flexibilität von CPS zu ermöglichen und Industrie<br />
4.0 in breitem Ansatz zu implementieren.<br />
AUTOR<br />
Dr. WALTER SPETH (geb. 1959)<br />
ist Mitglied des Namur-<br />
Arbeitskreises „Automation<br />
Security“. Nach dem Studium<br />
der Physik mit abschließender<br />
Promotion auf dem Feld<br />
der Teilchenphysik folgten<br />
Tätigkeiten als Berater,<br />
Abteilungs leiter und Geschäftsführer<br />
in der IT-Branche mit Schwerpunkt<br />
Security und Biometrie. Derzeit ist er als Senior<br />
Project Manager für Bayer Technology Services<br />
tätig. Seine Aufgabenfelder sind: Produktschutz<br />
durch Track-und-Trace-Lösungen für die Pharma-<br />
Branche, Schwachstellenanalyse für industrielle<br />
Produktionsanlagen hinsichtlich Cyber-Angriffen<br />
und Software-Entwicklungsstrategien für sicheren<br />
Code.<br />
Bayer Technology Services GmbH,<br />
D-51368 Leverkusen,<br />
Tel. +49 (0) 214 304 94 57,<br />
E-Mail: walter.speth@bayer.com<br />
MANUSKRIPTEINGANG<br />
08.08.2013<br />
Im Peer-Review-Verfahren begutachtet<br />
52<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
Wissenschaftlich<br />
fundierte Beiträge zur<br />
Anlagensicherheit<br />
Safety in der Praxis<br />
Die Automatisierungstechnik wird durch neue Forschungen und Entwicklungen<br />
bestimmt. Damit Ingenieure fit für ihren Job sind und die aktuellen Trends in der<br />
Automatisierungstechnik schnell und praktisch zur Hand haben, hat die Zeitschrift<br />
„<strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische Praxis“ die Buchreihe „<strong>atp</strong> kompakt“<br />
etabliert. Daraus erscheint der mittlerweile sechste Band: „Safety in der Praxis“.<br />
Hrsg.: Leon Urbas<br />
1. Auflage 2014<br />
112 Seiten, farbig, Broschur<br />
ISBN: 978-3-8356-7115-7<br />
Preis: € 59,–<br />
www.di-verlag.de<br />
Das Buch erscheint im DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München<br />
Jetzt bestellen!<br />
WISSEN FÜR DIE<br />
ZUKUNFT<br />
Bestellung per Fax: +49 201 / 820 Deutscher 02-34 Industrieverlag oder GmbH abtrennen | Arnulfstr. und 124 im | Fensterumschlag 80636 München einsenden<br />
Ja, ich bestelle gegen Rechnung 3 Wochen zur Ansicht<br />
___Ex.<br />
Safety in der Praxis<br />
1. Auflage 2014 – ISBN: 978-3-8356-7115-7 für € 59,– (zzgl. Versand)<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 />
Vulkan-Verlag GmbH<br />
Versandbuchhandlung<br />
Postfach 10 39 62<br />
45039 Essen<br />
E-Mail<br />
Branche / Wirtschaftszweig<br />
Bevorzugte Zahlungsweise Bankabbuchung Rechnung<br />
Bank, Ort<br />
Widerrufsrecht: Sie können Ihre Vertragserklärung innerhalb von zwei Wochen ohne Angabe von Gründen in Textform (z.B.<br />
Brief, Fax, E-Mail) oder durch Rücksendung der Sache widerrufen. Die Frist beginnt nach Erhalt dieser Belehrung in Textform.<br />
Zur Wahrung der Widerrufsfrist genügt die rechtzeitige Absendung des Widerrufs oder der Sache an die Vulkan-Verlag GmbH,<br />
Versandbuchhandlung, Postfach 10 39 62, 45039 Essen.<br />
Bankleitzahl<br />
Ort, Datum, Unterschrift<br />
Kontonummer<br />
PAATP62013<br />
Nutzung personenbezogener Daten: Für die Auftragsabwicklung und zur Pflege der laufenden Kommunikation werden personenbezogene Daten erfasst und gespeichert. Mit dieser Anforderung erkläre ich mich damit einverstanden, dass ich<br />
vom DIV Deutscher Industrieverlag oder vom Vulkan-Verlag per Post, per Telefon, per Telefax, per E-Mail, nicht über interessante, fachspezifische Medien und Informationsangebote informiert und beworben werde.<br />
Diese Erklärung kann ich mit Wirkung für die Zukunft jederzeit widerrufen.
HAUPTBEITRAG<br />
Komponentenkapselung<br />
und -selbstbeschreibung<br />
Konzept und Anwendung in der Prozessautomation<br />
Die Kapselung heterogener Automatisierungskomponenten durch webbasierte Standards,<br />
wie Websockets nach dem RFC 6455-Standard, ermöglicht im Vergleich zu SOAP oder<br />
REST, Antwortzeiten signifikant zu verringern sowie bidirektionale ereignisbasierte Server-Client-Verbindungen<br />
aufzubauen. Eine zusätzliche XML-basierte Komponentenselbstbeschreibung<br />
eröffnet Potenziale, anwendungsspezifische Ablaufbeschreibungssprachen<br />
automatisiert zu generieren. Die Anwendung wird im Beitrag am Beispiel der Automatisierung<br />
biotechnologischer Prozesse demonstriert.<br />
SCHLAGWÖRTER Automatisierung / Komponentenintegration / Webtechnologien<br />
Component Encapsulation and Self-Description –<br />
Concept and Application in Process Automation<br />
The encapsulation of heterogeneous automation components using web-based techniques<br />
like web sockets in accordance with RFC 6455 promises significantly faster response times<br />
compared to SOAP or REST and bidirectional event-based server-client communication.<br />
An additional XML-based component self-description has a potential for automated generating<br />
of application specific languages. The use of the concept is demonstrated using<br />
an example for the automation of biotechnological processes.<br />
KEYWORDS automation / component integration / web technologies<br />
54<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
WERNER HERFS, WOLFRAM LOHSE, DENIS ÖZDEMIR, ADAM MALIK, RWTH Aachen University<br />
Die Anbindung von Automatisierungskomponenten<br />
an übergeordnete Leitsysteme erfolgt durch<br />
eine weitgehend manuelle Implementierung einer<br />
Kapselungsschicht. Eine weitere Möglichkeit<br />
ist die Selbstbeschreibung von Automatisierungskomponenten,<br />
die der teilautomatisierten Anbindung<br />
dient. In beiden Fällen ist eine Kommunikationstechnologie<br />
für den Datenaustausch notwendig. Im zweiten Fall<br />
müssen zusätzlich Komponenten <strong>mittels</strong> einer geeigneten<br />
Sprache beschrieben werden. Als Kommunikationstechnologie<br />
kann OPC UA verwendet werden [1]. Komponenteneigenschaften<br />
werden mit Sprachen, wie Electronic Device<br />
Description Language (EDDL) beschrieben. Diese zielen<br />
primär auf die Diagnose und die Kalibrierung von<br />
Geräten ab. Der Einsatz von OPC UA setzt voraus, dass der<br />
OPC-UA-Server vom Komponentenhersteller angeboten<br />
wird. Insbesondere kleinere Hersteller von Automatisierungskomponenten,<br />
Hersteller spezialisierter Geräte, wie<br />
Komponenten für biologische Labore, bieten oft keine OPC-<br />
UA-Server für ihre Produkte an. In diesen Fällen kann<br />
entweder auf vorhandene Werkzeuge zur Entwicklung von<br />
OPC-UA-Servern oder auf andere Möglichkeiten des netzwerkbasierten<br />
Zugriffs auf Automatisierungskomponenten,<br />
wie auf Webservices, zurückgegriffen werden.<br />
Im Bereich speicherprogrammierbarer Steuerungen<br />
gibt es bereits Lösungen, die den HTTP-basierten Zugriff<br />
auf interne Variablen einer Steuerung gestatten, wie zum<br />
Beispiel Beckhoff ADS-HTTP. Die Nutzung dieser Technologien<br />
hat den Nachteil eines hohen Kommunikations-<br />
Overheads und dadurch verhältnismäßig langsamer<br />
Antwortzeiten. Zudem sind die aufgebauten Verbindungen<br />
unidirektional, sodass sich eine ereignisbasierte<br />
Kommunikation zwischen dem Server und dem Client<br />
nur unter Nutzung technischer Umwege verwirklichen<br />
lässt [2]. Diese beiden Nachteile können durch die Nutzung<br />
von HTML5-Websockets nach dem RFC 6455-Standard<br />
umgangen werden [3]. Websockets eignen sich dabei<br />
für die Anbindung von Automatisierungskomponenten<br />
an Leitsysteme, falls die Entwicklung von OPC-UA-Servern<br />
nicht in Frage kommt, und Webservices aufgrund<br />
ihres zeitlichen Verhaltens ungeeignet sind.<br />
1. WEBSOCKETS NACH RFC 6455<br />
Mit Websockets wurde ein Standard für die bidirektionale<br />
Kommunikation im World Wide Web festgelegt. Ziel<br />
war es, die Echtzeitkommunikation in die wachsende<br />
Zahl von Webanwendungen zu integrieren. Echtzeitkommunikation<br />
bedeutet zunächst, dass eine Client-Server-<br />
Verbindung ermöglicht wird, bei der der Server und der<br />
Client ohne Aufforderung eine Nachricht an das Gegenüber<br />
versenden können. Dadurch werden der Client und<br />
der Server befähigt, Meldungen über auftretende Ereignisse<br />
sofort zu versenden. Diese Meldungen werden auch<br />
als Push-Nachrichten bezeichnet. Zusammen mit einer<br />
Reduzierung der Größe versendeter Nachrichtenpakete<br />
verringert sich so deutlich die Latenz zwischen dem<br />
Auftreten eines Ereignisses und der Benachrichtigung<br />
über dieses Ereignis, abhängig von der Geschwindigkeit<br />
der Netzwerkverbindung. Die Verringerung dieser Latenz<br />
macht die Anwendung von Websockets in der Automatisierung<br />
von Produktionsanlagen interessant.<br />
Die bidirektionale Kommunikation im World Wide<br />
Web wurde bisher auf Umwegen durch Verfahren wie<br />
Polling und Long Polling erreicht. Beide versuchen den<br />
Nachteil von HTTP, die Halbduplex-Kommunikation, zu<br />
umgehen. Im ersten Fall wird der Server in einem bestimmten<br />
Intervall vom Client gefragt, ob neue Information<br />
vorliegt. Im zweiten Fall wird eine aufgebaute HTTP-<br />
Verbindung erst nach der Übermittlung neuer Daten<br />
durch den Server an den Client geschlossen. Danach<br />
muss der Client erneut eine Verbindung aufbauen und<br />
auf Nachrichten des Servers warten. In beiden Fällen<br />
werden viele Protokollverwaltungsdaten erzeugt. HTTP<br />
Request/Response Header können einige hundert Byte<br />
lang sein. Zusätzlich muss noch das I/O-Handling vom<br />
Server durchgeführt werden. Beim Polling werden zudem<br />
unnötige Nachrichten über die Nichtänderung des<br />
Zustands des Servers an den Client gesendet. Die mangelnde<br />
Leistungsfähigkeit dieser Methoden verhinderte<br />
die Entwicklung von Webanwendungen, die auf schnelle<br />
Echtzeitkommunikation angewiesen sind, wie kollaborative<br />
Websites. Die genannten Nachteile verursachen<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
55
HAUPTBEITRAG<br />
zudem auf mobilen Geräten wegen des häufigen Verbindungsaufbaus<br />
und größeren Datenaufkommens einen<br />
erhöhten Energieverbrauch. Abhilfe leisten an dieser<br />
Stelle Websockets.<br />
Websockets ermöglichen eine Vollduplex-Kommunikation<br />
über eine TCP-Verbindung mit wenig Overhead<br />
(2 Byte pro Nachricht). Der Aufbau der Verbindung zwischen<br />
dem Client und dem Server beginnt mit einem<br />
Websocket-Handshake. Hierbei stellt der Client über das<br />
HTTP-Protokoll eine Anfrage an den Server. Nach erfolgreichem<br />
Verbindungsaufbau wird auf das Websocket-<br />
Protokoll umgeschaltet. Dabei zeigt sich eine wichtige<br />
Eigenschaft von Websockets: Die bidirektionale Verbindung<br />
über Websockets kann unter Nutzung des gleichen<br />
Ports wie bei HTTP-Verbindungen arbeiten.<br />
1.1 Websockets in der Automatisierungstechnik<br />
Die klassische Einteilung der Kommunikation innerhalb<br />
produzierender Unternehmen nach der ISO TR 10314<br />
sieht fünf Ebenen vor, die ein hierarchisches Paradigma<br />
für die Entwicklung von Automatisierungslösungen vorgeben<br />
[4]. Die klassische Einteilung in Ebenen wurde<br />
unter anderem durch unterschiedliche Anforderungen<br />
an die Kommunikation bezüglich Datendurchsatz und<br />
Reaktionszeit vorgenommen. Im Zuge der Entwicklung<br />
neuer ethernetbasierter Bussysteme, die die Anforderungen<br />
an die kurze Reaktionszeit und an die Datenübertragungsrate<br />
erfüllen, löst sich die Einteilung der Automatisierungsebenen<br />
aber, sodass flacher hierarchisierte<br />
Steuerungsarchitekturen realisiert werden können. Hierzu<br />
werden Protokolle benötigt, die sich in breiteren Bereichen<br />
einsetzen lassen.<br />
Die Verwendung von Websockets zur Kapselung von<br />
Automatisierungskomponenten, die über ethernetbasierte<br />
Netzwerke kommunizieren, bietet zunächst den Vorteil,<br />
dass eine Webtechnologie genutzt werden kann, deren<br />
Konzept von Anfang an auf die Kommunikation über das<br />
Internet ausgelegt war. Im Zuge der Entwicklungen der<br />
Industrie 4.0 wird so ermöglicht, die Internettechnologien<br />
und die Automatisierungstechnik stärker zu verflechten.<br />
Da der Websocket-Standard inzwischen von vielen Webbrowsern<br />
unterstützt wird (Google Chrome, Safari, Opera<br />
ab Version 10.70, Mozilla Firefox ab Version 4.0, Internet<br />
Explorer ab Version 10.0), können Automatisierungskomponenten<br />
prinzipiell auch durch eine HTML5-basierte<br />
Nutzerschnittstelle bedient und angesteuert werden.<br />
2. KAPSELUNGSKONZEPT<br />
Die Kommunikation mit heterogenen Automatisierungskomponenten<br />
unterschiedlicher Hersteller erfordert ein<br />
Konzept für eine einheitliche Schnittstelle, welche die<br />
einzelnen Komponenten kapselt und damit für das übergeordnete<br />
Leitsystem einheitliche Zugriffsmethoden anbietet.<br />
Das vorgestellte Konzept nutzt Websockets für die<br />
Kommunikation und verbindet Automatisierungskomponenten<br />
über ein Protokoll, das gleichzeitig für die bidirektionale<br />
Kommunikation im Internet verwendet wird.<br />
2.1 Synchrone und asynchrone Aktionen<br />
Heterogene Komponenten in der Automatisierungstechnik<br />
umfassen speicherprogrammierbare Steuerungen<br />
unterschiedlicher Hersteller und Embedded Boards mit<br />
eigener Steuerungslogik oder Software, die zum Beispiel<br />
für die Durchführung bestimmter Prozesse zuständig ist<br />
und die Ergebnisse an ein übergeordnetes Leitsystem<br />
übermittelt. In allen genannten Fällen werden Teil-Prozessschritte,<br />
Aktionen genannt, ausgeführt. Die Ausführung<br />
einer Aktion kann dabei aus einem atomaren oder<br />
mehreren zusammengesetzten Schritten bestehen. Eine<br />
weitere Unterscheidung betrifft die Dauer der Aktion.<br />
Aktionen von kurzer Dauer lassen sich meist synchron<br />
aufrufen. In diesem Fall wartet das übergeordnete Leitsystem<br />
so lange mit der Ausführung nachfolgender Anweisungen,<br />
bis die synchrone Aktion erfolgreich abgelaufen<br />
ist. Länger andauernde Aktionen mit unbekannter<br />
Dauer erfordern eine asynchrone Ausführung. In diesem<br />
Fall wird der Ablauf in einem übergeordneten Leitsystem<br />
nicht blockiert und nachfolgende Aktionen können parallel<br />
gestartet werden. Das übergeordnete Leitsystem<br />
wird über die erfolgte Ausführung der asynchronen Aktion<br />
benachrichtigt. Das Kapselungskonzept unterstützt<br />
die synchrone und asynchrone Ausführung von Aktionen.<br />
Das erfordert zunächst den Aufbau einer Kommunikationsschicht.<br />
2.2 Kommunikationsschicht<br />
Das Konzept für die Kommunikationsschicht implementiert<br />
ein Remote-Procedure-Call-Protokoll und baut dabei<br />
auf einer zunächst beliebigen bidirektionalen Transportschicht<br />
auf, die für die Übertragung der Daten verantwortlich<br />
ist. Das Konzept sieht eine beliebige Austauschbarkeit<br />
dieser Schicht unter der Bedingung vor,<br />
dass eine bidirektionale Kommunikation ermöglicht<br />
wird. Zusätzlich muss die Transportschicht das Senden<br />
von Daten als String oder Byte-Array und die Übergabe<br />
dieser Daten an eine Methode bereitstellen. So sind<br />
Websockets, reine TCP/IP-Verbindungen oder auch direkte<br />
Verknüpfungen über Ereignisse, als Transportschicht<br />
denkbar. Im letzten Fall kann die Kommunikation<br />
vollständig in einer Bibliothek gekapselt werden.<br />
Unidirektionale Protokolle, wie Webservices, können in<br />
Kombination mit einem Polling-Algorithmus ebenso als<br />
Transportschicht genutzt werden, was jedoch aufgrund<br />
des Aufwands nur die Ausnahme ist.<br />
Senden von Nachrichten<br />
Die Ausführung von Aktionen auf einer gekapselten<br />
Komponente und das Empfangen von Rückmeldungen<br />
erfordern die Umsetzung von Aufrufen in Nachrichtenobjekte,<br />
die in ein für die Transportschicht passendes<br />
Format (Text oder Binärdaten) serialisiert werden. Das<br />
Konzept sieht Nachrichtenobjekte bestehend aus einer<br />
ID, einem Adressfeld und einer beliebigen Anzahl von<br />
benannten Parametern vor. Die ID identifiziert eindeutig<br />
eine Nachricht während der Verarbeitung. Das Adressfeld<br />
beinhaltet den Namen der aufzurufenden Aktion<br />
56<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
eziehungsweise die ID der Nachricht, die beantwortet<br />
wird. Parameter werden jeweils als ein assoziatives Feld<br />
von String-Objekt-Paaren versendet und hängen vom<br />
Kontext der jeweiligen aufzurufenden Aktion und ihren<br />
Parametern ab.<br />
Für das Senden von Nachrichten werden zwei Methoden<br />
bereitgestellt. Die erste serialisiert lediglich die übergebene<br />
Nachricht und versendet sie anschließend über<br />
die unterliegende Transportschicht. Die zweite Methode<br />
synchronisiert zudem die sonst asynchrone Kommunikation,<br />
indem der Methodenaufruf nach dem Senden bis<br />
zum Eintreffen einer Antwortnachricht blockiert wird.<br />
Synchrone Aufrufe können insbesondere bei sequenziellen<br />
Aufrufen von Aktionen in einer festgelegten Reihenfolge<br />
sinnvoll sein, wenn die Aktion gleiche Anlagenkomponenten<br />
nutzt.<br />
Empfangen von Nachrichten<br />
Bei der Verarbeitung empfangener Nachrichten werden<br />
drei Fälle unterschieden. Im Fall einer Nachricht, die<br />
die Ausführung einer Aktion bewirken soll, wird eine<br />
zuvor registrierte Funktion aufgerufen. Bei der Registrierung<br />
werden dabei Aktionsnamen mit lokalen Funktionen<br />
verknüpft, die Nachrichtenobjekte als Parameter<br />
entgegennehmen. Nachrichten, die ab diesem Zeitpunkt<br />
den zuvor verknüpften Aktionsnamen als Adresse angeben,<br />
werden an die entsprechende lokale Funktion<br />
übergeben. Im Fall einer Antwortnachricht wird eine<br />
zuvor beim Senden angegebene Callback-Funktion aufgerufen.<br />
Der letzte Fall betrifft Nachrichten, für die keine<br />
zuständige Aktion ermittelt werden kann, da keine<br />
Callback- und keine öffentliche Funktion registriert<br />
wurden. In diesen Fällen wird eine Fehlernachricht<br />
übermittelt.<br />
Sicherheit<br />
Der Aufbau von Websocket-Verbindungen kann über normale<br />
HTTP- oder geschützte HTTPS-Verbindungen erfolgen.<br />
Eine zertifikatsbasierte Authentifizierung und Verschlüsselung<br />
über Transport Layer Security (TLS) wird<br />
im Fall von HTTPS angeboten. Daten können somit sicher<br />
über Websocket-Verbindungen transportiert werden.<br />
Aktionsnamen, einen Text zur Erläuterung der Aktion,<br />
eine Liste von Parameterbeschreibungen, eine Angabe<br />
zu der voraussichtlichen Dauer der Aktionsausführung<br />
sowie einige Flags mit Metainformationen, die je nach<br />
Einsatzfall zusätzliche prozessspezifische Informationen<br />
enthalten können. Letztere kann zum Beispiel die<br />
Information über die Möglichkeit der erneuten Ausführung<br />
einer Aktion nach einer Not-Aus-Unterbrechung<br />
sein. Parameterbeschreibungen können den Namen,<br />
den Parametertyp, einen Beschreibungstext und die<br />
Information, ob der Parameter optional ist, enthalten.<br />
Ebenso können Default-Werte, zulässige Wertebereiche<br />
sowie eine Schrittweite möglicher Werte angegeben<br />
werden. Wertebereiche von String-Parametern werden<br />
über reguläre Ausdrücke oder spezielle, vordefinierte<br />
Klassen eingegrenzt.<br />
Zwischenschichten<br />
Beim Aufrufen von Aktionen einer Automatisierungskomponente<br />
kann Information aus externen Quellen<br />
notwendig sein. Ein Beispiel ist der Materialfluss in einer<br />
Produktionsanlage, wo die örtlichen Koordinaten einzelner<br />
Werkstücke in einer Datenbank gespeichert werden.<br />
Der Aufruf der Transportaktion der zuständigen<br />
Automatisierungskomponente muss in diesem Fall mit<br />
aktuellen Koordinaten des zu transportierenden Werkstücks<br />
erfolgen. Für solche Fälle wurde ein Konzept für<br />
beliebig viele Zwischenschichten entwickelt, die einen<br />
Aufruf und seine Parameter transparent manipulieren<br />
können, siehe Bild 1.<br />
Die Zwischenschichten lassen sich auch nutzen, um<br />
die Aufrufe zu protokollieren. Eine weitere Anwendungsmöglichkeit<br />
ist das Manipulieren der Aktionsbeschreibung<br />
einer Automatisierungskomponente. Ein<br />
solcher Schritt kann zum Beispiel nötig sein, wenn<br />
Aktionen mit vielen vorhandenen, jedoch in der aktuellen<br />
Anwendungsdomäne nicht benötigten Parame-<br />
2.3 Komponentenselbstbeschreibung<br />
Die Transportschicht bietet bereits eine bidirektionale<br />
Kommunikation für Nachrichten in Form von Strings<br />
und Byte-Arrays an. Allerdings definiert die Transportschicht<br />
nicht, welche Aktionen einzelne Automatisierungskomponenten<br />
offerieren und wie diese sich aufrufen<br />
lassen. Das vorgestellte Konzept ermöglicht die<br />
Identifikation einzelner Komponenten und ihrer möglichen<br />
Aktionen zur Laufzeit bis hin zum Aufbau einer<br />
anwendungsspezifischen Sprache für die Komponentenansteuerung.<br />
Aktionsbeschreibung<br />
Eine Aktionsbeschreibung besteht aus Daten und Metadaten,<br />
die die Schnittstelle einer Automatisierungskomponente<br />
vollständig definieren. Sie umfasst den<br />
BILD 1: Server-Client-Kommunikation über Zwischenschichten<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
57
HAUPTBEITRAG<br />
tern, verwendet werden sollen. In diesem Fall kann eine<br />
reduzierte, an die Anwendungsdomäne angepasste Aktionsbeschreibung,<br />
realisiert werden. Der Aufruf der<br />
entsprechenden Aktion kann dann durch die Zwischenschicht<br />
transparent mit zusätzlichen Parametern<br />
erweitert werden.<br />
Die Zwischenschichten müssen zuvor im Client registriert<br />
werden. Sie werden während der Kommunikation<br />
in der Reihenfolge ihrer Registrierung aufgerufen. Die<br />
registrierten Zwischenschichten müssen ihre Manipulationen<br />
auf die jeweils aktuellen Aktionsmengen aus<br />
vorher ausgeführten Zwischenschichten beziehen, da<br />
diese bereits dort verändert werden können.<br />
2.4 Anwendungsspezifische Sprache<br />
Die Programmierung von Abläufen auf Basis von Aktionen<br />
einzelner gekapselter Automatisierungskomponenten<br />
wird durch die Nutzung des vorgeschlagenen Selbstbeschreibungskonzepts<br />
unterstützt. Die Selbstbeschreibung<br />
von Komponenten enthält bereits die notwendige<br />
Information über die aufrufbaren Aktionen sowie ihre<br />
Parameter. Diese Information kann zum Aufbau einer<br />
XML-basierten Sprache verwendet werden, deren Elemente<br />
aus komponentenspezifischen Befehlen bestehen.<br />
Ablaufprotokolle<br />
Das Konzept der anwendungsspezifischen Sprache (application<br />
specific language, ASL) für die Ablaufprotokolle<br />
sieht die automatische Generierung von XML-Schemadateien<br />
vor, die später die Struktur vorgeben. Bild 2 zeigt<br />
den Prozess der Schemagenerierung. Dabei werden statische<br />
XSD-Schemata mit dynamischen Inhalten ergänzt.<br />
Sämtliche gekapselten Komponenten einer Automatisierungsanlage<br />
stellen XML-basierte Aktionsbeschreibungen<br />
bereit (siehe 2.3). Zusammen mit statischen XSD-<br />
Schema-Templates, die unter anderem vordefinierte Kontrollstrukturen<br />
für die Modellierung von Ablaufprotokollen<br />
enthalten, werden durch Ergänzung um<br />
dynamische Inhalte (vorhandene Komponenten-Aktionsbeschreibungen)<br />
XSD-Schemata generiert. Die XSD-Schemata<br />
können später in einem XML-Editor bei der manuellen<br />
Definition von XML-Ablaufprotokollen die Struktur<br />
und den möglichen Inhalt eines Protokolls vorgeben. Die<br />
Schema-Generierung besteht aus drei Schritten. Im ersten<br />
Schritt wird ein XML-Schema mit XML-Datentypen erzeugt.<br />
Diese domänenspezifischen Datentypen können<br />
zuvor in einem XSD-Template vorgegeben werden. Denkbar<br />
sind hier Begriffe, die zum Beispiel fachspezifisch<br />
Werkstücke beschreiben. Im zweiten Schritt wird auf<br />
Basis der registrierten Anlagenkomponenten und ihrer<br />
verfügbaren Aktionen jeweils eine Schema-Datei generiert.<br />
Hierbei wird aus jedem Modulnamen und einem<br />
vorgegebenen Präfix ein Name für einen XML-Namensraum<br />
erzeugt. Dieser Namensraum wird mit Elementen<br />
vervollständigt, die aus den Aktionsbeschreibungen der<br />
Anlagenkomponenten stammen. Dabei werden Argumente<br />
einer Aktion zu Attributen eines Elements. Im letzten<br />
Schritt wird eine zentrale XSD-Schemadatei unter Einbindung<br />
der zuvor erstellten Schemata generiert, die die<br />
Syntax des künftigen XML-Protokolldokuments enthält.<br />
3. ANWENDUNGSBEISPIEL BIOLOGISCHE ZELLPRODUKTE<br />
Das Kapselungskonzept wurde am Beispiel der individualisierten<br />
Herstellung biologischer Zellprodukte in<br />
dem Projekt StemCellFactory [5, 6] umgesetzt. Hierzu<br />
wurden Komponenten einer automatisierten Anlage, siehe<br />
Bild 3, zur Kultivierung von induzierten pluripotenten<br />
Stammzellen (iPS-Zellen) an ein übergeordnetes<br />
Leitsystem angebunden.<br />
Das am Werkzeugmaschinenlabor der RWTH Aachen<br />
University entwickelte Leitsystem unterstützt die Herstellung<br />
individualisierter Zellprodukte, sodass jede Zellprobe<br />
nach einem individuellen biologischen Protokoll<br />
durch die einzelnen Komponenten der Automatisierungsanlage<br />
wandern kann. Die zuvor beschriebene anwendungsspezifische<br />
Sprache vereinfacht in diesem Fall die<br />
Formalisierung biologischer Ablaufbeschreibungen.<br />
3.1 iPS-Zellen<br />
Induzierte pluripotente Stammzellen [7, 8] sind Stammzellen,<br />
die durch die künstliche Reprogrammierung von<br />
Körperzellen entstehen. Die Möglichkeit der Herstellung<br />
von iPS-Zellen eröffnet neue Potenziale für die Medizin.<br />
Insbesondere im Bereich der Medikamentenherstellung<br />
können so Präparate mit Hilfe patienteneigener Zellen<br />
getestet werden. Im Gegensatz zu embryonalen Stammzellen,<br />
deren Gewinnung ethisch problematisch ist, können<br />
iPS-Zellen aus Haut- und Knochenmarkszellen gewonnen<br />
werden. Bisher wurden iPS-Zellen mit hohem<br />
manuellen Aufwand im Labor gezüchtet. Die Automatisierung<br />
dieser Züchtung senkt die Herstellungskosten<br />
signifikant und ermöglicht so in Zukunft mehr Menschen<br />
den Zugang zu neuen Heilungsmethoden.<br />
3.2 Automatisierungsanlage<br />
Die Anlage zur automatisierten Herstellung von iPS-Zellen<br />
besteht aus heterogenen Laborkomponenten, die jeweils<br />
durch unterschiedliche Schnittstellen nach proprietären<br />
Protokollen angesteuert werden, siehe Bild 4.<br />
Einzelne Anlagenkomponenten (Materialschleuse,<br />
Decapper (Öffnen von Zentrifugenröhrchen), Inkubator,<br />
Barcode-Scanner, Greifer, Linearachse, Zentrifuge und<br />
Schüttler) wurden über den Ethercat-Feldbus beziehungsweise<br />
Ethercat-Feldbusklemmen (RS232, DeviceNet) an<br />
einen Beckhoff Industrie-PC mit integrierter SPS angebunden.<br />
Dieser Industrie-PC (Microsoft Windows 7) wurde<br />
mit einem .NET-basierten Websocket-Server ausgestattet.<br />
Der Pipettierroboter (Liquid Handling Unit) verfügt<br />
über eine Steuerung auf Basis eines Embedded Boards.<br />
An dieser Stelle wurde ein javabasierter Websocket-Server<br />
verwendet. Weitere Komponenten (Messtechnik) werden<br />
über die Software LabView angesteuert. Von LabView bereitgestellte<br />
Webservices werden durch eine lokale Trans-<br />
58<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
BILD 2: Generierung der anwendungsspezifischen<br />
Sprache für die Ablaufprotokolle<br />
BILD 4: Steuerungstechnische Architektur<br />
der automatisierten Anlage<br />
BILD 3: Komponenten einer Anlage<br />
zur Herstellung von iPS-Zellen<br />
BILD 5: Exemplarische Modellierung von biologischen<br />
Ablaufprotokollen mit einer ASL<br />
portschicht gekapselt. Sämtliche Komponenten verfügen<br />
über eine Selbstbeschreibung der verfügbaren Aktionen.<br />
3.3 Generierte anwendungsspezifische Sprache<br />
Die generierte anwendungsspezifische Sprache ermöglicht<br />
die Modellierung von biologischen Ablaufprotokollen<br />
in einem XML-Editor, hier Microsoft Visual Studio,<br />
siehe Bild 5, wobei die Autovervollständigungsfunktion<br />
auf Basis des zuvor generierten XSD-Schemas mögliche<br />
Aktionen und notwendige Parameter vorschlägt. Die anwendungsspezifische<br />
Sprache ist gezielt auf die biologische<br />
Domäne ausgelegt und berücksichtigt die verfügbaren<br />
Aktionen einzelner Anlagenkomponenten, wie die<br />
Transportaktionen. In der automatisierten Anlage werden<br />
Zellproben in Transportgefäßen, wie Microtiterplatten<br />
(MTP) und Zentrifugenröhrchen (Tube), mit Hilfe<br />
eines Roboters durch die automatisierte Anlage transportiert.<br />
Jedes Transportgefäß trägt einen Barcode.<br />
Ein Roboter kann Transportgefäße in bestimmte Anlagenstationen,<br />
wie den Inkubator einstellen (putMaterial)<br />
oder aus diesem entnehmen (takeMaterial). Weiterhin können<br />
Transportgefäße geöffnet (openMTP, openTube), verschlossen<br />
(closeMTP, closeTube) oder entsorgt (trashMaterial)<br />
werden. Ebenso können Barcodes einzelner Zellproben<br />
gelesen werden (ScanBarcode). Das vorgestellte<br />
Konzept der Zwischenschichten ermöglicht die Erstellung<br />
von Protokollen mit individuell benannten Transportgefäßen<br />
(hier myMTP), wobei die örtlichen Koordinaten für<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013<br />
59
HAUPTBEITRAG<br />
die Transportaktion nach dem Aktionsaufruf datenbankbasiert<br />
in einer Zwischenschicht ergänzt werden.<br />
ZUSAMMENFASSUNG UND AUSBLICK<br />
Ein Konzept für die Kapselung von Automatisierungskomponenten<br />
auf Basis bidirektionaler Websocket-Kommunikation<br />
wurde in diesem Beitrag vorgestellt. Eine<br />
zusätzliche Komponentenselbstbeschreibung wird für<br />
die Generierung einer anwendungsspezifischen Sprache<br />
auf XML-Basis verwendet, die die Modellierung von Ablaufprotokollen<br />
ermöglicht. Das vorgestellte Konzept<br />
wurde an einer automatisierten Anlage zur Herstellung<br />
induzierter pluripotenter Stammzellen angewendet.<br />
Es erfordert einen initialen Aufwand für die manuelle<br />
Implementierung der Client-Server-Struktur, der<br />
Komponentenselbstbeschreibung und der ausführbaren<br />
Aktionen sowie der auftretenden Ereignisse. Die Implementierung<br />
folgt jedoch in weiten Teilen einem Muster<br />
und kann generativ ablaufen. Die Erstellung eines formalen<br />
Schnittstellenmodells für die Kapselung der<br />
Server-Client-Kommunikation ist geeignet, um gleichzeitig<br />
als bindende Spezifikation für weitere Implementierungen<br />
zu dienen.<br />
REFERENZEN<br />
MANUSKRIPTEINGANG<br />
13.08.2013<br />
Im Peer-Review-Verfahren begutachtet<br />
[1] Mahnke, W., Leitner, S.-H., Damm, M.: OPC Unified<br />
Architecture, Springer Verlag, Berlin Heidelberg 2009<br />
[2] Crane, D., McCarthy, P.: Comet and Reverse Ajax:<br />
The Next-Generation Ajax 2.0, Apress, Berkeley<br />
California 2009<br />
[3] Wang, V., Salim, F., Moskovits, P.: The Definitive Guide<br />
to HTML5 WebSocket: Build Real-Time Applications<br />
with HTML5, Apress, New York 2013<br />
[4] Weck, M., Brecher, C.: Werkzeugmaschinen: Automatisierung<br />
von Maschinen und Anlagen, Springer<br />
Verlag, Berlin Heidelberg 2006<br />
[5] Marx, U., Schenk, F., Behrens, J., Meyr, U., Wanek, P.,<br />
Zang, W., Schmitt, R., Brüstle, O., Zenke, M., Klocke, F.:<br />
Auto matic Production of Induced Pluripotent Stem<br />
Cells, Procedia CIRP 5 (2013), S. 2-6.<br />
[6] Bio.NRW Ziel2 Wettbewerb 2009: StemCellFactory,<br />
http://www.stemcellfactory.de<br />
[7] Takahashi, K., Tanabe, K., Ohnuki, M., Narita, M.,<br />
Ichisaka, T., Tomoda, K., Yamanaka, S.: Induction of<br />
pluripotent stem cells from adult human fibroblasts<br />
by defined factors, Cell 131 (2007), H. 5, S. 861–872.<br />
[8] Yum J , Vodyanik, M.A., Smuga-Otto, K., Antosiewicz-<br />
Bourget, J., Frane, J.L., Tian, S., Nie, J., Jonsdottier,<br />
G.A., Ruotti, V., Stewart, R., Sluvkin, I.I., Thomson, J.A.:<br />
Induced pluripotent stem cell lines derived from human<br />
somatic cells, Science 318 (2007), Nr. 5858, S. 1917–1920.<br />
AUTOREN<br />
Dr.-Ing. WERNER HERFS, MBA (geb. 1975) hat<br />
zwischen 2007 und 2012 die Abteilung Steuerungstechnik<br />
und Automatisierung geleitet und ist<br />
seit März 2012 geschäftsführender Oberingenieur<br />
und akademischer Rat des Lehrstuhls für Werkzeugmaschinen<br />
an der RWTH Aachen University.<br />
RWTH Aachen University,<br />
Werkzeugmaschinenlabor (WZL),<br />
Steinbachstr. 19, D-52074 Aachen,<br />
Tel. +49 (0) 241 802 74 10,<br />
E-Mail: w.herfs@wzl.rwth-aachen.de<br />
Dipl.-Ing. WOLFRAM LOHSE (geb. 1981) war von<br />
2007 bis 2012 als wissenschaftlicher Mitarbeiter am<br />
Lehrstuhl für Werkzeugmaschinen der RWTH<br />
Aachen University tätig. Seit März 2012 leitet er die<br />
Abteilung Steueurungstechnik und Automatisierung.<br />
RWTH Aachen University,<br />
Werkzeugmaschinenlabor (WZL),<br />
Steinbachstr. 19, D-52074 Aachen,<br />
Tel. +49 (0) 241 802 74 55,<br />
E-Mail: w.lohse@wzl.rwth-aachen.de<br />
Dipl.-Ing. DENIS ÖZDEMIR (geb. 1984) war seit<br />
2009 wissenschaftlicher Mitarbeiter am Lehrstuhl<br />
für Werkzeugmaschinen der RWTH Aachen<br />
University. Seit 2012 leitet er die Gruppe Informationstechnik<br />
und -management in der Abteilung<br />
Steuerungstechnik und Automatisierung. Seine<br />
Hauptarbeitsgebiete umfassen Verhaltenssimulation<br />
und Produktdatenmanagement.<br />
RWTH Aachen University,<br />
Werkzeugmaschinenlabor (WZL),<br />
Steinbachstr. 19, D-52074 Aachen,<br />
Tel. +49 (0) 241 802 74 58,<br />
E-Mail: d.oezdemir@wzl.rwth-aachen.de<br />
Dipl.-Inform. ADAM MALIK (geb. 1976) arbeitet<br />
seit 2010 als wissenschaftlicher Mitarbeiter in<br />
der Gruppe Informationstechnik und -management<br />
am Lehrstuhl für Werkzeugmaschinen der<br />
RWTH Aachen University in der Abteilung<br />
Steuerungstechnik und Automatisierung. Seine<br />
Hauptarbeitsgebiete umfassen Fertigungsleitsysteme<br />
und modellbasierte Softwareentwicklung.<br />
RWTH Aachen University,<br />
Werkzeugmaschinenlabor (WZL),<br />
Steinbachstr. 19, D-52074 Aachen,<br />
Tel. +49 (0) 241 802 74 56,<br />
E-Mail: a.malik@wzl.rwth-aachen.de<br />
60<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
Process Control<br />
Systems Engineering<br />
Process Control Systems (PCS) are distributed control systems (DCS) that<br />
are specialized to meet specific requirements of the process industries. The<br />
text book focuses on PCS engineering basics that are common to different<br />
domains of the process industries. It relates to an experimental research<br />
plant which serves for the exploration of the interaction between process<br />
modularization and process automation methods. This permits to capture<br />
features of highly specialized and integrated mono-product plants as well<br />
as application areas which are dominated by locally standardized generalpurpose<br />
apparatus and multi-product schemes. While the text book’s theory<br />
is applicable for all PCS of different suppliers, the examples refer to<br />
Siemens’ control system PCS 7. Focusing on a single PCS enables readers to<br />
use the book in basic lectures on PCS engineering as well as in computer<br />
lab courses, allowing students to gain hands-on experience.<br />
Editor: L. Urbas<br />
1 st <strong>edition</strong> 2012, 204 pages, content in English, hardcover,<br />
ISBN: 978-3-8356-3198-4<br />
Price € 49,80<br />
www.di-verlag.de<br />
DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München<br />
Order now!<br />
KNOWLEDGE FOR THE<br />
FUTURE<br />
Order now by fax: +49 201 / 820 Deutscher 02-34 Industrieverlag or send GmbH in a letter | Arnulfstr. 124 | 80636 München<br />
Yes, I place a firm order for the technical book. Please send<br />
— copies of Process Control Systems Engineering<br />
1st <strong>edition</strong> 2012 (ISBN: 978-3-8356-3198-4)<br />
at the price of € 49,80 (plus postage and packing)<br />
Company/Institution<br />
First name, surname of recipient (department or person)<br />
Street/P.O. Box, No.<br />
Country, Postalcode, Town<br />
reply / Antwort<br />
Vulkan-Verlag GmbH<br />
Versandbuchhandlung<br />
Postfach 10 39 62<br />
45039 Essen<br />
GERMANY<br />
Phone<br />
E-Mail<br />
Line of business<br />
Fax<br />
Please note: According to German law this request may be withdrawn within 14 days after order date in writing<br />
to Vulkan Verlag GmbH, Versandbuchhandlung, Postfach 10 39 62, 45039 essen, Germany.<br />
In order to accomplish your request and for communication purposes your personal data are being recorded and stored.<br />
It is approved that this data may also be used in commercial ways by mail, by phone, by fax, by email, none.<br />
this approval may be withdrawn at any time.<br />
Date, signature<br />
PAPCSE2013
IMPRESSUM / VORSCHAU<br />
IMPRESSUM<br />
VORSCHAU<br />
Verlag:<br />
DIV Deutscher Industrieverlag GmbH<br />
Arnulfstraße 124, D-80636 München<br />
Telefon + 49 (0) 89 203 53 66 0<br />
Telefax + 49 (0) 89 203 53 66 99<br />
www.di-verlag.de<br />
Geschäftsführer:<br />
Carsten Augsburger, Jürgen Franke<br />
Verlagsleiterin:<br />
Kirstin Sommer<br />
Spartenleiterin:<br />
Anne Purschwitz geb. Hütter<br />
Herausgeber:<br />
Dr.rer.nat. Thomas Albers<br />
Dr. Gunther Kegel<br />
Dipl.-Ing. Hans-Georg Kumpfmüller<br />
Dr.-Ing. Wilhelm Otten<br />
Beirat:<br />
Dr.-Ing. Kurt Dirk Bettenhausen<br />
Prof. Dr.-Ing. Christian Diedrich<br />
Prof. Dr.-Ing. Ulrich Epple<br />
Prof. Dr.-Ing. Alexander Fay<br />
Prof. Dr.-Ing. Michael Felleisen<br />
Prof. Dr.-Ing. Georg Frey<br />
Prof. Dr.-Ing. Peter Göhner<br />
Dipl.-Ing. Thomas Grein<br />
Prof. Dr.-Ing. Hartmut Haehnel<br />
Dr.-Ing. Jörg Kiesbauer<br />
Dipl.-Ing. Rolf Marten<br />
Dipl.-Ing. Gerald Mayr<br />
Dr. Jörg Nothdurft<br />
Dr.-Ing. Josef Papenfort<br />
Dr. Andreas Wernsdörfer<br />
Dipl.-Ing. Dieter Westerkamp<br />
Dr.rer.nat. Christian Zeidler<br />
Organschaft:<br />
Organ der GMA<br />
(VDI/VDE-Gesell schaft Messund<br />
Automatisierungs technik)<br />
und der NAMUR (Interessengemeinschaft<br />
Automatisierungstechnik<br />
der Prozessindustrie).<br />
Redaktion:<br />
Anne Purschwitz geb. Hütter (ahü)<br />
(verantwortlich)<br />
Telefon + 49 (0) 89 203 53 66 58<br />
Telefax + 49 (0) 89 203 53 66 99<br />
E-Mail: purschwitz@di-verlag.de<br />
Aljona Hartstock (aha)<br />
Telefon + 49 (0) 89 203 53 66 78<br />
E-Mail: hartstock@di-verlag.de<br />
Gerd Scholz (gz)<br />
Einreichung von 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@di-verlag.de<br />
Fachredaktion:<br />
Dr.-Ing. Michael Blum<br />
Dipl.-Ing. Heinrich Engelhard<br />
Prof. Dr.-Ing. Jürgen Jasperneite<br />
Dr.-Ing. Bernhard Kausler<br />
Dr.-Ing. Niels Kiupel<br />
Prof. Dr.-Ing. Gerrit Meixner<br />
Dr.-Ing. Jörg Neidig<br />
Dipl.-Ing. Ingo Rolle<br />
Dr.-Ing. Stefan Runde<br />
Prof. Dr.-Ing. Frank Schiller<br />
Bezugsbedingungen:<br />
„<strong>atp</strong> <strong>edition</strong> – 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-Abonnement + 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 />
DataM-Services GmbH, Leserservice <strong>atp</strong><br />
Herr Marcus Zepmeisel<br />
Franz-Horn-Str. 2, 97082 Würzburg<br />
Telefon + 49 (0) 931 417 04 59<br />
Telefax + 49 (0) 931 417 04 94<br />
leserservice@di-verlag.de<br />
Verantwortlich für<br />
den Anzeigenteil:<br />
Inge Spoerel<br />
Telefon + 49 (0) 89 203 53 66 22<br />
Telefax + 49 (0) 89 203 53 66 99<br />
E-Mail: spoerel@di-verlag.de<br />
Es gelten die Preise der Mediadaten 2013<br />
Anzeigenverwaltung:<br />
Brigitte Krawczyk<br />
Telefon + 49 (0) 89 203 53 66 12<br />
Telefax + 49 (0) 89 203 53 66 99<br />
E-Mail: krawczyk@di-verlag.de<br />
Art Direction / Layout:<br />
deivis aronaitis design | dad |<br />
Druck:<br />
Druckerei Chmielorz GmbH,<br />
Ostring 13,<br />
D-65205 Wiesbaden-Nordenstadt<br />
Gedruckt auf chlor- und<br />
säurefreiem Papier.<br />
Die <strong>atp</strong> wurde 1959 als „Regelungstechnische<br />
Praxis – rtp“ gegründet.<br />
DIV Deutscher Industrieverlag<br />
GmbH München<br />
Die Zeitschrift und alle in ihr enthaltenen<br />
Beiträge und Abbildungen sind urheberrechtlich<br />
geschützt. Mit Ausnahme der<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 />
DIV Deutscher Industrieverlag GmbH,<br />
Arnulfstraße 124, D-80636 München.<br />
Alleiniger Gesellschafter des Verlages<br />
ist die ACM-Unternehmensgruppe,<br />
Ostring 13,<br />
D-65205 Wiesbaden-Nordenstadt.<br />
ISSN 2190-4111<br />
DIE AUSGABE 1-2 / 2014 DER<br />
ERSCHEINT AM 10.02.2014<br />
MIT AUSGEWÄHLTEN BEITRÄGEN DER<br />
NAMUR-HAUPTSITZUNG 2013<br />
Der Prolist-Workflow<br />
im Eclass-Umfeld<br />
Effektives Engineering und<br />
früher Start-up – Virtuelle<br />
Inbetriebnahme am Beispiel<br />
eines Batch-Projekts<br />
Einsatz von Operator Training<br />
Simulatoren (OTS) in der<br />
Prozessindustrie<br />
Datenaustausch in heterogenen<br />
Systemlandschaften<br />
Package Unit Integration –<br />
Abstrakte Beschreibung<br />
mit EDD<br />
Aus aktuellem Anlass können sich die Themen<br />
kurzfristig verändern.<br />
LESERSERVICE<br />
E-MAIL:<br />
leserservice@di-verlag.de<br />
TELEFON:<br />
+ 49 (0) 931 417 04 59<br />
62<br />
<strong>atp</strong> <strong>edition</strong><br />
12 / 2013
Erreichen Sie die Top-Entscheider<br />
der Automatisierungstechnik.<br />
Sprechen Sie uns an wegen Anzeigenbuchungen<br />
und Fragen zu Ihrer Planung.<br />
Inge Spoerel: Tel.: +49 89 203 53 66-22<br />
E-Mail: spoerel@di-verlag.de