04.08.2014 Aufrufe

atp edition Einsatz robotergeführter Patientenliegen (Vorschau)

Erfolgreiche ePaper selbst erstellen

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

7-8 / 2014<br />

56. Jahrgang B3654<br />

DIV Deutscher Industrieverlag GmbH<br />

Automatisierungstechnische Praxis<br />

<strong>Einsatz</strong> <strong>robotergeführter</strong><br />

<strong>Patientenliegen</strong> | 28<br />

Cloud-enabled Automation<br />

Systems using OPC UA | 34<br />

Auf dem Weg zum<br />

Internet of Portals | 42<br />

Industrie 4.0 am Beispiel<br />

einer Verbundanlage | 52<br />

IT-Security-Konzepte für<br />

die Prozessindustrie | 62<br />

Modellbasierter Entwurf<br />

in der Anwendung | 70


update<br />

ATP EDITION | BRANCHE | VERANSTALTUNGEN | FORSCHUNG | PRODUKTE<br />

IHR NEWSLETTER FÜR<br />

DIE AUTOMATION<br />

Aktuell, kompetent und auf den Punkt<br />

Jetzt anmelden und sofort lesen:<br />

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


EDITORIAL<br />

Schöne neue<br />

(Produktions-)Welt<br />

Internet der Dinge, Industrie 4.0, Smart Manufacturing – solche Begriffe<br />

prägen derzeit die Debatte um die Zukunft der Produktion. Dabei nimmt<br />

die Diskussion um die Technologien breiten Raum ein und bisweilen ist<br />

kaum zu erkennen, welcher Nutzen für die Kunden mit den neuen Methoden<br />

verbunden ist. Ich meine, wir sollten die Nutzenargumentation wieder mehr<br />

in den Vordergrund stellen und neue Automationsansätze primär danach<br />

bewerten.<br />

Doch was erwartet der Konsument von der Produktion? Weltweit gesehen<br />

will die Menschheit mehr Wohlstand erreichen und dabei die natürlichen<br />

Ressourcen nachhaltiger als bisher nutzen. Für uns in den hoch entwickelten<br />

Ländern geht es zusätzlich noch darum, auch in Zukunft noch bezahlbare<br />

Produktion im eigenen Land zu halten. Voraussetzung für beide Ziele ist<br />

eine Steigerung der Produktions- und Ressourceneffizienz bei einer gleichzeitig<br />

zunehmenden Individualisierung der Produkte.<br />

Die zunehmende Vernetzung von Konsumenten, Lieferanten und Produktionseinheiten<br />

lässt globale Wertschöpfungsnetzwerke entstehen, in denen<br />

eine global optimierte Ressourcenallokation möglich und Redundanz verringert<br />

wird. Die horizontale Vernetzung von Produktionseinheiten und<br />

Kunden erlaubt es, die Aufträge dort zu platzieren, wo sie aus Effizienzgesichtspunkten<br />

am besten abzuarbeiten sind. Die vertikale Vernetzung innerhalb<br />

eines Betriebes sorgt für eine sichere und schnelle Verteilung der<br />

relevanten Daten und eine hocheffiziente Kooperation aller Beteiligten. Doch<br />

über diesen Aspekt der Vernetzung hinaus darf nicht vergessen werden, dass<br />

durch die neuen Technologien auch die bisher übliche strikte Trennung<br />

zwischen Produkt und Dokumentation aufgehoben wird. Das bedeutet, alle<br />

Informationen zum Produkt sind informationstechnisch untrennbar mit<br />

dem Produkt verbunden und somit jederzeit, und in bisher nicht gekannter<br />

Aktualität und vor allem Konsistenz, verfügbar. Und dies gilt sowohl für<br />

das hergestellte Produkt als auch für die Geräte, die Teil der Produktionsanlage<br />

sind. Das spart Zeit bei der Konfiguration, Inbetriebnahme und Wartung<br />

von komplexen Anlagen und erleichtert die Anpassung der Anlage an<br />

geänderte Bedürfnisse. Diesen Nutzen wird der Anwender wahrscheinlich<br />

sehr viel schneller und unmittelbarer wahrnehmen, noch bevor der Traum<br />

von weltumspannenden globalen Wertschöpfungsnetzwerken und individuellen<br />

Produkten zum Preis von Massenware Wahrheit wird.<br />

Insofern ist der Nutzen von Industrie 4.0 auch evolutionär erlebbar und<br />

dies sollten wir unseren Kunden im Rahmen der Diskussion immer wieder<br />

vor Augen führen. Die Vorteile der Vernetzung beginnen auf der Ebene des<br />

Shop-Floors und der durchgängig verfügbaren Information in der vertikalen<br />

Vernetzung. Das sich selbst steuernde Werkstück ist vielleicht die Zukunftsvision,<br />

aber auf die brauchen wir nicht zu warten, um handfeste Vorteile für<br />

den industriellen Anwender zu bieten.<br />

DR.-ING.<br />

PETER ADOLPHS,<br />

Geschäftsführer<br />

Entwicklung & Marketing,<br />

Pepperl+Fuchs GmbH,<br />

Mannheim<br />

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

7-8 / 2014<br />

3


INHALT 7-8 / 2014<br />

VERBAND<br />

6 | Neuer ZVEI-Präsident Ziesemer: Digitale<br />

Gesellschaft ist eines der wichtigsten Themen<br />

DKE-Geschäftsführer führt CENELEC<br />

Gunther Kegel in die VDE-Spitze berufen<br />

FORSCHUNG<br />

7 | Forschungsverbund gründet Campus<br />

„Automatisierung und Digitalisierung“<br />

Größter deutscher Solarspeicher-Park:<br />

Regelungsverfahren eliminieren Erzeugungsspitze<br />

BRANCHE<br />

8 | Namur-Tagung zu dezentraler Intelligenz – neue Wege<br />

für die Prozessautomatisierung der Zukunft<br />

Simulation: Umfrage soll Roadmap ermöglichen<br />

9 | InIT-Forscher gewinnen internationalen Preis mit einem<br />

Konzept für die Automation Cloud<br />

Forschungsfabrik SmartFactory bringt intelligente<br />

Automatisierungslösungen bis zur <strong>Einsatz</strong>reife<br />

10 | „Deutschland verfügt über eines der weltbesten<br />

Startguthaben für den Weg zu Industrie 4.0“<br />

12 | <strong>atp</strong> award 2013: Wushan Liang und Rando Meister<br />

als beste Nachwuchswissenschaftler geehrt<br />

18 | AALE: Fachtagung an der Nahtstelle zwischen Hochschule<br />

und Industrie mit Wachstumspotenzial<br />

INTERVIEW<br />

14 | „Im realen <strong>Einsatz</strong> müssen wir den Nutzen belegen“<br />

DR.-ING. DAGMAR DIRZUS IM INTERVIEW MIT <strong>atp</strong> <strong>edition</strong><br />

4<br />

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

7-8 / 2014


PRAXIS<br />

20 | Intelligente Stromversorgungen erleichtern<br />

Prüfabläufe in der Forschung<br />

24 | Neues Sicherheitsschaltgerät bietet<br />

Gesamtlösung in Vormontageanlagen<br />

bei Continental<br />

26 | Intelligente Feldbusinstallationen<br />

bieten optimalen Fehlerschutz<br />

und maximale Anlagenverfügbarkeit<br />

Produkte,<br />

Systeme<br />

und Service<br />

für die<br />

Prozessindustrie?<br />

Natürlich.<br />

HAUPTBEITRÄGE<br />

28 | <strong>Einsatz</strong> <strong>robotergeführter</strong> <strong>Patientenliegen</strong><br />

A.DUFFE, H.ARENBECK UND D.ABEL<br />

34 | Cloud-enabled Automation Systems<br />

using OPC UA<br />

J. SCHMITT, T. GOLDSCHMIDT UND P. VORST<br />

42 | Auf dem Weg zum Internet of Portals<br />

D. GROSSMANN, M. BREGULLA, S. BANERJEE,<br />

D. SCHULZ UND R. BRAUN<br />

52 | Industrie 4.0 am Beispiel<br />

einer Verbundanlage<br />

M. WEYRICH, C. DIEDRICH, A. FAY, M. WOLLSCHLAEGER,<br />

S. KOWALEWSKI, P. GÖHNER, B. VOGEL-HEUSER<br />

62 | IT-Security-Konzepte<br />

für die Prozessindustrie<br />

K.-H. NIEMANN<br />

70 | Modellbasierter Entwurf<br />

in der Anwendung<br />

P. S. STELTER, B. BÜCHAU UND G. GRÖBE<br />

Zum Beispiel der magnetischinduktive<br />

Durchflussmesser<br />

ProcessMaster. Er setzt neue<br />

Maßstäbe mit umfangreichen<br />

Diagnosemöglichkeiten, einer<br />

Messabweichung von 0,2 %,<br />

Explosionsschutz sowie der<br />

ScanMaster-Software. Erfahren<br />

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

der Durchflussmessung für die<br />

Prozessindustrie:<br />

www.abb.de/durchfluss<br />

Wussten Sie, dass Ihnen ABB<br />

neben dem umfassenden Portfolio<br />

für die Instrumentierung ebenso<br />

herausragende Produkte und<br />

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

modernste Leitsysteme sowie<br />

erstklassigen Service bietet?<br />

Lesen Sie mehr unter:<br />

www.abb.de/<br />

prozessautomatisierung<br />

RUBRIKEN<br />

3 | Editorial<br />

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

ABB Automation Products GmbH<br />

Tel.: 0800 111 44 11<br />

Fax: 0800 111 44 22<br />

vertrieb.messtechnik-produkte@de.abb.com


VERBAND<br />

Neuer ZVEI-Präsident Ziesemer: Digitale<br />

Gesellschaft ist eines der wichtigsten Themen<br />

Michael Ziesemer führt für drei Jahre als<br />

Präsident den ZVEI. Der bestimmte den<br />

63-Jährigen bei der Mitgliederversammlung<br />

in München zum Nachfolger von Friedhelm<br />

MICHAEL ZIESE- Loh, der satzungsgemäß nicht wiedergewählt<br />

MER: „Das Internet werden konnte. Loh wurde für seine Verdienste<br />

um die Elektroindustrie mit der ZVEI-<br />

der Dinge ergänzt<br />

das Internet der Ehrenpräsidentschaft ausgezeichnet.<br />

Dienste und<br />

Ziesemer ist Chief Operation Officer und<br />

durchdringt immer stellvertretender Vorstandsvorsitzender bei<br />

stärker alle Endress+Hauser. Er gehört seit zehn Jahren<br />

Lebensbereiche“, dem ZVEI-Vorstand an, ab 2008 als Vizepräsident.<br />

Mit Gründung des ZVEI-Fachver-<br />

prognostiziert der<br />

neue ZVEI-Präsident.<br />

Bild: ZVEI glied des Fachverbandsvorstands und Vorsitbands<br />

Automation im Jahr 2000 war er Mitzender<br />

des Fachbereichs Prozessautomatisierung.<br />

Als ZVEI-Präsident wird Ziesemer zugleich<br />

Vizepräsident des BDI (Bundesverband der Deutschen<br />

Industrie) sein.<br />

In den engeren Vorstand berief der ZVEI-Vorstand auf<br />

seiner konstituierenden Sitzung: Klaus Helmrich,<br />

(Siemens, Vizepräsident), Andreas Bettermann (OBO<br />

Bettermann), Dr. Wolfgang Bochtler (Mektec Europe,<br />

Nippon Mektron), Dr. Dirk Hoheisel (Robert Bosch),<br />

Dr. Gunther Kegel (Pepperl+Fuchs), Dr. Peter Köhler<br />

(Weidmüller), Stephanie Spinner-König (Spinner),<br />

Dr. Peter Terwiesch (ABB Deutschland), Georg Walkenbach<br />

(Beurer). Frank Stührenberg (Phoenix Contact)<br />

wurde als Schatzmeister bestätigt.<br />

Der neue Präsident Ziesemer betonte: „Die erfolgreiche<br />

Umsetzung der Energiewende und die digitale Gesellschaft<br />

sind die großen Themen unseres Verbands.“ Die<br />

Energiewende sei eine Generationenaufgabe, die mithilfe<br />

der Produkte und Lösungen der Elektroindustrie erfolgreich<br />

gestaltet werden könne. Chancen sieht Ziesemer<br />

auch bei der voranschreitenden Digitalisierung.<br />

„Das Internet der Dinge ergänzt das Internet der Dienste<br />

und durchdringt immer stärker alle Lebensbereiche“,<br />

prognostiziert Ziesemer.<br />

(gz)<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 />

BERNHARD THIES:<br />

Er tritt 2016 die<br />

Nachfolge des<br />

Norwegers Tore<br />

Trondvold an der<br />

Spitze des Europäischen<br />

Komitees<br />

für Elektrotechnische<br />

Normung<br />

an. Bild: DKE<br />

DKE-Geschäftsführer<br />

führt CENELEC<br />

Dr.-Ing. Bernhard Thies ist zum Präsidenten<br />

der europäischen Normungsorganisation<br />

CENELEC (Europäisches Komitee für elektrotechnische<br />

Normung) gewählt worden. Der<br />

Sprecher der Geschäftsführung der DKE<br />

Deutsche Kommission Elektrotechnik Elektronik<br />

Informationstechnik im DIN und VDE<br />

tritt zum 1. Januar 2016 die Nachfolge des<br />

Norwegers Tore Trondvold an der Spitze der<br />

CENELEC an. Thies ist seit Jahren in der nationalen,<br />

europäischen und internationalen<br />

Normung aktiv, unter anderem als Leiter des<br />

CEN/CLC/ETSI External Relations Komitees.<br />

Zu seinen Zielen als CENELEC-Präsident zählen<br />

die Umsetzung der gemeinsamen Normungsstrategie<br />

„Ambitions 2020“ von CENE-<br />

LEC und CEN (Europäisches Komitee für<br />

Normung) und des CENELEC-Implementierungsplans,<br />

die Weiterentwicklung neuer<br />

Normungskonzepte in Zukunftsfeldern wie<br />

Smart Grids und Smart Cities sowie die Vertiefung der<br />

Zusammenarbeit mit internationalen Normungsorganisationen<br />

wie der Internationalen Elektrotechnischen<br />

Kommission (IEC).<br />

(gz)<br />

DKE DEUTSCHE KOMMISSION ELEKTROTECHNIK<br />

ELEKTRONIK INFORMATIONSTECHNIK IM DIN UND VDE,<br />

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

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

Gunther Kegel in die<br />

VDE-Spitze berufen<br />

Dr. Bruno Jacobfeuerborn, Geschäftsführer<br />

Technik der Telekom<br />

Deutschland, ist auf der VDE-<br />

Delegiertenversammlung 2014 zum<br />

neuen VDE-Präsidenten gewählt<br />

worden. Er tritt zum 1. Januar 2015<br />

die Nachfolge von Dr. Joachim<br />

Schneider an. Schneider ist Mitglied<br />

des Vorstands von RWE<br />

Deutschland und scheidet turnusgemäß<br />

als VDE-Präsident aus.<br />

Schneider und der neu in die VDE-<br />

Spitze berufene Dr. Gunther Kegel,<br />

Vorsitzender der Geschäftsführung<br />

von Pepperl+Fuchs, werden als<br />

Stellvertretende VDE-Präsidenten<br />

tätig sein. Als Mitglied des VDE-<br />

AB 2015 NEUER<br />

VIZEPRÄSIDENT<br />

DES VDE:<br />

Pepperl+Fuchs-<br />

Chef Dr. Gunther<br />

Kegel.<br />

Bild: Pepperl+Fuchs<br />

Präsidiums bestätigt wurde Alf Henryk Wulf, Vorsitzender<br />

des Vorstandes von Alstom Deutschland. Neu ins<br />

Präsidium zog Dr. Martin Schumacher ein, Mitglied des<br />

Vorstandes der deutschen ABB. Die VDE-Präsidiumsmitglieder<br />

kommen traditionell aus Hochschule und<br />

Industrie und decken die gesamte Bandbreite der Elektro-<br />

und Informationstechnik ab.<br />

(gz)<br />

VDE VERBAND DER ELEKTROTECHNIK ELEKTRONIK<br />

INFORMATIONSTECHNIK E.V.,<br />

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

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

6<br />

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

7-8 / 2014


FORSCHUNG<br />

Forschungsverbund gründet Campus<br />

„Automatisierung und Digitalisierung“<br />

Ein neu gegründeter Forschungsverbund mit Partnern<br />

aus Industrie und Wissenschaft arbeitet zukünftig<br />

gemeinsam an Software und Technologien für die Automatisierung<br />

und Digitalisierung der Industrie sowie<br />

an den Themen Internet der Dinge, Cloud-Lösungen, IT-<br />

Sicherheit und Smart Data. An der Kooperation beteiligen<br />

sich die Siemens AG, die Technische Universität<br />

München, die Ludwig-Maximilians-Universität München,<br />

das Forschungszentrum für Künstliche Intelligenz<br />

und das Fraunhofer-Institut für Angewandte und Integrierte<br />

Sicherheit (AISEC). Siemens plant, innerhalb von<br />

zwei Jahren einen zweistelligen Millionen-Euro-Betrag<br />

zu investieren.<br />

Der Campus Automatisierung und Digitalisierung<br />

wird seinen Schwerpunkt in München haben. Die Forschungsergebnisse<br />

sollen in weiteren Schritten bis zu<br />

Marktreife gebracht werden.<br />

„Mit Industrie 4.0 hält das Internet der Dinge Einzug<br />

in die Fabriken. Nur zusammen mit führenden Industriepartnern<br />

wie Siemens wird es gelingen, nun die Voraussetzungen<br />

für die Umsetzung in den Fabrikalltag zu<br />

schaffen und Deutschland zum Leitanbieter für die Digitalisierung<br />

der Produktion zu machen“, sagt Prof. Dr.<br />

Wolfgang Wahlster, CEO des DFKI.<br />

Zu den ersten geplanten Forschungsthemen gehören<br />

autonome Roboter, die eng mit Menschen interagieren<br />

können. Fertigungsprozesse und Roboter sollen durch<br />

„digitale Zwillinge“ modelliert und simuliert werden.<br />

Die Kooperationspartner wollen außerdem eine einheitliche<br />

Sprache für die Kommunikation von Maschinen<br />

DIE VERTRETER des Forschungscampus nach der<br />

Vertragsunterzeichnung in München. Bild: Siemens AG<br />

untereinander finden. Zudem sollen Algorithmen zur<br />

Smart-Data-Analyse großer Datenmengen erforscht werden,<br />

wie sie für intelligente Energienetze, die Industrieautomatisierung,<br />

Smart Cities oder Gesundheitssysteme<br />

eingesetzt werden können. <br />

(aha)<br />

DEUTSCHES FORSCHUNGSZENTRUM FÜR<br />

KÜNSTLICHE INTELLIGENZ GMBH, DFKI,<br />

Trippstadter Straße 122, D-67663 Kaiserslautern,<br />

Tel. +49 (0) 631 20 57 50, Internet: www.dfki.de<br />

Größter deutscher Solarspeicher-Park:<br />

Regelungsverfahren eliminieren Erzeugungsspitze<br />

Das Karlsruher Institut für Technologie (KIT) hat mit<br />

seinen Partnern SolarWatt und Kostal Solar Electric<br />

den größten Solarstrom-Speicher-Park in Deutschland<br />

in Betrieb genommen. In der Ein-Megawatt-Anlage arbeiten<br />

Solarzellen, Batterien und Wechselrichter zusammen,<br />

um Solarstrom zu speichern und jederzeit<br />

verfügbar zu machen. Die Batterien werden dabei von<br />

neuartigen Prognose- und Regelungsverfahren so gesteuert,<br />

dass sie vor allem mittags den Sonnenstrom<br />

speichern und ihn dann bei Bedarf etwa abends, nachts<br />

oder morgens abgeben. Auf diese Weise eliminieren<br />

sie die Erzeugungsspitze am Mittag.<br />

In der Anlage sind mehr als 100 verschiedene Systemkonfigurationen<br />

aufgebaut, die sich etwa in der Ausrichtung,<br />

Neigung oder technischen Bauteilen unterscheiden.<br />

Die Auswertung der Leistungsdaten soll zeigen,<br />

welche Systemkonfigurationen netzverträglich sind. Die<br />

Erkenntnisse sollen zum Gelingen der Energiewende<br />

beitragen. Der in der Anlage erzeugte Strom wird auf<br />

dem Campus Nord des KIT für den Betrieb von Großforschungsgeräten<br />

eingesetzt.<br />

(aha)<br />

IN DEM SOLARSPEICHER-PARK des KIT werden neue<br />

Technologien für die Energiewende erprobt. Bild: KIT<br />

KARLSRUHER INSTITUT FÜR TECHNOLOGIE,<br />

Kaiserstr. 12, D-76131 Karlsruhe,<br />

Tel. +49 (0) 721 60 80, Internet: www.kit.edu<br />

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

7-8 / 2014<br />

7


BRANCHE<br />

Namur-Tagung zu dezentraler Intelligenz – neue<br />

Wege für die Prozessautomatisierung der Zukunft<br />

MODULARE AUTOMATISIERUNGSSYSTEME MIT<br />

OFFENEN, standardisierten Schnittstellen sind<br />

erforderlich, um den neuen Marktanforderungen<br />

gerecht zu werden. Dieses Thema steht im Fokus<br />

der Namur-Hauptsitzung. Bild: BASF<br />

Vor dem Hintergrund steigender Volatilitäten der Absatzmärkte<br />

und immer kürzerer Produktlebenszyklen<br />

zeigt das Konzept der starren Prozessanlagen zunehmend<br />

Schwächen. Die Zeit von der Planung über die<br />

Installation bis hin zur Inbetriebnahme wie auch die<br />

Kostenreduktion bei der Anpassung auf individuelle<br />

Produktionsmengen und -arten werden für Anlagenbetreiber<br />

zu kritischen Faktoren. Um den Marktanforderungen<br />

nach Schnelligkeit, Flexibilität und wirtschaftlicher<br />

Größenanpassung gerecht zu werden, bedarf es<br />

modularer Automatisierungssysteme mit offenen, standardisierten<br />

Schnittstellen. Nur so kann die Automatisierung<br />

der steigenden Flexibilität von zunehmend modular<br />

aufgebauten Prozessanlagen gerecht werden.<br />

Die 77. Namur-Hauptsitzung, und mit ihr Wago Kontakttechnik<br />

als Sponsor, widmen sich diesem Thema<br />

unter dem Titel „Dezentrale Intelligenz – Neue Wege in<br />

der Prozessautomatisierung“. In Bad Neuenahr wird es<br />

am 6. und 7. November 2014 daher um einen konkreten<br />

Lösungsansatz für eine Prozessautomatisierung der Zukunft<br />

gehen. Die jährliche Namur-Hauptsitzung ist eine<br />

der größten Veranstaltungen in der Prozessindustrie und<br />

findet weltweit Beachtung.<br />

Der Sponsor Wago ist im Bereich der elektrischen Federverbindungstechnik<br />

zu einem Weltmarktführer aufgestiegen<br />

und bietet seit über 20 Jahren ebenfalls Automatisierungssysteme<br />

an. Auf der Namur-Hauptsitzung<br />

tritt Wago an, einen Weg in eine neue Automatisierungsarchitektur<br />

modularer Prozessanlagen darzustellen.<br />

Wago wird in einem Plenarvortrag und weiteren fünf<br />

Workshops in enger Abstimmung mit der Namur ein<br />

neues Konzept zur modularen, skalierbaren Prozessautomatisierung<br />

vorstellen. Bestandteile sind das Engineering,<br />

die digitale Beschreibung von Prozessmodulen<br />

sowie eine offene, herstellerunabhängige Systemkommunikation<br />

und Schnittstellenarchitektur zur Automatisierung<br />

von Prozessanlagen mit dezentraler Automatisierung<br />

oder Package Units.<br />

Dem Plenarvortrag folgen Beiträge der Namur, die<br />

neue Anforderungen sowie aktuelle Entwicklungen aufgreifen<br />

und die Ergebnisse zur seit der letzten Hauptsitzung<br />

gestarteten Initiative zum Namur-Datencontainer<br />

nach NE 150 (Standardisierung eines hersteller- und<br />

systemunabhängigen Datenaustausches zwischen CAE<br />

und PLS) darstellen. Diskutiert werden auch aktuelle<br />

Themen der Arbeitskreise wie etwa Security, Assistenzsysteme,<br />

Sensorik und Antriebstechnik.<br />

(gz)<br />

NAMUR-GESCHÄFTSSTELLE,<br />

c/o Bayer Technology Services GmbH,<br />

Gebäude K 9, D-51368 Leverkusen,<br />

Tel. +49 (0) 214 307 10 34, Internet: www.Namur.de<br />

SIMULATION: UMFRAGE SOLL ROADMAP ERMÖGLICHEN<br />

Wie sieht die Anwendung von Simulation heute und morgen im Lebenszyklus einer Prozessanlage aus?<br />

Antworten dazu soll nun eine<br />

Online-Umfrage liefern. Initiiert wurde<br />

diese Untersuchung vom VDI/VDE<br />

GMA-Fachausschuss 6.11 zur<br />

virtuellen Inbetriebnahme unter<br />

Leitung von Prof. Dr. Mike Barth sowie<br />

von Mathias Oppelt (Siemens) und<br />

Prof. Dr. Leon Urbas (TU Dresden).<br />

Ziel der Studie über Simulation in den<br />

Prozessindustrien ist es, den aktuellen<br />

Stand und die Vision zur Anwendung<br />

von Simulation im Lebenszyklus einer<br />

Prozessanlage zu erfassen. Daraus<br />

soll eine Technologie-Roadmap zur<br />

Anwendung von Simulation in den<br />

Prozessindustrien abgeleitet werden,<br />

auf deren Ausprägung Experten durch<br />

Ihre Teilnahme an der Umfrage<br />

Einfluss nehmen können. Die<br />

Auswertung der Daten erfolgt<br />

anonymisiert. Die Umfrage ist über<br />

folgenden Link zu erreichen:<br />

www.simulation-studie.de<br />

oder via http://customersatisfaction.<br />

siemens.com/surveycenter/studio/<br />

Survey_inet/SimulationStudie<br />

MATHIAS OPPELT,<br />

Siemens AG, I IA AS PA PRM 2,<br />

Östliche Rheinbrückenstr. 50,<br />

D-76187 Karlsruhe,<br />

Tel. +49 (0) 721 595 21 78,<br />

E-Mail: oppelt.mathias@siemens.com<br />

8<br />

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

7-8 / 2014


InIT-Forscher gewinnen internationalen Preis<br />

mit einem Konzept für die Automation Cloud<br />

Forscher vom Institut für industrielle Informatik (InIT)<br />

der Hochschule Ostwestfalen-Lippe sind die Gewinner<br />

des internationalen Cloud Innovation World Cup.<br />

Die Preisverleihung erfolgte in London. Für ihr Konzept<br />

einer Automation Cloud sind die Forscher in London mit<br />

dem ersten Platz in der Kategorie Industrie 4.0 geehrt<br />

worden. Die Gewinner haben sich gegen mehrere hundert<br />

Konkurrenten durchgesetzt. Omid Givehchi, wissenschaftlicher<br />

Mitarbeiter am InIT, nahm den Preis in<br />

der Olympia Hall entgegen.<br />

Der Vorteil von Cloud Computing: Daten werden nur<br />

ein Mal auf einen Server geladen, der Nutzer kann sie<br />

dann jederzeit und von überall abrufen. Steuerungsprogramme<br />

und die Software großer Produktionsanlagen<br />

sollen nicht mehr auf einem festen Rechner installiert,<br />

sondern in das Internet ausgelagert werden. Steuerungsfunktionen,<br />

die bisher durch Hardwarekomponenten<br />

direkt an den Maschinen und Anlagen angebracht sind,<br />

sollen dann in der „Automation Cloud“ zur Verfügung<br />

stehen und als Dienste abgerufen werden. Statt weiter<br />

Hardware zu installieren und Steuerungen zu programmieren,<br />

greift der Anwender auf die bereits programmierte<br />

Steuerung in der Cloud zurück.Das möchte sich<br />

die Industrie zunutze machen. Das Lemgoer Forschungsinstitut<br />

InIT arbeitet an der Umsetzung. (aha)<br />

INSTITUTSLEITER Prof. Jürgen Jasperneite (li.)<br />

und Mitarbeiter Omid Givehchi (re.) haben mit der<br />

Automation Cloud den ersten Platz belegt. Bild: InIT<br />

HOCHSCHULE OSTWESTFALEN-LIPPE,<br />

Liebigstr. 87, D-32657 Lemgo,<br />

Tel. +49 (0) 5261 70 20,<br />

Internet: www.hs-owl.de<br />

Forschungsfabrik SmartFactory bringt intelligente<br />

Automatisierungslösungen bis zur <strong>Einsatz</strong>reife<br />

Auf Initiative der Fraunhofer-Gesellschaft und der<br />

Hochschule OWL entsteht in Lemgo die Zukunftsfabrik<br />

SmartFactoryOWL. Investiert werden rund fünf<br />

Millionen Euro. Zusammen mit der Erweiterung des<br />

Centrum Industrial IT (CIIT) ensteht damit in Ostwestfalen-Lippe<br />

(OWL) ein Technologiecampus für die Intelligente<br />

Automation.<br />

Seit 2009 forschen das Fraunhofer-Anwendungszentrum<br />

Industrial Automation (IOSB-INA) und die Hochschule<br />

OWL gemeinsam an Technologien, um die intelligente<br />

Fabrik zu realisieren. Jetzt geben sie den Anstoß<br />

für eine – in diesem Umfang – einzigartige Forschungsfabrik<br />

in Ostwestfalen-Lippe. Auf zirka 2000 Quadratmeter<br />

sollen darin Lösungen für die intelligente Automation<br />

erforscht, entwickelt und erprobt werden. Die<br />

Fertigstellung ist für das erste Halbjahr 2015 geplant.<br />

Die SmartFactoryOWL ist eine Plattform für Wissensund<br />

Technologietransfer, um insbesondere produzierenden<br />

Unternehmen und Fabrikausrüstern den Übergang<br />

in neue Technologien zu ermöglichen. Für Professor<br />

Jürgen Jasperneite, Leiter des Fraunhofer-Anwendungszentrums<br />

und Initiator des Projektes, lässt sich<br />

„die Tragfähigkeit neuer Ansätze nur an deren Praxistauglichkeit<br />

messen“. Die Forschungsfabrik wird daher<br />

neben Demonstratoren über eine reale Produktions- und<br />

IT-Umgebung verfügen. Kleine und mittelständische<br />

Unternehmen haben hier sogar die Möglichkeit mit Hilfe<br />

einer Kleinserienfertigung ihre Produktionssysteme<br />

und -abläufe zu optimieren und Personal zu schulen.<br />

Die Realisierung der Forschungsfabrik ist für Jasperneite<br />

nicht nur ein klares Bekenntnis der Fraunhofer-Gesellschaft<br />

zum Standort Lemgo. „Durch das gemeinsame<br />

Engagement von Fraunhofer und der Hochschule OWL<br />

wird die Spitzenclusterregion Ostwestfalen-Lippe zudem<br />

über die Grenzen hinaus signifikant gestärkt“, hebt er<br />

hervor. Der Standort in Lemgo ist eines der drei regionalen<br />

Leistungszentren im BMBF-Spitzencluster „it’s OWL –<br />

Intelligente Technische Systeme OstWestfalenLippe“.<br />

Dr. Oliver Herrmann, Präsident der Hochschule OWL<br />

ergänzt: „Die Zukunftsfabrik ist ein Meilenstein zur<br />

weiteren Profilierung des Wissenschaftsstandortes Lemgo<br />

und bietet einzigartige und praxisnahe Bedingungen<br />

für Studierende der Ingenieurswissenschaften.“ (gz)<br />

FRAUNHOFER-ANWENDUNGSZENTRUM INDUSTRIAL<br />

AUTOMATION (IOSB-INA),<br />

Langenbruch 6, D-32657 Lemgo,<br />

Internet: www.iosb-ina.fraunhofer.de<br />

HOCHSCHULE OSTWESTFALEN-LIPPE,<br />

Liebigstraße 87, D-32657 Lemgo,<br />

Internet: www.hs-owl.de<br />

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

7-8 / 2014<br />

9


BRANCHE<br />

„Deutschland verfügt über eines der weltbesten<br />

Startguthaben für den Weg zu Industrie 4.0“<br />

GMA-Tagung Automation 2014: Smarte Technologien für die Automation der Zukunft im Fokus<br />

Geschwindigkeit, Geschwindigkeit, Geschwindigkeit“<br />

– fordert Dr.-Ing. Kurt D. Bettenhausen beim<br />

Einstieg in die Industrie 4.0-Welt. Als weitere Erfolgsfaktoren<br />

auf Weg in die Produktion der Zukunft sieht<br />

der Vorsitzende der VDI/VDE-Gesellschaft Mess- und<br />

Automatisierungstechnik (GMA) die Qualifikation der<br />

Mitarbeiter sowie den Auf- und Ausbau der erforderlichen<br />

Infrastruktur.<br />

Die deutsche Ausgangsposition sei sehr gut. Vor allem<br />

dank des bereits hohen Automatisierungsgrads und des<br />

ebenfalls hohen Qualifikationsniveaus der Mitarbeiter<br />

„verfügt Deutschland über eines der weltbesten Startguthaben<br />

für Industrie 4.0“, betonte Bettenhausen bei der<br />

GMA-Tagung „Automation 2014“, die sich vor allem smarten<br />

Technologien für alle Branchen und für Industrie 4.0<br />

widmete. Zusammen mit den parallel stattfindenden VDI-<br />

Tagungen zu industrieller Robotik und Gebäudeautomation<br />

zog die Automation 2014 rund 500 Teilnehmer an:<br />

Ziel erreicht, verkündete Bettenhausen erfreut.<br />

Eine Umfrage unter den GMA-Mitgliedern, deren Ergebnisse<br />

Bettenhausen und die neue GMA-Geschäftsführerin<br />

Dr.-Ing. Dagmar Dirzus (siehe auch Interview ab Seite 14)<br />

vorstellten, zeigte neben einer grundsätzlich großen Zuversicht<br />

der Branche auch Handlungsfelder zum Thema<br />

Industrie 4.0 auf. Ein wichtiger Punkt: „Das Funktionieren<br />

der Cloud in der Automation ist Voraussetzung für Industrie<br />

4.0“, unterstrich Dagmar Dirzus. Allerdings wird die<br />

Cloud nach Ansicht der befragten GMA-Mitglieder in den<br />

Unternehmen nur zögerlich Einzug halten. Im Mittel der<br />

rund 400 Antworten ergab sich die Einschätzung, dass die<br />

Cloud-Nutzung erst in 6,1 Jahren im Unternehmen „selbstverständlich“<br />

werde. Vor einem Jahr lag das rechnerische<br />

Mittel der Antworten auf dieselbe Frage bei 6,6 Jahren.<br />

Berücksichtigt man die zwölf Monate, die zwischen beiden<br />

Umfragen liegen, so wird die Cloud-Nutzung heute<br />

also zurückhaltender gesehen als noch vor einem Jahr.<br />

CYBER-PHYSISCHE SYSTEME WERDEN REALITÄT<br />

Die Vorteile des Cloud Computing sehen die Befragten<br />

aktuell vor allem in zentraler Datenhaltung (48,4 Prozent)<br />

und in höherer Effizienz durch Nutzung von Speicher und<br />

Rechenkapazitäten in der Cloud. Als mögliche zusätzliche<br />

Dienstleistungen aus der Cloud nennen die Befragten vor<br />

allem Software-Update-Management, die Auswertung von<br />

Störungen und Diagnoseaufgaben (jeweils zwischen gut<br />

51 und knapp 45 Prozent). Damit, so sagte Dagmar Dirzus,<br />

„wird der Trend bestätigt, dass cyber-physische Systeme<br />

beginnen, Realität zu werden, indem ‚Condition Monitoring‘<br />

immer weiter Einzug hält“. Das übergreifende Management<br />

von Ressourcen folgt auf Platz vier.<br />

Auch die Nutzung smarter Geräte, die einen Baustein<br />

von Industrie 4.0 darstellen, ist relativ selten. Knapp<br />

60 Prozent der Befragten sehen in den Anlagen ihres<br />

Unternehmens derzeit keine beziehungsweise eine sehr<br />

geringe Nutzung smarter Geräte. „Diese Aussage kann<br />

nicht befriedigen“, stellt GMA-Chef Bettenhausen fest.<br />

Was die Definition „smarter“ Geräte angeht, kristallisierte<br />

sich bei der Umfrage eine mehrheitliche, allerdings<br />

nicht komplett einheitliche Aussage heraus:<br />

Knapp zwei Drittel der Befragten sehen die Kommunikationsfähigkeit<br />

als bedeutendste Eigenschaft. Für<br />

knapp 53 Prozent gehört auch eine intuitive Bedienbarkeit<br />

zu smarten Geräten, knapp 43 Prozent erwarten<br />

eine einfache Bedienbarkeit.<br />

HOHER INFORMATIONSBEDARF ZU INDUSTRIE 4.0<br />

Zumindest bei vielen der Befragten herrscht offenbar<br />

noch großer Informationsbedarf zu Industrie 4.0: Nur gut<br />

43 Prozent der Befragten fühlen sich bereits gut bis sehr<br />

gut, mehr als die Hälfte aber nur ausreichend oder sogar<br />

unzureichend informiert. Dagmar Dirzus: „Dass immerhin<br />

knapp die Hälfte mit dem Informationsstand zufrie-<br />

den ist – dazu haben vor allem die Verbände und bereits<br />

BESTE STIMMUNG<br />

Die Mitglieder der GMA erwarten weiteres Wachstum für ihre Branche<br />

Die jüngste Mitgliederumfrage<br />

der GMA zeigt die Branche in sehr<br />

guter Laune: 70 Prozent der<br />

Befragten hegen positive Erwartungen<br />

für die wirtschaftliche<br />

Entwicklung in den nächsten drei<br />

Jahren bei den Herstellern von<br />

Mess- und Automatisierungstechnik.<br />

Für die Anwender dieser<br />

Technik sagen gut 60 Prozent eine<br />

positive Entwicklung voraus.<br />

Die Chancen für Wachstum der<br />

Mess- und Automatisierungstechnik<br />

werden dabei vor allem in<br />

China gesehen, erst mit großem<br />

Abstand gefolgt von Indien,<br />

danach erst folgen etwa gleichauf<br />

die Heimatmärkte. Bemerkenswert<br />

ist dabei die Einschätzung<br />

der wichtigsten Anwendungs<br />

felder: Die konventionellen<br />

Technologien, Maschinen- und<br />

Anlagenbau, Produktions- und<br />

Fahrzeugtechnik werden als<br />

bedeutendste Wachstumstreiber<br />

für Regelungs- und Automatisierungstechnik<br />

gesehen. Im<br />

Bereich Sensorik, Mess- und<br />

Prüftechnik werden die stärksten<br />

Impulse von der Fahrzeugtechnik<br />

erwartet, gefolgt von Maschinen<br />

und Anlagenbau sowie Produktionstechnik.<br />

10<br />

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

7-8 / 2014


KURT D.<br />

BETTENHAUSEN:<br />

Der GMA-Vorsitzende<br />

betonte,<br />

IT Security seit<br />

eine notwendige<br />

Voraussetzung für<br />

Cloud-Lösungen<br />

in der produzierenden<br />

Industrie.<br />

Bilder: VDI<br />

DIE GMA-SPITZE: Kurt D. Bettenhausen und<br />

Dagmar Dirzus stellten aktuelle Umfrageergebnisse<br />

zum Thema Industrie 4.0 vor.<br />

seit 2011 der VDI maßgeblich beigetragen. Wir nehmen<br />

unsere Aufgabe sehr ernst, hieran weiter zu arbeiten.“<br />

Trotz dieser Informationslücke sehen fast 80 Prozent<br />

der Befragten Deutschland als führend oder zumindest<br />

als „fast follower“ bei Einführung und Entwicklung von<br />

Industrie 4.0. Um die Anwendungen möglichst schnell<br />

in die Unternehmen zu tragen, sei nun wichtig, „den<br />

konkreten Nutzen von Industrie 4.0 in realen Industrieumgebungen<br />

nachzuweisen“, fordert der GMA-Präsident.<br />

Auch neue Geschäftsmodelle gelte es zu entwickeln.<br />

In der GMA arbeite man mit Hochdruck an konkreten<br />

Use Cases. Nach Papieren zu Wertschöpfungsketten,<br />

Komponenten von Industrie 4.0 und Referenzmodellen<br />

stellte die GMA nun den Statusreport „Industrie 4.0 –<br />

CPS-basierte Automation“ vor. In den kommenden<br />

sechs Monaten sollen Veröffentlichungen zu den Feldern<br />

IT Security, Geschäftsmodelle und Arbeitsumfeld<br />

Industrie 4.0 folgen.<br />

Die Sicherstellung der IT Security gilt als unabdingbar.<br />

„Wenn die IT-Infrastrukturen wie die Cloud für<br />

Industrie 4.0 in die produzierende Industrie Einzug<br />

halten sollen, ist IT Security die notwendige Voraussetzung“,<br />

hebt Bettenhausen hervor. Um die künftig notwendige<br />

Vernetzung der Wertschöpfungsketten zu ermöglichen,<br />

sei zudem die Standardisierung von Schnittstellen,<br />

Semantiken und Ontologien erforderlich.<br />

KÜNFTIG NOCH HÖHERE QUALIFIKATIONEN NÖTIG<br />

Auswirkungen wird der Wandel zu Industrie 4.0 auch<br />

auf die Arbeitsplätze haben. Deren Anzahl dürfte zwar<br />

gleich bleiben, wie knapp zwei Drittel der Befragten<br />

erwarten. Aber das Qualifikationsniveau wird noch<br />

weiter steigen. Denn „durch die erhöhte Flexibilität der<br />

Anlagen und der Wertschöpfungsstrukturen steigt auch<br />

ihre Komplexität“, betont Bettenhausen und erläutert:<br />

„Sich selbst adaptierende Systeme, Module, die fähig<br />

sind, ihre Anmeldung im System selbst vorzunehmen,<br />

ihre Verfügbarkeit kund zu tun und einen virtuellen<br />

wie physischen Orts- oder Reihenfolgewechsel selbst<br />

zu managen sind die Lösung, die Industrie 4.0 anbieten<br />

wird. Die Entscheidungsfähigkeit und -notwendigkeit<br />

bleibt jedoch beim Menschen.“<br />

Um die Systeme für Menschen beherrschbar zu machen,<br />

seien „neuartige Benutzerschnittstellen notwendig,<br />

die alle relevanten Daten zusammenführen und sie<br />

für den Entscheider in einer optimierten Darstellung zur<br />

Verfügung stellen, um Transparenz herzustellen und<br />

damit Entscheidungsbefähigung sicherzustellen“. Und<br />

infolge der Verlagerung von Entscheidungen aus der Managementebene<br />

in die produktionsnahen Bereiche „müssen<br />

sich Ausbildungs- und Studieninhalte ändern. Die<br />

Anzahl qualitativ hochwertig Aus- beziehungsweise<br />

Weitergebildeter wird steigen müssen“, so Bettenhausen.<br />

AUTOR<br />

GERD SCHOLZ<br />

arbeitet als freier Journalist<br />

für <strong>atp</strong> <strong>edition</strong>.<br />

DIV Deutscher Industrieverlag GmbH,<br />

Arnulfstraße 124, D-80636 München,<br />

Tel. +49 (0) 89 203 53 66 78,<br />

E-Mail: GerdScholz@t-online.de<br />

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

7-8 / 2014<br />

11


BRANCHE<br />

VDI-EHRENPLAKETTE GEHT AN PROF. GÖHNER<br />

Mit der bronzenen VDI-Ehrenplakette wurde beim<br />

Kongress Automation Prof. Peter Göhner ausgezeichnet.<br />

GMA-Vorsitzender Dr. Kurt D. Bettenhausen überreichte<br />

Göhner die Auszeichnung für sein außerordentliches<br />

ehrenamtliches Engagement in der Gesellschaft<br />

Mess- und Automatisierungstechnik (GMA).<br />

Unter anderem hat er das erste Leitbild der GMA im<br />

Jahr 2 000 mitentwickelt und die GMA-Aktivitäten zu<br />

„Agenten in der Automation“ entwickelt. Zudem hat<br />

er langjährig im Programmkomitee des Automatisierungskongresses<br />

mitgewirkt.<br />

Darüber hinaus hat sich Göhner für ein besseres<br />

Verständnis der Automation in der breiten Gesell<strong>atp</strong><br />

award 2013: Wushan Liang und Rando Meister<br />

als beste Nachwuchswissenschaftler geehrt<br />

Prof. Peter Göhner erhielt VDI-Ehrenplakette für Verdienste um die GMA<br />

<strong>atp</strong>-CHEFREDAKTEUR PROF. LEON<br />

URBAS (Mitte) überreichte den <strong>atp</strong><br />

award 2013 an Dr.-Ing. Thomas Hauff,<br />

Wushan Liang, Rando Meister und<br />

Prof. Alexander Fay (v.li.). Bild: Scholz<br />

500 BESUCHER kamen zur Automation 2014 und<br />

den beiden Schwesterkongressen. Bild: VDI<br />

Wushan Liang und Rando Meister sind die besten<br />

Nachwuchswissenschaftler, die 2013 in <strong>atp</strong> <strong>edition</strong><br />

veröffentlicht haben. Sie und ihre Autorenteams<br />

wurden mit dem <strong>atp</strong> award 2013 ausgezeichnet. Prof.<br />

Dr.-Ing. Leon Urbas, Chefredakteur der <strong>atp</strong> <strong>edition</strong>,<br />

übergab die Preise vor dem Plenum der Tagung Automation<br />

2014 in Baden-Baden. Die Jury bestehend aus<br />

Prof. Urbas und der Fachredaktion der <strong>atp</strong> <strong>edition</strong> hat<br />

die veröffentlichten Beiträge bewertet und jeweils<br />

einen Gewinnerbeitrag in den beiden Kategorien Industrie<br />

und Hochschule gewählt. In der Kategorie<br />

Industrie hat sich die Jury für den Beitrag „Genauigkeit<br />

von Messgeräten überwachen“ der Autoren<br />

Dr.-Ing. Thomas Hauff, Wushan Liang, Matthias<br />

Strauss (BASF SE), Prof. Christian Brecher und<br />

Matthias Strauss (RWTH Aachen) entschieden. Der<br />

Beitrag ist in der Ausgabe 1-2/2013 der <strong>atp</strong> <strong>edition</strong><br />

erschienen und beschreibt eine Strategie, die dabei<br />

hilft, das Driften von Messsignalen in Schutzeinrichtungen<br />

durch Vergleich redundanter Kanäle automatisch<br />

zu detektieren. Stellvertretend für das Autorenteam<br />

nahmen Hauff und Liang die Auszeichnung in<br />

Form einer Glaspyramide beim Automatisierungskongress<br />

entgegen. Das Preisgeld von jeweils 2 000 Euro<br />

erhält der jüngste Autor eines Teams, dieser darf nicht<br />

älter als 35 Jahre sein. In diesem Jahr geht es in der<br />

Kategorie Industrie daher an Wushan Liang.<br />

In der Kategorie Hochschule nahmen Prof. Alexander<br />

Fay und Rando Meister von der Helmut-Schmidt-<br />

Universität/Universität der Bundeswehr Hamburg die<br />

Auszeichnung und die Urkunden entgegen. Gemeinsam<br />

mit Dennis Cory (Deutscher Blinden- und Sehbehindertenverein<br />

e. V.) und Christian Ehring (RTB<br />

GmbH & Co. KG) veröffentlichten sie in der Ausgabe<br />

7-8/2013 der <strong>atp</strong> <strong>edition</strong> den Beitrag mit dem Titel<br />

„Bus-ID: Orientierung für Blinde an der Haltestelle“.<br />

Der Beitrag hat das Forschungsprojekt Bus-ID zum<br />

Thema, das durch eine RFID-basierte Orientierungshilfe<br />

eine Lösung für die barrierefreie Gestaltung von<br />

Verkehrsanlagen im öffentlichen Raum aufzeigt. Die<br />

Anwendung in der Praxis wurde in Feldtests des Prototypen<br />

an einer Bushaltestelle sowie an einem signalisierten<br />

Fußgängerüberweg überprüft. Als jüngster<br />

Autor des Teams erhält Meister das Preisgeld in Höhe<br />

von 2 000 Euro.<br />

12<br />

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

7-8 / 2014


Ihr Erfolg durch<br />

unsere Erfahrung<br />

PROF. PETER GÖHNER wurde für sein<br />

langjähriges Engagement geehrt (li.).<br />

Dr. Kurt D. Bettenhausen (re.). Bild: Scholz<br />

schaft eingesetzt. So hat er mit dem „Wunderland<br />

der Automatisierungstechnik“ an der Universität<br />

Stuttgart mit einleuchtenden Beispielen die Automation<br />

erklärt. Dazu zählen auch seine Ideen rund<br />

um das Thema Fußball. Ein Beispiel dafür ist der<br />

automatische Fußballtorwart Goalias. Der VDI<br />

würdigt mit der Ehrenplakette seit 1948 ehrenamtliche<br />

Mitarbeiter des Vereins.<br />

Stellungsregler Bauart 3730 und 3731<br />

• Komfortables Bedienen vor Ort und über<br />

Prozessleitsystem (HART ® , PROFIBUS-PA<br />

oder FOUNDATION fieldbus)<br />

• Robuste Anbausätze für Hub- und<br />

Schwenkantriebe<br />

• Geeignet für den <strong>Einsatz</strong> in sicherheitsgerichteten<br />

Kreisen (SIL 3 gem. IEC 61508)<br />

• Integrierte Ventildiagnose für Regel- und<br />

Auf/Zu-Armaturen (z. B. Teilhubtest (PST))<br />

• Global einsetzbar durch nationale und<br />

internationale Explosionsschutz-<br />

Zulassungen (Ex ia oder Ex d)<br />

AUTORIN<br />

Bewährte Stellungsregler mit<br />

hoher Regelgüte<br />

ALJONA HARTSTOCK<br />

ist Volontärin bei<br />

der <strong>atp</strong> <strong>edition</strong> im<br />

Deutschen Industrieverlag.<br />

DIV Deutscher Industrieverlag GmbH,<br />

Arnulfstraße 124, D-80636 München,<br />

Tel. +49 (0) 89 203 53 66 78,<br />

E-Mail: hartstock@di-verlag.de<br />

A01147DE<br />

SAMSON AG · MESS- UND REGELTECHNIK<br />

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

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

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

SAMSON GROUP · www.samsongroup.net


INTERVIEW<br />

DR.-ING.<br />

DAGMAR DIRZUS:<br />

Die neue Geschäftsführerin<br />

der VDI/<br />

VDE-Gesellschaft<br />

Mess- und Automatisierungstechnik<br />

will<br />

unter anderem ein<br />

einheitliches Verständnis<br />

innerhalb der<br />

Industrie zum Thema<br />

Industrie 4.0 vorantreiben.<br />

14<br />

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

7-8 / 2014


„Im realen <strong>Einsatz</strong> müssen<br />

wir den Nutzen belegen“<br />

Dr.-Ing. Dagmar Dirzus im Interview mit <strong>atp</strong> <strong>edition</strong><br />

<strong>atp</strong> <strong>edition</strong> sprach mit Dr.-Ing. Dagmar Dirzus am Rande der Automation 2014 über die Herausforderungen,<br />

die das Thema Industrie 4.0 für die GMA mit sich bringt. Dagmar Dirzus hat zum 1. Juni die Geschäftsführung<br />

der VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik von Dieter Westerkamp übernommen, der<br />

seit Beginn des Jahres den Bereich „Technik und Wissenschaft“ im VDI leitet.<br />

<strong>atp</strong> <strong>edition</strong>: Frau Dirzus, Sie haben die Geschäftsführung<br />

der GMA mitten in der „4. industriellen Revolution“ übernommen<br />

– was bedeutet Industrie 4.0 für die GMA?<br />

DAGMAR DIRZUS: Wir werden fortsetzen, was wir<br />

schon in Gang gebracht haben: Als VDI und GMA begleiten<br />

wir das Thema Industrie 4.0 bereits seit Jahren.<br />

Anfang 2013 – damals verantwortete ich beim VDI<br />

Wissensforum die Entwicklung von Tagungen zum Thema<br />

Automatisierung – haben wir mit unserem ersten<br />

Kongress zu Industrie 4.0 ein Zeichen gesetzt. Ein Jahr<br />

später folgte die Neuauflage und nun widmet sich die<br />

Automation 2014 dem Thema. Aktuell steht in der GMA<br />

die inhaltliche Arbeit im Vordergrund, um die „smarte“<br />

Produktion voranzubringen.<br />

<strong>atp</strong> <strong>edition</strong>: Wie strukturieren Sie diese inhaltliche Arbeit?<br />

DAGMAR DIRZUS: Im Februar 2013 hat die GMA den Fachausschuss<br />

7.21 zu Industrie 4.0 gegründet, den Prof. Ulrich<br />

Epple leitet. Bereits knapp ein Jahr zuvor hatte der<br />

FA 7.20 zu cyber-physischen Systemen (CPS) unter Leitung<br />

von Prof. Stefan Kowalewski die Arbeit aufgenommen.<br />

Intern koordinieren Dr. Heinz Bedenbender den FA<br />

7.21 und ich den FA 7.20. Dabei arbeiten wir eng zusammen.<br />

Beide Ausschüsse haben bereits mehrere White<br />

Paper zu ihren Themen veröffentlicht. Nun, zur Automation<br />

2014, haben wir den Statusreport zum Forschungsbedarf<br />

bei der CPS-basierten Automation vorgelegt.<br />

<strong>atp</strong> <strong>edition</strong>: Reichen die Aktivitäten über diese beiden<br />

Ausschüsse hinaus?<br />

DAGMAR DIRZUS: In einem neuen Fokusprojekt bündeln<br />

wir das gesamte relevante Know-how. In diesem Rahmen<br />

treffen sich die Leiter aller betroffenen Fachbereiche sowie<br />

die jeweiligen Fachausschussleiter im Zwei-Wochen-<br />

Rhythmus und leisten intensive inhaltliche Arbeit. Anders<br />

als die Plattform Industrie 4.0 können wir hier extrem in<br />

die Tiefe gehen und fachlich Wichtiges für die Community,<br />

aber auch für die Öffentlichkeit zur Verfügung stellen.<br />

Durch diese Konstellation vermeiden wir Überschneidungen,<br />

Doppelarbeit und ungewolltes Gegeneinanderarbeiten.<br />

Zudem stellt dieses Fokusprojekt eine Art<br />

Rundum-Radar für uns dar. Dort erfahren wir auch sehr<br />

schnell, was außerhalb der GMA, VDI-weit, in anderen<br />

Verbänden und der Plattform Industrie 4.0 geschieht.<br />

<strong>atp</strong> <strong>edition</strong>: Ändert Industrie 4.0 Strukturen und Vorgehensweisen<br />

in der GMA?<br />

DAGMAR DIRZUS: Im Zusammenhang mit Industrie 4.0<br />

testen wir viele neue Ansätze in Pilotanwendungen. Beispielsweise<br />

haben wir im Internet eine neue Landing Page<br />

zum Thema eingerichtet, auf der wir alle Aktivitäten und<br />

Bereiche des VDI gebündelt und auch Social Media integriert<br />

haben. Ebenso arbeiten wir an der Suchmaschinenoptimierung:<br />

Vor kurzem hatten wir es bei Google auf<br />

Rang vier in den Suchergebnissen zu „Industrie 4.0“ geschafft.<br />

Später sind wir auf Platz 14 abgerutscht. Hier<br />

sammeln wir sehr viele neue Erfahrungen.<br />

<strong>atp</strong> <strong>edition</strong>: Alle Welt spricht von Industrie 4.0 – aber ist<br />

der Fachöffentlichkeit überhaupt schon klar, was genau<br />

damit gemeint ist?<br />

DAGMAR DIRZUS: Klar und eindeutig definiert ist Industrie<br />

4.0 durch die „Plattform Industrie 4.0“ seit April 2013<br />

– belastbar und öffentlich zugänglich. Das ist die Definition,<br />

auf die wir uns verbändeweit geeinigt haben.<br />

<strong>atp</strong> <strong>edition</strong>: Ihre jüngste Umfrage unter den GMA-Mitgliedern<br />

zeigte allerdings, dass sich etwa jeder zweite nur ausreichend<br />

oder unzureichend darüber informiert fühlte ...<br />

DAGMAR DIRZUS: Es mag sein, dass viele Unternehmen,<br />

Universitäten oder Institutionen Industrie 4.0 für sich anders<br />

oder unklar definieren. Hier steuern wir mit dem<br />

Aufbau eines Glossars gegen. Das wird sich zu 99 Prozent<br />

auf die Plattform Industrie 4.0 und unsere Fachausschüsse<br />

stützen und dazu beitragen, ein einheitliches Verständnis<br />

zu schaffen.<br />

Bilder: Scholz<br />

<strong>atp</strong> <strong>edition</strong>: Stellt dieses Fokusprojekt einen singulären<br />

Ansatz da?<br />

DAGMAR DIRZUS: Es ist ein neues Vorgehen, das wir<br />

künftig auch auf andere Fachgebiete übertragen werden,<br />

sofern das im konkreten Fall Nutzen verspricht. Wir erkennen<br />

schon jetzt, dass hier ein großes Potenzial liegt.<br />

<strong>atp</strong> <strong>edition</strong>: Wie kommt es zu der Unsicherheit in den Unternehmen?<br />

DAGMAR DIRZUS: Ich glaube, es gibt zu viele Informationen<br />

von allen möglichen Seiten. Dabei ist „von allen möglichen<br />

Seiten“ hier das Problem: Wir haben es hier nicht<br />

nur mit fundierten, belastbaren Quellen zu tun. So entsteht<br />

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

7-8 / 2014<br />

15


INTERVIEW<br />

eine Verwirrung, die dazu führt, dass viele Unternehmen,<br />

vor allem aus dem Mittelstand, bei uns nachfragen, um<br />

Klarheit und zuverlässige Information zu bekommen.<br />

<strong>atp</strong> <strong>edition</strong>: Worin liegen die drei größten Herausforderungen<br />

bei der Umsetzung von Industrie 4.0?<br />

DAGMAR DIRZUS: Wir benötigen erstens Pilotprojekte in<br />

der realen Produktion, die den Nutzen des neuen Ansatzes<br />

belegen. Zum zweiten besitzt die Standardisierung<br />

eine hohe Bedeutung. Schließlich müssen wir die Information<br />

über das Thema verbessern, um in der Industrie<br />

das Interesse daran und in der Öffentlichkeit dessen Akzeptanz<br />

zu erhöhen.<br />

<strong>atp</strong> <strong>edition</strong>: Wie groß ist die Gefahr, dass Deutschland im<br />

weltweiten Wettbewerb den Anschluss verliert?<br />

DAGMAR DIRZUS: Wir befinden uns in einer sehr guten<br />

Ausgangsposition. Der Automatisierungsgrad ist hoch, weil<br />

wir kein Niedriglohnland sind, und die Mitarbeiter sind<br />

fachlich sehr gut qualifiziert. Aber wir, die Verbände, müssen<br />

mit den Unternehmen zügig Lösungen zur Umsetzung<br />

der Produktion der Zukunft erarbeiten. Hier ist Deutsch-<br />

<strong>atp</strong> <strong>edition</strong>: Sind diese Pilotprojekte schon in Sicht?<br />

DAGMAR DIRZUS: Derartige beispielhafte <strong>Einsatz</strong>fälle<br />

erwarten wir zunächst aus der Automobilindustrie, da<br />

dort relativ oft Anlagen neu geplant oder umgeplant werden<br />

müssen – nämlich jedes Mal, wenn ein Modellwech-<br />

sel stattfindet. Dort können wir also recht schnell sehen,<br />

was passiert, wenn man ein ganzheitliches Engineering<br />

einsetzt. Eine große Herausforderung stellt aktuell die<br />

sogenannte Diensteplattform dar: Um die Potenziale von<br />

Industrie 4.0 auszuschöpfen, muss eine solche Dienste-<br />

plattform die Kommunikation unterschiedlicher Software<br />

ermöglichen. Nur so wird es beispielsweise möglich, die<br />

Erkenntnisse aus dem realen Anlagenbetrieb in die Si-<br />

mulation zurückzuspielen und damit die Simulation für<br />

die nächste Inbetriebnahme zu verbessern.<br />

<strong>atp</strong> <strong>edition</strong>: Wie aktiv gehen Sie in die breite Öffentlichkeit?<br />

DAGMAR DIRZUS: Ich möchte nur ein Beispiel nennen:<br />

Kürzlich habe ich bei einer Anhörung im niedersächsischen<br />

Landtag erklärt, woum es sich bei Industrie 4.0<br />

handelt, warum das wichtig ist für Deutschland und für<br />

Niedersachsen und welche Aktivitäten bei uns zu diesem<br />

Thema laufen. Wir gehen hier stärker als bei anderen<br />

Themen an die Öffentlichkeit – und wir merken: Die Öffentlichkeit<br />

erwartet auch diese Informationen von uns.<br />

16<br />

<strong>atp</strong> <strong>edition</strong>: Wie lässt sich die Standardisierung voran-<br />

treiben?<br />

DAGMAR DIRZUS: Hier befinden wir uns noch ein Stück<br />

weit in einer Warteposition. Standardisierung lässt sich<br />

erst dann sinnvoll durchführen, wenn die Inhalte definiert<br />

sind, die es zu standardisieren gilt. Einen ersten Schritt<br />

dahin könnten Regelungen für die Diensteplattform bil-<br />

den. Daran arbeiten wir zurzeit.<br />

<strong>atp</strong> <strong>edition</strong>: Worin liegen die Hauptaufgaben<br />

im dritten Bereich, der Information und Kom-<br />

munikation?<br />

DAGMAR DIRZUS: In der Industrie geht es,<br />

wie ich schon erwähnte, darum, ein gemeinsames,<br />

einheitliches Verständnis des Themas<br />

zu schaffen. Für die breite Öffentlichkeit geht<br />

es sicher auch darum, wie Arbeit und Ar-<br />

beitsplätze durch Industrie 4.0 beeinflusst<br />

werden. Denn es ist noch nicht flächende-<br />

ckend angekommen, dass es keine menschenleere<br />

Fabrik geben wird, sondern dass<br />

die Arbeitsplätze erhalten und durch Industrie<br />

4.0 sogar gesichert werden. Zu diesem<br />

Thema richten wir nun einen Fachausschuss<br />

ein, in dem wir in Zusammenarbeit mit dem<br />

Fraunhofer IAO diese Frage detailliert beleuchten.<br />

Dort werden wir auch diskutieren,<br />

welche Qualifikation die Mitarbeiter künftig<br />

besitzen müssen. Den Ergebnisbericht wollen<br />

wir zur Automation 2015 vorlegen.<br />

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

7-8 / 2014


land mit hervorragenden Automatisierungsunternehmen,<br />

bei denen es sich um Global Player handelt, sehr gut aufgestellt.<br />

Aber wir müssen auch die Politik „mitnehmen“.<br />

Denn eine höhere Flexibilisierung, die schneller auf Kundenwünsche<br />

reagieren kann, erfordert vielleicht auch eine<br />

weitere Flexibilisierung der Arbeitszeitmodelle.<br />

<strong>atp</strong> <strong>edition</strong>: Wird Automatisierung nach der „4. industriellen<br />

Revolution“ eher ein Thema für IT-Spezialisten sein?<br />

DAGMAR DIRZUS: Mechanik, Elektrotechnik und IT müssen<br />

zusammenspielen. Ich glaube nicht, dass in den nächsten<br />

drei bis fünf Jahren der IT-Anteil zunehmen wird.<br />

Wichtig ist aber, dass die Experten aus allen drei Bereichen<br />

mit einander intensiv kommunizieren.<br />

<strong>atp</strong> <strong>edition</strong>: Maschinenbauer und IT-Experten haben nicht<br />

immer den besten Draht zu einander – funktioniert dieser<br />

Austausch in der GMA?<br />

DAGMAR DIRZUS: Ja, in unseren Fach-<br />

ausschüssen kommunizieren die unterschiedlichen<br />

Experten am Runden Tisch<br />

sehr konstruktiv und erarbeiten dort<br />

wichtige Ergebnisse.<br />

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

Sehen Sie sich im Nachteil,<br />

weil die GMA nicht in der „Plattform In-<br />

dustrie 4.0“ vertreten ist? Zur Teilnahme eingeladen hatte<br />

die Bundesregierung ja nur VDMA, ZVEI und Bitkom.<br />

DAGMAR DIRZUS:<br />

Nein. Auf der Fachebene – in unseren<br />

Ausschüssen und mit den anderen Verbänden – arbeiten<br />

wir sehr intensiv und erfolgreich und erzielen gute Ergebnisse.<br />

Der ZVEI beispielsweise hat zu den vier Arbeitsgruppen<br />

der Plattform „Spiegelgremien“ aufgesetzt, in denen<br />

sich ein Großteil der Personen wiederfindet, die auch in<br />

der Plattform aktiv sind, um inhaltlich nun schnell voran<br />

zukommen. In jedem dieser Gremien ist die GMA vertreten.<br />

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

Als wichtige Hürde für eine „smarte“ Produk-<br />

tion wird die Absicherung der Systeme gegen Angriffe<br />

gesehen. Wann wird es Lösungen geben?<br />

„In einem neuen Fokusprojekt bündeln wir das<br />

gesamte relevante Know-how, das in der GMA<br />

zum Thema Industrie 4.0 vorhanden ist.“<br />

DAGMAR DIRZUS: Die Bedeutung der IT Security haben<br />

die meisten Unternehmen sehr klar erkannt. Wie weit<br />

sie mit der Umsetzung sind, lässt sich schwer sagen.<br />

Gerade die kleineren Unternehmen beklagen oft hohe<br />

Kosten. Die erforderlichen Lösungen sind auf dem Markt<br />

verfügbar, aber sie müssen auch kostengünstiger werden,<br />

um sich flächendeckend zu etablieren. Eine wesentliche<br />

Aufgabe in diesem Feld ist die Sensibilisierung der<br />

Mitarbeiter für IT-Sicherheit. Denn unvorsichtiges Verhalten<br />

kann die technische Sicherheit oft aushebeln. An<br />

dieser Bewusstseinsbildung arbeiten wir. Aber wir sind<br />

im Bereich der IT-Sicherheit nicht der zentrale Player.<br />

Das Interview führten Aljona Hartstock und Gerd Scholz<br />

ZUR PERSON<br />

DR.-ING. DAGMAR DIRZUS<br />

(45) studierte Maschinenbau<br />

an der RWTH Aachen und<br />

promovierte im Werkzeugmaschinenlabor<br />

bei Prof. Gün-<br />

ther Schuh. Dort arbeitete sie in<br />

vielen Projekten auf dem Gebiet<br />

der Produktionsplanung, -simulation<br />

und -optimierung. Im Anschluss<br />

war sie im Wissenstransfer<br />

tätig, unter anderem als Ge-<br />

schäftsführerin des WZLforums<br />

sowie der International Academy<br />

der RWTH Aachen. 2012 begann<br />

Dirzus ihre Tätigkeiten im VDI Wissensforum<br />

und entwickelte VDI-<br />

Tagungen und Seminare im Bereich<br />

der Automation. Mitte 2013<br />

wechselte Sie als wissenschaftliche<br />

Mitarbeiterin zum VDI e.V. und<br />

koordinierte Fach- und Richtlinienausschüsse<br />

der VDI/VDE-Gesellschaft<br />

Mess- und Automatisierungstechnik<br />

GMA.<br />

Als Geschäftsführerin der GMA ist<br />

Dirzus nun verantwortlich für die<br />

gesamte ehrenamtliche Gemeinschaftsarbeit<br />

dieser Fachgesellschaft.<br />

Die GMA ist fachlicher Träger<br />

einer Vielzahl von Veranstaltungen<br />

im Gebiet der Mess- und<br />

Automatisierungstechnik sowie der<br />

Optischen Technologien. Etwa 50<br />

VDI/VDE-Richtlinien werden jährlich<br />

in den GMA-Gremien erarbeitet<br />

und veröffentlicht.<br />

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

7-8 / 2014<br />

17


BRANCHE<br />

AALE: Fachtagung an der Nahtstelle zwischen<br />

Hochschule und Industrie mit Wachstumspotenzial<br />

Elfte Konferenz an der OTH Regensburg mit 170 Teilnehmern – drei Student Awards verliehen<br />

Die AALE-Konferenz hat sich zu einem bewährten<br />

Forum für Hochschulprofessoren und Vertreter aus<br />

Wirtschaft und Industrie aus dem gesamten deutschsprachigen<br />

Raum entwickelt und dient zum Erfahrungsaustausch<br />

über moderne Konzepte, Entwicklungen<br />

und die Lehre in der Automatisierungstechnik.<br />

Die elfte AALE-Konferenz für Angewandte Automatisierungstechnik<br />

in Lehre und Entwicklung (AALE)<br />

lockte 170 Teilnehmer an die Ostbayerische Technische<br />

Hochschule (OTH) Regensburg. Die AALE sowie ihr<br />

Träger- und Förderverein VFAALE e. V. verstehen sich<br />

als Schnittstelle zwischen Hochschule und Industrie.<br />

Zwei Tage ging es an der OTH Regensburg darum,<br />

gemeinsam mit der Industrie die neuesten Erkenntnisse<br />

aus der Welt der Automation zu erfahren und Herausforderungen<br />

der Lehre und Forschung zu diskutieren.<br />

Neben zahlreichen Fachvorträgen und einer Postersession<br />

fand eine konferenzbegleitende Ausstellung namhafter<br />

Firmen statt, die die Möglichkeit bot, aktuelle<br />

Produktentwicklungen auf dem Gebiet der Automatisierungstechnik<br />

kennenzulernen. Zu den 17 Ausstellern<br />

zählte der DIV Deutscher Industrieverlag, der auch<br />

Printmedienpartner der AALE ist. Der zitierfähige Tagungsband<br />

zur AALE 2014 ist beim DIV erhältlich, ebenso<br />

wie die Tagungsbände früherer AALE-Konferenzen.<br />

FÜNF PLENAR- UND 30 FACHVORTRÄGE<br />

2014 wurden auf der Konferenz fünf Plenarvorträge<br />

und 30 Fachvorträge in drei parallelen Sessions gehalten.<br />

Deren Themen lauteten: Lehre, adaptive Systeme,<br />

Automatisierungssysteme und -lösungen, Modellbildung<br />

und Simulation, Kommunikation, mobile und<br />

kollaborierende Systeme, virtuelle Inbetriebnahme,<br />

Reglerentwurf, Robotik, Demonstratoren sowie Verifikation<br />

und Test. Alle Fachvorträge wurden in einem<br />

Blind-Review-Verfahren begutachtet und ausgewählt.<br />

Abgerundet wurde die Konferenz durch ein bunt gemischtes<br />

Begleitprogramm für die Teilnehmenden, die<br />

aus dem gesamten Bundesgebiet anreisten. Organisiert<br />

haben die Konferenz die Fakultät Maschinenbau und<br />

das Zentrum für Weiterbildung und Wissensmanagement<br />

(ZWW) der OTH Regensburg. „Wir freuen uns,<br />

dass die inzwischen elfte AALE-Konferenz erstmalig<br />

in Bayern stattfand und ein großer Erfolg war“, sagt<br />

Prof. Dr. Ralph Schneider von der Fakultät Maschinenbau<br />

der OTH Regensburg. „Als Fachkonferenz für industrielle<br />

Automation an der Nahtstelle zwischen<br />

Hochschule und Industrie besitzt sie ein hohes Wachstumspotenzial“,<br />

so Prof. Dr. Schneider.<br />

Bei der Verleihung der AALE Student Awards stand<br />

die Jury in der Kategorie Master/Diplom vor einer seltenen<br />

Situation. Die beiden besten eingereichten Arbeiten<br />

waren exakt gleich gut bewertet worden. Daher<br />

erhielten Daniel Geweth von der TH Mittelhessen sowie<br />

Josef Wittmann von der HS München beide die Auszeichnung.<br />

Gesponsert wurde das Preisgeld in Höhe<br />

von 1000 Euro von BASF. Geweth hatte sich mit der der<br />

Optimierung von Regelungsstrukturen für Parallelstrukturen<br />

befasst. Wittmanns Thema waren Drehzahlregelung<br />

und Fehlerdetektion für Fahrzeugschiebedächer<br />

mit Positionssensoren niedriger Auflösung unter<br />

Verwendung eines adaptiven Multiraten-Beobachters.<br />

In der Kategorie Bachelor erhielt Alexander-Nicolai<br />

Köhler von der HS Fulda die mit 500 Euro dotierte Auszeichnung<br />

für seine Arbeit zu Untersuchungen zur<br />

Regelung der relativen Luftfeuchte in einer Vitrine.<br />

Dieser Preis wurde von Phoenix Contact gestiftet.<br />

AB 2015 MIT OPTMIERTEM INHALTLICHEN KONZEPT<br />

Für die künftigen AALE-Konferenzen soll das inhaltliche<br />

Konzept etwas verändert werden. Das Konferenzprogramm<br />

konzentrierte sich bisher weniger auf eine<br />

übergreifende Fachspezifik, sondern mehr auf Fachbeiträge<br />

in Zusammenarbeit von Hochschulen und Industrie.<br />

Die meisten Fachbeiträge kommen aus Hochschulen,<br />

flankiert von einigen Plenarvorträgen aus Industrie<br />

und Verbänden zu übergreifenden Themen. Es<br />

werden Beiträge zu Themen aus allen Gebieten mit Bezug<br />

zur Automatisierungstechnik akzeptiert: Trends in<br />

der Automatisierungstechnik, Forschungs- und Entwicklungsarbeiten,<br />

Kooperationen zwischen Hochschule<br />

und Industrie sowie Lehre und Ausbildung, Didaktik<br />

und MINT-Projekte. Zukünftig soll die Konferenz nun<br />

stärker auf ein aktuelles Leitthema ausgerichtet werden.<br />

Die AALE 2015 findet vom 4. bis 6. März 2015 an der<br />

FH Jena statt. Die Organisation übernimmt der Fachbereich<br />

Elektro- und Informationstechnik in Zusammenarbeit<br />

mit dem VFAALE. In Jena werden zirka 200 Teilnehmer<br />

und 20 Industrieaussteller erwartet. Das Auswahlverfahren<br />

für die Beiträge wird verschärft (Double-Blind-Peer-Review),<br />

um die fachliche Qualität der<br />

Beiträge weiter zu erhöhen. Die Konferenz wird auch<br />

in Jena mit einem attraktiven Rahmenprogramm (Galadinner<br />

in der Sternwarte, historische Stadtführung,<br />

Besuch von Weimar) abgerundet. Die Teilnehmergebühr<br />

von 70 Euro wird nicht steigen.<br />

ZAHL DER MITGLIEDSFIRMEN SOLL WACHSEN<br />

Bis dahin hat sich der VFAALE einiges vorgenommen.<br />

Zu den Aufgaben, die sich Vorstand und Beirat gesetzt<br />

haben, gehören unter anderem die aktive Werbung weiterer<br />

Mitgliedsfirmen. Ende April lag der Mitgliederstand<br />

bei 47, davon 16 Unternehmen, ein Verlag, zehn Fachhochschulen<br />

und 20 Priv<strong>atp</strong>ersonen. Zudem soll erreicht<br />

werden, dass Mitglieder auf ihren Messeständen Werbung<br />

für den VFAALE machen. Organisiert werden soll<br />

auch ein Kurzbeitrag in allen relevanten Zeitschriften.<br />

Auch die gemeinsamen Aktivitäten mit Industrieverbänden<br />

sollen ausgebaut werden. So will man auch mit wichtigen<br />

Verbänden wie beispielsweise Namur, VDI/VDE-<br />

GMA, VDMA und ZVEI über eine Strategie der Zusammenarbeit<br />

und gemeinsame Aktivitäten diskutieren.<br />

18<br />

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

7-8 / 2014


BESTE BACHELOR-ARBEIT: Alexander-Nicolai Köhler von der<br />

HS Fulda erhielt einen AALE Student Award für seine Arbeit<br />

zur Regelung der relativen Luftfeuchte in einer Vitrine.<br />

35 VORTRÄGE<br />

zu Themen<br />

an der<br />

Schnittstelle<br />

zwischen<br />

Hochschule<br />

und Industrie<br />

hörten die<br />

Teilnehmer der<br />

AALE 2014.<br />

170 TEIL-<br />

NEHMER<br />

besuchten<br />

die elfte<br />

AALE-Fachkonferenz,<br />

die diesmal<br />

an der OTH<br />

Regensburg<br />

stattfand.<br />

BESTE MASTERARBEIT: Daniel Geweth von der TH Mittelhessen<br />

sowie Josef Wittmann von der HS München reichten<br />

die besten Arbeiten in der Kategorie Master/Diplom ein und<br />

wurden mit AALE Student Awards geehrt. Bilder: OTH Regensburg<br />

Zudem will sich der VFAALE als Mitorganisator<br />

oder Unterstützer von nationalen und internationalen<br />

Fachkonferenzen zur Automationstechnik profilieren.<br />

Diskutiert werden soll auch eine Zusammenarbeit mit<br />

dem neu gegründeten New Automation e. V. im Bildungsbereich.<br />

Zur Verbesserung der Zusammenarbeit<br />

zwischen Fachhochschulen und Universitäten im Bereich<br />

der Automatisierungstechnik soll ein Meeting<br />

des VFAALE-Vorstandes und des Beirats mit Universitätskollegen<br />

beitragen.<br />

In Zusammenarbeit mit dem AALE-Beirat soll der<br />

AALE Student Award öffentlich noch besser bekannt<br />

gemacht werden, damit die Zahl der Bewerbungen für<br />

den Preis weiter zunimmt. Ziel ist es, so viele Bewerbungen<br />

zu erreichen, dass insgesamt drei Preisträger<br />

in den Kategorien Projektarbeit, Bachelor-Arbeit und<br />

Master-Arbeit vergeben werden können. Die Akquise<br />

über die Hochschulen und deren Vertreter soll verstärkt<br />

werden. Das Begutachtungsverfahren wird 2014<br />

weiter optimiert.<br />

Der Vereinsvorstand wird zudem die Arbeit der AGs<br />

Bachelor und Promotion unterstützen. Das Ziel lautet<br />

hier, in 2014 ein Beispiel-Curriculum Bachelor zur breiten<br />

Diskussion zu entwickeln.<br />

Und nicht zuletzt wird sich der VFAALE aktiv an der<br />

Vorbereitung der AALE 2015 an der FH Jena beteiligen<br />

und die AALE 2015 auch wieder finanziell unterstützen.<br />

AUTOR<br />

GERD SCHOLZ<br />

arbeitet als freier Journalist<br />

für <strong>atp</strong> <strong>edition</strong>.<br />

DIV Deutscher Industrieverlag GmbH,<br />

Arnulfstraße 124, D-80636 München,<br />

Tel. +49 (0) 89 203 53 66 78,<br />

E-Mail: GerdScholz@t-online.de<br />

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

7-8 / 2014<br />

19


PRAXIS<br />

Intelligente Stromversorgungen erleichtern<br />

Prüfabläufe in der Forschung<br />

Im Fehlerfall erfolgt eine sichere Abschaltung<br />

DIE PRIMÄRSCHALTREGLER der 1,2-kW-Klasse<br />

eignen sich als Prüf-, Test- oder Laborgerät für<br />

Forschungseinrichtungen.<br />

DIE LEISTUNG DER STROMVERSORGUNG<br />

lässt sich programmieren.<br />

Zeit möglichst effektiv zu nutzen und gleichzeitig<br />

Fehlerquellen auszuschließen, ist eine Grundvoraussetzung<br />

für die meisten Test- und Prüfaufbauten oder<br />

Forschungsprojekte. Eine weitere Forderung ist oft eine<br />

große Flexibilität. Vielfach sollen mit ein und derselben<br />

Anordnung komplexe Betriebsabläufe, Kräfte- und Belastungsverläufe<br />

unter sich verändernden Rahmenbedingungen<br />

gefahren werden. Intelligente, über digitale<br />

und analoge Schnittstellen programmierbare Stromversorgungen<br />

werden hier zum Problemlöser. Diese Stromcomputer<br />

bearbeiten zuvor definierte Abläufe eigenständig<br />

und tragen auch in anderer Hinsicht dazu bei, den<br />

Gesamtaufwand zu minimieren. Das Spektrum reicht<br />

hier von der integrierten elektronischen Last bis hin zur<br />

funktionalen Sicherheit.<br />

FLEXIBLE STROMVERSORGUNG FÜR SIMULATIONEN<br />

Was haben Hochleistungsakkumulatoren, Motor-, Airbag-<br />

und Bordsteuergeräte, elektrische Antriebe oder<br />

Trafos gemeinsam? Sie alle werden umfangreichen, elektrischen<br />

Simulationsprüfungen unterzogen, um zu erkennen,<br />

wie die eingesetzten Bauteile auf sämtliche im<br />

späteren <strong>Einsatz</strong> vorkommenden Belastungsfaktoren<br />

reagieren. Dies erfordert flexible Prüfgeräte, die zum Beispiel<br />

bei Tests unter rauen Umgebungsbedingungen wie<br />

Feuchte-, Temperatur, Vibrationen oder Schocks das elektrische<br />

Umfeld nachbilden, um die Elektronik für den<br />

harten <strong>Einsatz</strong> zu prüfen. An die eingesetzten Stromversorgungen<br />

stellt dies besondere Anforderungen. Zum<br />

einen, weil sie die Voraussetzung für eine sichere und<br />

stabil den Vorgaben folgende Spannungsversorgung sind,<br />

die wiederum unabdingbar für reproduzierbare Testergebnisse<br />

ist. Zum anderen sollten die Stromversorgungen<br />

selbst ein hohes Maß an Flexibilität bieten.<br />

Unterschiedliche Geräte zu prüfen, bedeutete bisher<br />

auch unterschiedliche Anforderungen an die Stromversorgungen,<br />

die nicht nur stabile Ausgangsspannungen<br />

liefern, sondern auch auf den jeweiligen Leistungsbedarf<br />

abgestimmt sein müssen. Auf wechselnde<br />

Prüflinge oder Abläufe zu reagieren, war damit zeitaufwendig,<br />

zumal meist noch manuelle Einstellarbeiten<br />

zu erledigen waren. Bei den normalerweise üblichen,<br />

analog programmierbaren Stromversorgungen kann<br />

man lediglich Sollwerte aus der Ferne einstellen oder<br />

die jeweiligen Ist-Werte abfragen. Für viele Prüfabläufe<br />

sind diese Möglichkeiten keineswegs ausreichend und<br />

ein solches Vorgehen ist daher wenig praktikabel. Mit<br />

der Baureihe Energy 1200 bietet die Firma Kniel Stromversorgungen,<br />

die sich über unterschiedliche digitale<br />

Schnittstellen programmieren lassen.<br />

VON DER STROMVERSORGUNG ZUM „STROMCOMPUTER“<br />

Die Primärschaltregler der 1,2-kW-Klasse eignen sich<br />

dadurch als Prüf-, Test- oder Laborgerät. Der Anwender<br />

kann hier nicht nur für Strom, Spannung und Leistung<br />

Soll- und Grenzwerte definieren, sondern auch unterschiedliche<br />

Sequenzen programmieren, die die Stromversorgung<br />

dann selbsttätig abarbeitet. Auch die Pro-<br />

20<br />

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

7-8 / 2014


grammabläufe mehrerer Geräte lassen sich präzise<br />

synchronisieren, was bei größeren Anlagen viel Aufwand<br />

spart. Die für die jeweilige Aufgabe notwendigen<br />

Einstellungen werden zuvor programmiert und sind<br />

dann automatisch abrufbar. Man muss also während<br />

eines Ablaufs oder Versuchs an der Stromversorgung<br />

keine Einstellungen manuell verändern und kann bei<br />

verschiedenen Abläufen einfach zwischen innerhalb<br />

des Gerätes hinterlegten Programmen umschalten.<br />

Da die Geräte sowohl als Stromquelle als auch als<br />

Stromsenke arbeiten, sind Akkutests ein wichtiges <strong>Einsatz</strong>gebiet.<br />

Mit ihnen lassen sich dann zum Beispiel<br />

mehrere parallel geschaltete Batteriezellen sehr sensibel<br />

mit der notwendigen Spannung versorgen und präzise<br />

vorgegebene Lade- und Entladesequenzen zyklisch<br />

abarbeiten. Ein ebenfalls typischer Anwendungsbereich<br />

sind Bordnetzsimulationen im Bereich der Kfz-<br />

Elektronik. Hier kann die Stromversorgung zum Beispiel<br />

die temperaturabhängigen Eigenschaften von<br />

Batterien simulieren, ebenso wie den typischen Spannungseinbruch<br />

bei Motorstart oder beim Zuschalten<br />

starker Verbraucher wie zum Beispiel Klimaanlage oder<br />

Heckscheibenheizung. Praxisgerecht ist die integrierte<br />

Stromsenke beziehungsweise Entladeschaltung auch<br />

zur schnellen Entladung des Ausgangskreises. Ein Anwendungsbeispiel<br />

ist die Entladung der Rückspeisenergie,<br />

wenn Motoren im Bremsbetrieb geprüft werden.<br />

Damit die angeschlossene, empfindliche Elektronik<br />

beim Betrieb oder beim Testen nicht durch versehentlich<br />

falsch programmierte Sollwerte zerstört wird, können<br />

in der Stromversorgung Grenzwerte (Limits) eingestellt<br />

werden. Auf diese Weise werden untere und<br />

obere Spannungs- und Stromwerte für die Sollwerte<br />

begrenzt. Damit sich auch bei den eingestellten Istwerten<br />

kein bedrohlicher Betriebszustand für die Prüflinge<br />

ergeben kann, lassen sich Überwachungswerte<br />

(Protection) setzen. Diese Schutzfunktionen legen den<br />

unteren beziehungsweise oberen Spannungs-, Stromund<br />

Leistungsüberwachungswert fest. Wird ein Istwert<br />

außerhalb der zulässigen Fenstereinstellungen detektiert,<br />

gibt es eine Fehlermeldung und der Geräteausgang<br />

der Stromversorgung wird deaktiviert. Die Stromversorgung<br />

kann aber auch als Konstantstromquelle ohne<br />

Fensterbereich arbeiten. Zu diesem Zweck wird der<br />

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

Messtechnik Regeltechnik Steuerungstechnik Prozessleitsysteme<br />

Mittwoch, 17. September 2014<br />

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

Friedrich-Ebert-Halle<br />

Erzbergerstr. 89<br />

67063 Ludwigshafen<br />

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

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

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

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

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

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

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

www.meorga.de<br />

info@meorga.de<br />

MEORGA GmbH<br />

Sportplatzstraße 27<br />

66809 Nalbach<br />

Tel. 06838 / 8960035<br />

Fax 06838 / 983292<br />

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

7-8 / 2014<br />

21


PRAXIS<br />

CONDITION<br />

(ro)<br />

verzögerte WARNUNG<br />

EVENT<br />

(ro)<br />

FAULT INDICATION<br />

(ro)<br />

“CC“ aktiv<br />

1 1<br />

1<br />

3<br />

wird nichtinvertiert<br />

“1“ wird verzögert<br />

wird nicht<br />

weitergegeben<br />

weitergegeben<br />

weiterverarbeitet<br />

1 4,0 s<br />

3<br />

LOGIC<br />

(rw: 0/1/3)<br />

DELAY<br />

(rw: 0,005 .. 65535s)<br />

FAULT STATE<br />

(rw: 1/3)<br />

Einstellungen durch den Anwender<br />

EINSATZ ALS KONSTANTSTROMQUELLE: Das Gerät<br />

meldet, wenn der Stromregler länger als 4 s aktiv ist.<br />

CONDITION<br />

(ro)<br />

EVENT<br />

(ro)<br />

FAULT INDICATION<br />

(ro)<br />

“CV“ inaktiv<br />

0<br />

0 10 s<br />

1<br />

LOGIC<br />

(rw: 0/1/3)<br />

wird invertiert<br />

weitergegeben<br />

1<br />

DELAY<br />

(rw: 0,005 .. 65535s)<br />

“1“ wird verzögert<br />

weitergegeben<br />

1 1<br />

wird direkt<br />

weitergegeben<br />

FAULT STATE<br />

(rw: 1/3)<br />

ERROR<br />

(führt zur Abschaltung<br />

des Geräteausgangs)<br />

DER GERÄTEAUSGANG wird deaktiviert, wenn der<br />

Spannungsregler länger als 10 s inaktiv ist.<br />

Strom-, Spannungs- oder Leistungsregler überwacht.<br />

Bei inaktivem Regler wird dann eine entsprechende<br />

Meldung generiert.<br />

SICHERE ABSCHALTUNG IM FEHLERFALL<br />

Medizintechnische Anwendungen, Prüfaufbauten oder<br />

Fertigungseinrichtungen bei denen Anlagensicherheit<br />

eine wichtige Rolle spielt, können von weiteren Eigenschaften<br />

der Stromcomputer profitieren. So erfüllen die<br />

Stromversorgungen die Anforderungen nach funktionaler<br />

Sicherheit gemäß EN/IEC 62061 SIL2 und EN ISO<br />

13849-1, Performance Level (PL) d. Zwei geprüfte und<br />

zertifizierte Enable-Eingänge sorgen für eine sichere<br />

Abschaltung im Fehlerfall. Der Anwender muss also<br />

die Anlagen- oder Maschinensicherheit nicht über andere<br />

Wege realisieren; es reicht, die Stromversorgung<br />

abzuschalten. Gerade bei Test- und Prüfaufbauten kann<br />

sich so der Abnahmeaufwand deutlich reduzieren.<br />

Außerdem sind die Interlock-Funktionalität (Wiederanlaufsperre)<br />

des Enable-Eingangs und das Wiedereinschaltverhalten<br />

des Geräteausgangs (save power on)<br />

konfigurierbar; damit ist ein bewusstes Wiedereinschalten<br />

möglich. Der Anwender kann also wählen, wie die<br />

Stromversorgung nach einem Stillstand wieder starten<br />

soll. Sinnvoll in einigen Applikationen kann auch die<br />

bei Bedarf aktivierbare Ladestromkompensation sein.<br />

Ist sie aktiviert, wird der Stromsollwert automatisch so<br />

angepasst, dass an der angeschlossenen Last auch während<br />

der Ladephase der internen Ausgangskapazität der<br />

gesamte programmierte Strom verfügbar ist.<br />

PROGRAMMIERUNG AUCH AUS DER FERNE<br />

Die intelligenten Stromversorgungen lassen sich auch in<br />

anderen Bereichen einsetzen, zum Beispiel an Teilchenbeschleunigern<br />

(Beamlines) oder in der Lasertechnik.<br />

Sie sind für den rauen industriellen <strong>Einsatz</strong> ausgelegt<br />

und regeln sehr präzise. Integrierte Filter sorgen für geringe<br />

Ripple- und Störüberlagerung des Ausgangs. Im<br />

Temperaturbereich zwischen -20 und +50 °C kann die<br />

volle Nennleistung dauerhaft, also ohne Derating, entnommen<br />

werden. Die Geräte sind dauerkurzschlussfest<br />

und schalten sich bei thermischer Überlastung automatisch<br />

ab. Weitere Features sind ein Power-Fail-Signal,<br />

aktive Lastaufteilung bei Parallelschaltung oder Redundanzbetrieb<br />

mehrerer Stromversorgungen, Störmeldung<br />

bei Übertemperatur sowie eine 5-V-Hilfsspannung. Dank<br />

der intelligenten Stromversorgungen lassen sich folglich<br />

elektrische Simulationen, Prüfungen in vielen Bereichen<br />

effektiver und damit wirtschaftlicher gestalten, aber<br />

auch zahlreiche andere Abläufe, bei denen es auf eine<br />

präzise Versorgung ankommt, werden einfacher.<br />

Dazu trägt die Programmierung bei: Standardmäßig<br />

sind die Stromversorgungen mit RS232, USB und CAN-<br />

Open-Schnittstelle ausgestattet. LAN-Schnittstelle und<br />

die bereits erwähnte 5-V-Analog-Schnittstelle gibt es<br />

als Option. Bereits vorhandene analoge Messkarten der<br />

22<br />

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

7-8 / 2014


DIE STROMVERSORGUNG lässt sich aus der<br />

Ferne oder direkt am Gerät programmieren.<br />

ALS OPTION ist ein<br />

Handbedienteil erhältlich<br />

Bilder: Kniel<br />

Anwender lassen sich dann weiter nutzen. Falls gewünscht,<br />

kann man die Stromversorgungen auch<br />

direkt am Gerät oder mit einer als Option erhältlichen<br />

Handbedieneinheit programmieren. Letzteres<br />

kann in puncto Sicherheit Vorteile bringen, da<br />

am Gerät selbst dann nichts mehr versehentlich<br />

verstellt werden kann.<br />

AUTOR<br />

DIETER BRETSCHNEIDER<br />

ist Geschäftsführer<br />

bei Kniel System-Electronic<br />

GmbH in Karlsruhe.<br />

Kniel System-Electronic GmbH,<br />

Kurzheckweg 8, D-76187 Karlsruhe,<br />

Tel. +49 (0) 721 959 21 13,<br />

E-Mail: d.bretschneider@kniel.de


PRAXIS<br />

Neues Sicherheitsschaltgerät bietet Gesamtlösung<br />

in Vormontageanlagen bei Continental<br />

Geräte auf Anforderungen gemäß Europäischer Maschinenrichtlinie ausgelegt<br />

IM WERK FRANKFURT ging die neue<br />

Vormontageanlage P104 für ein kleines<br />

EBS-Ventil Ende 2013 in Betrieb –<br />

mit innovativer Sicherheitstechnik.<br />

MARKUS MÜLLER (li.), Leiter Energie- und<br />

Automatisierungstechnik bei Continental,<br />

und Jens Maurer (re.), Projekteur bei der<br />

Herbert Betz GmbH & Co. KG, sind sich einig:<br />

„Das neue Sicherheitsschaltgerät bringt<br />

uns viele Vorteile in Bezug auf Konstruktion,<br />

Verdrahtung, steuerungs technische<br />

Flexibilität und Service.“<br />

JEDE DOPPELSTATION in der Vormontageanlage<br />

besitzt einen Schaltkasten, weshalb<br />

der Vorteil des geringen Platz bedarfs beim<br />

<strong>Einsatz</strong> des neuen Sicherheitsschaltgeräts<br />

Sirius 3SK1 von Siemens sehr wichtig war.<br />

DAS SICHERHEITSSCHALT-<br />

GERÄT 3SK1 ist durch die vier<br />

Dip-Schalter an der Gehäusefront<br />

flexibel einsetzbar.<br />

Signalerweiterungen lassen<br />

sich über entsprechende Zusatzmodule<br />

ohne Verdrahtungsaufwand<br />

erreichen. Bilder: Siemens<br />

Elektronische Bremssysteme liegen im Trend, denn<br />

sie schaffen ein hohes Maß an Sicherheit für Fahrer<br />

und Fahrzeug. Continental gehört zu den führenden<br />

Herstellern solcher Systeme. Im Zuge von Produktionserweiterungen<br />

kam erstmals eine innovative Sicherheitslösung<br />

in den neuen Vormontagelinien zum <strong>Einsatz</strong>:<br />

ein modular erweiterbares Sicherheitsschaltgerät,<br />

das kompakt, flexibel sowie schnell zu installieren ist.<br />

Der Trend zu elektronischen Bremssystemen in Kraftfahrzeugen<br />

ist ungebrochen. Sie sorgen für ein sicheres<br />

Abbremsen bis zum Stillstand. Eines dieser elektronischen<br />

Module (EBS) heißt bei Continental MK100. Das<br />

Bremssystem ist skalierbar und kann an die Fahrzeuggröße<br />

angepasst werden. Diese Einheiten werden im Werk<br />

Frankfurt hergestellt. Der dazu notwendige Automatisierungsgrad<br />

ist hoch und liegt in diesem Bereich bei über<br />

95 Prozent. „Vor allem in der Vormontage zeigt sich die<br />

hohe Kunst, viele, teils extrem kleine Bauteile möglichst<br />

rationell und qualitätsbewusst zu verbauen“, sagt Markus<br />

Müller, Leiter der Abteilung Energie- und Automatisierungstechnik,<br />

im Werk Frankfurt von Continental.<br />

Im Zuge von Kapazitätserweiterungen wurde unter<br />

anderem eine neue Vormontagelinie für ein zirka 4 cm<br />

langes MK100-Ventil gebaut. Diese läuft seit Ende 2013<br />

im Produktivbetrieb. Bei Vormontagelinien für kleine<br />

Bauteile werden kurze Taktzeiten erreicht. „Nach meiner<br />

Erfahrung gehört die Vormontage zu den Königsdisziplinen<br />

innerhalb der Automatisierung, weil dort die<br />

Aufgabenstellung aus schnellen Zyklen und komplexen<br />

Kleinteilen sehr anspruchsvoll ist“, sagt Jens Maurer aus<br />

der Elektrokonstruktion bei der Herbert Betz GmbH &<br />

Co. KG in Schotten-Eschenrod bei Frankfurt.<br />

SICHERHEITSTECHNIK FÜR RISIKOBEURTEILUNG<br />

Der Dienstleister mit etwa 160 Mitarbeitern unterstützt den<br />

Automobilzulieferer seit vier Jahrzehnten gewissermaßen<br />

als verlängerte Werkbank bei der Entwicklung und dem<br />

Bau leistungsfähiger Produktionslinien. Wichtig ist neben<br />

der Produktivität die Anlagen- und Betriebssicherheit, die<br />

mit Hilfe moderner Sicherheitstechnik erreicht wird.<br />

Das Sicherheitsschaltgerät Sirius 3SK1 von Siemens<br />

kommt erstmals in der neuen Vormontagelinie zum Ein-<br />

24<br />

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

7-8 / 2014


satz. Jede der etwa 30 Stationen innerhalb der Vormontagelinie<br />

bekam eine eigene Risikobeurteilung gemäß<br />

Europäischer Maschinenrichtlinie, die die Sicherheitstechnik<br />

entsprechend komplex macht. „Kein Problem“,<br />

sagt Maurer, „denn die neuen Geräte sind genau für<br />

solche Aufgabenstellungen entwickelt worden.“ Einer<br />

der Vorteile des Geräts ist seine Breite von 22,5 mm, da<br />

in Vormontagelinien meist nur wenig Bauraum für die<br />

Elektrotechnik zur Verfügung steht. Kompakter ist das<br />

Advanced-Grundgerät Mini mit 17,5 mm Baubreite.<br />

RÜCKWANDBUS ERLEICHTERT SIGNALERWEITERUNGEN<br />

Ein sich selbst aufbauender Rückwandbus vereinfacht<br />

Signalerweiterungen. Erweiterungsmodule müssen<br />

nicht zusätzlich verdrahtet werden: Die Geräte werden<br />

nicht direkt auf der Hutschiene montiert, sondern auf<br />

den dazu gehörigen Träger gesteckt.<br />

Als weitere Verbesserung zu der bisher eingesetzten<br />

Lösung sehen die Experten auch die hohe Flexibilität des<br />

Sirius-3SK1-Geräts. Zum Beispiel mussten bisher eigene<br />

Lösungen eingesetzt werden, wenn es um die Überwachung<br />

der Schutztürkontakte ging. Denn das Sicherheitsschaltgerät<br />

für den Not-Aus-Taster war nicht in der Lage,<br />

Türkontakte mit Schließer-Öffner-Funktion zu überwachen.<br />

Das gleiche Problem bestand beim <strong>Einsatz</strong> von Reed-<br />

Kontakten. „Mit der neuen Lösung können wir sämtliche<br />

Türkontaktschalter, die wir hier standardmäßig einsetzen,<br />

mit einem einzigen Gerätetyp absichern“, sagt Müller.<br />

AN VIELEN STELLEN ZEIT SPAREN<br />

Die Betriebstechnik-Mitarbeiter brauchen außerdem weniger<br />

Zeit, wenn sie ein Gerät austauschen. Etwa 20 Prozent<br />

schneller gehe ein Wechsel, so die Einschätzung.<br />

Mehr Zeit werde bei der Elektrokonstruktion gespart.<br />

Der Grund dafür liegt in der Unterstützung durch die Firma<br />

Siemens, die viele der notwendigen Informationen wie<br />

Maße, CAD-Zeichnungen, Dokumentation und weitere im<br />

Daten-Workflow bereitstellt. Maurer sagt: „Seit wir unsere<br />

Elektrokonstruktion auf Eplan P8 umgestellt haben, lassen<br />

sich gewisse Arbeiten erheblich komfortabler erledigen.“<br />

Dazu gehört das Einlesen der so genannten EDZ(Eplan<br />

Data Zip)-Dateien, die Siemens für seine Geräte zur Verfügung<br />

stellt. Diese können über eigene Makros auf<br />

Knopfdruck in das System eingepflegt werden. Obwohl<br />

es Elektrokonstrukteure gewohnt sind, bei wiederkehrenden<br />

Bauteilen entsprechende Makros selbst zu<br />

schreiben, sieht Maurer jedoch einen Zeitvorteil von<br />

zirka 30 Prozent bei Verwendung der Siemens-Makros.<br />

Gegenüber der manuellen Suche aller benötigen Unterlagen<br />

beziehungsweise Zeichnungen und Informationen<br />

erkennt er bei der Verwendung der EDZ-Makros<br />

eine Zeitersparnis von rund 80 Prozent pro Gerät.<br />

GESAMTLÖSUNG FÜR JE ZWEI STATIONEN<br />

Der grundsätzliche Aufbau der Sicherheitstechnik in<br />

der neuen Vormontageanlage sieht vor, dass drei Si-<br />

cherheitsschaltgeräte jeweils zwei gleichartigen Stationen,<br />

die zur Minimierung der Zykluszeit notwendig<br />

sind, zugeordnet sind. Die Geräte befinden sich in<br />

einem Schaltkasten, der zu den beiden Stationen gehört.<br />

Ein Grundgerät überwacht die Schutztüren der<br />

beiden Stationen, jeweils ein weiteres Grundgerät überwacht<br />

die Not-Aus-Funktion in einer Station. Ideal ist<br />

deshalb aus Sicht der beiden Automatisierungsspezialisten<br />

die Möglichkeit der flexiblen Anpassung der<br />

Grundgeräte an die vorhandenen Aufgabenstellungen.<br />

Sie besitzen vier Dip-Schalter, welche die individuelle<br />

Zuordnung innerhalb der Sicherheitskette ermöglichen.<br />

Schalter eins ist bei der Anlage so eingestellt, dass<br />

nach dem Schließen der Schutztür ein automatischer<br />

Wiederanlauf erfolgt. Mit Dip-Schalter zwei lässt sich<br />

die Querschlusserkennung aktivieren, die bei der Anlage<br />

eingestellt ist. Mit der dritten Auswahlmöglichkeit<br />

wird definiert, ob zwei Sensoren einkanalig überwacht<br />

werden, oder ein Sensor zweikanalig, wie es bei der Vormontageanlage<br />

der Fall ist. Auch hier erweist sich das<br />

3SK1 als innovatives Gerät mit Rationalisierungspotenzial.<br />

Denn bei der bisherigen Lösung mit Sicherheitsschaltgeräten<br />

hätte man von zweikanalig auf einkanalig<br />

zusätzliche Hardwarebrücken verdrahten müssen.<br />

Und der vierte Dip-Schalter gibt dem Anlagenbetreiber<br />

die Freiheit, nach einem Stopp mit oder ohne Anlauftestung<br />

weiterzuarbeiten. Diese Option wird bei Continental<br />

dafür genutzt, um nach einer Stromabschaltung den<br />

Not-Aus-Taster auf seine Funktionsfähigkeit zu überprüfen.<br />

Erst wenn dieser gedrückt worden ist, gibt das Sicherheitsschaltgerät<br />

den Zyklus wieder frei.<br />

Es ist wahrscheinlich, dass die Vormontagelinie<br />

Nachahmer bekommt. „Oft konstruieren wir eine Montagelinie,<br />

die dann mehrfach vervielfältigt wird und in<br />

anderen Produktionswerken weltweit zum <strong>Einsatz</strong><br />

kommt“, sagen Müller und Maurer.<br />

AUTOR<br />

Dipl.-Ing. RALPH SCHADE ist<br />

Senior Projektmanager Branchenvertrieb<br />

Auto mobil im Bereich<br />

Industry Auto mation bei Siemens<br />

in Frankfurt.<br />

Siemens AG,<br />

Rödelheimer Landstr. 5-9,<br />

D-60478 Frankfurt am Main,<br />

Tel. +49 (0) 69 797 27 99,<br />

E-Mail: ralph.schade@siemens.com<br />

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

7-8 / 2014<br />

25


PRAXIS<br />

Intelligente Feldbusinstallationen bieten optimalen<br />

Fehlerschutz und maximale Anlagenverfügbarkeit<br />

Diagnosefähige Gerätekoppler der neuesten Generation erkennen und isolieren Störungen proaktiv<br />

ÜBERWACHUNG DER<br />

FELDBUSPHYSIK AN JEDEM<br />

AUSGANG: Die neue<br />

Feldbarriere kann auch<br />

schleichende Veränderungen<br />

in der Installation und Störungen melden.<br />

DIE ZUVERLÄSSIGKEIT STEIGT WEITER: Eine neue<br />

Generation von Feldbuskomponenten erlaubt einen<br />

weiteren Schritt zur 100-prozentigen Verfügbarkeit.<br />

FEHLER PROGRESSIV<br />

ERKENNEN UND ISOLIEREN:<br />

Der FieldConnex-Segment<br />

Protektor ist ein zentraler<br />

Baustein der intelligenten<br />

Feldbusinstallation in der<br />

Zone 2 oder in Bereichen<br />

ohne Explosionsschutz.<br />

Bilder: Pepperl+Fuchs<br />

Wenn es darum geht, Fehler proaktiv zu erkennen<br />

und sicher zu beherrschen, sind Intelligente Feldbusinstallationen<br />

das Mittel der Wahl. Mit einer neuen<br />

Generation diagnosefähiger Gerätekoppler ist nun das<br />

Ideal der hundertprozentigen Verfügbarkeit wieder einen<br />

Schritt näher gerückt.<br />

Wegen ihrer hohen Zuverlässigkeit sind Feldbussysteme<br />

in allen Bereichen der Prozessautomation im<br />

<strong>Einsatz</strong>. Doch selbst bei der verlässlichen Kommunikation<br />

über Feldbus kann es zu Fehlern kommen. In mehrjährigen<br />

Studien hat Pepperl+Fuchs daher genau untersucht,<br />

wie diese Fehlerszenarien aussehen und welche<br />

ganz konkreten Maßnahmen davor schützen. Die dabei<br />

gewonnenen Erkenntnisse sind nun in die neuen diagnosefähigen<br />

Gerätekoppler und die FieldConnex-Feldbarriere<br />

von Pepperl+Fuchs eingeflossen.<br />

AUCH SEHR SELTENE FEHLER WURDEN UNTERSUCHT<br />

Zu den Fehlern, die in der Praxis häufiger vorkommen,<br />

zählen Spannungsspitzen, die durch Blitzschlag entstehen.<br />

Auch langsame Änderung des Signalpegels<br />

durch eindringende Feuchtigkeit oder Kontaktprellen<br />

zählen zu den typischen Fehlerszenarien.<br />

Wird zum Beispiel ein Kabel beim Gerätetausch im<br />

laufenden Betrieb durch die Verschraubung gezogen,<br />

kann es zu einem kurzschließenden Prellen kommen.<br />

Treten diese stark dynamischen elektrischen Impulse<br />

nur sehr kurz auf, sind davon nur einzelne Feldbustelegramme<br />

betroffen – aufgrund der im Protokoll definierten<br />

Wiederholung der Datenübertragung bleibt eine<br />

solche Störung ohne Folgen. Dauert das Prellen aber<br />

länger an, kann es zu Kommunikationsfehlern mit<br />

mehreren Teilnehmern kommen. Derartige Störungen<br />

können im schlimmsten Fall sogar zum ungewollten<br />

Abschalten der gesamten Anlage führen.<br />

Doch nicht nur solche eher typischen Szenarien wurden<br />

in den Studien untersucht. Es galt auch, Fehlern<br />

auf die Spur zu kommen, deren Auftreten relativ unwahrscheinlich<br />

ist. Selbst wenn Anlagenbetreiber<br />

kaum mit solchen Vorkommnissen rechnen müssen, ist<br />

es doch entscheidend, sie beherrschbar zu machen. Nur<br />

so ist es möglich, die maximale Verfügbarkeit einer<br />

Anlage zu gewährleisten.<br />

STÖRUNGEN VORAUSSCHAUEND HANDHABEN<br />

Ein sicherer Weg, diese Fehlerszenarien zu beherrschen,<br />

ist eine vorausschauende und automatisierte<br />

Handhabung von Fehlern durch intelligente Installation.<br />

Dabei passt sich die Feldbusinfrastruktur durch<br />

fehlertolerante Technologie den tatsächlichen Anforderungen<br />

im täglichen Betrieb an. Für den Anwender<br />

heißt das zum Beispiel: Geräteaustausch mit maximalem<br />

Komfort, ohne zusätzliche Vorkehrungen und ohne<br />

das Risiko eines Segmentausfalls.<br />

26<br />

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

7-8 / 2014


Wichtiger Bestandteil solch intelligenter Feldbusinstallationen<br />

sind die diagnosefähigen FieldConnex-<br />

Gerätekoppler, deren neueste Generation eigens dafür<br />

entwickelt wurde, Fehler proaktiv zu erkennen und zu<br />

isolieren, bevor sie zu einem Ausfall führen können.<br />

So gewährleisten sie, dass die Anlage vor einer Vielzahl<br />

der genannten Fehler geschützt ist. Auf diese Weise<br />

wird beispielsweise auch sichergestellt, dass Wartungsarbeiten<br />

an der Installation ohne negative Rückwirkung<br />

auf den Anlagenbetrieb bleiben.<br />

FieldConnex-Gerätekoppler erkennen die spezielle<br />

Dynamik von Signalen, die durch Kontaktprellen, oder<br />

durch die Vibration loser Kontakte hervorgerufen werden<br />

und können diese von regulären Feldbussignalen<br />

unterscheiden. So sind sie in der Lage, typische Mängel<br />

in der Installation zu finden und zu isolieren. Der betroffene<br />

Ausgang wird vorübergehend abgeschaltet, um<br />

die Feldbuskommunikation vor Störungen zu schützen.<br />

DER PHYSICAL LAYER WIRD OPTIMAL ÜBERWACHT<br />

Selbst schwer aufzuspürende temporäre Fehler, wie<br />

zum Beispiel nachlassende Signalpegel bei eindringendem<br />

Regenwasser, werden so gefunden und isoliert.<br />

Der Physical Layer wird auf diese Weise optimal überwacht,<br />

zeitraubende Fehlersuche wird vermieden und<br />

die Anlagenverfügbarkeit deutlich erhöht.<br />

Noch sicherer, zuverlässiger und für den Nutzer noch<br />

komfortabler werden die Feldbusinstallationen im Betrieb<br />

künftig durch die neue FieldConnex-Feldbarriere<br />

(R4D0-FB-IA). Denn mit diesem neuen Baustein ist erstmals<br />

eine Überwachung der Feldbusphysik an jedem<br />

Ausgang der Feldbarriere möglich. So können auch<br />

schleichende Veränderungen in der Installation und<br />

Störungen in die Leitwarte gemeldet werden. Dieses<br />

Monitoring gewährleistet ein noch höheres Maß an<br />

Transparenz und schließt eine wichtige Lücke in der<br />

Überwachung, denn es zeigt notwendigen Instandhaltungsbedarf<br />

proaktiv auf.<br />

Eine entscheidende Neuerung ist auch das ausgefeilte<br />

Lastmanagement der Feldbarriere. Die zwölf Ausgänge<br />

starten sequentiell und mindern damit die Belastung<br />

der Stromversorgung durch den Einschaltstrom. Erreicht<br />

der Segmentstrom kritische Werte, erfolgt ein<br />

automatischer Lastabwurf der weniger kritischen Busteilnehmer<br />

und schützt so vor dem Ausfall des ganzen<br />

Segments.<br />

FELDBARRIERE MIT SELBSTÜBERWACHUNG<br />

Komplettiert wird die integrierte Intelligenz durch die<br />

Selbstüberwachungsfunktion der Feldbarriere, die<br />

ebenfalls Meldungen in die Leitwarte übertragen<br />

kann. Die Feldbarriere selbst wird typischerweise in<br />

Zone 1/Div. 2 installiert. Feldinstrumente können in<br />

Zone 0/Div. 1 installiert werden.<br />

Auch der FieldConnex-Segment Protektor verfügt<br />

über die Fähigkeit, Fehler progressiv zu erkennen und<br />

zu isolieren. Damit ist er ebenfalls ein zentraler<br />

Baustein jeder intelligenten Feldbusinstallation in der<br />

Zone 2 oder in Bereichen ohne Explosionsschutz. Die<br />

neue, überarbeitete Version (F2-SP-IC) im kompakten<br />

Aluminiumgehäuse ist der kleinste Gerätekoppler, der<br />

auf dem Markt verfügbar und so besonders für beengte<br />

Verhältnisse geeignet ist. Die Form der Anschlüsse<br />

kann frei gewählt werden – möglich sind Federzugoder<br />

Schraubklemmen.<br />

STATUS-LEDS JEDERZEIT VON AUSSEN SICHTBAR<br />

Ein Plus in puncto Anlagensicherheit und komfortabler<br />

Handhabung stellt auch das neue LED-Konzept dar: Die<br />

Status-LEDs sind dank des neuen Gehäusedesigns zu<br />

jeder Zeit von außen sichtbar. Das ermöglicht die<br />

schnelle Diagnose auf einen Blick und spart sowohl<br />

Zeit als auch Kosten bei der Wartung vor Ort.<br />

Der neue FieldConnex-Segment-Protektor ist geeignet<br />

für den <strong>Einsatz</strong> in Zone 2/Div. 2 und im Nicht-Ex-<br />

Bereich. Die Geräteanschlüsse sind eigensicher Ex ic<br />

für die Zone 2/Div. 2. Gesichert mit zusätzlichen<br />

Zündschutzarten für den Explosionsschutz können<br />

auch in Zone 1/Div. 1 eingebaute Feldgeräte angeschlossen<br />

werden.<br />

Beide FieldConnex-Gerätekoppler arbeiten völlig autark<br />

und ganz ohne Konfiguration. Sie ergänzen die<br />

Familie der diagnosefähigen Intelligent Fieldbus-Komponenten<br />

in idealer Weise. Die innovativen Features<br />

sind ein weiterer, wichtiger Schritt auf dem Weg zum<br />

Ideal der hundertprozentigen Verfügbarkeit.<br />

AUTOR<br />

ANDREAS HENNECKE<br />

ist Produktmarketingmanager<br />

im Geschäftsbereich<br />

Prozessautomation<br />

bei Pepperl+Fuchs.<br />

Pepperl+Fuchs GmbH,<br />

Lilienthalstraße 200, D-68307 Mannheim,<br />

Tel. +49 (0) 621 776 16 01,<br />

E-Mail: ahennecke@de.pepperl-fuchs.com<br />

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

7-8 / 2014<br />

27


HAUPTBEITRAG | AUTOMATION 2014<br />

<strong>Einsatz</strong> <strong>robotergeführter</strong><br />

<strong>Patientenliegen</strong><br />

Exakte Dosisapplikation in der Strahlentherapie möglich<br />

Variiert die Gewebelage schnellteilender Tumorzellen während der Radiotherapie<br />

als Konsequenz nicht abstellbarer physiologischer Vorgänge, wie durch Atmung, so<br />

lässt sich eine optimale Dosisverteilung nicht gewährleisten. Bestenfalls kann eine<br />

Anpassung des Fokusbereichs an die statistische Positionsverteilung des Tumorgewebes<br />

vorgenommen werden, wobei jedoch auch gesundes Gewebe hohen Strahlendosen<br />

ausgesetzt wird. In einem Voruntersuchungsprojekt wurden bereits die Grundlagen<br />

für die Technologie einer robotergeführten Patientenliege für den <strong>Einsatz</strong> in<br />

der Radiotherapie entwickelt. Mit deren Hilfe ergab sich eine signifikante Reduktion<br />

der Strahlenbelastung gesunder Gewebebestandteile aufgrund von Bewegungen<br />

physiologischen Ursprungs.<br />

SCHLAGWÖRTER Robotergeführte Patientenliege / Strahlentherapie / Bewegungskompensation<br />

Application of a Robot-driven Examination Table –<br />

Exact dose Distribution in Radiotherapy<br />

Due to the variation of the position of the tissue of fast dividing tumour cells during<br />

radiotherapy as a consequence of physiological processes, e.g. respiration, optimum<br />

dose distribution cannot be guaranteed. Currently it is at best possible to adjust the<br />

area of focus to the statistical position distribution of the target tumour cells. However,<br />

this means that healthy body tissue around the tumour will also be exposed<br />

to high radiation doses. In a pre-examination project, the principles for the technology<br />

of a robot driven examination table have been developed. This makes it possible<br />

to significantly reduce the radiation exposure of healthy tissue in the case of<br />

physiological movements.<br />

KEYWORDS robot driven operating table / radiotherapy / motion compensation<br />

28<br />

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

7-8 / 2014


ANDRÉ DUFFE, HENRY ARENBECK, DIRK ABEL, RWTH Aachen University<br />

Radiotherapie ist eine etablierte Technik zur<br />

selektiven Zerstörung schnellteilender Tumorzellen,<br />

deren Anwendung stets eine Schädigung<br />

gesunder Zellen nach sich zieht. Ist<br />

die Lage des zu bestrahlenden Tumors unveränderlich<br />

und bekannt, so kann mit Hilfe mathematischer<br />

radiologischer Modelle ein Therapieplan ausgearbeitet<br />

werden, der eine exakte Dosisapplikation und<br />

somit eine minimale radiologische Belastung gesunder<br />

Zellen gewährleistet. Variiert die Gewebelage während<br />

der Bestrahlung als Konsequenz nicht abstellbarer physiologischer<br />

Vorgänge, wie Atmung, Herzschlag oder<br />

Verdauung, so lässt sich bis heute eine optimale Dosisverteilung<br />

nicht gewährleisten. In der medizinischen<br />

Praxis wird bestenfalls eine Anpassung des Fokusbereichs<br />

der Bestrahlung an die statistische Positionsverteilung<br />

des zu zerstörenden Tumorgewebes vorgenommen.<br />

Dies bedeutet eine Ausdehnung des Fokusbereiches<br />

so weit, dass das Tumorgewebe zu jedem Zeitpunkt<br />

in diesem Bereich enthalten ist. Diese Praxis hat<br />

zur Folge, dass gesundes, den Tumor umlagerndes<br />

Gewebe hohen Strahlendosen ausgesetzt wird, was die<br />

Nebenwirkungen der Radiotherapie verschärft und in<br />

einigen Fällen eine Anwendung dieser Therapieform<br />

unmöglich macht.<br />

In einem Voruntersuchungsprojekt „Roboterbasierte<br />

Systeme zur Simulation und Kompensation physiologischer<br />

Bewegungen für den <strong>Einsatz</strong> in der Radiotherapie“<br />

wurden von Forschern der RWTH Aachen,<br />

dem Universitätsklinikum Aachen und Mitarbeitern<br />

der Kuka Laboratories GmbH Grundlagen für eine<br />

Technologie einer Patientenliege für den <strong>Einsatz</strong> in<br />

der Radiotherapie entwickelt. Mit deren Hilfe kann im<br />

Fall von Bewegungen physiologischen Ursprungs der<br />

Zielgewebestrukturen eine signifikante Reduktion der<br />

Strahlenbelastung gesunder Gewebebestandteile erreicht<br />

werden. Die Grundlagen bestehen aus vier Komponenten.<br />

Die erste Komponente stellt eine robotergeführte<br />

Patientenliege dar, die den Patienten während<br />

der Therapie vor dem Beschleuniger positioniert.<br />

Zweitens agiert das iMSS als Messsystem, das während<br />

der Bestrahlung die Atemlage des Patienten misst<br />

und die kartesische Tumorposition als Messwert in<br />

Echtzeit zur Verfügung stellt. Die dritte Komponente<br />

ist ein Motion Compensation Modul (MCM). Dabei<br />

handelt es sich um ein regelungstechnisches Algorithmen-Framework,<br />

das aus den Messdaten des iMSS die<br />

zukünftige Atemlage prädizieren kann und modellprädiktive<br />

Regler beinhaltet, die genutzt werden können,<br />

um durch eine geeignete Aktorik die Patientenatmung<br />

zu kompensieren. Die vierte Komponente stellt<br />

das 4-D-Phantom dar, welches eine Parallelkinematik<br />

zur Messung der Bestrahlungsintensität von bewegten<br />

Bestrahlungszielen ermöglicht und mehrdimensionale<br />

Bewegungen präzise abbildet. Diese Komponente<br />

macht den Prozess der 4-D-Radiotherapie von der Validierung<br />

eines 4-D-CT-Datensatzes bis zur Verifikation<br />

der resultierenden Dosisapplikation an einem Lungentumormodell<br />

experimentell darstellbar und überprüfbar.<br />

Die vier Komponenten ergeben kombiniert eine Patientenliege,<br />

die gestützt durch mathematische Modelle<br />

der humanen Physiologie aktiv Gewebebewegungen<br />

therapiebegleitend kompensieren kann. Durch Integration<br />

einer solchen Patientenliege in ein Radiotherapiesystem<br />

und die damit ermöglichte exakte Dosisapplikation<br />

in bewegten Zielstrukturen lassen sich die Therapieverträglichkeit<br />

(Reduktion der Schädigung gesunden<br />

Gewebes) und die Therapieeffizienz signifikant<br />

steigern, da sich das Potenzial verkürzter Genesungsphasen,<br />

reduzierter Behandlungszeiten und verbesserter<br />

Behandlungsresultate ergibt.<br />

1. KOMPENSATION VON TUMORBEWEGUNGEN<br />

Respirationsbedingte Tumorbewegungen, ausgelöst<br />

durch Atembewegungen des Patienten, erweitern das<br />

Planning Target Volume (PTV) und verursachen eine<br />

geringere Effektivität der Bestrahlung. 4-D-Bestrahlungsmethoden<br />

haben eine höhere Effektivität der Behandlung<br />

zum Ziel, die durch die Anpassung der<br />

Strahlungsübertragung an die Tumorbewegung während<br />

der Therapie erreicht werden soll.<br />

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

7-8 / 2014<br />

29


HAUPTBEITRAG | AUTOMATION 2014<br />

Dies kann durch eine Manipulation der Position des<br />

Linearbeschleunigers [1] oder der Position des Patienten<br />

mit Hilfe eines Roboters realisiert werden. In<br />

jedem Fall muss die verwendete Aktorik schwere<br />

Massen mit hohen Beschleunigungen verfahren und<br />

dabei eine hohe Präzision gewährleisten, um respirationsbedingte<br />

Tumorbewegungen zu kompensieren.<br />

Die Regelung für eine solche Kompensation benötigt<br />

einen nicht kausalen Regler, der die vorausgesagten<br />

Tumorpositionen miteinbezieht, um eine Phasenverschiebung<br />

und Verzögerung der Roboterbewegung,<br />

der Datenverarbeitung und des Datentransfers gewährleisten<br />

zu können.<br />

Die Prädiktion der Tumorposition kann mit Hilfe<br />

von verschiedenen Techniken, beispielsweise mittels<br />

eines adaptiven Filters [2,3], eines Regressionsmodels<br />

[4,5] sowie eines Fuzzy-Systems [6] ermöglicht werden.<br />

Allen Methoden ist gemein, dass sich die Resultate<br />

der Prädiktion mit jeder neuen Messung der Tumorposition<br />

verändern. Diese Variation innerhalb der<br />

Prädiktion muss vom Regler toleriert werden. Im<br />

Voruntersuchungsprojekt wurden zwei Regelungsarten<br />

mit dem Industrieroboter getestet: Es wurde (1)<br />

eine Vorsteuerung (FFS) und (2) eine modelprädiktive<br />

Regelung (MPC) genutzt. Zur Validierung wurden die<br />

Spezifikationen der Anwendung in der Radiotherapie<br />

durch repräsentative Tests, das Modellieren einer<br />

vorhergesagten Prädiktionsvariation und die Messung<br />

des Fehlers bei der Regelung betrachtet. Dieser<br />

Fehler beschreibt die räumliche Abweichung zwischen<br />

der Referenz- und der tatsächlichen lokalisierten<br />

Tumorposition als Worst-Case-Fehler bei der Dosisverteilung.<br />

2. METHODEN<br />

Referenzsignals des Reglers modelliert. Für jeden<br />

Zeitschritt wurde durch einen zufälligen Arbeitsprozess<br />

ein Abweichungssignal erstellt, das dann mittels<br />

eines exponentiell steigenden, bei null startenden<br />

Faktors gemessen wurde und anschließend durch einen<br />

Tiefpass-Filter lief. Zu jedem Zeitschritt wurde<br />

das assoziierte (zeitvariierende) Abweichungssignal<br />

zu der zukünftigen Trajektorie des ursprünglichen<br />

Referenzsignals hinzugefügt, um das verfälschte Referenzsignal<br />

des Reglers zu erstellen. Die Zusammenstellung<br />

der Abweichungssignale zeigt Bild 1. Die<br />

Intraprädiktionsvarianz, x, wurde als die maximale<br />

Variation des Abweichungssignals bei Tref/8 relativ zu<br />

Aref definiert, wobei Tref die allgemeine Dauer des<br />

Atemzyklus und Aref die allgemeine Amplitude des<br />

Referenzsignals darstellt. Die Interprädiktionsvarianz,<br />

y, wurde als die maximale Distanz zwischen den<br />

Outputs der zufälligen Wege von zwei erfolgreichen<br />

Zeitschritten relativ zu der Breite des Bereichs der<br />

zufälligen Wege definiert. Die Intraprädiktionsvarianz<br />

variierte zwischen x ∈ [0, 7.5, …, 75] %. Die Interprädiktionsvarianz<br />

wurde zwischen y ∈ [10, 80] %<br />

variiert.<br />

2.3 Modellieren des Roboters und der Regelung<br />

FFC und MPS wurden in Simulink/Matlab implementiert<br />

und auf ein xPC-Target übertragen. Das Übertragungsverhalten<br />

zwischen den Soll- und Ist-Achsstellungen<br />

der Roboterachsen wurde mittels ARX-Modellen<br />

erfasst. Die Vorsteuerung wurde zuerst ohne zusätzlichen<br />

Regler implementiert und zeigte bereits<br />

eine sehr gute Nachführung von Referenztrajektorien.<br />

Allerdings wies die Vorsteuerung eine leichte Regelabweichung<br />

auf, weshalb ein Regelkreis mit integra-<br />

2.1 Aufnahme von Testdaten<br />

Die Testdaten wurden mit einem Vicon MX Motion<br />

Capture-System mittels einer Anordnung von 10 Kameras<br />

aufgenommen. Dabei wurde die Position von<br />

24 körperfremden Strukturen in Form von Markern<br />

ermittelt, die auf der Brust und dem Bauchraum einer<br />

gesunden, männlichen Person in horizontaler Position<br />

verteilt waren. Eine repräsentative Marker-Trajektorie<br />

von zweiminütiger Dauer wurde ausgewählt, die<br />

die tatsächlichen, spontanen Atembewegungen widerspiegelt.<br />

Durch die Projektion der kartesischen<br />

Trajektorie in seine Hauptbewegungsrichtung wurde<br />

ein eindimensionales Referenzsignal für die Regelung<br />

erzielt.<br />

2.2 Modellieren der Prädiktionsvarianz<br />

Die Prädiktionsvarianz wurde durch ein unstrukturiertes<br />

Verfälschen der zukünftigen Trajektorie des<br />

BILD 1: Histogramm der Abweichungssignale (farbig)<br />

und eines exemplarischen Abweichungssignals<br />

(schwarz) für eine feste Intraprädiktionsvarianz x<br />

30<br />

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

7-8 / 2014


tivem Anteil benötigt wurde. Hier wurde ein PI-Regler<br />

ausgewählt, da er aufgrund des proportionalen Anteils<br />

eine schnellere Regelung ermöglicht. Für die modellprädiktive<br />

Regelung wurde das identifizierte ARX-<br />

Modell verwendet. Die Abtastzeit beträgt aufgrund des<br />

Robotertaktes 12 ms.<br />

3. VERSUCHE UND ERGEBNISSE<br />

3.1 Quantifizierung des Positionsfehlers<br />

Das Ergebnis der Messung der Trajektorientreue mit<br />

einem Trackingsystem kann als relativer Worst-Case-<br />

Fehler der Dosisverteilung zu der PTV als ein Resultat<br />

der Tumorbewegung bezogen auf die optimale<br />

Dosisverteilung eines stationären Tumors interpretiert<br />

werden. Der Fehler wird im Folgenden als medizinischer<br />

Fehler bezeichnet. Diese Annahme basiert<br />

auf der Annahme eines kugelförmigen Tumors<br />

mit einem Radius von 10 mm und 2 s Bestrahlungsdauer.<br />

In Bild 2 ist das Ergebnis der Messung der Trajektorientreue<br />

dargestellt. Es werden die drei Fälle (1) keine<br />

Regelung, (2) FFC und (3) MPC verglichen. Ohne<br />

Regelung wird ein medizinischer Fehler von 13,47 %<br />

erreicht. Mit Reglern liegt dieser Fehler immer unter<br />

2,5 % – die Abhängigkeit von der Intraprädiktionsvarianz<br />

und Interprädiktionsvarianz ist in Bild 3 dargestellt.<br />

Bild 3 zeigt, dass FFC bezogen auf die Interprädiktionsvarianz<br />

weniger Robustheit als MPC ausweist.<br />

Nichtsdestotrotz erzielen beide Regler zufriedenstellende<br />

Resultate im Zusammenhang mit der 4-D-Radiotherapie.<br />

Ein Nachteil von beiden Techniken ist ihre<br />

starke Abhängigkeit von einem ausreichend akkuraten<br />

Modell des geregelten Systems. Wie dargestellt, kann<br />

ein solches Modell durch Systemidentifikationstechniken<br />

erhalten werden, während es jedoch vom Roboter<br />

und seinem Arbeitspunkt abhängt. Dementsprechend<br />

kann die erneute Konfiguration des internen<br />

Modells des Reglers von Roboter zu Roboter, von Patient<br />

zu Patient und sogar von Behandlung zu Behandlung<br />

nötig sein, um zufriedenstellende Resultate zur<br />

Regelung der Lokalisierung zu erhalten.<br />

Im nächsten Schritt wird bei diesem Projekt die<br />

Robustheit von FFC und MPC in Bezug auf Modellunsicherheiten<br />

und die resultierende Komplexität der<br />

praktischen Anwendung dieser Regler beurteilt.<br />

Ebenso werden alternative Regelungsmethoden angewandt<br />

und getestet, die zukünftig weniger Modellgenauigkeit<br />

voraussetzen. Mögliche Methoden sind<br />

dafür die repetitive Regelung und die Iterative Learning-Regelung.<br />

FAZIT<br />

Basierend auf den beschriebenen Untersuchungen<br />

lässt sich zusammenfassen, dass die Vorsteuerung mit<br />

PI-Regler und die MPR für das Nachführen von Atemtrajektorien<br />

im Vergleich zum Fall, dass kein Regler<br />

verwendet wird, den medizinischen Fehler verringern.<br />

Diese Regler eignen sich somit für das Nachführen<br />

von Atemtrajektorien. Für größere Amplituden<br />

erwiesen sich die Regler als stabil hinsichtlich des<br />

medizinischen Fehlers. Dieser stieg mit der Amplitude<br />

nur moderat an. Der Vergleich des medizinischen<br />

Fehlers mit Atemtrajektorien mit besonderer Charakteristik<br />

ergab keine abweichende Bewertung der Regelungsverfahren<br />

und bestätigte damit die bisherigen<br />

Ergebnisse. Ein genauer Vergleich der geeigneten Regler<br />

ergibt, dass die MPR den kleinsten medizinischen<br />

BILD 3: Darstellung des medizinischen Fehlers<br />

in Abhängigkeit von der Intraprädiktionsvarianz<br />

und Interprädiktionsvarianz<br />

BILD 2: Ergebnis. rot: Referenz,<br />

türkis: keine Regelung, grün: FFC, blau: MPC<br />

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

7-8 / 2014<br />

31


HAUPTBEITRAG | AUTOMATION 2014<br />

AUTOREN<br />

Dipl. Wirt.-Ing. ANDRÉ DUFFE (geb. 1983)<br />

studierte Wirtschaftsingenieurwesen an<br />

der RWTH Aachen und an der Universiti<br />

Sans Malaysia, Penang/Malaysia. Anschließend<br />

war er wissenschaftlicher<br />

Mitarbeiter am Werkzeugmaschinenlabor<br />

der RWTH Aachen, wo er als Teamleiter<br />

die Arbeitsgruppe Bildgebende Verfahren<br />

und modelbasierte Messtechnik leitete.<br />

Seit 2013 ist er wissenschaftlicher Mitarbeiter am Institut für<br />

Regelungstechnik der RWTH Aachen. Dort ist André Duffe<br />

der Referent des Profilbereich Mobility & Transport Engineering<br />

der RWTH Aachen und Leiter des Projektes „Robotergeführte<br />

Patientenliege für den <strong>Einsatz</strong> in der Strahlentherapie“.<br />

Institut für Regelungstechnik RWTH Aachen,<br />

D-52056 Aachen, Tel. +49 (0) 241 802 80 12,<br />

E-Mail: A.Duffe@irt.rwth-aachen.de<br />

Fehler aufweist, gefolgt von der Vorsteuerung mit PI-<br />

Regler. Die Totzeitvorsteuerung weist von den drei<br />

Regelungsverfahren den größten Fehler auf. Allerdings<br />

bewegen sich diese Unterschiede in allen Testfällen<br />

in einem Bereich des medizinischen Fehlers von<br />

unter 1 %. Die drei Regelungsverfahren können hinsichtlich<br />

des medizinischen Fehlers als nahezu gleichwertig<br />

betrachtet werden.<br />

Weitere Untersuchungen sind bereits geplant. In<br />

einem ersten Schritt werden verschiedene reale Prädiktoren<br />

implementiert und die Regelungsverfahren mit<br />

diesen getestet. Nach der Auswahl eines Prädiktors wer-<br />

den die Regelungsverfahren mit einem größeren Roboter<br />

an einem realen Patienten appliziert werden, um zu<br />

überprüfen, ob sich hieraus neue Erkenntnisse für die<br />

Wahl des Reglers ergeben.<br />

MANUSKRIPTEINGANG<br />

23.06.2014<br />

Im Peer-Review-Verfahren begutachtet<br />

Univ.-Prof. Dr.-Ing. DIRK ABEL (geb. 1958)<br />

ist seit 2001 leitender Professor des<br />

Lehrstuhls und Instituts für Regelungstechnik<br />

sowie Sprecher des Profilbereichs<br />

„Mobility and Transport Engineering“.<br />

Außerdem ist er stellvertretender Vorsitzender<br />

der VDI/VDE-Gesellschaft für<br />

Mess- und Automatisierungstechnik<br />

(GMA). Prof. Abel studierte Maschinenbau<br />

am Institut für Regelungstechnik an der RWTH, wo er auch<br />

promovierte. Anschließend arbeitete er als Oberingenieur am<br />

Institut für Regelungstechnik und habilitierte über rechnergestützte<br />

Automatisierungstechnik.<br />

Institut für Regelungstechnik RWTH Aachen,<br />

D-52056 Aachen, Tel. +49 (0) 241 802 75 01,<br />

E-Mail: D.Abel@irt.rwth-aachen.de<br />

Dipl. Ing. HENRY ARENBECK (geb. 1979)<br />

studierte Maschinenbau an der Universität<br />

Duisburg-Essen und der Universität<br />

von Arizona. Im Zuge seiner Tätigkeit als<br />

wissenschaftlicher Mitarbeiter am Institut<br />

für Regelungstechnik der RWTH Aachen<br />

leitete er über zwei Jahre die Arbeitsgruppe<br />

„Medizintechnik“. Seine Arbeitsgebiete<br />

umfassen die Robotik sowie<br />

modellbasierte regelungstechnische Verfahren im Kontext<br />

der Strahlen therapie, Rehabilitation und Intensivmedizin.<br />

Institut für Regelungstechnik RWTH Aachen,<br />

D-52056 Aachen, Tel. +49 (0) 241 802 80 13,<br />

E-Mail: H.Arenbeck@irt.rwth-aachen.de<br />

REFERENZEN<br />

[1] Adler Jr., J.R., Chang, S.D, Murphy, M.J., Doty, J.,<br />

Geis, P., Hancock, S.L..: The Cyberknife:<br />

A Frameless Robotic System for Radiosurgery.<br />

Stereotactic and Functional Neu-rosurgery 69,<br />

S. 124-128, 1998<br />

[2] Riaz, N., Shanker, P., Wiersma, R., Gudmundsson, O.,<br />

Mao, W., Widrow, B., Xing, L.: Predicting respiratory<br />

tumor motion with multi-dimensional adaptive filters<br />

and supprt vector regression. Physics in medicine<br />

and Biology 54 (Nr. 19), S. 5735-5748, 2009<br />

[3] Ramrath, L., Schlaefer, A., Ernst, F., Dietrich, S.,<br />

Schweikard, A.: Prediction of respiratory motion<br />

with a multi-frequency based Extended Kalman<br />

Filter. International Journal of CARS Suppl. 1 (Nr. 2),<br />

S. 56-58, 2007<br />

[4] Ruan, D., Fessler, J.A., Balter, J.M.: Real-time<br />

prediction of respiratory motion based on local<br />

regression methods. Physics in medicine and<br />

biology 52 (Nr. 23), S. 7137, 2007<br />

[5] Ernst, F., Schweikard, A.: Forecasting respiratory<br />

motion with accurate online support vector<br />

regression (SVRpred). International Journal of<br />

CARS 4 (Nr. 5), S. 439-447, 2009<br />

[6] Otto, P.: Fuzzy-basierte Zeitreihenvorhersage<br />

(Fuzzy-based Time Series Forcasting). At-Automatisierungstechnik<br />

48 (Nr. 7), S. 327, 2000<br />

32<br />

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

7-8 / 2014


<strong>atp</strong> Kompaktwissen<br />

Band 1 –<br />

Erfolgreiches Engineering<br />

Hrsg. Frank Schiller, 1. Auflage 2010, 138 Seiten, Broschur<br />

Buch + CD-ROM für € 79,–<br />

ISBN 978-3-8356-3210-3<br />

Band 3 –<br />

Praktische Messtechnik<br />

Hrsg. Frank Schiller, 1. Auflage 2010, 70 Seiten, Broschur<br />

Buch + CD-ROM für € 59,–<br />

ISBN 978-3-8356-3213-4<br />

Band 5 –<br />

Industrielle Informationssicherheit<br />

Hrsg. Leon Urbas, 1. Auflage 2014, 80 Seiten, Broschur<br />

Buch für € 59,–<br />

ISBN 978-3-8356-7113-3<br />

<strong>atp</strong> kompakt Kollektion (Bände 1-6)<br />

€ 299,80<br />

ISBN 978-3-8356-7146-1<br />

Band 2 –<br />

Effiziente Kommunikation<br />

Hrsg. Frank Schiller, 1. Auflage 2010, 70 Seiten, Broschur<br />

Buch + CD-ROM für € 59,–<br />

ISBN 978-3-8356-3212-7<br />

Band 4 –<br />

Automation in der Wasserbranche<br />

Hrsg. Frank Schiller, 1. Auflage 2010, 146 Seiten, Broschur<br />

Buch + CD-ROM für € 59,–<br />

ISBN 978-3-8356-3226-4<br />

Band 6 –<br />

Safety in der Praxis<br />

Hrsg. Leon Urbas, 1. Auflage 2014, 112 Seiten, Broschur<br />

Buch für € 59,–<br />

ISBN 978-3-8356-7115-7<br />

DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München<br />

www.di-verlag.de<br />

Jetzt bestellen!<br />

Bestellung per Fax: +49 (0) 201 Deutscher / 82002-34 Industrieverlag GmbH oder | Arnulfstr. abtrennen 124 und | 80636 im München Fensterumschlag einsenden<br />

Ja, ich bestelle gegen Rechnung 3 Wochen zur Ansicht<br />

___ Ex. <strong>atp</strong> kompakt Kollektion (Bände 1-6)<br />

ISBN: 978-3-8356-7146-1 für € 299,80 (zzgl. Versand)<br />

Firma/Institution<br />

___ Ex.<br />

___ Ex.<br />

___ Ex.<br />

___ Ex.<br />

___ Ex.<br />

___ Ex.<br />

<strong>atp</strong> kompakt<br />

Band 1 – ISBN: 978-3-8356-3210-3 für € 79,– (zzgl. Versand)<br />

Band 2 – ISBN: 978-3-8356-3212-7 für € 59,– (zzgl. Versand)<br />

Band 3 – ISBN: 978-3-8356-3213-4 für € 59,– (zzgl. Versand)<br />

Band 4 – ISBN: 978-3-8356-3226-4 für € 59,– (zzgl. Versand)<br />

Band 5 – ISBN: 978-3-8356-7113-3 für € 59,– (zzgl. Versand)<br />

Band 6 – ISBN: 978-3-8356-7115-7 für € 59,– (zzgl. Versand)<br />

Vorname, Name des Empfängers<br />

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

Land, PLZ, Ort<br />

Antwort<br />

Vulkan-Verlag GmbH<br />

Versandbuchhandlung<br />

Postfach 10 39 62<br />

45039 Essen<br />

Telefon<br />

E-Mail<br />

Telefax<br />

Branche / Wirtschaftszweig<br />

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

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

Zur Wahrung der Widerrufsfrist genügt die rechtzeitige Absendung des Widerrufs oder der Sache an die Vulkan-Verlag GmbH,<br />

Versandbuchhandlung, Huyssenallee 52-56, 45128 Essen.<br />

Ort, Datum, Unterschrift<br />

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

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.<br />

PAATPK2014


HAUPTBEITRAG | AUTOMATION 2014<br />

Cloud-enabled Automation<br />

Systems using OPC UA<br />

Extension and Evaluation of Communication in OPC UA<br />

Emerging applications like smart grids and the Internet of Things pose new challenges<br />

to industrial systems. A drawback of OPC UA in the context of cloud-based applications<br />

are its client-server based communication concept and challenges due to<br />

firewalls, proxies, dynamic IP addresses, NATs and client-lookup strategies. Our aim<br />

is to interleave OPC UA with web and cloud technologies. We extended the communication<br />

concept of OPC UA and provide an evaluation of various protocols that serve<br />

as an additional transport layer underneath OPC UA.<br />

KEYWORDS OPC UA / Automation / Cloud / Web technologies / XMPP / WebSockets<br />

Automationssysteme in der Cloud auf der Basis von OPC UA –<br />

Erweiterung und Analyse der Kommunikation in OPC UA<br />

Neuartige Anwendungen wie Smart Grids und Internet-of-Things stellen industrielle<br />

Steuerungssysteme vor neue Herausforderungen wie das Zusammenspiel aus<br />

dem Client-Server basierten Konzept von OPC UA und Firewalls, NATs, dynamischen<br />

IP-Adressen, Client-Lookup Strategien und Proxies. In dieser Arbeit wurde das<br />

Kommunikationskonzept von OPC UA erweitert und mit Webtechnologien wie XMPP<br />

und WebSockets verknüpft, um eine Anbindung von OPC UA basierten Systemen<br />

an die Cloud zu ermöglichen. Die Anwendbarkeit und Leistungsfähigkeit wurde<br />

anhand einer prototypischen Implementierung betrachtet.<br />

SCHLAGWÖRTER OPC UA / Automation / Cloud / Webtechnologien / XMPP /<br />

WebSockets<br />

34<br />

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

7-8 / 2014


JOHANNES SCHMITT, THOMAS GOLDSCHMIDT, PHILIPP VORST, ABB Forschungszentrum<br />

The targeted scenario focuses on automation<br />

systems where an application (or service) in<br />

the cloud has to communicate and interact<br />

with field devices on a site (for example a building<br />

or plant). With “the cloud” we denote a<br />

data centre with infrastructure for cloud computing [6],<br />

connected to the Internet or a private network. One or<br />

more of the following exemplary applications can be<br />

assumed:<br />

Remote control: As long as requirements like delay<br />

constraints and reliability are met, a remote logic in<br />

the cloud can be used to control elements on site.<br />

The advantages of a cloud-based approach are the<br />

global view of aggregating the information of multiple<br />

sites and virtually unlimited CPU power based<br />

on scalable infrastructure. Another benefit is the<br />

easy integration of mobile devices like smartphones.<br />

Cloud historian: A data historian in the cloud is of<br />

special interest when a virtually infinite amount<br />

of data should be stored and/or data should be stored<br />

securely in a remote location because of (legal)<br />

data backup requirements.<br />

Service platform: The cloud type “Platform as a<br />

Service” (PaaS) provides a modular software concept<br />

and common interfaces as a basis for additional<br />

services, to obtain an extensible system architecture.<br />

The advantage of a cloud is the flexibility<br />

to provide virtually unlimited resources for the<br />

services which process the data obtained from the<br />

devices.<br />

OPC UA defines a meta-data model and interfaces to the<br />

data model. Using an OPC UA based communication<br />

between the cloud and a site provides full access to the<br />

information of the OPC UA server(s) at the site. Without<br />

any media breach like mapping or protocol conversion,<br />

a cloud application can make use of the functionality<br />

of the OPC UA server on the site. As OPC UA is powerful<br />

in terms of extensibility of its data model and semantic<br />

self-description of the information, this approach<br />

is flexible and future proof.<br />

A cloud application needs an OPC UA client in order<br />

to access the data provided by an OPC UA server deployed<br />

locally at a site or building. As a major extension to<br />

its predecessor OPC, OPC UA provides binary or XMLencoded<br />

messages over TCP or HTTP(S) [1]. This makes<br />

OPC UA routable, platform-independent and much more<br />

flexible – especially for Internet-based or cloud-based<br />

applications [2]. Since OPC UA uses a client-server based<br />

communication concept, the client starts the connection<br />

to the server (“A” in Figure 1). Following this communication<br />

principle, OPC UA has to cope with firewalls, dynamic<br />

IP-addresses, NATs and client-lookup strategies.<br />

The common approach of the protocols XMPP and<br />

WebSockets is to establish the connection from the<br />

local-side and re-use this existing connection from the<br />

cloud-side in order to access services [4] behind firewalls<br />

(as depicted in Figure 1 with “B”). While XMPP<br />

follows an asynchronous message-queue based principle<br />

using an intermediate message broker, WebSockets<br />

are employed for synchronous direct calls.<br />

1. CONCEPT / PROTOTYPE DESIGN<br />

We have extended the client-server principle of the OPC<br />

UA stack by mechanisms which allow for bidirectional<br />

communication. This extension enables a cloud to local-side<br />

communication over a previously established<br />

local to cloud-side connection (as depicted in Figure 1<br />

with “B”).<br />

As another extension we developed a prototype for<br />

an “OPC UA proxy server” which provides transparent<br />

access (for example for other cloud applications) to multiple<br />

client-side OPC UA servers through the cloud-side<br />

OPC UA client (comparable to the concept of an aggregating<br />

server [3], but without replication). This proxy<br />

server concept aims to provide a central point for communication<br />

in the cloud for both the OPC UA servers<br />

connecting to the cloud and the cloud applications<br />

requiring access to the information on the OPC UA servers.<br />

The prototyped OPC UA proxy server shown in<br />

Figure 2 provides multiple mechanisms to manage the<br />

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

7-8 / 2014<br />

35


HAUPTBEITRAG | AUTOMATION 2014<br />

access to remote OPC UA servers as they are commonly<br />

available for other cloud services. These mechanisms<br />

comprise connection management, remote node management,<br />

subscription and alarm/event management<br />

as well as access management. However for this work<br />

we will further focus on the aspects of communication<br />

towards the local infrastructure.<br />

1.1 Integration of WebSockets<br />

For our implementation of the WebSocket protocol we<br />

have used the Jetty-WebSocket (Version 8) libraries – as<br />

they provide both an API for a WebSocket server as well<br />

as for a WebSocket client (which is not always included,<br />

as the client part is typically JavaScript based).<br />

Our WebSocket implementation is designed to allow<br />

bidirectional communication. Therefore, a common<br />

element in our implementation manages and holds all<br />

established WebSocket connections for later use.<br />

A flag in the WebSocket settings decides how to<br />

handle the WebSocket connection:<br />

Server-Flag: Opens a WebSocket server at the given<br />

URL<br />

Client-Flag: If no connection to the given URL<br />

exists, the WebSocket tries periodically to connect<br />

to the WebSocket server at the given URL.<br />

This approach makes it possible to decide whether the<br />

OPC UA client should be the WebSocket server and the<br />

OPC UA server the WebSocket client or vice versa.<br />

In addition, an OPC UA client can re-use an existing<br />

connection. Using this concept it is possible to use the<br />

same connection for an OPC UA server and for an OPC<br />

UA client on the same machine. This is usefulin cloud<br />

technologies, where a cloud-application can be bound<br />

to only one port or on a smartphone providing its sensors<br />

as nodes within a built-in OPC UA server and at<br />

the same time using the connection to the OPC UA<br />

client for a connection to the proxy server.<br />

1.2 Integration of XMPP<br />

For the integration of the XMPP protocol, one of the<br />

most popular implementations of XMPP was used:<br />

Smack from Ignite Realtime (http://www.igniterealtime.org).<br />

The XMPP server which was used later as<br />

broker to setup the connection between multiple clients<br />

– called Openfire - is also from Ignite Realtime.<br />

Some embedded and lightweight implementations of<br />

XMPP exist – which makes it especially interesting for<br />

applications in the area of Internet of Things (IoT) [5]<br />

and for OPC UA as the consortium announced on the<br />

roadmap for 2015.<br />

Both the OPC UA server and the OPC UA client act<br />

as XMPP client – they initially create an XMPP connection<br />

to the XMPP server. The transport protocol in<br />

Smack is based on a modular concept. Here two modules<br />

were integrated and used:<br />

org.jivesoftware.smack.XMPPConnection: this is<br />

the default long-lived XMPP specific TCP protocol.<br />

This connection type has the ability to enable<br />

the SecurityMode (using SSL “XMPP-SSL” or<br />

another, XMPP-specific security mechanism<br />

“XMPP-SEC”).<br />

org.jivesoftware.smack.BOSHConnection: this module<br />

provides a bidirectional data transport based<br />

on (long living) HTTP requests. While using the<br />

“XMPP-BOSH” based transport, an HTTP proxy<br />

can be configured and enables bidirectional communication<br />

through an enterprise HTTP proxy.<br />

2. PERFORMANCE EVALUATION<br />

As a proof-of-concept and for a performance analysis,<br />

we integrated and tested our system on local machines,<br />

private clouds, embedded devices, mobile devices and<br />

public clouds. The analysis comprises a comparison of<br />

traditional OPC UA over TCP and HTTPS with the new<br />

approaches of OPC UA over XMPP and WebSockets. In<br />

addition, we also analysed the impact of parallel requests,<br />

different security configurations and also the<br />

usage of XMPP over BOSH which allows traversing<br />

HTTP proxies.<br />

All the following results show the delay for a requestresponse<br />

scenario reading a node value at the OPC UA<br />

server– this means it represents the sum of the delays<br />

for message encoding, message processing and transport<br />

on the client and the server. Unless mentioned otherwise,<br />

the results show the average delays per requestresponse<br />

observed over 10 000 test-runs with one thread.<br />

2.1 Protocol overhead comparison<br />

Both new approaches, XMPP and WebSockets wrap the<br />

OPC UA encoded data as payload in their protocol. However<br />

they use and provide various mechanisms for<br />

communication and transport management.<br />

Figure 3 shows as comparison of the different transport<br />

means on a local machine, focusing on the plain<br />

protocol overhead. OPC.TCP (SEC) with a delay of about<br />

0.45 ms can be seen as a reference value which will<br />

typically be applied in OPC UA based systems. The OPC.<br />

TCP (SEC) uses its own mechanisms for signing and<br />

encrypting the data (similar to but not based on SSL).<br />

HTTPS denotes the other OPC UA transport protocol<br />

included in the official OPC UA stack. It uses regular<br />

HTTP over SSL. Like typical HTTP based approaches,<br />

this protocol also uses a new connection per request<br />

and base64 for encoding, which makes it slower than<br />

OPC.TCP. Pure HTTP was not tested, because OPC UA<br />

36<br />

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

7-8 / 2014


FIGURE 1: Old (A)<br />

and new (B)<br />

communication<br />

concept in OPC UA<br />

FIGURE 3: Delay for an OPC UA request-response<br />

FIGURE 2: OPC UA proxy server<br />

FIGURE 4: Average delay on Raspberry and Android<br />

uses pure HTTP only in combination with the XML<br />

encoding, which is currently not supported by the<br />

OPC UA Java stack.<br />

Typically XMPP uses also a binary TCP transport mechanism<br />

– but with the necessity to use a base64 encoding<br />

in order to wrap the binary data into an XML container.<br />

This and the additional hop over the XMPP server (on the<br />

same PC) make XMPP slower than OPC.TCP. In comparison<br />

to HTTPS this approach is faster – which may be<br />

because it re-uses previously established connections.<br />

XMPP can be used in two secure modes: XMPP-SSL uses<br />

a (deprecated) approach by applying a SSL connection to<br />

the XMPP server, while XMPP-SEC uses an XMPP internal<br />

mechanism to provide a secured transport (with endto-end<br />

encrypted body). Both approaches have a similar<br />

delay in this scenario. XMPP-BOSH uses a BOSH based<br />

transport. BOSH itself uses an HTTP-long polling approach.<br />

The communication over base64+XMPP+BOSH<br />

has the highest latency – but also the ability to work over<br />

HTTP proxies, NATs and firewalls.<br />

The approach using WebSockets (WS) transports the<br />

data like native OPC.TCP – but with the bidirectional<br />

communication strategy. This results in a similar delay<br />

during the communication: The unsecure approaches<br />

need 0.25 ms WS compared to 0.21 ms OPC.<br />

TCP; the secure approach WS (SSL) is also comparable<br />

to OPC.TCP (SEC) with enabled signing and encryption<br />

mechanisms.<br />

2.2 Platform comparison<br />

In this scenario an Android device (Samsung Galaxy<br />

Tab S2) or a Raspberry Pi was used as an example for a<br />

field device gateway on an embedded device. While the<br />

Raspberry was connected using a 1Gbit LAN, the Android<br />

device was connected over a Wi-Fi access point<br />

in the same LAN. In the case of XMPP the XMPP server<br />

was installed on the PC. The results in Figure 4 give an<br />

approximation of the expected delay:<br />

Usually the embedded device was used as the local<br />

instance (which receives requests from the PC in the<br />

role of a remote/cloud instance). In some cases also the<br />

“backward-direction” was tested (marked with “BW”)<br />

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

7-8 / 2014<br />

37


HAUPTBEITRAG | AUTOMATION 2014<br />

FIGURE 5: OPC UA<br />

communication with<br />

the cloud<br />

FIGURE 7:<br />

Response time<br />

for a prototype<br />

of a Soft-PLC in<br />

a private cloud<br />

FIGURE 6:<br />

Soft-PLC in the<br />

cloud controlling<br />

a simulated<br />

device on the site<br />

– this means in these cases the embedded device sends<br />

requests to the PC.<br />

OPC.TCP (SEC) on Raspberry was used in Basic128Rsa15<br />

mode – instead of the default Basic256<br />

mode, which did not work. The test labelled with<br />

“OPC.TCP Raspberry (local)” shows the performance<br />

if the requests are sent only within the Raspberry<br />

(local-only requests with no network communication<br />

involved / similar to the local PC scenario). HTTPS<br />

on Raspberry did not seem to work properly as it showed<br />

latencies of up to 4.7 seconds. In the reverse direction<br />

it worked, but also with relatively high latencies<br />

around 33 ms. On Android, HTTPS was excluded<br />

due to problems with overlapping namespaces with<br />

the Android SDK.<br />

The tests on Android showed similar behaviour –<br />

with a somewhat higher latency, which might be caused<br />

by the Wi-Fi connectivity.<br />

AUTHORS<br />

Dr. JOHANNES SCHMITT<br />

(born 1979) is Scientist in<br />

the group Intelligent<br />

Devices at ABB Corporate<br />

Research. His research<br />

focusses communication<br />

and especially middleware<br />

technologies for automation<br />

systems. He also investigates<br />

the use of OPC UA on embedded or<br />

mobile devices up to cloud based systems.<br />

ABB AG Forschungszentrum,<br />

Wallstadter Str. 59, D-68526 Ladenburg,<br />

Tel. +49 (0) 6203 71 60 08,<br />

E-Mail: Johannes.O.Schmitt@de.abb.com<br />

Dr. THOMAS GOLD-<br />

SCHMIDT (born 1982) is a<br />

Principal Scientist at the<br />

ABB Corporate Research in<br />

Germany. He focuses on<br />

domain-specific language<br />

engineering and software<br />

architectures in the<br />

automation domain.<br />

Thomas holds a PhD in computer science from<br />

the Karlsruhe Institute of Technology, Germany.<br />

ABB AG Forschungszentrum,<br />

Wallstadter Str. 59, D-68526 Ladenburg,<br />

Tel. +49 (0) 6203 71 61 34,<br />

E-Mail: thomas.goldschmidt@de.abb.com<br />

38<br />

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

7-8 / 2014


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

Jetzt bestellen!<br />

2.3 Influence of Network Connection<br />

In this scenario, the new extensions are used in order<br />

to communicate with an OPC UA instance in the cloud.<br />

The results in Figure 5 were obtained for 100 test runs.<br />

The first test called “WebSocket LocalCloud” was<br />

conducted using a virtual machine running the<br />

cloud framework on the local PC. It shows the impact<br />

of the cloud framework itself – the delay in this case<br />

is about 1.74 ms.<br />

The second test was done using a traditional client-server<br />

connection by applying a OPC.TCP (SEC)<br />

connecting to the cloud – in this case the local instance<br />

sends requests to the OPC UA server in the<br />

cloud “backwards” (BW).<br />

Within the ABB LAN it is only possible to communicate<br />

through an HTTP proxy towards a real<br />

cloud on the Internet. This restricts the communication<br />

on XMPP based on BOSH and a Telecom Wi-<br />

Fi Hotspot Hotspot (marked with “Wlan”).<br />

For this reason the third test which applies the<br />

WebSocket technique is also only possible over<br />

Wi-Fi. The delay is similar to the basic OPC.TCP<br />

(SEC) approach – but in this case it was communicated<br />

from the cloud towards the local instance.<br />

The fourth test uses XMPP (without BOSH) which<br />

was also only possible over Wi-Fi. Both XMPP tests<br />

used the XMPP server in the cloud and the OPC UA<br />

instances locally on the PC – this means one requestresponse<br />

travels to the cloud and back again ( marked<br />

with “2 way”). The delay can be assumed to be halved<br />

if the requesting entity wwere placed in the cloud.<br />

The last test shows the only approach which worked<br />

within the ABB network together with its HTTP<br />

proxy and which enables a cloud-to-local instance<br />

Dr. PHILIPP VORST<br />

(born 1979) is a Senior<br />

Scientist with ABB<br />

Corporate Research in<br />

Germany. His research<br />

interests include software<br />

architecture methods with<br />

applications in automation.<br />

Philipp holds a PhD degree<br />

in computer science (mobile robotics) from the<br />

University of Tübingen, Germany.<br />

ABB AG Forschungszentrum,<br />

Wallstadter Str. 59, D-68526 Ladenburg,<br />

Tel. +49 (0) 6203 71 62 80,<br />

E-Mail: philipp.vorst@de.abb.com<br />

<strong>atp</strong> <strong>edition</strong> erscheint in der DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München<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!


HAUPTBEITRAG | AUTOMATION 2014<br />

communication backwards over the local instance–tocloud<br />

connection. With this approach it is possible to<br />

connect an OPC UA proxy server in a cloud with an OPC<br />

UA server in the ABB LAN.<br />

2.4 Soft-PLC in a Private Cloud<br />

As a proof-of-concept and to round up the scenario of an<br />

“automation system in the cloud”, a Soft-PLC service was<br />

instantiated in the cloud controlling a (simulated) device<br />

on the site. In this setup, the communication between the<br />

Soft-PLC and the proxy server was using a Message Queue<br />

[7] (as shown in Figure 6 with “MQ”) in order to use an<br />

asynchronous and loosely coupled communication to scale<br />

up the instances of running Soft-PLCs in the cloud if<br />

needed. The Soft-PLC subscribes using OPC UA over the<br />

proxy server at the simulated device in order to get notification<br />

about status changes of the device via MQ. As a reaction,<br />

the Soft-PLC sends back a control command via MQ<br />

and OPC UA over WebSockets to the simulated device. This<br />

setup uses a private cloud approach with a cloud instance<br />

hosted on an ABB server in Sweden and connected via VPN<br />

over the Internet to the ABB research labs in Germany.<br />

The delay between a status change of the device and<br />

a reaction in the form of a control command was<br />

measured. Figure 7 shows the results for 10 000 test runs<br />

as a histogram. In most cases the response time was<br />

around 75-80 ms with a few outliers around 300-400 ms.<br />

2.5 Evaluation results<br />

The goal of the presented performance evaluation and<br />

some additional tests in combination with embedded<br />

systems and clouds was to give a proof of concept and to<br />

establish an order of magnitude for the average delay.<br />

This makes it possible to explore the limits of current<br />

technical solutions for industrial applications and serves<br />

practitioners as a reference so that other applications can<br />

be compared to our performance measurement results.<br />

The additional overhead for WebSockets/XMPP compared<br />

to OPC.TCP is in most cases up to 5ms; the average<br />

delay for one request on an embedded device in the local<br />

network is between 5 and 15 ms. But the basic delay for<br />

the communication over the Internet to a cloud instance<br />

has to be taken into account in any case – for example<br />

the same request towards a system in the (Amazon) cloud<br />

takes about 200 ms. The delay might depend on various<br />

factors like the cloud provider, the physical distance, the<br />

DSL provider, the load of the cloud instance, and the time<br />

of day – usually this value is between 50 and 350 ms.<br />

In all cases no message losses were observed, which<br />

can be seen as an indicator for a robust communication.<br />

Other tests taking also the number of parallel requests<br />

into account showed that most approaches are also able<br />

to handle multitude parallel requests (tested up to 100)<br />

with almost linear increase in the delays – except for<br />

XMPP-BOSH where packet losses at about 3 parallel<br />

requests can be observed.<br />

Additional results also show that by re-using established<br />

connections the latency can be reduced – for example while<br />

HTTPs takes around 2 ms per request, WebSockets over<br />

SSL take only about 0.6 ms. Also, the delay of synchronous<br />

calls over XMPP and the indirection through the message<br />

broker can be relatively low, so that XMPP can be considered<br />

as an alternative to WebSockets. XMPP also provides<br />

additional features such as asynchronous calls and multicast<br />

which could be interesting for future extensions.<br />

CONCLUSIONS<br />

The proof of concept shows that it is possible to engineer<br />

automation systems for the cloud by using an OPC<br />

UA based architecture in combination with extended<br />

transport mechanisms. With this approach it is also<br />

possible to instantiate “classic” OPC UA connections<br />

from the proxy server in the cloud to OPC UA servers<br />

on distributed sites – using a stack without WebSocket<br />

support but at the expense of having to manually<br />

address all connection issues like firewalls, NAT, etc.<br />

Because the network connection to the cloud typically<br />

introduces the largest portion of communication delay, a<br />

fundamental question should be considered before<br />

enabling an automation system for the cloud: Can the constraints<br />

for communication delays be met by the network<br />

link to the cloud infrastructure?<br />

REFERENCES<br />

[1] National Instruments: Why OPC UA Matters.<br />

MANUSKRIPTEINGANG<br />

26.06.2014<br />

Im Peer-Review-Verfahren begutachtet<br />

http://www.ni.com/white-paper/13843/en/<br />

[2] OPC Training Institute: OPC UA: An End-User’s Perspective.<br />

http://www.controlglobal.com/assets/Media/Marketing<br />

Manager/ 081121_OPC_EndUsersPerspective.pdf<br />

[3] Leitner, S., Mahnke, W.: OPC UA – Service Oriented<br />

Architecture for Industrial Applications, 2006<br />

[4] Lubbers, Greco: HTML5 Web Sockets: A Quantum Leap in<br />

Scalability for the Web.<br />

https://www.websocket.org/quantum.html<br />

[5] Kirsche, M., Klauck, R.: Unify to Bridge Gaps: Bridging<br />

XMPP into the Internet of Things, PerCoM 2012<br />

[6] NIST Special Publication 500-292: NIST Cloud Computing<br />

Reference Architecture, September 2011<br />

[7] Mahesh-Kumar, M., Approach for Deploying, Executing and<br />

Scaling an IEC6113-3-based Soft-PLC Component on a<br />

Multi-tenant Industrial Cloud System for the Automation<br />

Domain, Master Thesis TU-Dortmund, 2014<br />

40<br />

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

7-8 / 2014


Process Control<br />

Systems Engineering<br />

Process Control Systems (PCS) are distributed control systems (DCS) that are specialized<br />

to meet specific requirements of the process industries. The text book focuses on PCS<br />

engineering basics that are common to different domains of the process industries.<br />

It relates to an experimental research plant which serves for the exploration of the<br />

interaction between process modularization and process automation methods. This<br />

permits to capture features of highly specialized and integrated mono-product plants as<br />

well as application areas which are dominated by locally standardized general-purpose<br />

apparatus and multi-product schemes. While the text book’s theory is applicable for all<br />

PCS of different suppliers, the examples refer to Siemens’ control system PCS 7. Focusing<br />

on a single PCS enables readers to use the book in basic lectures on PCS engineering as<br />

well as in computer lab courses, allowing students to gain hands-on experience.<br />

Editor: Leon Urbas<br />

1 st <strong>edition</strong> 2012<br />

204 pages, content in English,<br />

165 x 230 mm, hardcover<br />

ISBN: 978-3-8356-3198-4<br />

Price € 49,80<br />

www.di-verlag.de<br />

DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München<br />

Order now!<br />

KNOWLEDGE FOR THE<br />

FUTURE<br />

Order now by fax: +49 201 / 820 02-34 or send in a letter<br />

Deutscher Industrieverlag GmbH | Arnulfstr. 124 | 80636 München<br />

Yes, I place a firm order for the technical book. Please send<br />

— copies of the Process Control Systems 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 />

reply / Antwort<br />

Vulkan-Verlag GmbH<br />

Versandbuchhandlung<br />

Postfach 10 39 62<br />

45039 Essen<br />

GERMANY<br />

Country, Postalcode, Town<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 />

PAPCSE2014


HAUPTBEITRAG | AUTOMATION 2014<br />

Auf dem Weg zum<br />

Internet of Portals<br />

Anwendungen für OPC UA Server Aggregation<br />

Geräte und Komponenten in der industriellen Automatisierung werden zunehmend<br />

intelligenter. Als Konsequenz migrieren Dienste wie Serverfunktionen, die heute<br />

auf Steuerungs­ beziehungsweise Systemebene erbracht werden, in die Geräte der<br />

unteren Ebenen. Um die daraus resultierende Komplexität in der Kommunikationsstruktur<br />

zu verringern, schlagen die Autoren eine Aggregationsarchitektur vor. Der<br />

Beitrag erläutert die einzelnen Bestandteile der Architektur und beschreibt eine<br />

prototypische Umsetzung.<br />

SCHLAGWÖRTER Verteilte Systeme / Industrielle Kommunikation / Aggregation<br />

Internet of Portals –<br />

Applications for OPC UA Server Aggregation<br />

Devices and components in industrial automation systems are becoming more and<br />

more intelligent. Consequently, functions such as server services are migrating into<br />

the device level. To solve the increasingly complex communication structures, an<br />

architecture for server aggregation is proposed and a prototype implementation is<br />

described.<br />

KEYWORDS distributed systems / industrial communication / aggregation<br />

42<br />

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

7-8 / 2014


DANIEL GROSSMANN, MARKUS BREGULLA, SUPRATEEK BANERJEE, TH Ingolstadt<br />

DIRK SCHULZ, ROLAND BRAUN, ABB Forschungszentrum<br />

In heutigen Automatisierungssystemen spielt vertikale<br />

Integration eine wichtige Rolle, da Komponenten<br />

auf den verschiedenen Ebenen der Automatisierungspyramide<br />

Information miteinander austauschen.<br />

Geräteintegration beispielsweise macht Information<br />

von Feldgeräten, wie etwa Diagnosedaten,<br />

für übergeordnete Ebenen verfügbar.<br />

1. STAND DER TECHNIK<br />

Aktuelle Integrationstechnologien wie Field Device<br />

Integration (FDI) definieren Client­Server­Architekturen<br />

[1]. In der FDI­Architektur repräsentiert ein zentraler<br />

Server die Daten und Funktionen der im Automatisierungssystem<br />

enthaltenen Feldgeräte. FDI nutzt<br />

OPC Unified Architecture (UA) zur Informationsmodellierung<br />

und als Middleware­Technologie [2]. Der<br />

FDI­Server stellt zudem die Topologie aus Kommunikationsnetzen<br />

und Feldgeräten dar. Er ist über industrielle<br />

Kommunikationsprotokolle (zum Beispiel Profibus,<br />

Profinet, HART, Foundation Fieldbus) mit den<br />

Feldgeräten verbunden. Sobald der Server eine Anfrage<br />

von einem Client erhält, kommuniziert er mit dem<br />

Feldgerät und holt die notwendige Information ein.<br />

Nach einer optionalen Verarbeitung dieser Daten bekommt<br />

der Client die entsprechende Information als<br />

Antwort. Andere Integrationstechnologien wie Field<br />

Device Tool (FDT) oder Analyzer Device Integration<br />

(ADI) folgen ähnlichen zentralen Ansätzen. All diese<br />

Ansätze definieren eine zentrale Integrationsplattform,<br />

siehe Bild 1.<br />

1.1 Integrationsplattformen<br />

Integrationsplattformen repräsentieren eine oder<br />

mehrere Komponenten des Automatisierungssystems.<br />

Das bedeutet, dass eine Integrationsplattform<br />

Information über die Struktur des Systems (Komponenten<br />

und deren Beziehungen) sowie Daten von<br />

Komponenten enthält. Diese Information wird als<br />

Informationsmodell abgebildet. Ein Informationsmodell<br />

besteht in der Regel aus Objekten, die in Beziehungen<br />

zu anderen Objekten stehen (Strukturinformation).<br />

Objekte sind Instanzen eines Typs. Die zugehörige<br />

Typinformation ist ebenfalls im Informationsmodell<br />

abgebildet. Objekte besitzen Daten, die<br />

gelesen und geschrieben (Instanzdaten) und Funktionen,<br />

die aufgerufen werden können (Verhalten).<br />

Dementsprechend stellt ein Informationsmodell<br />

zur Verfügung:<br />

Typinformation,<br />

Strukturinformation (Objekte und Beziehungen),<br />

Instanzdaten (Daten von Objekten) und<br />

Information über das Verhalten von Objekten.<br />

1.2 Trend zur Verteilung<br />

Geräte und Subsysteme verfügen in zunehmenden<br />

Maße über Rechenkapazität, Speicher und Kommunikationsbandbreite.<br />

Dieser Trend zur steigenden<br />

Intelligenz in Geräten führt dazu, dass Geräte Funktionen<br />

selbstständig zur Verfügung stellen, die derzeit<br />

extern in der zentralen Integrationsplattform<br />

erbracht werden. Am Ende dieser Entwicklung agieren<br />

Geräte und Subsysteme selbst als Integrationsplattformen<br />

und bieten entsprechende Information<br />

und Dienste an. Bereits heute gibt es Steuerungen und<br />

Feldgeräte mit eingebettetem OPC UA Server. Ein<br />

Vorteil dieser dezentralen Funktionserbringung liegt<br />

darin, dass Funktionen einzelner Geräte sich bereits<br />

nutzen lassen, obwohl das gesamte Automatisierungssystem<br />

noch nicht in Betrieb genommen wurde.<br />

Die aktuellen Entwicklungen Richtung cyber­physischer<br />

Systeme und Industrie 4.0 verstärken den<br />

Trend hin zu verteilten intelligenten Komponenten,<br />

die kooperativ zusammenarbeiten. Das Ergebnis ist<br />

ein vermaschtes Netz mit Kommunikationsbeziehungen<br />

zwischen Anbietern von Daten und Funktionen<br />

(Servern) und Nutzern dieser Daten und Funktionen<br />

(Clients), siehe Bild 2.<br />

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

7-8 / 2014<br />

43


HAUPTBEITRAG | AUTOMATION 2014<br />

1.3 Auflösen der Vermaschung<br />

Der beschriebene Trend hin zu verteilten, intelligenten<br />

Komponenten bringt Vor­ und Nachteile: Während des<br />

Lebenszyklus eines Automatisierungssystems greifen<br />

verschiedene Tools als Clients auf die Daten und<br />

Funktionen der verteilten Server in Geräten oder Subsystemen<br />

zu, zum Beispiel um diese zu konfigurieren.<br />

Bei einer zentralen Integrationsplattform wird dieser<br />

Zugriff zentral erbracht und auch zentral überwacht.<br />

In einem Szenario mit mehreren dezentralen Integrationsplattformen<br />

müssen Verbindungen zwischen<br />

Clients und Servern (manuell) geplant und eingerichtet<br />

werden. Darüber hinaus greifen Clients in der Regel<br />

nicht nur auf ein einzelnes Gerät zu, sondern auf eine<br />

Reihe von Geräten. Als Folge muss ein solcher Client<br />

mehrere Server (Integrationsplattformen) kennen. Jede<br />

dieser Client­Server­Verbindungen muss zudem unter<br />

IT­Security­Gesichtspunkten aufgebaut, verwaltet und<br />

überwacht werden. Das Planen und Einstellen verbindungsspezifischer<br />

Security­Richtlinien wiederum<br />

bedeutet einen enormen Aufwand.<br />

Es ist also eine Architektur notwendig, in der eine Aggregationskomponente<br />

die Illusion einer zentralen Integrationsplattform<br />

bietet. Dadurch bleiben die Vorteile<br />

eines zentralen Zugangspunktes erhalten und die Komplexität<br />

mehrerer Client­Server­Verbindungen wird reduziert.<br />

Die Aggregationskomponente kann zudem als Security<br />

Supervisor agieren, der die Verbindungen aus Security­<br />

Perspektive verwaltet und überwacht. Die Aggregationskomponente<br />

greift auf unterlagerte verteilte Integrationsplattformen<br />

auf Geräte­ oder Subsystemebene zu und aggregiert<br />

deren Struktur­ und Instanzdaten, siehe Bild 3.<br />

2. GENERELLE ANFORDERUNGEN AN AGGREGATION<br />

Integrationsplattformen stellen Typ­ und Strukturinformation,<br />

Instanzdaten und Verhaltensdaten zur Verfügung,<br />

siehe Abschnitt 1.1. Wenn Integrationsplattformen<br />

aggregiert werden, dann muss diese Information konsolidiert<br />

werden. Beispielsweise können semantisch<br />

gleiche Typen in zwei verteilten Integrationsplattformen<br />

enthalten sein. Wenn diese Integrationsplattformen aggregiert<br />

werden, dann müssen diese beiden semantisch<br />

gleichen Typen im Informationsmodell des Aggregationsservers<br />

zu einem einzigen Typ konsolidiert werden.<br />

Gleiches gilt für Objekte: Ein Informationsmodell repräsentiert<br />

einen Teil des Automatisierungssystems. Zwei<br />

Informationsmodelle können überlappende Teile des<br />

Automatisierungssystems abbilden. Daraus folgt, dass<br />

Objekte in beiden Informationsmodellen enthalten sind,<br />

die in einem aggregierten Informationsmodell zu einem<br />

Objekt zusammengelegt werden müssen. Damit sind die<br />

folgenden Anforderungen zu erfüllen:<br />

Auflösen und Zusammenführen von Typen: Typen in verschiedenen<br />

Integrationsplattformen, die semantisch gleiche<br />

Typen repräsentieren, müssen aufgelöst und im Aggregationsserver<br />

zu einem Typ zusammengeführt werden.<br />

Auflösen und Zusammenführen von Objekten: Objekte,<br />

die in unterschiedlichen Integrationsplattformen<br />

definiert und die Instanzen semantisch gleichartiger<br />

Typen sind, müssen aufgelöst und im Aggregationsserver<br />

zu Instanzen des konsolidierten Typs werden.<br />

Zusammenführen von Strukturinformation: Referenzen<br />

zwischen Objekten müssen aufgelöst und im<br />

Aggregationsserver zusammengeführt werden.<br />

Consumer<br />

(Client)<br />

Consumer<br />

(Client)<br />

Consumer<br />

(Client)<br />

Consumer<br />

(Client)<br />

Consumer<br />

(Client)<br />

Consumer<br />

(Client)<br />

Consumer<br />

(Client)<br />

Consumer<br />

(Client)<br />

Consumer<br />

(Client)<br />

Consumer<br />

(Client)<br />

Central Integration<br />

Platform (Server)<br />

Dev. Dev. Dev. GW Subsyst.<br />

Dev. Dev. Dev. GW Subsyst.<br />

Dev. Dev. Dev. Dev. Dev. Dev.<br />

Dev. Dev. Dev. Dev. Dev. Dev.<br />

BILD 1: Zentrale Integrationsplattform<br />

BILD 2: Resultierende Vermaschung<br />

44<br />

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

7-8 / 2014


Mapping von Strukturinformation: Objekte und deren<br />

Unterstrukturen, die in einer Integrationsplattform definiert<br />

sind, können in Realität Unterstrukturen von<br />

Objekten sein, die in einer anderen Integrationsplattform<br />

abgebildet sind. Diese Strukturen müssen von<br />

einem Aggregationsserver zu einer übergeordneten<br />

Struktur zusammengefügt werden.<br />

Auflösen gleicher Objekte: Objekte, die in unterschiedlichen<br />

Integrationsplattformen existieren, können<br />

Abbildungen einer einzigen Entität oder verschiedener<br />

Facetten einer einzigen Entität in der realen Welt<br />

sein. Ein Aggregationsserver muss diese Objekte zu<br />

einem einzigen Objekt zusammenführen.<br />

Modifikation der Struktur: Ein Aggregationsserver<br />

muss Dienste zum Verändern der Strukturinformation<br />

anbieten, zum Beispiel Objekte und Referenzen erzeugen<br />

und löschen. In solchen Fällen muss ein Aggregationsserver<br />

die Anfragen an die betreffende unterlagerte Integrationsplattform<br />

weiterleiten, sodass dort beispielsweise<br />

eine Instanz des angegebenen Typs erstellt wird.<br />

Verteilung von Typinformation: Objekte werden als<br />

Instanzen von Typen gebildet, die in einer Integrationsplattform<br />

bekannt sind. Der Aggregationsserver besitzt<br />

das Wissen, welche Typen in welchen unterlagerten<br />

Integrationsplattformen definiert sind. Dabei kann es<br />

zu der Situation kommen, dass ein Objekt in einer Integrationsplattform<br />

erstellt werden soll, in der der angegebene<br />

Typ nicht bekannt ist. In einem solchen Fall<br />

muss die nötige Typinformation an die unterlagerte<br />

Integrationsplattform verteilt werden, sodass das Objekt<br />

dort wie angefordert erstellt werden kann.<br />

Zugangskontrolle: Der Zugang zu unterlagerten Integrationsplattformen<br />

kann Beschränkungen unterliegen.<br />

Consumer<br />

(Client)<br />

Consumer<br />

(Client)<br />

Consumer<br />

(Client)<br />

Aggregation<br />

Server<br />

Consumer<br />

(Client)<br />

Consumer<br />

(Client)<br />

Dev. Dev. Dev. GW Subsyst.<br />

Dev. Dev. Dev. Dev. Dev. Dev.<br />

BILD 3: Aggregationsserver<br />

Ein Aggregationsserver agiert als Single Point of Access<br />

und verwaltet und überwacht Zugriffe von Clients auf<br />

unterlagerte Integrationsplattformen.<br />

Eine Aggregationsarchitektur muss die beschriebenen<br />

Anforderungen adressieren.<br />

3. OPC-UA-BASIERTE INTEGRATIONSPLATTFORMEN<br />

OPC UA ist eine mögliche Umsetzungstechnologie für<br />

Informationsmodelle. Die Modellierung folgt dabei dem<br />

objektorientierten Ansatz. Objekte und Typen werden als<br />

Knoten im Adressraum des OPC UA Server dargestellt [3].<br />

Von einem Wurzelknoten ausgehend gibt es im Wesentlichen<br />

die Unterknoten Objects und Types. Der Objects­<br />

Knoten beinhaltet Unterknoten, die beispielsweise Entitäten<br />

der realen Welt abbilden. Der Types­Knoten enthält<br />

die Typinformation. Alle Objekte sind Instanzen der darin<br />

enthaltenen Typen. Die Beziehungen zwischen Knoten<br />

werden über Referenzen abgebildet, die wiederum<br />

selbst Knoten sind (Instanzen von Referenztypen). Bild 4<br />

zeigt ein Beispiel eines OPC­UA­Informationsmodells.<br />

Im Beispiel sind zwei Objekttypen ObjectTypeA und<br />

ObjectTypeB definiert. ObjectTypeA erbt vom Basistyp aller<br />

Objekte, dem BaseObjectType. ObjectTypeB hingegen<br />

erbt von ObjectTypeA und definiert ein Property MyProperty<br />

über eine hasProperty­Referenz, eine Variable MyVariable<br />

über eine hasComponent­Referenz und eine Methode,<br />

ebenfalls über eine hasComponent­Referenz. Von ObjectTypeB<br />

existieren zwei Instanzen Object1 und Object2.<br />

Object1 referenziert seinen Objekttyp ObjectTypeB über<br />

eine hasTypeDefinition­Referenz. Da Informationsmodelldiagramme<br />

schnell unübersichtlich werden, gibt es die<br />

alternative Möglichkeit, den Objekttyp direkt im Objekt<br />

festzuhalten. Diese Notation wird bei Object2 genutzt.<br />

Ein OPC­UA­Knoten besitzt eine Reihe von Attributen.<br />

Neben dem Value­Attribut ist das NodeId­Attribut wichtig,<br />

da es einen Knoten im Adressraum eines OPC UA<br />

Server eindeutig identifiziert [4]. Die NodeId besteht aus<br />

einem Namespace­Index und einem Identifier. OPC UA<br />

nutzt Namespaces, um sicherzustellen, dass Definitionen<br />

in Informationsmodellen stets eindeutig sind. Der Namespace­Index<br />

zeigt auf eine Position in der Namespace­<br />

Tabelle eines OPC UA Server. Diese wiederum ist eine<br />

Liste von Namespace URI (uniform resource identifier)<br />

zusammen mit den zugehörigen Indizes. FDI beispielsweise<br />

hat die Namespace URI http://opcfoundation.org/<br />

UA/FDI/. Die zu einer Namespace URI zugeordneten<br />

Namespace­Indizes können sich in OPC UA unterscheiden.<br />

Dabei lassen sich die unterschiedlichen Namespace­<br />

Indizes aber immer über die Namespace­Tabelle auflösen.<br />

Der Identifier der NodeId kann entweder eine Ganzzahl,<br />

eine UUID oder ein String sein. Auch wenn sich Identifier<br />

wiederholen, ist die Kombination aus Namespace­<br />

Index und Identifier immer eindeutig in einem einzelnen<br />

OPC UA Server. Zusätzlich zu den NodeIds, die einen<br />

Knoten im Adressraum eindeutig identifizieren, besitzt<br />

jeder Knoten noch einen Browsename. Vom Wurzelkno­<br />

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

7-8 / 2014<br />

45


HAUPTBEITRAG | AUTOMATION 2014<br />

Object 1<br />

BaseObjectType<br />

Typen<br />

Aggregation<br />

OPC UA Client<br />

Configurator<br />

1 n 1<br />

1<br />

BILD 4: OPC-UA-<br />

Informationsmodell<br />

(Beispiel)<br />

ObjectType B:<br />

Object 2<br />

MyProperty<br />

MyProperty<br />

MyVariable<br />

Method<br />

ObjectType<br />

A<br />

ObjectType<br />

B<br />

MyProperty<br />

MyVariable<br />

OPC UA Server<br />

1<br />

1<br />

1<br />

Aggregation<br />

Node Manager<br />

1 1<br />

n<br />

OPC UA Client<br />

1<br />

1<br />

1<br />

1<br />

1<br />

1<br />

Security<br />

Manager<br />

Discovery<br />

Manager<br />

Type Manager<br />

Node Factory<br />

Aggregation Server<br />

Configuration<br />

Instance<br />

Mapping Rules<br />

Type Mapping<br />

Rules<br />

MyVariable<br />

1 n<br />

Method<br />

Method<br />

Aggregated<br />

Server<br />

BILD 5: Systemarchitektur<br />

ten eines OPC­US­Servers ausgehend, identifiziert die<br />

Zusammensetzung der einzelnen Browsenames, Browsepath<br />

genannt, ebenfalls einen Knoten eindeutig. Clients<br />

können a priori Wissen über die Zusammensetzung<br />

des Browsename nutzen, zum Beispiel weil diese in einer<br />

Informationsmodellspezifikation wie etwa FDI definiert<br />

sind, um die zugehörige NodeId eines Knotens beim OPC<br />

UA Server zu erfragen. Der Zugriff auf den Knoten erfolgt<br />

dann wiederum über dessen NodeId.<br />

4. SYSTEMARCHITEKTUR<br />

Dieser Abschnitt beschreibt die Systemarchitektur für die<br />

Aggregation von Integrationsplattformen, siehe Bild 5.<br />

Kernelemente dieser Architektur sind aggregierte Server,<br />

Aggregationsserver und ein Aggregationskonfigurator.<br />

4.1 Aggregierter Server<br />

Aggregierte Server, auch unterlagerte Server genannt,<br />

repräsentieren die Entitäten des Automatisierungssystems.<br />

Ein aggregierter Server kann eine einzelne Komponente,<br />

zum Beispiel ein Feldgerät, ein Subsystem, das<br />

wiederum aus Komponenten besteht, einen Teil des<br />

Automatisierungssystems oder aber das gesamte Automatisierungssystem<br />

repräsentieren.<br />

4.2 Aggregationsserver<br />

Der Aggregationsserver stellt den Kern der Aggregationsarchitektur<br />

dar. Er verbindet sich mit den unterlagerten<br />

Servern über OPC­UA­Dienste und aggregiert<br />

deren Typ­, Instanz­ und Strukturdaten. Diese Information<br />

wird vom Aggregationsserver selbst wieder über<br />

OPC­UA­Dienste angeboten. Der Aufbau des Aggregationsservers<br />

ist in Abschnitt 5 beschrieben.<br />

4.3 Aggregationskonfigurator<br />

Der Aggregationskonfigurator ist ein Werkzeug zur<br />

Konfiguration des Aggregationsservers. Er erzeugt<br />

Information über die zu aggregierenden Server. Der<br />

Aggregationskonfigurator kann während der Planung<br />

oder während der Laufzeit des Automatisierungssystems<br />

eingesetzt werden. Beim <strong>Einsatz</strong> während der<br />

Planung erzeugt der Aggregationskonfigurator Konfigurationsdaten,<br />

siehe Abschnitt 4.4, die persistent<br />

gespeichert werden, zum Beispiel in einer Konfigurationsdatenbank.<br />

Während der Laufzeit, das heißt,<br />

wenn der Aggregationsserver und die zu aggregierenden<br />

Server verfügbar sind, greift der Aggregationskonfigurator<br />

direkt auf den Aggregationsserver zu,<br />

um die zu aggregierenden Server zu konfigurieren.<br />

Der Aggregationskonfigurator wird auch dazu genutzt,<br />

die Typ­ und Instanzzuordnungsregeln zu defi<br />

n i e r e n .<br />

4.4 Konfiguration<br />

Die Konfiguration enthält Information über die zu aggregierenden<br />

Server, zum Beispiel URL. Der Aggregationsserver<br />

liest die Konfiguration, um zu wissen, welche<br />

unterlagerten Server zu aggregieren sind.<br />

46<br />

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

7-8 / 2014


4.5 Typzuordnungsregeln<br />

Die Typzuordnungsregeln enthalten Information darüber,<br />

wie semantisch gleiche Typen identifiziert werden<br />

können. Da solche Typknoten in verschiedenen<br />

Servern unterschiedliche NodeIds haben können, benötigt<br />

der Aggregationsserver zusätzliche Information<br />

für die Identifikation, beispielsweise Properties, die<br />

verglichen werden müssen. Im Falle von FDI wird ein<br />

Gerätetypknoten über seine Properties Manufacturer,<br />

Model und Device Revision identifiziert [5]. Die Typzuordnungsregeln<br />

können entweder lokal im Aggregationsserver<br />

definiert werden oder über das Informationsmodell<br />

des aggregierten Servers dynamisch zur<br />

Laufzeit geladen werden. Abschnitt 6.2 beschreibt die<br />

dafür notwendigen Ergänzungen im Informationsmodell<br />

des aggregierten Servers.<br />

4.6 Instanzzuordnungsregeln<br />

Instanzzuordnungsregeln enthalten Information über<br />

die Handhabung von Objekten. Es kann zum Beispiel<br />

notwendig sein, beim Erkunden des Adressraums eines<br />

unterlagerten Servers nicht weiter in Unterknoten abzuzweigen,<br />

außer ein Client fragt explizit danach.<br />

Gründe dafür können beispielsweise sein, dass dies<br />

unnötige Last im unterlagerten Server erzeugen würde,<br />

weil das interne Objektmodell geladen werden muss,<br />

im Fall von FDI muss zum Beispiel das FDI Device<br />

Package geladen werden. Auch Information über fest<br />

definierte Objekte ist in den Regeln enthalten, sodass<br />

ein Aggregationsserver diese Objekte in mehreren unterlagerten<br />

Servern identifizieren und zusammenführen<br />

kann. Derartige fest definierte Objekte besitzen in<br />

der Regel eine feste NodeId, die in einer Informationsmodellspezifikation<br />

definiert ist. Die Instanzzuordnungsregeln<br />

können entweder lokal im Aggregationsserver<br />

definiert oder über das Informationsmodell des<br />

aggregierten Servers dynamisch zur Laufzeit geladen<br />

werden. Abschnitt 6.2 beschreibt die dafür notwendigen<br />

Ergänzungen im Informationsmodell des aggregierten<br />

Servers.<br />

5. ARCHITEKTUR DES AGGREGATIONSSERVERS<br />

5.1 Aggregation Node Manager<br />

Der Aggregation Node Manager ist der zentrale Singleton,<br />

der die Knoten im Adressraum des Aggregationsservers<br />

verwaltet. Der Aggregation Node Manager<br />

setzt unter anderem die nachfolgend genannten Funktionen<br />

um:<br />

Er erzeugt eine OPC UA Session pro unterlagerten<br />

Server. Sobald die Verbindung hergestellt ist, erkundet<br />

der Aggregation Node Manager den Adressraum des<br />

unterlagerten Servers Knoten für Knoten. Typknoten<br />

werden dabei mit den Typzuordnungsregeln verglichen.<br />

Im Falle von Instanzknoten werden die Instanzzuordnungsregeln<br />

herangezogen. Anhand der<br />

Regeln wird entschieden, wie der Knoten im Aggregationsserver<br />

zu handhaben ist. Der Aggregationsserver<br />

prüft außerdem, ob er die Typ- und Instanzzuordnungsregeln<br />

dynamisch aus dem Informationsmodell<br />

des zu aggregierenden Servers lesen kann, siehe Abschnitt<br />

6.2. Für jeden aggregierten Knoten wird ein<br />

Proxy-Knoten vom Aggregation Node Manager erstellt.<br />

Die notwendigen Zuordnungsdaten jedes Proxy-Knotens<br />

zum Originalknoten in den unterlagerten Server<br />

werden erzeugt und verwaltet. Die Proxy-Knoten werden<br />

dabei von der Node Factory erzeugt und an den<br />

Aggregation Node Manager übergeben. Auch die Referenzen<br />

zwischen Originalknoten werden vom Aggregation<br />

Node Manager nachgebildet, sodass die ursprüngliche<br />

Strukturinformation erhalten bleibt. Im<br />

Falle doppelt vorhandener Knoten, zum Beispiel bei<br />

überlappenden Strukturen, oder bereits vorhandene<br />

Typ-Knoten, wird nur die entsprechende Mapping-<br />

Information erzeugt und kein neuer Knoten im Adressraum<br />

des Aggregationsservers erstellt. Alle erzeugten<br />

Typ-Knoten werden vom Type Manager verwaltet,<br />

siehe Abschnitt 5.2.<br />

Ein Aggregation Node Manager kann nur Anfragen<br />

entgegennehmen, die an einen Namespace gerichtet<br />

sind, für den dieser zuständig ist. Darum registriert sich<br />

der Aggregation Node Manager für alle im unterlagerten<br />

Server vorhandenen Namespaces. Dabei werden auch<br />

die entsprechenden Namespace-Indizes verwaltet.<br />

Anfragen von Clients an einen Proxy-Knoten, wie<br />

Read, Write, Subscribe, werden vom Aggregation Node<br />

Manager aufgrund der Mapping-Tabellen an den entsprechenden<br />

unterlagerten Server weitergeleitet. Die<br />

NodeIds in der Anfrage werden dabei durch die NodeIds<br />

im unterlagerten Server ersetzt. Da eine Anfrage<br />

an den Aggregationsserver sich auf Knoten in unterschiedlich<br />

unterlagerten Servern beziehen kann, teilt<br />

der Aggregation Node Manager eine solche Anfrage<br />

entsprechend auf.<br />

5.2 Type Manager<br />

Der Type Manager verwaltet alle Typ-Knoten im Aggregationsserver.<br />

Dazu nutzt der Type Manager die Zuordnungsregeln,<br />

um festzustellen, ob ein spezifischer Typ-<br />

Knoten im Aggregationsserver bereits vorhanden ist.<br />

Der Type Manager kennt auch alle Namespace-Tabellen<br />

der unterlagerten Server.<br />

5.3 Node Factory<br />

Die Node Factory erzeugt die Proxy-Knoten. Proxy-<br />

Knoten sind Kopien von Originalknoten, die die Attribute<br />

enthalten, außer die Value- und NodeId-Attribute.<br />

Das NodeId-Attribut wird mit einer neuen NodeId belegt.<br />

Die Node Factory erstellt Proxy-Knoten für Typ-<br />

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

7-8 / 2014<br />

47


HAUPTBEITRAG | AUTOMATION 2014<br />

BaseObjectType<br />

gregationsserver dann mit der Aggregation eines solchen<br />

unterlagerten Servers beauftragen. Die Aggregation<br />

an sich wird dann vom Aggregation Node Manager<br />

durchgeführt.<br />

OpcUaServerType<br />

AggregatedServer<br />

Type<br />

BaseDataVariableType:<br />

ServerUrl<br />

AvailableServer<br />

SetType<br />

OpcUaServer<br />

AggregatedServer<br />

SetType<br />

Aggregated<br />

Server<br />

ResidesIn<br />

Aggregate<br />

Server<br />

5.7 Security Manager<br />

Der Security Manager implementiert die Zugangskontrolle<br />

zu den aggregierten Knoten. Dabei kann der Security<br />

Manager beispielsweise den Zugang zu einzelnen<br />

Knoten oder generell zu Knoten eines bestimmten<br />

unterlagerten Servers verwehren. Außerdem kann die<br />

Art des Zugriffs eingeschränkt werden, zum Beispiel<br />

nur lesender Zugriff, keine Methodenausführung.<br />

ServerType<br />

Server<br />

BILD 6: Informationsmodell<br />

des Aggregationsservers<br />

und Instanz­Knoten. Für die Erzeugung einer neuen<br />

NodeId muss jeweils die Liste der fest definierten NodeIds<br />

geprüft werden.<br />

5.4 OPC UA Client<br />

Der OPC UA Client kapselt die Funktionalität für die<br />

Verbindung mit einem unterlagerten Server. Ein OPC<br />

UA Client ist dabei mit einem unterlagerten Server verbunden.<br />

Der OPC UA Client erhält die Anfragen über<br />

den Aggregation Node Manager bereits mit der korrekten<br />

NodeId im unterlagerten Server.<br />

5.5 OPC UA Server<br />

Der OPC UA Server bietet die Dienste des Aggregationsservers<br />

an. Zum einen erfolgt darüber der Zugriff auf<br />

aggregierte Knoten im Adressraum des Aggregationsservers.<br />

Zum anderen stellt der Aggregationsserver darüber<br />

Managementfunktionen zur Verfügung, über die sich<br />

beispielsweise die für eine Aggregation zur Verfügung<br />

stehenden Server abfragen lassen, siehe Abschnitt 6.1.<br />

5.6 Discovery Manager<br />

Object<br />

Der Discovery Manager nutzt die OPC­UA­Discovery­<br />

Mechanismen, um das Netzwerk nach möglichen unterlagerten<br />

Servern zu durchsuchen. Die gefundenen<br />

Server werden über das Informationsmodell des Aggregationsservers<br />

publiziert. Clients können den Ag­<br />

6. INFORMATIONSMODELL FÜR DIE AGGREGATION<br />

Dieser Beitrag definiert zwei Informationsmodellerweiterungen,<br />

die die Aggregation unterstützen. Abschnitt<br />

6.1 beschreibt die Erweiterungen für den Aggregationsserver.<br />

Dies umfasst im Wesentlichen Information und<br />

Dienste für die Verwaltung aggregierter Server. Abschnitt<br />

6.2 beschreibt eine optionale Erweiterung für<br />

das Informationsmodell unterlagerter Server. Darüber<br />

werden hauptsächlich die Typ­ und Instanzzuordnungsregeln<br />

verfügbar gemacht, um eine vollständig<br />

automatisierte Aggregation zu ermöglichen. Sind diese<br />

Erweiterungen nicht implementiert, dann können diese<br />

Regeln über den Aggregationskonfigurator bereitgestellt<br />

werden, siehe Abschnitt 4.3.<br />

6.1 Aggregationsserver<br />

6.1.1 Informationsmodell<br />

Der OpcUaServerType repräsentiert einen OPC UA Server.<br />

Dazu referenziert der Type eine Variable ServerUrl,<br />

die die URL des OPC UA Server enthält (Bild 6).<br />

Der AggregatedServerType erbt von OpcUaServerType<br />

und referenziert ein ServerType­Objekt. Das Server­<br />

Type­Objekt ist in der OPC­UA­Spezifikation definiert.<br />

Es enthält detaillierte Information über einen OPC UA<br />

Server, die auch Information über den aktuellen Status<br />

zur Verfügung stellt. Der AvailableServerSetType referenziert<br />

OpcUaServer, die für die Aggregation als unterlagerte<br />

Server zur Verfügung stehen. Die Liste kann<br />

dabei entweder auf der Basis von Planungsdaten oder<br />

aber über den Discovery­Manager erstellt werden. Der<br />

AggregatedServerSetType referenziert die aggregierten<br />

OpcUaServer. Das erlaubt es Clients, den Zustand der<br />

unterlagerten Server direkt im Informationsmodell des<br />

Aggregationsservers zu beobachten. Der Aggregated-<br />

ServerSetType enthält zudem eine Methode, die die<br />

NodeId eines OpcUaServer­Knotens im AvailableServerSet<br />

entgegennimmt. Darüber wird der Aggregationsserver<br />

angewiesen, den entsprechenden unterlagerten<br />

48<br />

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

7-8 / 2014


Objects<br />

Ava<br />

ilab<br />

le<br />

Serve<br />

rSetTy<br />

yp<br />

pe<br />

AvailableServerSet<br />

BILD 7: Informationsmodellbeispiel<br />

BaseObjectType<br />

BILD 8: Informationsmodell<br />

des aggregierten Servers<br />

Op<br />

cUa<br />

Serve<br />

rTy<br />

yp<br />

e<br />

Server_1<br />

Aggrega<br />

tedServerSetTy<br />

pe<br />

AggregatedServerSet<br />

Aggre<br />

ega<br />

tedServe<br />

rTy<br />

yp<br />

e<br />

Server_2<br />

AggregationSupport<br />

Type<br />

TypeMappingRule<br />

SetType<br />

TypeMappingRule<br />

Type<br />

InstanceMapping<br />

RuleSetType<br />

InstanceMapping<br />

RuleType<br />

TypeManagement<br />

ServiceType<br />

Aggre<br />

ega<br />

tedServe<br />

rTy<br />

yp<br />

e<br />

Server_3<br />

TypeMappingRule<br />

InstanceMapping<br />

Rule<br />

Object_A<br />

Object_B<br />

Reside<br />

desIn<br />

ResidesIn<br />

TypeMappingRule<br />

Set<br />

InstanceMapping<br />

RuleSet<br />

ExportType<br />

Definition<br />

ImportType<br />

Definition<br />

Object_C<br />

TypeManagement<br />

Service<br />

Server zu aggregieren. Dieser Server verschwindet<br />

dann aus dem AvailableServerSet und erscheint im AggregatedServerSet.<br />

Die ResidesIn­Referenz erbt vom<br />

NonHierarchicalReferenceType. Die Referenz zeigt den<br />

Ursprung eines aggregierten Knotens an, in dem sie den<br />

entsprechenden AggregatedServer referenziert.<br />

6.1.2 Beispiel<br />

Das Beispiel in Bild 7 zeigt ein AvailableServerSet, das<br />

einen OpcUaServer Server_1 enthält, der zur Aggregation<br />

zur Verfügung steht. Das AggregatedServerSet enthält<br />

die beiden AggregatedServer­Objekte Server_2 und<br />

Server_3. Die Knoten Object_A, Object_B und Object_C<br />

wurden von diesen beiden Servern aggregiert. Die ResidesIn­Referenz<br />

zeigt den Ursprung dieser Knoten im<br />

Server_2 und Server_3 an. Object_A und Object_B<br />

stammen aus Server_2. Object_C ist zwar ein Unterknoten<br />

von Object_2 stammt aber dennoch aus einem anderen<br />

unterlagerten Server Server_3.<br />

6.2 Aggregierter Server<br />

6.2.1 Informationsmodell<br />

Der TypeMappingRuleSetType referenziert Objekte vom<br />

Typ TypeMappingRuleType, siehe Bild 8. Der TypeMappingRuleType<br />

repräsentiert die Typzuordnungsregeln.<br />

Diese Regeln können auf der Basis von Standards erstellt<br />

sein, zum Beispiel Regeln, um Gerätetypen in FDI zu<br />

vergleichen. Der InstanceMappingRuleSetType referenziert<br />

Objekte vom Typ InstanceMappingRuleType. Der<br />

InstanceMappingRuleType repräsentiert dabei die Instanzzuordnungsregeln.<br />

Diese Regeln können ebenso auf<br />

einem Standard aufbauen. Der TypeManagementService-<br />

Type bietet standardisierte Dienste zur Verwaltung von<br />

Typen in einem OPC UA Server. Dazu werden zwei Methoden<br />

– ExportTypeDefinition und ImportTypeDefinition<br />

– angeboten. Die ExportTypeDefinition­Methode serialisiert<br />

den angefragten Type. Die Methode nimmt dazu die<br />

NodeId des Typeknotens entgegen. Rückgabewert ist eine<br />

NodeId, unter der die serialisierte Typinformation gelesen<br />

werden kann. Im Falle von FDI kann darüber das<br />

zugehörige FDI Device Package gelesen werden. Die ImportTypeDefinition<br />

nimmt serialisierte Typinformation<br />

entgegen und erstellt den entsprechenden Typ im Typsystem<br />

des Servers. Im Falle von FDI wird der entsprechende<br />

Gerätetyp erstellt. Der AggregationSupportType<br />

referenziert die TypeMappingRuleSet, das InstanceMappingRuleSet<br />

und die TypeManagementService.<br />

6.2.2 Beispiel<br />

Bild 9 zeigt ein Beispiel eines unterlagerten Servers: Das<br />

AggregationSupport­Objekt ist ein Unterknoten des<br />

ServerCapabilities­Knotens, der Teil des Standardserver­Objekts<br />

ist. Über den AggregationSupport ist der<br />

Aggregationsserver in der Lage, alle für die Aggregation<br />

notwendige Information aus dem unterlagerten Server<br />

zu lesen. In diesem Sinne fügt der AggregationSupport<br />

Fähigkeiten zur Selbstbeschreibung hinzu. Über die TypeManagementServices,<br />

die Bestandteil des AggregationSupports<br />

sind, kann ein Aggregationsserver Typinfor­<br />

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

7-8 / 2014<br />

49


HAUPTBEITRAG | AUTOMATION 2014<br />

mationen zu den unterlagerten Servern verteilen. Beispielsweise<br />

kann ein Client die Erstellung einer Instanz<br />

eines bestimmten Typs in einem unterlagerten Server<br />

anfragen. Ist der betreffende Typ im unterlagerten Server<br />

nicht bekannt, kann der Aggregationsserver die Typinformation<br />

über ExportTypeDefinition aus einem Server<br />

abrufen, in dem der Type bekannt ist, und dann über<br />

ImportTypeDefinition an den unterlagerten Server weitergeben.<br />

Nun kann dort das angefragte Objekt erfolgreich<br />

werden, ohne dass im Falle von FDI das zugehörige<br />

FDI Device Package manuell importiert werden muss.<br />

Objects<br />

BILD 10:<br />

Prototyp<br />

FDI<br />

Server 1<br />

ServerType<br />

Server<br />

FDI<br />

Server 2<br />

REFERENZEN<br />

BILD 9: Beispiel eines<br />

Informationsmodells<br />

ServerCapabilitiesType<br />

Server<br />

AggregationSupportType<br />

AggregationSupport<br />

FDI<br />

Client<br />

UA<br />

Expert<br />

Aggregation Server<br />

FDI<br />

Server 3<br />

Sample<br />

Server 1<br />

Sample<br />

Server 2<br />

[1] IEC 62769-1 CDV: Field Device Integration (FDI),<br />

Technical Specification – Part 1: Overview. IEC, 2013.<br />

[2] IEC 62541-1: OPC UA Specification – Part 1: Concepts. IEC, 2010.<br />

[3] IEC 62541-3: OPC UA Specification – Part 3: Address Space Model. IEC, 2010.<br />

[4] IEC 62541-5: OPC UA Specification – Part 5: Information Model. IEC, 2011.<br />

[5] IEC 62769-5 CDV: Field Device Integration (FDI), Technical<br />

Specification – Part 5: FDI Information Model. IEC, 2013.<br />

[6] Promotorengruppe Kommunikation der<br />

Forschungsunion Wirtschaft – Wissenschaft (Hrsg.): Umsetzungsempfehlungen<br />

für das Zukunftsprojekt Industrie 4.0. April 2013<br />

7. PROTOTYP<br />

Das beschriebene Konzept wurde prototypisch umgesetzt.<br />

Der dabei entwickelte Aggregationsserver wurde<br />

genutzt, um drei FDI­Server zusammen mit weiteren<br />

OPC UA Servern aus den Stack­Beispielen zu aggregieren,<br />

siehe Bild 10. Nach der Aggregation wurde der<br />

resultierende Adressraum des Aggregationsserver mit<br />

Hilfe des OPC UA Clients UA Expert analysiert. Darüber<br />

wurde der Zugriff auf aggregierte Knoten geprüft.<br />

Read­, Write­ und Subscription­Aufrufe wurden erfolgreich<br />

durchgeführt und an die entsprechenden unterlagerten<br />

Server weitergeleitet. Abschließend wurde ein<br />

FDI Client mit dem Aggregationsserver verbunden, um<br />

zu prüfen, ob der FDI Client mit dem aggregierten Informationsmodell<br />

dreier unterlagerter FDI Server arbeiten<br />

kann. Da der Aggregationsserver die Illusion eines<br />

einzigen Servers anbietet, konnte der FDI Client ohne<br />

jede Veränderung mit dem Aggregationsserver arbeiten.<br />

Der Prototyp demonstriert, dass das beschriebene Konzept<br />

anwendbar ist, um mehrere unterlagerte Server zu<br />

aggregieren und damit die Vorteile eines zentralen Zugangspunktes<br />

mit den Vorteilen verteilter intelligenter<br />

Komponenten zu vereinen.<br />

Die prototypische Implementierung der beschriebenen<br />

Aggregationsarchitektur ist in der Lage, beliebige<br />

OPC UA Server zu aggregieren. Die Aggregation<br />

wurde erfolgreich mit drei verschiedenen FDI­Servern<br />

und mehreren OPC­UA­Beispielservern getestet. Alle<br />

Server wurden erfolgreich in ein einziges Informationsmodell<br />

aggregiert. Auch die dynamische Aggregation<br />

von Servern über Discovery­Mechanismen konnte<br />

erfolgreich überprüft werden. Lese­ und Schreibaufträge<br />

sowie Subscriptions zeigten die gewünschten<br />

positiven Ergebnisse. Server, die die beschriebenen<br />

Erweiterungen im Informationsmodell implementierten,<br />

konnten zudem automatisch ohne manuelle<br />

Konfigurationsschritte, zum Beispiel Zuordnungsregeln<br />

für Typen, aggregiert werden. Der abschließende<br />

Test eines FDI Clients im Zusammenspiel mit dem<br />

Aggregationsserver und drei unterlagerten FDI­Servern<br />

zeigte, dass das eigentliche Ziel, nämlich die Illusion<br />

einer zentralen Integrationsplattform, erreicht<br />

wurde. Der Aggregationsserver verhielt sich aus Sicht<br />

des FDI Clients völlig transparent, sodass der FDI Client<br />

arbeiten konnte, als wäre er mit nur einem FDI­<br />

Server verbunden.<br />

AUSBLICK<br />

Die flexible Zusammenarbeit intelligenter verteilter<br />

Komponenten ist eine Kernfunktionalität für Industrie<br />

4.0 [6]. Vermaschte Kommunikationsnetze, wie etwa<br />

das Internet of Things, bilden einen der möglichen Lösungsansätze.<br />

Auch wenn Kommunikation eine essenzielle<br />

Kernfunktion für Industrie 4.0 ist, so sind die<br />

Autoren der Meinung, dass dazu nicht zwangsläufig<br />

50<br />

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

7-8 / 2014


eziehungsweise in allen Fällen eine vermaschte Kommunikationsstruktur<br />

notwendig ist. Die eingangs erwähnte<br />

Komplexität solcher Kommunikationsstrukturen<br />

sowie die möglichen Sicherheitsrisiken beziehungsweise<br />

der für einen sicheren Betrieb erforderliche<br />

Administrationsauswand sind hier zu bedenken. Die<br />

Autoren schlagen daher ein Internet of Portals vor, in<br />

dem Aggregationsplattformen miteinander kommunizieren.<br />

Jede Aggregationsplattform kapselt dabei Geräte,<br />

Subsysteme oder ganze Systeme. Dabei bleiben die Kommunikationsbeziehungen<br />

einfacher zu überblicken und<br />

aus Sicherheitsgesichtspunkten einfacher und damit<br />

weniger aufwendig zu administrieren. Über Mechanismen<br />

wie Discovery und dynamische Aggregation ist das<br />

Internet dennoch keine starre Struktur, sondern kann<br />

sich veränderlichen Randbedingungen ebenfalls flexibel<br />

anpassen. Das vorgestellte Konzept der OPC­UA­<br />

Server­Aggregation geht einen ersten Schritt in eine<br />

solche Richtung.<br />

MANUSKRIPTEINGANG<br />

29.06.2014<br />

Im Peer-Review-Verfahren begutachtet<br />

AUTOREN<br />

Prof. Dr.­Ing. DANIEL GROSSMANN (geb. 1977)<br />

ist Professor für Ingenieurinformatik und<br />

Datenverarbeitung an der Technischen Hochschule<br />

Ingolstadt. Zu seinen Forschungsthemen<br />

zählen neben Geräteintegration vor<br />

allem verteilte Systeme und Informationsmodellierung<br />

in der Automatisierungstechnik<br />

sowie industrielle Kommunikation.<br />

Zuvor war Daniel Großmann Mitarbeiter am<br />

Forschungszentrum Deutschland der ABB AG.<br />

In dieser Rolle arbeitete er maßgeblich an<br />

der FDI­Technologie mit und leitete zwei<br />

Arbeitsgruppen in der FDI­Standardisierung.<br />

Daniel Großmann studierte Maschinenbau<br />

an der Technischen Universität München<br />

mit den Schwerpunkten Informationstechnik<br />

und Automatisierungstechnik. Für seine<br />

Promotion an der TU München im Bereich<br />

Geräteintegration erhielt er 2008 den NAMUR­<br />

Award.<br />

Technische Hochschule Ingolstadt,<br />

Esplanade 10, D-85049 Ingolstadt,<br />

Tel. +49 (0) 841 93 48 28 80,<br />

E-Mail: daniel.grossmann@thi.de<br />

Prof. Dr.­Ing. MARKUS BREGULLA (geb. 1963)<br />

ist seit 2002 Professor für Automatisierungstechnik<br />

an der TH Ingolstadt. Zuvor war er<br />

als wissenschaftlicher Assistent an der<br />

TU­München tätig, wo er 2002 promovierte.<br />

Bregulla studierte Elektrotechnik und war<br />

zunächst als Entwicklungsingenieur für<br />

die Firma ELOP tätig bevor er als selbständiger<br />

Berater und Softwareentwickler arbeitete.<br />

Technische Hochschule Ingolstadt,<br />

Esplanade 10, D-85049 Ingolstadt,<br />

E-Mail: markus.bregulla@thi.de<br />

M.Sc. SUPRATEEK BANERJEE (geb. 1986) ist<br />

seit 2012 wissenschaftlicher Mitarbeiter an der<br />

THI Ingolstadt. Dort forscht er in den Bereichen<br />

industrielle Kommunikation und vertikale/<br />

horizontale Integration. Er studierte an der<br />

Universität Stuttgart INFOTECH. Zuvor studierte<br />

er an der West Bengal University und sammelte<br />

Erfahrung als Systems Engineer.<br />

Technische Hochschule Ingolstadt,<br />

Esplanade 10, D-85049 Ingolstadt,<br />

E-Mail: suprateek.banerjee@thi.de<br />

Dr. rer. nat. DIRK SCHULZ (geb. 1976) ist seit 2006<br />

Wissenschaftler am ABB Forschungszentrum in<br />

Ladenburg. Nach einem Studium der Technischen<br />

Informatik an der Universität Mannheim, promovierte<br />

er über Schutzverfahren für Taktverteilung<br />

in synchronen EVU Weiterverkehrsnetzen.<br />

Aktuell ist er ist als Principal Scientist für den<br />

Bereich Netzwerkmanagement und Geräteintegration<br />

in der Konzernforschung verantwortlich.<br />

ABB AG Forschungszentrum,<br />

Wallstadter Str. 59, D-68526 Ladenburg,<br />

E-Mail: dirk.schulz@de.abb.com<br />

Dipl.­Inf. (FH) ROLAND BRAUN (geb. 1961)<br />

studierte Informatik an der FH Köln. Nach<br />

Stationen in der Produktentwicklung ist er<br />

seit 2004 in der ABB Forschung tätig. Seine<br />

Hauptarbeitsgebiete sind Geräteintegrationstechnologien,<br />

(Feldbus)Protokolle sowie die<br />

Mitarbeit in Standardisierungsgremien.<br />

ABB AG Forschungszentrum,<br />

Wallstadter Str. 59, D-68526 Ladenburg,<br />

E-Mail: roland.braun@de.abb.com<br />

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

7-8 / 2014<br />

51


HAUPTBEITRAG | AUTOMATION 2014<br />

Industrie 4.0 am Beispiel<br />

einer Verbundanlage<br />

Aspekte der Modellierung und dezentralen Architektur<br />

Das Thema Industrie 4.0 verspricht umwälzende Veränderungen in der automatisierten<br />

Fertigung, der Produktionsorganisation und den Prozessen in der Industrie.<br />

In diesem Beitrag werden am Beispiel einer automatisierungstechnischen Verbundanlage<br />

im Sinne eines Zusammenschlusses von Teilanlagen der beteiligten Institute<br />

Potenziale von Industrie 4.0 aufgezeigt und in Bezug auf die Automatisierungstechnologien<br />

diskutiert. Anhand des Anlagenverbundes werden vor allem Aspekte<br />

des Managements von Flexibilität sowie die Möglichkeiten des Informationsaustausches<br />

aufgrund von Dezentralität und Vernetzung verdeutlicht.<br />

SCHLAGWÖRTER Industrie 4.0 / Flexibilität / Industrie-4.0-Komponenten /<br />

Koordination dezentraler Systeme<br />

Industry 4.0 and an Automated System –<br />

Aspects of System Modeling and Decentralized Architecture<br />

Industry 4.0 promises revolutionary changes in automated manufacturing, production<br />

organization, and industrial processes. Its potential is demonstrated with the<br />

integration of distributed facilities of the participating institutes and discussed with<br />

reference to automation technologies. In particular, ways of managing flexibility and<br />

opportunities for information exchange are highlighted for decentralised network<br />

systems.<br />

KEYWORDS Industry 4.0 / flexibility / Industry 4.0 components / coordination of<br />

decentralised systems<br />

52<br />

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

7-8 / 2014


MICHAEL WEYRICH, Universität Stuttgart<br />

CHRISTIAN DIEDRICH, Otto-von-Guericke-Universität Magdeburg<br />

ALEXANDER FAY, Helmut-Schmidt-Universität Hamburg<br />

MARTIN WOLLSCHLAEGER, Technische Universität Dresden<br />

STEFAN KOWALEWSKI, RWTH Aachen University<br />

PETER GÖHNER, Universität Stuttgart<br />

BIRGIT VOGEL-HEUSER, Technische Universität München<br />

Das flexible Management von Produktionsanlagen<br />

ist ein zentrales Thema der Automatisierungstechnik.<br />

Schneller neue Produkte am<br />

Markt zu platzieren, Produktionsanlagen<br />

optimal auszulasten, Spitzenlasten bei der<br />

Produktion abzufedern oder Schwierigkeiten in den<br />

Zulieferketten rasch zu begegnen, sind wichtige Anforderungen<br />

an die Produktion, die erfolgskritisch für die<br />

Zukunft ganzer Industriestandorte sein können.<br />

Viele Forschungsarbeiten befassen sich daher seit<br />

Dekaden mit Themen der Flexibilisierung beziehungsweise<br />

mit der Erhöhung der Agilität von Produktionssystemen<br />

aus den unterschiedlichen Perspektiven des<br />

Produktionsmanagements, der Automatisierungstechnik<br />

und des Maschinenbaus.<br />

Die neuen technologischen Möglichkeiten, wie Adhoc-Vernetzung<br />

und intelligente Steuerungen, die unter<br />

den Schlagworten Industrie 4.0 mit Hilfe von cyberphysischen<br />

Systemen (CPS) subsumiert werden, bieten<br />

viele Chancen. Eine Zukunftsaufgabe ist es, Produktionsmaschinen,<br />

Betriebsmittel, Logistik im Sinne einer<br />

Industrie 4.0 zu organisieren [1]. Daraus entstand die<br />

Idee, anhand des Zusammenschlusses der einzelnen<br />

Automatisierungsanlagen der Institute der Autoren typische<br />

Szenarien von Industrie 4.0 aufzuzeigen.<br />

1. ANSATZ DER AUTOMATISIERUNGSVERBUNDANLAGE<br />

Um die Herausforderungen und den Nutzen von Industrie<br />

4.0 zu demonstrieren, werden die damit verbundenen<br />

Verfahren und Konzepte der Automatisierungstechnik<br />

am Beispiel der Individualproduktion vorgestellt [2, 6].<br />

Auf dieser Basis werden Kopplungsansätze, Datenmodellierung,<br />

dezentrale Steuerung sowie die interaktive Zuteilung<br />

automatischer Teilanlagen diskutiert [5, 7].<br />

Geschmacksvariationen – bestellen. Dieser Auftrag<br />

wird dann auf den unterschiedlichen Anlagen des<br />

Verbundes an den beteiligten Universitätsinstituten<br />

dezentral und über Deutschland verteilt produziert.<br />

Dabei dient das Konzept von Joghurt, der individuell<br />

und auf Kundenwunsch produziert wird, als Beispiel<br />

für kundenindividuelle, den sich rasch ändernden<br />

Wünschen des Marktes anpassende Produktion und<br />

verfolgt keineswegs den Anspruch auf eine verfahrenstechnische<br />

Umsetzung, sondern dient als Szenario,<br />

um die Möglichkeiten der Automatisierungstechnik<br />

aufzuzeigen.<br />

1.2 Die dezentrale Verbundanlage<br />

Die Verbundanlage besteht aus einzelnen Produktionsanlagen,<br />

die in den Laboren der Institute bereits existieren.<br />

Bild 2 zeigt den entstehenden Produktionsverbund<br />

sowie den Informationsfluss zwischen den Systemen.<br />

Dabei sind die Anlagen beziehungsweise Teilanlagen<br />

mit unterschiedlichster Steuerungstechnik<br />

versehen, wie zum Beispiel SPS, Mikrokontroller oder<br />

Industrie-PC. Alle Anlagen sind mit dem Internet verbunden<br />

und können miteinander kommunizieren.<br />

Auch die Unterstützung des Betriebspersonals durch<br />

Informationsaufbereitung und der <strong>Einsatz</strong> von Apps<br />

sind mit diesem Ansatz möglich.<br />

Es ist das Ziel, bestehende Anlagen weiter zu verwenden<br />

und diese auf der Feldebene nicht umzubauen,<br />

sondern diese Teilanlagen zu kapseln und so in den<br />

Industrie-4.0-Verbund einzufügen. Eine Neukonzeption<br />

der Teilanlagen, zum Beispiel auf Basis von einheitlichen<br />

Standards, ist nicht vorgesehen. So soll eine<br />

einfache Integration bestehender Teilanlagen im Sinne<br />

von Industrie-4.0-Komponenten ermöglicht werden.<br />

1.1 Szenarien der Anwendung<br />

Im Anwendungsszenario kann ein Kunde ein konfigurierbares<br />

Produkt – einen Joghurt in verschiedenen<br />

1.3 Anforderungen an die Automatisierungstechnik<br />

Aus Sicht des Produktionsszenarios bestehen eine Reihe<br />

von Anforderungen an die Automatisierungstech-<br />

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

7-8 / 2014<br />

53


HAUPTBEITRAG | AUTOMATION 2014<br />

nologie. Dabei müssen folgende Kernanforderungen in<br />

einem ersten Schritt realisiert werden:<br />

Anforderung 1: Einfache Vergabe des Auftrages für<br />

eine bestimmte Produktkonfiguration und Menge<br />

per Handy-App oder Internet.<br />

Anforderung 2: Automatische Auftragsplanung und<br />

Zuteilung der geeigneten Anlage, möglichst ohne<br />

manuelle Koordination eines Produktionsplaners.<br />

Auch der verteilte Anlagenverbund sollte einfach<br />

konfigurierbar sein. Benötigt wird ein flexibles und<br />

möglichst offenes Planungssystem zur Verwaltung<br />

der Produktionsanlagen, die ihre aktuelle Kapazität<br />

anbieten, da diese gegebenenfalls kurzfristig<br />

aufgrund anderer Aufträge belegt sein könnten.<br />

Anforderung 3: Einfaches An- und Abmelden von<br />

Produktionsanlagen und deren Kapazität im Gesamtsystem.<br />

Bei der Planung der jeweiligen Produktion,<br />

also dem Scheduling von Aufträgen, ergibt<br />

sich die nächste Anforderung.<br />

Anforderung 4: Möglichkeit der Berücksichtigung<br />

von besonderen Kriterien, wie Energieverbrauch<br />

von Anlagen, Wegstrecken in der Logistik, bei der<br />

Produktionsplanung.<br />

Es kann auch notwendig werden, bereits zugeteilte<br />

Aufträge durch die Anlagen direkt weiter- beziehungsweise<br />

unterzuvergeben, um zum Beispiel<br />

unmittelbar auf Störungen reagieren zu können.<br />

Dabei kann die Auftragsvergabe auf gleicher Ebene<br />

erfolgen oder als teilweise Untervergabe ausgeführt<br />

werden. Diese Vergabe sollte bilateral über die Industrie-4.0-Cloud<br />

ausgehandelt werden, ohne die<br />

anderen Teilnehmer behelligen zu müssen.<br />

Anforderung 5: Möglichkeit der Bildung von Produktionsclustern<br />

mit autarkem Auftragsmanagement<br />

und der Möglichkeit der Untervergabe.<br />

Schließlich ist eine Anforderung zur Betriebssicherheit<br />

der Kommunikation wichtig, die die Zuverlässigkeit<br />

des Kommunikationsprozesses betrifft.<br />

Anforderung 6: Falls die Internetverbindung kurzzeitig<br />

nicht verfügbar ist beziehungsweise unterbrochen<br />

wird, so dürfen keine Planungsinformationen<br />

verloren gehen.<br />

Weitere Anforderungen, wie die einfache Bedienbarkeit<br />

durch Anwender, Möglichkeiten der Diagnose oder Anforderungen<br />

an die IT-Sicherheit, sind ebenfalls relevant,<br />

werden aber im Beitrag nicht betrachtet.<br />

Im Rahmen des Produktionsbeispiels zeigt Bild 3 die<br />

einzelnen Vor- und Zwischenprodukte des Joghurts, wie<br />

Geschmacksstoffe oder Verpackungsmaterialien, die mit<br />

P1 bis P8 gekennzeichnet sind. Diese Produkte werden<br />

in den einzelnen Prozessstufen O11 bis O14 im Sinne<br />

der Herstellung beziehungsweise Veredelung oder der<br />

Fertigung von Verpackungen und der Gravur der Deckel<br />

produziert. Diese Produktionsschritte unterliegen jedoch<br />

Restriktionen in Bezug auf die Reihenfolge der<br />

Produktion oder müssen unmittelbar zusammenhängend<br />

in einzelnen Chargen (Batches) erfolgen. So kann<br />

natürlich die Veredelung mit Früchten erst erfolgen,<br />

wenn der Joghurt hergestellt wurde, und die Abfüllung<br />

des Joghurts sollte in einem Verfahrensschritt erfolgen.<br />

Mit Blick auf Bild 2 sind P1 und P2 Vorprodukte für<br />

P7. Allerdings kann P8 erst nach Verfügbarkeit von P7<br />

durch Zugabe von P3 produziert werden. Unabhängig<br />

davon ist die Produktion von P9, die parallel davor oder<br />

danach erfolgen kann.<br />

Reihenfolgerestriktionen sind besonders bei der Verteilung<br />

der Prozesse auf die Ressourcen zu beachten.<br />

Beim Scheduling, also dem Einplanen von konkreten<br />

Produktionsaufträgen auf Produktionsanlagen, müssen<br />

zudem weitere Aspekte, zum Beispiel die Logistik, berücksichtigt<br />

werden.<br />

Für einfache Produktionsprozesse sind diese Zuteilungen<br />

unter Umständen sehr einfache direkte Relationen:<br />

So kann die Herstellung des Joghurts aufgrund<br />

von Ressourcenverfügbarkeiten womöglich nur auf<br />

einer bestimmten Produktionsanlage erfolgen. Mit einer<br />

zunehmenden Verfügbarkeit von redundanten Ressourcen<br />

ergeben sich unterschiedliche Varianten für<br />

den Produktionsprozess. Aufgrund von konkurrierenden<br />

Produktaufträgen ergeben sich jedoch rasch<br />

komplexe Planungsaufgaben, die zudem mit einer Vielzahl<br />

von Restriktionen versehen sein können, was die<br />

BILD 1: Individuelle Produktion auf Kundenwunsch<br />

bedeutet: schnell neue Produkte am Markt<br />

platzieren, Produktionsanlagen optimal auslasten,<br />

Spitzenlast abfedern, Schwierigkeiten in der Zulieferkette<br />

rasch beheben, Kundenwünsche berücksichtigen,<br />

Produktion anpassen und flexibilisieren etc.<br />

54<br />

3. KONZEPTION<br />

Die Modellierung der Verbundanlage wird mit den Konzepten<br />

der VDI-Richtlinie 3682 beschrieben. Hierbei entspricht<br />

es dem Stand der Technik, den Prozess formalisiert<br />

in die Bestandteile Produkt, Prozess und Ressourcen<br />

zu untergliedern. Diese PPR-Methodik bildet die Basis<br />

für eine Vielzahl von industriellen Planungssystemen.<br />

Dabei folgt die Prozessbeschreibung der Einteilung Produkt<br />

(P), Prozesse beziehungsweise Prozessoperatoren<br />

(O), technische Ressource (T) sowie Bilanzgrenze (B).<br />

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

7-8 / 2014


Zuteilung von Prozessen komplex macht, da die Frage<br />

ist, wann welche Teilanlage gewählt werden soll.<br />

3.1 Auswahl von Teilanlagen<br />

Die einzelnen Teilanlagen stehen über Deutschland<br />

verteilt zur Verfügung und bieten ihr Leistungsspektrum<br />

in einem virtuellen Marktplatz an. Bild 4 (Zentraler<br />

Marktplatz) zeigt die Grundstruktur, die als Stern<br />

organsiert die einzelnen Anlagenkomponenten zentral<br />

verwaltet. Im Mittelpunkt steht der Markplatz, in dem<br />

sich alle beteiligten Teilanlagen listen lassen können.<br />

Die Anlagen sind dabei sehr unterschiedlich und erlauben<br />

die Realisierung unterschiedlicher Prozesse<br />

oder können auch identische Prozessschritte redundant<br />

abdecken, wenn sie an einer Auftragsvergabe teilnehmen.<br />

Auf dem Marktplatz sind somit alle Teilanlagen<br />

bekannt, wobei jeder Teilanlage ein Leistungsprofil<br />

zugeordnet ist, in dem die Fähigkeiten beziehungsweise<br />

Dienste beschrieben sind.<br />

Erfolgt nun eine Anfrage bezüglich der Herstellung<br />

einer Charge eines Produkts, so wird zunächst anhand<br />

des Leistungsprofils geprüft, welche Teilanlagen diese<br />

Aufgabe ausführen könnten. Sobald entsprechende Teilanlagen<br />

identifiziert wurden, muss eine konkrete Anfrage<br />

erfolgen, ob beziehungsweise wann die Teilanlage<br />

tatsächlich zur Verfügung steht, da diese beispielsweise<br />

durch Wartungsarbeiten außer Betrieb sein könnte.<br />

Bild 4 (Zwei Marktplätze) visualisiert ein Konzept, in<br />

dem zwei Marktplätze vorhanden sind, die teilweise<br />

dieselben Ressourcen gelistet haben. Solche Konzepte<br />

sind praktikabel, da es aus Sicht des einzelnen Anlagenbetreibers<br />

sinnvoll ist, um ihre Anlagen möglichst komplett<br />

auszulasten. Mit Blick auf einen einzelnen Marktplatz<br />

wäre es vielleicht sonst nicht möglich, die Teilanlagen<br />

vollständig auszulasten, da die Kapazität gar nicht<br />

vollständig gebraucht wird. Das Spektrum der Aufträge<br />

und die Verfügbarkeit der Teilanlagen entscheiden über<br />

die tatsächliche Belegung der Teilanlagen.<br />

In Bild 5 wird der Anmelde- und Anfrageprozess für<br />

die vier Teilanlagen T14, T24, T11, T21 an einem Marktplatz<br />

dargestellt. Dabei geht es um zwei Hauptfunktionen,<br />

die am Marktplatz ausgeführt werden: Zum einen<br />

die Funktion, die Leistungen im Sinne von Fähigkeiten<br />

oder Diensten zu listen, das heißt ein Verzeichnis zu<br />

erstellen, in dem alle technischen Möglichkeiten der<br />

Teilanlage beziehungsweise Industrie-4.0-Komponente<br />

dokumentiert sind. Zum anderen der Vorgang eines<br />

Auftragsvermittlers (Brokers), der Anfragen stellt, Angebote<br />

dazu erhält und dann schließlich die Wahl der<br />

Beauftragung trifft.<br />

Der Kommunikationszyklus am Marktplatz sieht wie<br />

folgt aus: In einem ersten Schritt melden sich alle Teilanlagen<br />

im Verzeichnis der Dienste und Fähigkeiten an.<br />

In einem zweiten Schritt kommt eine Vermittler-, das<br />

heißt eine Brokerfunktion zum Zuge, die ermittelt, welche<br />

Industrie-4.0-Komponenten oder Teilanlagen geeignet<br />

sind. In Schritt 3 und 4 werden diese Komponenten<br />

zunächst um ein Angebot gebeten, das dann durch die<br />

jeweiligen Industrie-4.0-Komponenten abgegeben wird.<br />

Schließlich erfolgt in Schritt 5 die Auswahl des Angebots,<br />

das dann abschließend (Schritt 6) beauftragt wird.<br />

Dieses Vorgehen mit einer zentralen Stellung Marktplatz<br />

in einer Stern-Struktur beziehungsweise Mehrstern-Struktur<br />

hat Realisierungsvorteile, da jeweils nur<br />

Punkt-zu-Punkt-Verbindungen zum Marktplatz aufgebaut<br />

werden müssen und jeder Marktplatz über eine<br />

zentrale Prozessplanung und Steuerung verfügt. Allerdings<br />

muss im Zentrum des Sterns immer die gesamte<br />

Information vorliegen. Dies hat Nachteile im Sinne der<br />

Informations- und der Ausfallsicherheit.<br />

I4.0 Komponente<br />

Teil-<br />

Anlage<br />

Institut<br />

1<br />

Forschungsverbundanlage<br />

I4.0 Komponente<br />

Teil-<br />

Anlage<br />

Institut<br />

…<br />

I4.0 Komponente<br />

Teil-<br />

Anlage<br />

Institut<br />

n<br />

I4.0 Cloud-Services zur Auftragsplanung und<br />

Zuteilung der Teilanlagen (I4.0 Komponenten)<br />

P3<br />

P4<br />

P1<br />

Joghurtherstellung<br />

O11<br />

P7<br />

Joghurtveredelung<br />

O12<br />

B12<br />

P8<br />

Abfüllung<br />

O14<br />

P2<br />

B11<br />

Gäranlage<br />

T11<br />

Mischanlage<br />

T12<br />

P5<br />

Deckelgravierung<br />

O13<br />

P9<br />

B13<br />

Fräsanlage<br />

T13<br />

Abfüllanlage<br />

T14<br />

Aufträge<br />

HMI<br />

P6<br />

B14<br />

BILD 2: Konzept des informationstechnischen<br />

Zusammenschlusses einzelner Anlagen zu einem<br />

virtuellen Produktionsverbund<br />

BILD 3: PPR-Modell der Verbundanlage<br />

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

7-8 / 2014<br />

55


HAUPTBEITRAG | AUTOMATION 2014<br />

Es besteht die Möglichkeit, weitere Kommunikationskanäle<br />

zwischen den einzelnen beteiligten Ressourcen<br />

herzustellen, wenn es um die Untervergabe von Aufträgen<br />

oder die Abgabe von aggregierten Angeboten<br />

geht. Beispielsweise kann im Fall einer Störung einer<br />

Industrie-4.0-Komponente eine andere Industrie-4.0-<br />

Komponente unterbeauftragt oder informiert werden,<br />

ohne sich erneut an den zentralen Marktplatz wenden<br />

zu müssen. Auf diese Weise wird Flexibilität aufgrund<br />

der Möglichkeit von Nebenabsprachen zwischen einzelnen<br />

Industrie-4.0-Komponenten gewonnen.<br />

Bild 6 zeigt eine solche Struktur, in der auch zwischen<br />

einzelnen Industrie-4.0-Komponenten direkte<br />

Kommunikation stattfindet.<br />

Allerdings wirft eine solche Kommunikationsstruktur<br />

Fragen in Bezug auf die Koordination der einzelnen<br />

Industrie-4.0-Komponenten auf, bei der die Rollen der<br />

Kommunikationspartner und womöglich Hierarchien<br />

definiert werden müssen. Zudem besteht die Möglichkeit,<br />

in einem hochvernetzten Szenario in jedem Knoten<br />

einen virtuellen Marktplatz zu duplizieren, wodurch<br />

ein zum Beispiel ausfallsicheres System entsteht, aber<br />

ein Synchronisationsmechanismus notwendig wird.<br />

Die Wahl der Architektur ist vom Use Case der Anwendung<br />

abhängig: So können Daten lokal verwaltet werden,<br />

um den Zugriff durch andere zu verhindern. Oder es kann<br />

ein robustes System erstellt werden, dessen Funktion<br />

beim Ausfall aufgrund von Redundanz weiterarbeitet.<br />

3.2 Kommunikationsarchitekturen<br />

Die Kommunikation zwischen den Teilsystemen lässt sich<br />

auf Basis voneinander abweichender Konzepte aufbauen.<br />

Die Kommunikationsanbindung einzelner Systeme beziehungsweise<br />

Industrie-4.0-Komponenten kann heute mit<br />

Hilfe unterschiedlicher Infrastruktur erfolgen. Es existieren<br />

auf einer syntaktischen Ebene bereits Standards und<br />

Verfahren zur Nachrichtenübermittlung. Allerdings sind<br />

bei der Auswahl die Rahmenbedingungen zu bedenken:<br />

Kommunikationsgeschwindigkeit: Die Verzugszeit, mit<br />

der Information von Sender zu Empfänger übertragen<br />

werden muss, kann stark variieren. Handelt es sich, wie<br />

in diesem Fall, um den Austausch von leittechnischer<br />

Information, so sind Antwortzeiten im Bereich von Sekunden<br />

oder Millisekunden üblich. Hingegen unterlägen<br />

Maschinensteuerungen und Antriebsregelungen harten<br />

Echtzeitanforderungen im Millisekunden-Bereich, was<br />

aufgrund der Anlagenstruktur hier so nicht gegeben ist.<br />

Übertragungsrate: Auch die Länge der zu übertragenden<br />

Botschaft kann unterschiedlich sein und ist<br />

grundsätzlich bei der Auswahl des Übertragungsprotokolls<br />

zu beachten. Allerdings ist die Übertragungsrate<br />

im Beispiel der Verbundanlage und den dort herrschenden<br />

zeitlichen Rahmenbedingungen nicht von<br />

zentraler Bedeutung.<br />

Kapselung von Information: Einzelne Daten lassen<br />

sich je nach Anwendung zu einem Portfolio aus Services<br />

zusammenfassen. Diese Orchestrierung im Sinne<br />

einer Service-orientierten Architektur (SOA) ist dabei<br />

abhängig von der Art der Anwendung und den sinnvollen<br />

Möglichkeiten der Bündelung von Diensten.<br />

Zuverlässigkeit der Übermittlung: Insbesondere bei der<br />

Übermittlung über Medien wie dem Internet kann nicht<br />

immer davon ausgegangen werden, dass alle Information<br />

vom Sender zum Empfänger gelangt. Um sicherzustellen,<br />

dass alle gesendeten Nachrichten ankommen,<br />

können Messaging-Systeme zum <strong>Einsatz</strong> gebracht werden,<br />

die die Zustellung einer Nachricht sicherstellen.<br />

Zentraler Marktplatz<br />

Tn<br />

T1<br />

Tn<br />

T11<br />

…<br />

Virtueller<br />

Marktplatz<br />

T12<br />

T21<br />

T4<br />

Virtueller<br />

Marktplatz<br />

T2<br />

BILD 5:<br />

Kommunikationszyklus<br />

zur<br />

Belegung<br />

Tn<br />

Zwei Marktplätze<br />

T11<br />

T41<br />

T3<br />

…<br />

Virtueller<br />

Marktplatz A<br />

T12<br />

T21<br />

Virtueller<br />

Marktplatz B<br />

T32<br />

T31<br />

BILD 4: Virtueller Marktplatz der Ressourcen.<br />

Oben: zentraler Marktplatz mit Ressourcen.<br />

Unten: unterschiedliche Marktplätze mit geteilten<br />

Ressourcen<br />

56<br />

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

7-8 / 2014


Einheitliche Architektur: Ideal ist, ein einheitliches<br />

Systemprotokoll im Sinne von OPC UA (unified architecture)<br />

zu nutzen, um einen möglichst strukturierten<br />

Austausch von Information sicherzustellen, das heißt,<br />

nicht nur Daten zu übertragen, sondern auch maschinenlesbar<br />

semantische Information zu übermitteln.<br />

Zudem gibt es Möglichkeiten, mit Hilfe einer agentenbasierten<br />

Architektur dezentrale Systeme zu steuern. Solche<br />

Agentensysteme bieten die Chance, dezentral organisierte<br />

Steuerungen beziehungsweise Optimierungen<br />

aufzubauen. Hierzu gibt es Standards der FIPA, die die<br />

Kommunikation zwischen Agenten regeln. Neben technischen<br />

Überlegungen in Bezug auf die grundsätzlichen<br />

Fähigkeiten sind ebenso Realisierungsaspekte von Bedeutung,<br />

da die Standards und Verfahren sich im Reifegrad<br />

und in der Verbreitung in der Praxis unterscheiden.<br />

4. REALISIERUNG<br />

Zur Realisierung der Verbundanlage wurden solche<br />

Verfahren ausgewählt, die unmittelbar umsetzbar sind.<br />

Die bestehenden Teilsysteme sollen als Industrie-4.0-<br />

Komponenten im Verbund sichtbar werden, um diese<br />

unmittelbar in eine Industrie-4.0-Gesamtarchitektur<br />

zu integrieren.<br />

4.1 Realisierung mit Agentensystem<br />

Um die sehr unterschiedlichen Anlagen in den Verbund<br />

flexibel einzubinden, kommt ein Agentensystem<br />

zum <strong>Einsatz</strong>. Agenten sind dynamische und gekapselte<br />

Module, die mit anderen Agenten und ihrer Umgebung<br />

interagieren können. Dabei verfolgen die Agenten<br />

eigene Ziele und haben Handlungsoptionen zur Verfügung,<br />

wodurch ein autonomes Verhalten entsteht. Somit<br />

bringt der Ansatz der Agentensysteme viele Voraussetzungen<br />

zur Realisierung komplexer Kommunikationsstrukturen<br />

mit, bei denen die Teilnehmer unterschiedliche<br />

Rollen haben.<br />

In Bild 7 ist die Topologie des verwendeten Agentensystems<br />

dargestellt. Einzelne Anlagen werden durch Agenten<br />

vertreten, die diese nach innen kapseln, um dann eine<br />

einheitliche Schnittstelle nach außen als Industrie-4.0-<br />

Komponente darzustellen. In der Industrie-4.0-Cloud ist<br />

alle wichtige Information zu den beteiligten Agenten, den<br />

Fähigkeiten und Dienstangeboten der Komponenten verzeichnet.<br />

Die Kommunikation zwischen den Agenten ist<br />

abhängig von der Aufgabe, die diese erfüllen sollen, und<br />

den Fähigkeiten der einzelnen Agenten.<br />

Innerhalb des Verbundes gibt es verschiedene Agententypen,<br />

die unterschiedliche Ziele verfolgen und<br />

Aufgaben wahrnehmen:<br />

Anlagenagent: Dieser repräsentiert die jeweilige automatisierte<br />

Maschine oder Teilanlage im Verbund über<br />

eine einheitliche Schnittstelle. Jeder dieser Agenten verfügt<br />

über eine spezifische Verbindung zu dem von ihm<br />

vertretenen automatisierten System nach innen und<br />

vertritt diese als Industrie-4.0-Komponente und deren<br />

Ziele im Verbund. Zur Repräsentation der Industrie-4.0-<br />

Komponente verfügen die Agenten über die Information,<br />

über welche Fähigkeiten das System verfügt beziehungsweise<br />

welche Aufgaben es erledigen kann. Ziele könnten<br />

zum Beispiel die maximale Auslastung oder die Belegung<br />

zu ganz bestimmten Zeitpunkten sein.<br />

Benötigt ein Agent des Verbundes eine besondere Fähigkeit<br />

einer anderen Industrie-4.0-Komponente, so<br />

verhandeln diese Agenten untereinander. Ziel der Ver-<br />

Virtueller Marktplatz in<br />

der I4.0 Cloud<br />

Angebots-<br />

Auswahl Anmeldung<br />

abgabe<br />

1<br />

2<br />

3<br />

4<br />

5<br />

6<br />

Broker-<br />

Funktion<br />

Welche I4.0-Komponenten /<br />

Teilanlagen sind geeignet?<br />

Verzeichnis Dienste<br />

und Fähigkeiten<br />

Anfrage „Abfüllen“<br />

Liste mit Komponenten<br />

Anfragen an Anlage T14<br />

Anfragen an Anlage T24<br />

Abgabe von Angeboten<br />

Abgabe von Angeboten<br />

Auswahl des besten Angebots<br />

Beauftragung<br />

Welche Dienste und<br />

Fähigkeiten stehen bereit?<br />

Anmelden mit<br />

Fähigkeiten<br />

I4.0<br />

Komponente<br />

Abfüllanlagen<br />

I4.0<br />

Komponente<br />

Gäranlagen<br />

T14 T24 T11 T21<br />

BILD 6:<br />

Systemtopologie<br />

mit Verbindung<br />

der Ressourcen<br />

untereinander<br />

und zentralem<br />

Marktplatz<br />

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

7-8 / 2014<br />

57


HAUPTBEITRAG | AUTOMATION 2014<br />

handlung ist es, eine für beide Seiten möglichst optimale<br />

Lösung zu finden, unter Berücksichtigung der<br />

Fähigkeiten und Randbedingungen der Einzelsysteme.<br />

Koordinationsagent: Die Aufgabe dieser Agenten ist<br />

die Koordination komplizierterer Abläufe innerhalb<br />

des Verbundes, welche nicht von einem einzelnen System<br />

im Sinne einer bilateralen Kommunikation durchgeführt<br />

werden können. Die Koordination der Produktion<br />

des Joghurts im Verbund durch einen Broker auf<br />

dem virtuellen Marktplatz ist eine solche Aufgabe.<br />

Dabei müssen die verschiedenen Arbeitsschritte organisiert<br />

und aufeinander abgestimmt werden. Dazu<br />

erfragt der Koordinationsagent bei der Industrie-4.0-<br />

Cloud, welche Agenten die benötigten Fähigkeiten anbieten<br />

und verhandelt anschließend mit diesen Agenten<br />

die Bedingungen für die Durchführung der Produktion.<br />

Kundenagent: Dieser Agent stellt die Schnittstelle des<br />

Verbundes zum Menschen dar, damit der Koordinationsagent<br />

bei den Verhandlungen die Interessen der Kunden<br />

berücksichtigen kann. Über den Kundenagenten<br />

kann ein Kunde neue Aufträge in das System eingeben.<br />

Dazu interagiert der Kundenagent mit dem Koordinationsagenten<br />

und teilt dem Kunden schließlich mit, wann<br />

mit der Joghurt-Produktion zu rechnen ist.<br />

Die Agenten in der Anwendung sind teilweise sehr unterschiedlich<br />

implementiert. Einerseits gibt es eigenentwickelte<br />

Agenten, die auch auf SPS lauffähig sind.<br />

Hierzu wurde auf eine besonders effiziente Programmierung<br />

geachtet. Andererseits wurden die Agenten<br />

auf der Plattform Jade implementiert, da manche Systeme<br />

ohnehin mit einem Industrie-PC ausgestattet sind<br />

und durch den <strong>Einsatz</strong> von offenen Plattformen Agentenfunktionalitäten<br />

in unterlagerten Industrie-4.0-<br />

Komponenten genutzt werden können.<br />

Die Verbindung zum System kann individuell verschieden<br />

sein und von einer einfachen Feldbus-Verbindung<br />

bis zu einer vollständigen Integration in die Steuerung<br />

des Systems reichen.<br />

4.2 Realisierung der Verzeichnisse in Industrie-4.0-Cloud<br />

In einer Industrie-4.0-Cloud ist die Managementinformation<br />

für den Agentenverbund enthalten. Im Agentenverzeichnis<br />

sind alle am Verbund beteiligten Agenten und<br />

deren Adressen aufgeführt. Damit dieses Verzeichnis<br />

stets aktuell ist, überprüft das Agentensystem in regelmäßigen<br />

Intervallen ob die eingetragenen Agenten noch<br />

erreichbar sind und aktualisiert das Agentenverzeichnis.<br />

Ein weiterer Bestandteil der Industrie-4.0-Cloud ist das<br />

Dienste- und Fähigkeitsverzeichnis, aus dem mit entsprechenden<br />

Nachrichten Information abgefragt werden<br />

kann. Dort ist hinterlegt, welcher Agent welche Fähigkeiten<br />

anbietet. Ein Agent, der für die Erfüllung seines<br />

Ziels eine Fähigkeit von einem anderen Agenten benö tigt,<br />

kann durch eine Abfrage der Verzeichnisse eine Liste mit<br />

Agenten erhalten, die die geforderte Fähigkeit besitzen<br />

beziehungsweise einen Dienst dazu anbieten.<br />

In der Industrie-4.0-Cloud ist zusätzlich noch das<br />

Botschaftsverzeichnis enthalten. In diesem Verzeichnis<br />

ist abrufbar, welche Botschaften zur Erbringung<br />

einer bestimmten Fähigkeit benötigt werden, dazu gehören<br />

die Botschaften, die bei der Verhandlung benötigt<br />

werden.<br />

Die Industrie-4.0-Cloud wurde mit einem klassischen<br />

zentralen Aufbau realisiert, das heißt, die Verzeichnisse<br />

werden von einem zentralen Agenten zur Verfügung<br />

gestellt. Vorteil dieses Aufbaus ist, dass keine<br />

komplizierten Synchronisationen notwendig sind. Allerdings<br />

wird die Cloud dadurch zu einem sicherheitskritischen<br />

Punkt, da bei einem Ausfall der Verbund nur<br />

noch sehr eingeschränkt funktionsfähig ist. Alternativ<br />

könnte die Industrie-4.0-Cloud auf mehrere Agenten<br />

verteilt werden; dabei ist es jedoch schwierig, die Synchronisation<br />

sicherzustellen, damit die Verzeichnisse<br />

der einzelnen Agenten dieselbe Information enthalten.<br />

4.3 Realisierung der Mensch-Maschine-Schnittstelle<br />

Die Mensch-Maschine-Schnittstelle wurde in Form<br />

eines Kundenportals umgesetzt. Über das Kundenportal<br />

werden Anfragen und Aufträge in die Industrie-4.0-<br />

Verbundanlage eingebracht. Dies können zum Beispiel<br />

Produktionsaufträge oder Diagnoseanfragen sein. Das<br />

Kundenportal besteht aus einem Kundenagenten und<br />

einer entsprechenden Benutzungsschnittstelle. Der<br />

Kundenagent ist dafür verantwortlich, mit den anderen<br />

Agenten des Industrie-4.0-Verbunds zu kommunizieren<br />

und entsprechende Daten auszutauschen. Für die Einbringung<br />

eines Auftrags sucht der Kundenagent in der<br />

Industrie-4.0-Cloud nach passenden Anlagen- beziehungsweise<br />

Koordinationsagenten, die den gewünschten<br />

Auftrag erledigen können, und kontaktiert diese im<br />

I4.0 Komponente<br />

I4.0 Komponente<br />

Gäranlage<br />

T11<br />

Agent<br />

Web Socket<br />

Abfüllanlage<br />

T14<br />

Agent<br />

Web Socket<br />

I4.0 Komponente<br />

Mischanlage<br />

T12<br />

Agent<br />

Web Socket<br />

I4.0 Komponente<br />

App.-<br />

Mensch-<br />

Maschine-<br />

Schnittstelle<br />

Fräsanlage<br />

T13<br />

Agent<br />

Web Socket<br />

Industrie-4.0-Cloud mit<br />

Agenten- Management<br />

und Koordination<br />

Agentenverzeichnis<br />

Kundenagent<br />

Diensteverzeichnis<br />

Fähigkeitenverzeichnis<br />

BILD 7: Agententopologie der Verbundanlage<br />

58<br />

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

7-8 / 2014


Anschluss mit der Bitte um Zusendung eines Angebots.<br />

Die Benutzungsschnittstelle, welche direkt an den<br />

Kundenagenten angebunden ist, erlaubt es, externe<br />

Aufträge in den Verbund einzubringen. Die Benutzungsschnittstelle<br />

kann als klassische Desktopanwendung<br />

realisiert sein, als mobile App für Smartphones<br />

und Tablets oder als mobile Webseite. Klassische Desktopanwendungen<br />

oder mobile Apps haben den Nachteil,<br />

dass für jedes Betriebssystem meist eigene Anwendungen<br />

entwickelt werden müssen, was mehr Aufwand<br />

erfordert.<br />

Der prototypische Aufbau der Benutzungsschnittstelle<br />

wurde daher als mobile Webseite ausgeführt. Das<br />

Design orientiert sich an Anwendungen für mobile<br />

Endgeräte, besteht jedoch aus einer Webseite, die auf<br />

sämtlichen Zielplattformen, wie Windows, iOS, Google,<br />

aufgerufen werden kann, siehe Bild 8. Die Benutzungsschnittstelle<br />

wurde mit HTML5 und Java Skript realisiert,<br />

ist per Maus und per Finger bedienbar und passt<br />

sich den verschiedenen Endgeräten, zum Beispiel<br />

Smartphone, Tablet, Desktop, automatisch an.<br />

Über das Kundenportal können ferner Rückmeldungen<br />

und Information zu aktuellen Prozessen eingesehen<br />

werden. So kann es einem Anwender ermöglicht<br />

werden, eine Bestellung über den gesamten Produktionsprozess<br />

zu verfolgen oder gar nachträglich Änderungen<br />

an der Bestellung vorzunehmen.<br />

4.4 Realisierung der Kommunikationsinfrastruktur<br />

BILD 8:<br />

Benutzungsschnittstelle<br />

des Kundenportals<br />

von<br />

myJoghurt<br />

Das System kommuniziert auf Basis von Web-Sockets<br />

über das Internet. Das Protokoll verwendet TCP-Sockets<br />

für das Senden beziehungsweise Empfangen von<br />

Nachrichten. Alle Agenten, die eine Industrie-4.0-<br />

Komponente vertreten, verwenden dasselbe Kommunikationsprotokoll<br />

nach außen, um mit den anderen<br />

Agenten des Verbundes Nachrichten auszutauschen.<br />

Der Anlagenverbund verwendet nach außen ein Protokoll,<br />

welches in den Grundzügen mit dem von der FIPA<br />

definierten Protokoll zur Agentenkommunikation vergleichbar<br />

ist. Nach innen erfolgt die Kommunikation<br />

zur jeweiligen Anlagenkomponente hingegen sehr unterschiedlich<br />

und ist spezifisch auf die jeweilige Teilanlage<br />

abgestimmt.<br />

In der vorliegenden Realisierung wird jeder Agent innerhalb<br />

des Protokolls über die IP-Adresse und den Port<br />

des Sockets identifiziert. Die eigentlichen Nachrichten<br />

werden als einfache Zeichenfolgen im ASCII-Format<br />

übertragen und nicht im HTTP-Protokoll. Eine Nachricht<br />

besteht dabei aus einzelnen Abschnitten, welche durch<br />

bestimmte Zeichen voneinander getrennt sind. Die Reihenfolge<br />

der einzelnen Abschnitte ist fest definiert.<br />

Dies erlaubt es, eine Nachricht auch auf Systemen mit<br />

nur eingeschränkten Fähigkeiten, zum Beispiel SPS,<br />

als Zeichenkette zu verarbeiten, da der Inhalt eines<br />

Feldes erst nach dem Zerlegen geparst werden muss.<br />

Dieses Protokoll wird für die Kommunikation zwischen<br />

den Agenten und mit der Industrie-4.0-Cloud<br />

verwendet. Hauptanteil der Kommunikation mit der<br />

Cloud ist die Klärung der Frage, welche Agenten eine<br />

bestimmte Fähigkeit zur Verfügung stellen beziehungsweise<br />

unter welcher Adresse dieser Agent erreichbar<br />

ist. Damit diese Information in der Cloud vorhanden<br />

ist, muss sich jeder teilnehmende Agent an der Cloud<br />

mit einer entsprechenden Nachricht anmelden. Dabei<br />

überträgt er neben seinem Namen und seiner Adresse<br />

eine Liste seiner Fähigkeiten.<br />

5. VERBESSERUNG DER<br />

KOMMUNIKATIONSINFRASTRUKTUR<br />

Die Verfügbarkeit der Kommunikationsinfrastruktur ist<br />

eine essenzielle Voraussetzung für die Flexibilität, durch<br />

die Industrie-4.0-gerechte Applikationen gekennzeichnet<br />

sind. Dies erfordert leistungsfähige Lösungen zum<br />

Management dieser Kommunikationsinfrastruktur, der<br />

vernetzten Industrie-4.0-Komponenten selbst und der<br />

durch sie angebotenen Dienste. Die Anforderungen aus<br />

der Applikation können herangezogen werden, um das<br />

Themenfeld Quality of Service zu spezifizieren. Hierzu<br />

gehören beispielsweise die garantierte Bereitstellung von<br />

Bandbreite, die Zusicherung von Prioritäten, das Garantieren<br />

von Zeitschranken und schließlich die Einhaltung<br />

von Kommunikationskosten.<br />

Die Integration von IT und Automatisierungsfunktionalität<br />

erfordert eine Erweiterung des Netzwerkmanagements<br />

dahingehend, dass es in der Lage sein muss, die<br />

automatisierungsspezifischen Anforderungen in einer<br />

zunehmend heterogenen Kommunikationsstruktur<br />

handhaben zu können und dabei möglichst existierende<br />

beziehungsweise etablierte Technologien zu integrieren.<br />

Derzeit wird in der Automation das Simple Network Management<br />

Protocol (SNMP) als De-facto-Standard eingesetzt.<br />

Dies reicht jedoch nicht aus, um die gestiegenen<br />

Anforderungen effizient erfüllen zu können.<br />

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

7-8 / 2014<br />

59


HAUPTBEITRAG | AUTOMATION 2014<br />

Im Rahmen der Automatisierungsverbundanlage sollen<br />

neue Entwicklungen wie Web Based Enterprise Management<br />

[3], in den Anwendungskontext eingeführt werden<br />

[4]. So nutzt Web Based Enterprise Management Technologien<br />

wie http und XML, trägt aber ebenso Sicherheitsüberlegungen<br />

Rechnung. Anders als bei SNMP sind Authentifikation,<br />

Autorisation, Integrität, Verschlüsselung<br />

und Logging fester Bestandteil der WBEM-Infrastruktur.<br />

AUTOREN<br />

Prof. Dr.-Ing. MICHAEL WEYRICH (geb. 1967) leitet seit April 2013<br />

das Institut für Automatisierungstechnik und Softwaresysteme<br />

(IAS) an der Universität Stuttgart. Zuvor war er an der Universität<br />

Siegen Professor für Fertigungsautomatisierung. Er verfügt über<br />

10-jährige Industrieerfahrung zunächst bei der Daimler AG und<br />

später bei der Siemens AG. Seine Forschungsinteressen liegen auf<br />

dem Gebiet von Cyber-physischen Produktionsmodulen sowie<br />

Smarten Komponenten für die Automatisierungstechnik. Dabei<br />

steht die Komposition, Modularisierung, Qualitätssicherung und<br />

Evaluation automatisierter Systeme im Mittelpunkt der Forschung.<br />

Institut für Automatisierungs- und Softwaretechnik,<br />

Universität Stuttgart, Pfaffenwaldring 47, D-70569 Stuttgart,<br />

Tel. +49 (0) 711 68 56 73 21, E-Mail: michael.weyrich@ias.uni-stuttgart.de<br />

Prof. Dr.-Ing. CHRISTIAN DIEDRICH (geb. 1957) leitet den Lehrstuhl<br />

Integrierte Automation an der Otto-von-Guericke-Universität Magdeburg.<br />

Außerdem ist er stellvertretender Institutsleiter des Ifak e.V. in<br />

Magdeburg. Seine Hauptarbeitsfelder umfassen Beschreibungsmethoden<br />

für Automatisierungsgeräte und -systeme, Engineeringmethoden<br />

und Informationsmanagement, formale Methoden in der Automatisierungstechnik.<br />

Er ist in nationalen und internationalen Standardisierungs-<br />

und Fachgremien (IEC, DKE, ZVEI, PNO) tätig.<br />

Otto-von-Guericke Universität Magdeburg,<br />

Institut für Automatisierungstechnik, PF 4120, D-39016 Magdeburg,<br />

Tel. +49 (0) 391 671 84 99, E-Mail: christian.diedrich@ovgu.de<br />

Prof. Dr.-Ing. ALEXANDER FAY (geb. 1970) ist Professor für Automatisierungstechnik<br />

an der Fakultät für Maschinenbau der Helmut-Schmidt-<br />

Universität/Universität der Bundeswehr, Hamburg. Sein Forschungsschwerpunkt<br />

sind Beschreibungsmittel, Methoden und Werkzeuge für<br />

einen effizienten Entwurf von Automatisierungssystemen.<br />

Helmut-Schmidt-Universität,<br />

Holstenhofweg 85, D-22043 Hamburg<br />

Prof. Dr.-Ing. STEFAN KOWALEWSKI (geb. 1962) leitet den<br />

Lehrstuhl Informatik 11 – Software für eingebettete Systeme an<br />

der RWTH Aachen. Seine Forschungsinteressen liegen in der<br />

An wendung und Weiterentwicklung modellbasierter und<br />

formaler Methoden beim Entwurf und der Validierung eingebetteter<br />

Software.<br />

RWTH Aachen,<br />

Informatik 11, Ahornstr. 55, D-52074 Aachen,<br />

Tel. +49 (0) 241 802 11 50, E-Mail: kowalewski@embedded.rwth-aachen.de<br />

Univ.-Prof. Dr.-Ing. habil. MARTIN WOLLSCHLAEGER<br />

(geb. 1964) ist seit 2003 Inhaber der Professur<br />

Prozesskommunikation an der TU Dresden. Arbeitsgebiete<br />

sind industrielle Automatisierungsnetze,<br />

Management von heterogenen industriellen Netzen,<br />

Informationsmodelle und Beschreibungssprachen<br />

sowie Integrationsprozesse in der Automation.<br />

Technische Universität Dresden,<br />

Institut für Angewandte Informatik,<br />

D-01062 Dresden, Tel. +49 (0) 351 46 33 96 70,<br />

E-Mail: martin.wollschlaeger@tu-dresden.de<br />

Prof. Dr.-Ing. Dr. h. c. PETER GÖHNER (geb. 1950)<br />

ist Leiter des Instituts für Automatisierungs- und<br />

Softwaretechnik (IAS) an der Universität Stuttgart.<br />

Seine Hauptarbeitsgebiete sind agentenorientierte<br />

Konzepte in der Automatisierungstechnik, benutzerorientierte<br />

Automatisierung, Energieoptimierung<br />

in technischen Systemen, Lernfähigkeit von<br />

automatisierten Systemen, Verlässlichkeit von<br />

automatisierten Systemen und Wiederverwendungskonzepte<br />

in der Automatisierungstechnik.<br />

Institut für Automatisierungs- und Softwaretechnik,<br />

Universität Stuttgart,<br />

Pfaffenwaldring 47, D-70550 Stuttgart,<br />

Tel. +49 (0) 711 68 56 73 01,<br />

E-Mail: peter.goehner@ias.uni-stuttgart.de<br />

Prof. Dr.-Ing. BIRGIT VOGEL-HEUSER (geb. 1961)<br />

promovierte nach dem Studium der Elektrotechnik<br />

an der RWTH (1991). Sie sammelte zehn Jahre<br />

Industrieerfahrung, unter anderem als technische<br />

Geschäftsführerin in der Siempelkamp Gruppe<br />

(Anlagenbau). Nach Lehrstuhlberufungen (Hagen<br />

1996; Wuppertal 2000; Kassel 2006) übernahm sie<br />

den Lehrstuhl für Automatisierung und Informationssysteme<br />

(ehemals: Lehrstuhl für Informationstechnik)<br />

an der TUM (2009). Sie forscht an der<br />

Entwicklung und System evolution verteilter<br />

intelligenter Eingebetteter Systeme in mechatronischen<br />

Produkten und Produktionsanlagen.<br />

Lehrstuhl für Automatisierung und Informationssysteme,<br />

Boltzmannstraße 15, 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 />

60<br />

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

7-8 / 2014


WBEM ist kein monolithischer Standard, sondern<br />

bezeichnet eine Gruppe von Technologien zum Systemmanagement.<br />

Auf Basis dieses objektorientierten Ansatzes werden die<br />

für das Management relevanten Eigenschaften der einzelnen<br />

Anlagenkomponenten, wie Verfügbarkeit, Auslastung,<br />

nutzbare Dienste, Diagnoseinformation und so weiter modelliert.<br />

Die funktionale Verknüpfung der so entstandenen<br />

Objekte bildet die Basis für ein Funktionsmodell, das die<br />

eigentlichen Managementaktivitäten umsetzt.<br />

ZUSAMMENFASSUNG UND AUSBLICK<br />

Im Beitrag wurde mit Hilfe von Agententechnologie eine<br />

dezentrale Industrie-4.0-Verbundanlage exemplarisch<br />

realisiert. Der Ansatz, ein Agentensystem zu benutzen,<br />

hat sich in der praktischen Umsetzung als zukunfts- und<br />

leistungsfähig erwiesen. Dabei wurden Eigenentwicklungen<br />

betrieben und die Agentenplattform Jade eingesetzt.<br />

Der <strong>Einsatz</strong> der existierenden Agentenplattform<br />

Jade benötigt viele Systemressourcen. Daher müssen zur<br />

Realisierung von Agenten auf SPS-Systemen eigene Entwicklungen<br />

durchgeführt werden.<br />

In Bezug auf die eingangs formulierten Anforderungen<br />

lassen sich folgende Realisierungen resümieren:<br />

Die Vergabe von Aufträgen (Anforderung A1) wird auf<br />

Basis eines Web-Interfaces für Smart Phones realisiert<br />

und ließ sich mit verfügbaren Techniken implementieren.<br />

Die automatische Auftragsplanung (Anforderung A2)<br />

erfolgt auf Basis eines einfachen Verfahrens zur Zuteilung<br />

von Angeboten. Dabei kommt ein Zuteilungsverfahren<br />

zum <strong>Einsatz</strong>, das zentral ausgeführt wird. Weiterführende<br />

Fragen der dezentralen Zuteilung (Scheduling)<br />

sind noch zu erforschen. Daher ist die Berücksichtigung<br />

von komplexen Kriterien bei der Produktionsplanung<br />

REFERENZEN<br />

(Anforderungen A4) ebenfalls Gegenstand zukünftiger<br />

Untersuchungen.<br />

Ein einfaches An- und Abmelden von Produktionsanlagen<br />

(Anforderung A3) ist auf Basis der Agentenarchitektur<br />

umgesetzt, da derzeit keine Veränderung an<br />

den Teilanlagen erfolgt und nur ein An- beziehungsweise<br />

Abmelden erforderlich ist. Weitergehende Untersuchungen<br />

mit Blick auf Re-Konfiguration im Sinne einer<br />

Anpassung der Anlagen an geänderte Marktanforderungen<br />

wären eine sinnvolle Weiterentwicklung [7].<br />

Ein autarkes Auftragsmanagement, das heißt, die<br />

Möglichkeit der Untervergabe von Aufgaben, die Teilanlagen<br />

bereits erhalten haben (Anforderung A5), erfolgt<br />

in der Verbundanlage durch die Jade-Agentenplattform.<br />

Diese Untervergabe ist jedoch noch weiter auszubauen,<br />

um beispielsweise auf Störungen schnell reagieren zu<br />

können. Somit steht heute eine verteilte Demonstrationsanlage<br />

zur Verfügung, mit der die Grundkonzepte<br />

von Industrie 4.0 dargestellt werden können.<br />

Die Anforderung nach einem sicheren Zustellen von Botschaften<br />

(Anforderung A6) ist derzeit noch nicht realisiert,<br />

da Web-Sockets zum <strong>Einsatz</strong> kommen. Die sichere Nachrichtenübermittlung<br />

im Sinne der garantierten Zustellung<br />

von Botschaften sowie einer effizienten Implementierung<br />

wird zukünftig noch eingehender betrachtet werden. Dabei<br />

kommt dem WBEM-Konzept besondere Aufmerksamkeit<br />

zu. Auch spielt die Verwendung von effizienten Kommunikationsprotokollen,<br />

wie zum Beispiel MQTT, eine Rolle.<br />

Es ist geplant, das Szenario in einem Folgeschritt als<br />

Referenz zur verteilten Anlagendiagnose einzusetzen.<br />

Bei Ausfall von ähnlichen Teilkomponenten könnte<br />

nachgefragt werden, wie dieser Ausfall gelöst wurde. Für<br />

dieses Szenario wird erwogen, OPC UA zu nutzen, um<br />

einen einheitlichen Datenaustausch im Anlagenverbund<br />

zu ermöglichen.<br />

MANUSKRIPTEINGANG<br />

19.06.2014<br />

Im Peer-Review-Verfahren begutachtet<br />

[1] Weyrich, M.: Intelligenz und Vernetzung in der<br />

Fertigung - Perspektiven aus der Forschung.<br />

Vortrag auf dem VDI Zukunftskongress „Industrie 4.0 -<br />

Chancen für den Produktionsstandort Deutschland“,<br />

Düsseldorf, 30. Januar 2013<br />

(http://www.ias.uni-stuttgart.de/service/<br />

vor traege/weyrich/2013-01-30_VDI-Zukunftskongress.pdf)<br />

[2] Diedrich, Ch., Fay, A., Grützner, J., Göhner, P., Vogel-<br />

Heuser, B., Weyrich, M., Wollschlaeger, M.: Automatisierungstechnischer<br />

Forschungsanlagenverbund für<br />

Industrie 4.0. Markt & Technik, Industrie 4.0 Summit<br />

2013, München, 16.-17. Oktober 2013.<br />

[3] Distributed Management Task Force: Web-Based<br />

Enterprise Management (WBEM) Initiative 2011.<br />

http://www.dmtf.org/standards/wbem/.<br />

[4] Lehmann, R., Frenzel, R., Wollschlaeger, M.:<br />

Integriertes System- und Dienste-Management.<br />

<strong>atp</strong> <strong>edition</strong> - Automatisierungstechnische Praxis 54(3),<br />

S. 50-56, 2012.<br />

[5] Bordasch, M., Göhner, P.: Fault prevention in industrial<br />

automation systems by means of a functional model and<br />

hybrid abnormity identification concept. In: IECON 2013<br />

– 39th Annual Conference of the IEEE Industrial Electronics<br />

Society, S. 2845-2850, 2013.<br />

[6] Pantförder, D., Mayer, F., Dietrich, Ch., Göhner, P.,<br />

Weyrich, M., Vogel-Heuser, B.: Agentenbasierte-dynamische<br />

Rekonfiguration von vernetzten, intelligenten<br />

Produktionsanlagen. In: Bauernhansl, T., ten Hompel,<br />

M.; Vogel-Heuser, B. (Hrsg.) Industrie 4.0 in der<br />

Produktion, Automatisierung und Logistik, S. 145 158.<br />

Berlin, Springer-Verlag 2014.<br />

[7] Weyrich, M., Wior, I., Bchennati, D., Fay, A.: Flexibilisierung<br />

von Automatisierungssystemen: Systematisierung<br />

der Flexibilitätsanforderungen von Industrie 4.0.<br />

Werkstatttechnik wt-online 104(3) S. 106 111, 2014.<br />

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

7-8 / 2014<br />

61


HAUPTBEITRAG | AUTOMATION 2014<br />

IT-Security-Konzepte<br />

für die Prozessindustrie<br />

Anforderungen im Kontext von Industrie 4.0<br />

Die Umsetzungsempfehlungen zu Industrie 4.0 sehen in der Beherrschung der IT-<br />

Sicherheit einen wesentlichen Erfolgsfaktor. Neue Sicherheitsarchitekturen werden<br />

als notwendig erachtet. Der Beitrag beschreibt die IT-Sicherheit im bisherigen Umfeld<br />

und erläutert dann die Bedingungen, die sich künftig im Kontext von Industrie 4.0<br />

ergeben werden. Am Beispiel des Wandels von Automatisierungssystemstrukturen<br />

in der Prozessindustrie werden Anforderungen an die IT-Sicherheit definiert und<br />

neue mögliche Lösungsansätze zu deren Realisierung aufgezeigt.<br />

SCHLAGWÖRTER IT-Sicherheit / Industrie 4.0 / Prozessindustrie / künftige Anforderungen<br />

IT Security Concepts for the Process Industry –<br />

Requirements in the Context of Industry 4.0<br />

The recommendations for implementing the Industry 4.0 strategic initiative identify<br />

IT security as a crucial factor for success. New, more extensive security architectures<br />

are necessary. An overview is given of current IT security measures and requirements<br />

are defined for IT security in the context of Industry 4.0. Taking process<br />

engineering as an example, future requirements for IT-security are determined and<br />

possible approaches are discussed.<br />

KEYWORDS IT-security / Industry 4.0 / process engineering / future requirements<br />

62<br />

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

7-8 / 2014


KARL-HEINZ NIEMANN, Hochschule Hannover<br />

Die Strukturen von Automatisierungssystemen<br />

in der Prozessindustrie erscheinen, im Vergleich<br />

zur Fertigungsindustrie, relativ konventionell.<br />

Bild 1 zeigt exemplarisch den<br />

Aufbau einer Automatisierungsanlage in der<br />

Prozessindustrie. Eine derartige Anlage in der Prozessindustrie<br />

ist geprägt durch folgende Sachverhalte:<br />

Die Kommunikation innerhalb des Automatisierungssystems<br />

erfolgt in verschiedenen Layern<br />

(Systembus , Feldbus , gegebenenfalls Sensor-/<br />

Aktor-Bus ). Bei komplexeren Systemen ist zwischen<br />

der Controller-Ebene und der Leitebene ggf.<br />

eine weitere Ebene mit Servern vorhanden.<br />

Die Anlage ist üblicherweise über eine Security-Appliance<br />

an das Unternehmensnetzwerk angebunden.<br />

Dabei ist es unerheblich, ob die Kopplung der<br />

Netzwerke über den dargestellten Server oder direkt<br />

zwischen den beiden Netzwerken erfolgt. Das Unternehmensnetzwerk<br />

ist in der Regel über eine weitere<br />

Security-Appliance mit dem Internet verbunden.<br />

Unternehmensnetzwerk und Systembus sind<br />

üblicherweise Ethernet-Netzwerke. Die verwendeten<br />

Switches sind im Bild nicht dargestellt.<br />

In vielen Fällen erfolgt die Kommunikation in der<br />

Feldebene durch klassische Feldbusse wie zum<br />

Beispiel Profibus und Profibus PA.<br />

Der Feldbus ist üblicherweise jeweils einem Controller<br />

zugeordnet. Pro Controller ist demzufolge<br />

ein separater Feldbus vorhanden.<br />

In Bezug auf die IT-Sicherheit einer so strukturierten<br />

Anlage lassen sich folgende Feststellungen treffen:<br />

Die Kommunikation innerhalb des gesamten Automatisierungssystems<br />

erfolgt, im Sinne der IT-<br />

Sicherheit, ungesichert und unverschlüsselt.<br />

Eine Authentifizierung der Netzwerkteilnehmer im<br />

Automatisierungsnetzwerk findet nicht statt.<br />

Eine Authentifizierung der Nutzer (Anlagenbediener)<br />

erfolgt häufig auf der Ebene von Schichtzugängen. Da<br />

individuelle Zugänge für eine Leistungs- und Verhaltenskontrolle<br />

herangezogen werden könnten, kommen<br />

diese selten zum <strong>Einsatz</strong>. Die Einführung von<br />

Systemen zur Leistungs- und Verhaltenskontrolle ist<br />

gemäß §87(1).6 BetrVG mitbestimmungspflichtig.<br />

Die Kommunikationsebene unterhalb der Controller<br />

ist im Sinne der IT-Sicherheit prinzipiell Bedrohungen<br />

ausgesetzt, deren Eintrittswahrscheinlichkeit<br />

bisher jedoch als gering angesehen wird. Es<br />

kommen Feldbusprotokolle zum <strong>Einsatz</strong>, die<br />

eine SPS mit den zugeordneten I/Os verbinden.<br />

Die klassischen Bedrohungen der Unternehmens-IT<br />

treffen insbesondere auf die Komponenten zu, die<br />

mit dem Systembus und dem Unternehmensnetzwerk<br />

verbunden sind, also Controller, Server und<br />

Operator-Konsolen, bedingt durch die Anbindung<br />

an den Systembus mit Standard-Ethernet-Protokoll.<br />

Ergänzt werden die beschriebenen Security-Appliances<br />

gegebenenfalls durch weitere Schutzmaßnahmen, wie<br />

zum Beispiel demilitarisierte Zonen.<br />

1. ÄNDERUNG VON SYSTEMSTRUKTUREN IN DER<br />

PROZESSINDUSTRIE<br />

Unabhängig vom Einfluss durch Industrie 4.0 sind momentan<br />

Änderungen in den Systemstrukturen in der<br />

Prozessindustrie festzustellen.<br />

Bild 2 zeigt die zurzeit stattfindende Änderung in der<br />

Topologie von Automatisierungsanlagen, die noch nicht<br />

auf die Konzepte von Industrie 4.0 zurückzuführen ist.<br />

Die in Bild 1 dargestellte Hierarchie der Bussysteme löst<br />

sich auf. Eine dedizierte Zuordnung von I/O-Systemen<br />

zu Controllern ist nicht mehr gegeben. Jeder Controller<br />

liest die benötigten Daten aus den entsprechenden I/O-<br />

Systemen aus. Damit entfällt die Notwendigkeit einer<br />

Controller-zu-Controller-Kommunikation zum Austausch<br />

von I/O-Daten. Derartige Strukturen wurden<br />

zum Patent angemeldet [2] und sind als Produkte am<br />

Markt erhältlich [3]. Hierbei spielt es keine Rolle, ob das<br />

Netzwerk, wie in Bild 2 dargestellt, als Ring oder als<br />

redundante Stern- oder Baumstruktur ausgeführt ist.<br />

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

7-8 / 2014<br />

63


HAUPTBEITRAG | AUTOMATION 2014<br />

Das in Bild 2 beschriebene System weist die folgenden<br />

Eigenschaften auf:<br />

Die Trennung von Systembus und Feldbus entfällt<br />

zugunsten einer einheitlichen Kommunikationsarchitektur.<br />

Die feste Zuordnung von I/O-Geräten (Remote-I/Os<br />

und Gateways zu den Sensor-Aktor-Bussen) zu den<br />

Controllern entfällt ebenfalls.<br />

An das einheitliche Kommunikationssystem sind<br />

Server, Operator-Konsolen, Controller und die I/O-<br />

Systeme angeschlossen.<br />

In Bezug auf die IT Sicherheit ist festzuhalten:<br />

Die zuvor gemachten Aussagen in Bezug auf die<br />

ungesicherte Kommunikation, die fehlende Authentifizierung<br />

der Netzwerkteilnehmer und Anlagenbediener<br />

gelten weiterhin.<br />

Aufgrund des durchgängigen Kommunikationsmediums<br />

sind alle Komponenten (mit Ausnahme der<br />

Sensoren und Aktoren) über die Industrial-Ethernet-Kommunikation<br />

erreichbar.<br />

In einem folgenden Schritt ist zu erwarten, dass sich<br />

Strukturen mit einer Durchgängigkeit des Industrial<br />

Ethernet von der Leitebene bis zum Sensor und Aktor,<br />

wie in Bild 3 dargestellt, etablieren werden.<br />

Obwohl derzeit bereits spezielle Komponenten und<br />

Steckverbinder in explosionsgefährdeten Bereichen<br />

zum <strong>Einsatz</strong> kommen [4], besteht die Herausforderung<br />

in der gleichzeitigen Energieversorgung der Komponenten<br />

über eine Zweidrahtleitung mit Leitungslängen von<br />

mehr als 100 m. In [5] wurde die Eignung von Industrial<br />

Ethernet für die Sensor-/Aktor-Vernetzung untersucht.<br />

Auf der Namur-Hauptsitzung 2013 wurde ein<br />

erstes Konzept für eine Ethernet-Zweidrahtlösung zur<br />

direkten Anbindung von Sensoren und Aktoren vorgestellt<br />

[6], das die oben genannten Anforderungen erfüllen<br />

soll. In Bezug auf die IT-Sicherheit lässt sich festhalten,<br />

dass dadurch die Sensoren und Aktoren direkt<br />

an das Industrial Ethernet angebunden und damit entsprechenden<br />

Gefährdungen ausgesetzt sind.<br />

2. ÄNDERUNG DER SYSTEMSTRUKTUREN<br />

IM KONTEXT VON INDUSTRIE 4.0<br />

Die erwähnten Änderungen in den Systemstrukturen<br />

lassen erkennen, dass die im Kontext von Industrie<br />

4.0 beschriebenen Änderungen [1] (zum Beispiel zunehmende<br />

horizontale und vertikale Integration) sich<br />

bereits heute in den behandelten Systemstrukturen<br />

widerspiegeln. In [7] wird abgeleitet, dass sich einige<br />

Konzepte von Industrie 4.0 (wie Losgröße eins, Produkt<br />

steuert den Produktionsprozess) nicht direkt auf<br />

die Prozessindustrie anwenden lassen. In [8] beschreibt<br />

der Autor die weitgehende Modularisierung<br />

von Anlagen als einen wesentlichen Aspekt für Industrie<br />

4.0 in der Prozessindustrie. In [9] wird von<br />

einem verstärkten <strong>Einsatz</strong> von Ad-hoc-Kommunikation<br />

ausgegangen.<br />

Als Arbeitshypothese für die weitere Diskussion werden<br />

die folgenden Strukturänderungen für die Prozessindustrie<br />

im Kontext von Industrie 4.0 angenommen:<br />

Zunehmende horizontale und vertikale Integration<br />

Einheitliches Kommunikationsmedium von der<br />

Leitebene bis zum Sensor/Aktor<br />

Modularisierung<br />

<strong>Einsatz</strong> von intelligenten, gegebenenfalls autonom<br />

agierenden Teilsystemen<br />

Ad-hoc-Kommunikation, selbstorganisierende Vernetzung<br />

Andere Aspekte wie Cloud Dienste, BYOD (bring your<br />

own device) werden nicht weiter betrachtet.<br />

3. BEWERTUNG DER BISHERIGEN<br />

IT-SICHERHEITSMASSNAHMEN<br />

Bild 4 zeigt die durchgängige Erreichbarkeit der Komponenten<br />

eines Automatisierungssystems über ein einheitliches<br />

Kommunikationsmedium in Abhängigkeit<br />

von der Systemstruktur.<br />

Es ist zu erkennen, dass aufgrund der dargestellten<br />

Evolution die durchgängige Erreichbarkeit der Komponenten<br />

immer weiter zunimmt. In der traditionellen<br />

Struktur sind lediglich Server, Konsolen und Engineering-Werkzeuge<br />

sowie die Controller an das Unternehmensnetzwerk<br />

angebunden und durchgängig erreichbar.<br />

Auf der Zeitschiene später liegende Strukturen erlauben<br />

hingegen einen standardisierten Zugriff auf alle Komponenten<br />

des Systems, einschließlich der Kommunikation<br />

über verteilte Standorte.<br />

Die momentan eingesetzten IT-Sicherheitskonzepte<br />

tragen dieser Entwicklung bisher nur eingeschränkt<br />

Rechnung. Es wird eine Abschottung der Anlage vom<br />

Unternehmensnetzwerk empfohlen [9,10] und gegebenenfalls<br />

eine weitere Untergliederung in Teilanlagen<br />

[11]. Diese Vorgehensweise unterstellt Bedrohungen von<br />

außen, die durch Security Appliances (zum Beispiel<br />

Firewall, auch in Verbindung mit demilitarisierten Zonen<br />

und weiteren Defense-in-depth-Maßnahmen) abzuwehren<br />

sind. Diese Sichtweise weist nach Auffassung<br />

des Autors die folgenden Defizite auf:<br />

1 | Das Risiko von Innentätern ist nicht hinreichend<br />

berücksichtigt<br />

2 | Die Abschottung ist durchdringbar<br />

3 | Dem beschriebenen Strukturwandel wird nicht<br />

Rechnung getragen.<br />

In einer Studie mit 9 600 befragten Personen aus 115<br />

Ländern [13] ergab sich für den Bereich Öl und Gas das<br />

in Bild 5 dargestellte Täterprofil (estimated likely source<br />

of incidents).<br />

Obwohl die Studie nur allgemeine IT-Sicherheitsvorfälle,<br />

ohne konkreten Bezug zu den Automatisierungssystemen,<br />

dokumentiert, so ist doch abzulesen, dass Angestellte und<br />

Dienstleister eine nennenswerte Quelle möglicher Angriffe<br />

darstellen. Für den Bereich Power and Utilities nennt die<br />

gleiche Studie für die Kategorie Current Employees einen<br />

64<br />

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

7-8 / 2014


Unternehmensnetzwerk<br />

Security Appliance<br />

Engineering<br />

Operator<br />

Konsole<br />

...<br />

Operator<br />

Konsole<br />

Operator<br />

Konsole<br />

Server<br />

Warte<br />

Operator<br />

Konsole<br />

...<br />

Operator<br />

Konsole<br />

Server<br />

Leitebene<br />

Systembus<br />

Controller<br />

Industrial Ethernet<br />

Controller<br />

Controller<br />

Controller<br />

Remote-<br />

I/O<br />

Technischer Prozess<br />

Feldbus<br />

Sensor-/Aktor-Bus<br />

Sensoren /Aktoren<br />

Prozess<br />

Remote-<br />

I/O<br />

Remote-<br />

I/O<br />

......<br />

Technischer Prozess<br />

Gateway zum<br />

Sensor-Aktor-Bus<br />

BILD 1: Bisherige Struktur einer Automatisierungsanlage<br />

in der Prozessindustrie<br />

BILD 2: Änderung der Struktur von Automatisierungsanlagen<br />

in der Prozessindustrie<br />

Engineering<br />

Operator<br />

Konsole<br />

...<br />

Operator<br />

Konsole<br />

Operator<br />

Konsole<br />

Server<br />

Warte<br />

Erreichbarkeit der Komponenten über<br />

einheitliches Kommunikationsmedium<br />

verteilte<br />

Standorte<br />

Sensoren /<br />

Aktoren<br />

CPS<br />

Controller<br />

Industrial Ethernet<br />

Controller<br />

Remote I/O, Antriebe<br />

CPS<br />

Controller<br />

CPS<br />

......<br />

Technischer Prozess<br />

BILD 3: Durchgängigkeit Industrial Ethernet<br />

bis zum Sensor/Aktor<br />

Server, Operator Konsolen, Engineering-Werkzeug,<br />

Unternehmensnetzwerk<br />

Aktuelle<br />

Struktur<br />

Struktur<br />

mit Industr.<br />

Ethernet<br />

Struktur<br />

mit Industr.<br />

Ethernet bis<br />

Sensor<br />

Industrie<br />

4.0<br />

BILD 4: Erreichbarkeit von Automatisierungskomponenten<br />

abhängig von Systemstruktur<br />

Zeitliche<br />

Entwicklung<br />

Estimated likely source of incidents<br />

Employees<br />

Former employees<br />

Current employees<br />

27%<br />

26%<br />

Trusted advisors<br />

Current service providers/consultants/contractors<br />

Former service providers/consultants/contractors<br />

Information brokers<br />

Suppliers/business partners<br />

16%<br />

16%<br />

15%<br />

14%<br />

BILD 5: Vermutete Quelle für<br />

IT-Sicherheitsvorfälle in der<br />

Öl- und Gasindustrie, siehe [13]<br />

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

7-8 / 2014<br />

65


HAUPTBEITRAG | AUTOMATION 2014<br />

Anteil von 37 %. Eine andere Studie zur Auswertung von<br />

IT-Sicherheitsvorfällen [14] ermittelte bei 63 437 erfassten<br />

Vorfällen im Jahr 2013 einen Innentäteranteil von 18 %.<br />

Neben der Problematik der Innentäter stellt sich weiterhin<br />

das Problem, dass die Abschottung von Systemen gegenüber<br />

dem Unternehmensnetzwerk und damit gegenüber dem<br />

Internet kompromittierbar ist. Bei einem simulierten Cyber-<br />

Angriff auf die Stadtwerke Ettlingen [15] gelang es der mit<br />

dem Angriff beauftragten Firma in das Unternehmensnetzwerk<br />

einzudringen und von dort in das Automatisierungsnetzwerk<br />

für die Energieverteilung vorzustoßen. In dem<br />

Moment, in dem Zugang zum Automatisierungsnetzwerk<br />

besteht, können die daran angeschlossenen Komponenten<br />

kompromittiert werden. In [16] wird zum Beispiel nachgewiesen,<br />

dass Komponenten in elektrischen Schaltanlagen<br />

Schwachstellen aufweisen, die sich zum Auslösen von<br />

Schaltvorgängen nutzen lassen. [17] zeigt, dass sich speicherprogrammierbare<br />

Steuerungen durch Einspielen eines<br />

Software-Updates kompromittieren lassen, ohne dass dafür<br />

ein Zugriff auf das Engineering-Werkzeug erforderlich ist.<br />

Mit dem Übergang zu von Industrie 4.0 beeinflussten<br />

Systemstrukturen wird es in der Prozessindustrie zu<br />

einer weiteren Auflösung bekannter Strukturen kommen.<br />

Die in Bild 4 dargestellte Entwicklung wird sich<br />

verstetigen. Hieraus ergeben sich weiterreichende Anforderungen<br />

in Bezug auf die IT-Sicherheitseigenschaften<br />

von Automatisierungssystemen.<br />

NR.<br />

A1<br />

A2<br />

A3<br />

A4<br />

A5<br />

A6<br />

ANFORDERUNG /PROBLEMSTELLUNG<br />

Sichere Kommunikation der Anlagenkomponenten<br />

muss auch bei geänderter<br />

Bedrohungslage gewährleistet sein.<br />

Konzept muss der Einführung von<br />

CPS Rechnung tragen. Der <strong>Einsatz</strong> von<br />

vielen Geräten mit geringer Rechenleistung<br />

ist zu berücksichtigen.<br />

Berücksichtigung von Ad-hoc-Netzwerken,<br />

selbstkonfigurierenden Netzwerken und<br />

Integrationstopologien<br />

Sichere Einbindung der Komponenten<br />

in das System<br />

Einbindung des Menschen in<br />

das Sicherheitskonzept<br />

Messbarkeit und Darstellung des<br />

Sicherheitsstatus des Systems<br />

4. ANFORDERUNGEN AN KÜNFTIGE<br />

SICHERHEITSARCHITEKTUREN<br />

Die Erfordernis einer verbesserten IT-Sicherheit im<br />

Kontext von Industrie 4.0 wurde erkannt und ist bereits<br />

an zahlreichen Stellen dokumentiert.<br />

Der ZVEI [18] fordert zum Beispiel: „Ein umfassendes<br />

Sicherheitskonzept für die gesamte Industrie muss<br />

entwickelt werden. Ganzheitliche Ansätze müssen von<br />

Beginn im täglichen Unternehmensbetrieb einbezogen<br />

werden.“ Diese Forderung des ZVEI bezieht sich insbesondere<br />

auf den Schutz von Firmengeheimnissen.<br />

Die Normungs-Roadmap Industrie 4.0 der DKE [39]<br />

gibt an: „Mit der intensiven Nutzung des Internets<br />

auch für automatisierungstechnische Steuerungsfunktionen,<br />

der Virtualisierung und des Cloud-Computing,<br />

jedoch auch durch die SelfX-Technologien<br />

(Selbstkonfiguration, Selbstheilung, Selbstoptimierung)<br />

und die agentenmäßige Vernetzung intelligenter<br />

Funktionen untereinander, erhält die IT-Security in<br />

Industrie 4.0 eine besondere Bedeutung. IT-Security<br />

ist eine wesentliche Voraussetzung für die Informationssicherheit<br />

und eng mit dieser verbunden.“<br />

Die Handlungsempfehlungen zu Industrie 4.0 [1]<br />

sehen zum Thema IT-Security die folgenden<br />

Aufgabenstellungen:<br />

Etablierung von Security by Design als<br />

Entwurfsprinzip<br />

Entwicklung und Etablierung von IT-Sicherheitskonzepten,<br />

-Architekturen und -Standards<br />

Eindeutige und sichere Identitätsnachweise<br />

für Produkte, Prozesse und Maschinen<br />

A7<br />

A8<br />

A9<br />

A10<br />

A11<br />

A12<br />

A13<br />

A14<br />

A15<br />

A16<br />

A17<br />

A18<br />

Schutz von geistigem Eigentum,<br />

Schutz gegen unautorisierten Nachbau<br />

Anpassbarkeit an künftige Vorgaben<br />

von Gesetzgebern und Behörden sowie<br />

an eine geänderte Bedrohungslage.<br />

Handhabbarkeit der Sicherheitslösung<br />

mit angemessenem Aufwand<br />

(Zeit, Material, Personal)<br />

Wirksamkeit des Konzeptes bei Kommunikation<br />

über Unternehmensgrenzen hinaus muss<br />

gegeben sein (Kunden, Lieferanten aber auch<br />

Ver- und Entsorger).<br />

Berücksichtigung mobiler Geräte und gegebenenfalls<br />

unternehmensfremder Geräte.<br />

Berücksichtigung von Cloud-Diensten<br />

(Unternehmens-Cloud, externe Cloud)<br />

Berücksichtigung intelligenter<br />

Sensorik /Aktorik<br />

Berücksichtigung hochverfügbarer<br />

Systemstrukturen<br />

Produktverfolgbarkeit, Produktdokumentation,<br />

insbesondere für Pharma-Anlagen<br />

Berücksichtigung von funktionaler Sicherheit<br />

Disaster Recovery<br />

Lange Lebensdauer/Betriebsdauer<br />

der Produktionsanlage<br />

66<br />

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

7-8 / 2014


TABELLE 1: Anforderungen und mögliche Lösungsansätze in Bezug auf<br />

IT-Security-Maßnahmen in der Prozessindustrie im Kontext von Industrie 4.0<br />

ERLÄUTERUNG UND MÖGLICHER LÖSUNGSANSATZ<br />

In [21] werden die zehn wichtigsten Schwachstellen von Automatisierungssystemen beschrieben. Eine weitere Beschreibung möglicher Angriffsszenarien<br />

auf Automatisierungssysteme findet sich in [22]. Es ist abzuleiten, dass die bisher praktizierte Abschottung von Automatisierungssystemen<br />

unzureichend ist. Erforderlich ist eine mit kryptografischen Mitteln gesicherte Kommunikation, wie sie zum Beispiel in [23] beschrieben ist.<br />

Auch wenn die Einführung von cyber-physischen Systemen (CPS) in Anlagen der Prozessindustrie später als in der Fertigungsindustrie<br />

stattfinden wird, müssen die Sicherheitskonzepte den Performance-Limitierungen von CPS Rechnung tragen. Eine Berücksichtigung von<br />

Rechnerplattformen mit begrenzten Ressourcen ist erforderlich. In [24] wird dargestellt, dass auch ressourcenbeschränkte Plattformen<br />

mit integrierten Sicherheitsfunktionen ausgestattet werden können.<br />

In [9] werden die Anforderungen, welche bei der Nutzung von Ad-hoc und selbstkonfigurierenden Netzwerken entstehen, beschrieben.<br />

Insbesondere eine sichere Bindung der digitalen Identität an die physikalische Identität wird hervorgehoben. In [25] wird ein zweistufiger<br />

Ansatz für die Industrie-4.0-Netzwerke vorgeschlagen. Der Beitrag geht davon aus, dass neben dem traditionellen Produktionsnetz ein<br />

Industrie-4.0-Integrationsnetzwerk vorhanden ist. Ein IT-Security-Ansatz muss beide Netzwerkformen unterstützen und insbesondere eine<br />

einfache Integration von modularisierten Anlagenkomponenten gestatten.<br />

Um eine sichere Kommunikation gemäß Anforderung A1 zu gewährleisten, ist eine sichere Authentifizierung der Komponenten im Netzwerk<br />

erforderlich. In [26] wird eine sichere Einbindung durch eine Public-Key-Infrastruktur beschrieben. Wichtig ist hierbei eine zuverlässige Bindung der<br />

digitalen an die physikalische Identität. Lösungsansätze bestehen hier über Security-Token-Technologien wie sie in [9] und [27] beschrieben werden.<br />

In [28] wird ein Abriss auf die Produktionsarbeit der Zukunft gegeben. Mitarbeiterinnen und Mitarbeiter sind Bestandteil von Industrie 4.0<br />

und aus diesem Grund in bestehende IT-Security-Konzepte einzubeziehen, wobei die Authentifizierung von Mitarbeitern einen wesentlichen<br />

Aspekt darstellt. Darüber hinaus sollten die Konzepte so gestaltet sein, dass sie für Mitarbeiterinnen und Mitarbeiter einfach nutzbar aber<br />

auch in Bezug auf die Verhaltensüberwachung akzeptabel sind. Ein möglicher Ansatz für die Authentifizierung sind zum Beispiel Security-<br />

Token-Technologien. Das Problem der Verhaltensüberwachung von Mitarbeitern wurde bereits erwähnt.<br />

Die unter den Anforderungen A1 und A4 beschriebene sichere Kommunikation erlaubt das Erkennen von Datenpaketen, die in Bezug auf die<br />

IT-Sicherheit kompromittiert sind. Die Ableitung von Alarmen sollte möglich sein. Darüber hinaus können die Komponenten eines Automatisierungssystems<br />

eine kontinuierliche Integritätsprüfung vornehmen, wie sie in [29] beschrieben wird. Netzwerk- und Infrastrukturkomponenten<br />

sollten in diese Überwachung einbezogen werden [20].<br />

Eine sichere Kommunikation gemäß Anforderung A1 muss nicht zwangsläufig vertraulich sein. Für die Anwendungen, die den Schutz<br />

geistigen Eigentums erfordern, müssen neben kryptografischen Prüfsummen gegebenenfalls Verschlüsselungsmechanismen eingesetzt<br />

werden. Darüber hinaus ist der Aspekt der Produktpiraterie zu beachten. In [9] und [30] wird der <strong>Einsatz</strong> von Security-Token-Technologien<br />

zum Schutz gegen unautorisierten Nachbau beschrieben.<br />

Neben Normen und Standards zur IT-Sicherheit von Produktionsanlagen [10,11,12] sind zunehmend Vorgaben durch den Gesetzgeber [31]<br />

oder durch Behörden [32] zu erwarten. Die IT-Sicherheitskonzepte müssen so flexibel sein, dass sie sich an eine sich ändernde Gesetzesund<br />

Vorschriftenlage sowie an geänderte Bedrohungslagen anpassen lassen.<br />

Die Kosten für IT-Sicherheitsvorfälle sind signifikant. Für das Jahr 2012 in Deutschland 4,8 Mio US-Dollar jährliche Kosten für IT-Sicherheitsvorfälle<br />

im Office-Bereich nachgewiesen [33]. Der Aufwand für IT-Sicherheitsmaßnahmen, insbesondere für die Integration des IT-Sicherheitsengineerings<br />

in das Engineering des Automatisierungssystems, sollte kostengünstiger sein. Zudem sind einfach zu handhabende Konzepte<br />

erforderlich.<br />

Die Verbindung von Wertschöpfungsketten im Kontext von Industrie 4.0 wird die Kommunikation von Produktionsdaten über Unternehmensgrenzen<br />

hinaus verstärken. IT-Sicherheitskonzepte müssen diesem Umstand Rechnung tragen. Darüber hinaus ist bei Maßnahmen zur<br />

Erhöhung der Energieeffizienz mit einer engeren Vernetzung der Produktionssysteme mit den Versorgungsnetzen zu rechnen. Auch Smart<br />

Grids sind von Cyber-Sicherheitsaspekten betroffen [34].<br />

Wird in diesem Beitrag nicht näher betrachtet.<br />

Wird in diesem Beitrag nicht näher betrachtet.<br />

Wie in Bild 3 dargestellt werden die Sensor- und Aktor-Komponenten künftig mit Industrial Ethernet Interfaces versehen werden. Die Bedrohungen,<br />

die bisher für Steuerungen und Remote I/Os gelten, wirken nun auch auf die Sensoren und Aktoren direkt. Siehe Anforderung A2.<br />

Automatisierungssysteme der Prozessautomatisierung sind häufig als hochverfügbare Systeme ausgelegt. In [35] werden als wesentliche<br />

Prinzipien der Hochverfügbarkeit unter anderem Redundanz, Transparenz, Autonomie, Fehlertoleranz, Skalierbarkeit und Separation<br />

genannt. Diese grundlegenden Prinzipien sind auf entsprechende IT-Sicherheitskonzepte anzuwenden.<br />

Die besonderen Erfordernisse der Dokumentation von Produktionsdaten, zum Beispiel gemäß FDA CFR21 Part 11, können durch ein<br />

entsprechendes IT-Sicherheitskonzept unterstützt werden [36].<br />

Die Erfordernisse sicherheitsgerichteter Systeme [37] sind im IT-Security-Konzept zur berücksichtigen.<br />

Die Fähigkeit, nach einer gravierenden Störung den Betrieb innerhalb kurzer Zeit wieder aufzunehmen, muss für das IT-Sicherheitskonzept<br />

gelten. In [38] werden Überlegungen zur Disaster-Recovery nach einem IT-Sicherheitsvorfall angestellt. Ein Start des Automatisierungssystems<br />

(zum Beispiel in einem Kraftwerk) muss ohne Zugriff auf das Internet möglich sein. IT-Sicherheitskonzepte müssen in diesem Fall<br />

autark und ohne Anbindung an entfernte Server operabel sein.<br />

Die typischen Laufzeiten von Anlagen in der Prozessindustrie sind zu beachten.<br />

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

7-8 / 2014<br />

67


HAUPTBEITRAG | AUTOMATION 2014<br />

Migrationsstrategie von Industrie 3.0 zu<br />

Industrie 4.0<br />

Der VDE-Trendreport [19] nennt Fragen der IT-Sicherheit<br />

als die größte Barriere im Hinblick auf die<br />

Etablierung von Industrie 4.0 in Deutschland.<br />

Die Fraunhofer-Verbünde definieren in ihrem Strategie-<br />

und Positionspapier Cyber-Sicherheit 2020 [20]<br />

eine Vielzahl von Anforderungen fokussiert auf verschiedene<br />

Industrien, zum Beispiel Energieerzeugung<br />

und Energieversorgung, industrielle Produktion<br />

und Automatisierung insbesondere in Bezug auf<br />

cyber-physische Systeme, wie sie im Kontext von<br />

Industrie 4.0 eingesetzt werden sollen.<br />

Tabelle 1 stellt die künftigen Anforderungen an die<br />

IT-Sicherheit in der Prozessindustrie dar. Wie schon<br />

ausgeführt, sind eine Reihe von Anforderungen nicht<br />

originär auf den durch Industrie 4.0 zu erwartenden<br />

Technologiewandel zurückzuführen, sondern auf den<br />

bereits beschriebenen stattfindenden Wandel in Struktur<br />

und im Aufbau von Automatisierungssystemen in<br />

der Prozessindustrie.<br />

Die hier definierten Anforderungen geben nur einen<br />

ersten Ausblick auf künftige IT-Sicherheitsanforderungen<br />

und die zugehörigen Lösungsansätze und erheben keinen<br />

Anspruch auf Vollständigkeit. Durch die Fokussierung<br />

auf die Prozessindustrie sind viele Anforderungen stark<br />

an bisherigen Vorgehensweisen und Strukturen orientiert.<br />

Dies trägt dem Aspekt Rechnung, dass eine Migration<br />

in Richtung Industrie 4.0 in der Prozessindustrie<br />

nach Auffassung des Autors langsamer erfolgen wird, als<br />

in der Fertigungsindustrie.<br />

ZUSAMMENFASSUNG<br />

Die Anlagen der Prozessindustrie befinden sich in<br />

einem technologischen Wandel, der bereits vor Indus-<br />

REFERENZEN<br />

[1] Kagermann, Henning et. al.: Umsetzungsempfehlungen für das Zukunftsprojekt<br />

Industrie 4.0. Abschlussbericht des Arbeitskreises Industrie 4.0.<br />

http://www.plattform-i40.de/sites/default/files/Abschlussbericht_Industrie4%200_barrierefrei.pdf,<br />

11.08.2013.<br />

[2] Jundt, Larry Oscar; et. al.: Methods and Apparatus to configure<br />

Process Control System Inputs and Outputs. 07.08.2008. Patent. Nummer:<br />

US 2008/0189441 A1.<br />

[3] Erni, Klaus: S-Series Electronic Marshalling. Hg. Emerson Process<br />

Management. 2012. http://www2.emersonprocess.com/siteadmincenter/<br />

PM%20DeltaV%20Documents/Product-DataSheets/DS_S-series-<br />

Electronic-Marshalling.pdf<br />

[4] Fritsch, A.: Industrial Ethernet Goes Process Automation…And What<br />

About Explosion Protection? In 4th European Conference on Electrical<br />

and Instrumentation Applications in the Petroleum & Chemical Industry,<br />

2007; S. 1–7<br />

[5] Jasperneite, J.; Schumacher, Markus: Echtzeit-Ethernet für die Sensor/<br />

Aktorvernetzung. Schlussbericht für das Forschungsprojekt ESANA.<br />

http://www.hs-owl.de/init/uploads/tx_initdb/esana_f.pdf<br />

[6] Scheuermann, A.: Nächster Feldbus, diesmal ohne Krieg. In IEE Elektrische<br />

Automatisierung + Antriebstechnik, Heft 1-2014, 2014; S. 12–13.<br />

[7] Ziesemer, M.: Industrie 4.0:Auswirkungen auf die Prozessautomation.<br />

Automatisierungskolloquium des Fachverbandes Automation des ZVEI<br />

in Heidelberg am 26.09.2013.<br />

http://www.zvei.org/Downloads/Automation/Industrie-40-Auswirkungenauf-die-Prozessindustrie.pdf<br />

[8] Schmitz, S.: Modularisierung verfahrenstechnischer Anlagen im Kontext der<br />

Industrie 4.0. Automatisierungskolloquium des Fachverbandes Automation<br />

des ZVEI in Heidelberg 26.09.2013. http://www.zvei.org/Downloads/<br />

Automation/Modularisierung-verfahrenstechni¬scher-Anlagen-im-<br />

Kontext-der-Industrie-40.pdf<br />

[9] Speth, W.: Nur Befehle befolgt. CPS erfordern sichere Identitäten.<br />

In <strong>atp</strong>-<strong>edition</strong>, 12/2013; S. 46–52.<br />

[10] PROFIBUS Nutzerorganisation e. V.: PROFINET Security Richtlinie. Richtlinie<br />

für PROFINET. Dokument Nr. 7.001, 2013. http://www.profibus.com/nc/<br />

download/specifications-standards/downloads/profinet-security-guideline/<br />

display/<br />

[11] ODVA Inc.: Securing EtherNet/IP Networks.<br />

http://www.odva.org/Portals/0/Library/Publications_Numbered/PUB00269R0_ODVA_Securing_EtherNetIP_Networks.pdf<br />

[12] Informationen des UK 931.1 zur Normenreihe IEC 62443. http://<br />

www.vde.com/de/technik/fs/seiten/informationenzu62443.aspx<br />

[13] PWC- PricewaterhouseCoopers LLP: The Global State of<br />

Information Security ® Survey 2014. http://www.pwc.com/gx/en/<br />

consulting-services/information-security-survey/download.jhtml<br />

[14] Verizon Enterprise: 2014 Data Breach Investigation Report.<br />

http://www.verizonenterprise.com/DBIR/2014/reports/rp_Verizon-DBIR-2014_en_xg.pdf<br />

[15] Lindner, F.: Licht aus! Sicherheit kritischer Infrastrukturen im<br />

Test. In c‘t Magazin für Computertechnik, Heft 9/2014; S. 150–155.<br />

[16] Coppolino, L. et al.: Exposing vulnerabilities in electric power<br />

grids: An experimental approach. In International Journal of<br />

Critical Infrastructure Protection, 7/2014; S. 51–60.<br />

[17] Schuett, C. et al.: An evaluation of modification attacks on<br />

programmable logic controllers. In International Journal of<br />

Critical Infrastructure Protection, 7/2014; S. 61–68.<br />

[18] ZVEI - Zentralverband Elektrotechnik und Elektronikindustrie<br />

e. V.: Positionspapier Cyber-Sicherheit und Schutz vor Wirtschaftsspionage,<br />

2013. http://www.zvei.org/Verband/Publikatio-<br />

nen/Seiten/Positionspapier-Cyber-Sicherheit-und-Schutz-vor-<br />

Wirtschaftsspionage.aspx<br />

[19] VDE Verband der Elektrotechnik Elektronik und Informationstechnik<br />

e. V.: VDE Trendreport 2013. Schwerpunkt Industrie 4.0.<br />

https://www.vde.com/de/InfoCenter/Seiten/Details.<br />

aspx?eslShopItemID=a9f9d134-ecc2-420f-ad10-c9cd552d2dbf<br />

[20] Neugebauer, Reimund et. al. (Hrsg.): Strategie-und Positionspapier<br />

Cyber-Sicherheit 2020 - Herausforderungen für die IT-Sicherheitsforschung.<br />

http://www.fraunhofer.de/content/dam/zv/de/<br />

ueber-fraunhofer/wissenschaftspolitik/Fraunhofer-Strategie-%20<br />

und%20Positionspapier%20Cyber-Sicherheit%202020.pdf<br />

[21] Bundesamt für Sicherheit in der Informationstechnik: Industrial<br />

Control System Security - Top 10 Bedrohungen und Gegenmaßnahmen.<br />

https://www.allianz-fuer-cybersicher-heit.de/ACS/<br />

68<br />

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

7-8 / 2014


trie 4.0 begonnen hat. Durch Industrie 4.0 werden laufende<br />

Entwicklungen weiter beschleunigt und zusätzlich<br />

neue Impulse gesetzt. Das Thema IT-Sicherheit<br />

wird als äußerst wichtig für den Erfolg von Industrie<br />

4.0 eingestuft. Für Anlagen der Prozessindustrie ergeben<br />

sich besondere Herausforderungen. Neben dem<br />

technologischen Wandel, der durch die Konzepte von<br />

Industrie 4.0 initiiert wird, sind zusätzlich die bekannten<br />

Anforderungen in Bezug auf Sicherheit (Safety),<br />

Hochverfügbarkeit sowie lange Betriebsdauer zu<br />

berücksichtigen. Die künftigen Anforderungen in Bezug<br />

auf die IT-Sicherheit, die zum Teil auch ohne Industrie<br />

4.0 zu erfüllen sind, wurden beschrieben. Mögliche<br />

Lösungsansätze für die einzelnen Aspekte wurden<br />

aufgezeigt.<br />

MANUSKRIPTEINGANG<br />

20.06.2014<br />

Im Peer-Review-Verfahren begutachtet<br />

AUTOR<br />

Prof. Dr.-Ing. KARL-HEINZ NIEMANN<br />

(geb. 1959) vertritt seit 2005 die Lehrgebiete<br />

Prozessinformatik und Automatisierungstechnik<br />

an der Hochschule Hannover. Von<br />

2002 bis 2005 war er an der Fachhochschule<br />

Nordostniedersachsen für das Lehrgebiet<br />

Prozessdatenverarbeitung verantwortlich.<br />

Davor war er in leitender Stellung in der<br />

Entwicklung von Prozessleitsystemen tätig,<br />

unter anderem bei ABB, Elsag Bailey und Hartmann & Braun.<br />

Hochschule Hannover, Fakultät I – Elektro- und Informationstechnik,<br />

Postfach 92 02 61, D-30441 Hannover, Tel. +49 (0) 511 92 96 12 64,<br />

E-Mail: Karl-Heinz.Niemann@HS-Hannover.de<br />

DE/_downloads/techniker/hardware/BSI-CS_005.pdf?__<br />

blob=publicationFile<br />

[22] Krotofil, M. et al.: Industrial control systems security: What is<br />

happening?: In 2013 IEEE 11th International Conference on<br />

Industrial Informatics (INDIN), 2013; S. 670–675. DOI 10.1109/<br />

INDIN.2013.6622964.<br />

[23] Runde, M., Tebbe, C., Niemann, K.-H., Börgmann, A.: IT-Security<br />

in Automatisierungsnetzwerken unter Verwendung kryptografischer<br />

Maßnahmen. In Jasperneite, J., Jumar, U. (Hrsg.):<br />

Jahreskolloquium Kommunikation in der Automation<br />

(KommA 2012) am 14.11.2012 in Lemgo. Lemgo, 2012.<br />

ISBN 978-3-9814062-2-1. S. 156-165.<br />

[24] Runde, M., Tebbe, C., Niemann, K.-H.: Performance evaluation<br />

of an IT security layer in real-time communication. IEEE 18th<br />

Conference on Emerging Technologies & Factory Automation<br />

(ETFA) am 12.09.2013 in Cagliari. Cagliari, Italien, 2013. ISBN<br />

978-1-4799-0862-2, DOI: 10.1109/ETFA.2013.6647942.<br />

[25] Drath, Rainer et. al.: Integrationstopologie eines Industrie 4.0<br />

Netzwerkes für Produktionssysteme. Anforderungen an eine<br />

Industrie 4.0 Integrationstopologie. http://www.plattform-i40.<br />

de/sites/default/files/Sprechertext%20zu%20I40%20-%20<br />

Exemplarische%20Integrationstopologie%20v01.pdf<br />

[26] Hausmann, S. Heiss, S.: Usage of public key infrastructures<br />

in automation networks: 2012 IEEE 17th Conference on<br />

Emerging Technologies & Factory Automation (ETFA 2012),<br />

2012; S. 1–4. DOI 4. 10.1109/ETFA.2012.6489750.<br />

[27] Runde, M., Niemann, K.-H., Hausmann, S., Heiss, S.: Anwendung<br />

komponentenbezogener IT-Sicherheitsmaßnahmen in Automatisierungsnetzwerken.<br />

In Automation 2012. Kongress Baden-<br />

Baden, 13. und 14. Juni 2012. VDI-Berichte 2171, VDI-Verlag<br />

GmbH, Düsseldorf, 2012. S. 391-394.<br />

[28] Dieter Spath (Hrsg.): Produktionsarbeit der Zukunft -<br />

Industrie 4.0. http://www.iao.fraunhofer.de/images/iao-news/<br />

produktionsarbeit-der-zukunft.pdf<br />

[29] Runde, M, Tebbe, C., Niemann, K.-H., Toemmler, J.: Automated<br />

Decentralized IT Security Supervision in Automation Networks.<br />

In IEEE 10th International Conference on Industrial Informatics,<br />

25.-27. Juli 2012, Beijing, China. Seite 1243-1239. ISBN: 978-1-4673-0310-1.<br />

[30] Runde, M., Tebbe, C., Niemann, K.-H., Börgmann, A.: IT-Security in Automatisierungsnetzwerken<br />

unter Verwendung kryptografischer Maßnahmen. In Jasperneite,<br />

J., Jumar, U. (Hrsg.): Jahreskolloquium Kommunikation in der Automation (KommA<br />

2012) am 14.11.2012 in Lemgo. Lemgo, 2012. ISBN 978-3-9814062-2-1. S. 156-165.<br />

[31] Referentenentwurf des Bundesministeriums des Innern Entwurf eines<br />

Gesetzes zur Erhöhung der Sicherheit informationstechnischer Systeme.<br />

https://www.bmi.bund.de/SharedDocs/Downloads/DE/Gesetzestexte/<br />

Entwuerfe/Entwurf_it-sicherheitsgesetz.pdf<br />

[32] Bundesnetzagentur Energieabteilung: Sicherheitskatalog gem. § 11 Abs.<br />

1a EnWG. http://www.bundesnetzagentur.de/cln_1931/DE/Sachgebiete/<br />

ElektrizitaetundGas/Unternehmen_Institutionen/Versorgungssicherheit/<br />

IT_Sicherheit/IT_Sicherheit_node.html<br />

[33] Ponemon Institute LLC: 2013 Cost of Data Breach Study. Global Analysis.<br />

https://www4.symantec.com/mktginfo/whitepaper/053013_GL_NA_WP_<br />

Ponemon-2013-Cost-of-a-Data-Breach-Report_daiNA_cta72382.pdf<br />

[34] Wagner, M. et al.: Smart grid cyber security: A German perspective: 2012<br />

International Conference on Smart Grid Technology, Economics and Policies<br />

(SG-TEP), 2012; S. 1–4. DOI 10.1109/SG-TEP.2012.6642389.<br />

[35] Bundesamt für Sicherheit in der Informationstechnik (Hg.) (2009):<br />

Prinzipien der Verfügbarkeit. Hochverfügbarkeitskompendium.<br />

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Hochverfuegbarkeit/3_Prinzipien_Verfuegbarkeit_pdf.pdf<br />

[36] Xcert International, Inc.: Meeting the FDA’s Requirements for Electronic Records<br />

and Electronic Signatures (21 CFR Part 11). Hg. v. Inc. Xcert International.<br />

http://www.21cfrpart11.com/files/library/compliance/xcert_fda_white_paper.pdf<br />

[37] Wieczorek, F. et al.: Zusammenhang von Security und Funktionaler Sicherheit.<br />

Relevante Begriffe und Zuordnungen für die Automatisierung. In <strong>atp</strong>-<strong>edition</strong>,<br />

06-2013; S. 40–46.<br />

[38] Al-Khabbaz, F. et al.: Disaster recovery planning & methodology for Process<br />

Automation Systems: IEEE EUROCON 2011 - International Conference on<br />

Computer as a Tool, 2011; S. 1–4. DOI: 10.1109/EUROCON.2011.5929151.<br />

[39] Die deutsche Normungs-Roadmap Industrie 4.0. Version 1.0 Stand 1.12.2013.<br />

http://www.dke.de/de/std/informationssicherheit/documents/rz_roadmap%20<br />

industrie%204-0_email.pdf<br />

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

7-8 / 2014<br />

69


HAUPTBEITRAG | AALE<br />

Modellbasierter Entwurf<br />

in der Anwendung<br />

Automatisierung von Teilprozessen einer Abfüllanlage<br />

Am Beispiel der Automatisierung einer Sortierstation einer Flaschenabfüllanlage<br />

wird ein modellbasierter Entwurf mittels Matlab/Simulink, Stateflow und einer<br />

erforderlichen Toolbox zur automatischen Codegenerierung durchgeführt. Als Zielsystem<br />

wird das M1-System der Firma Bachmann eingesetzt. Im Beitrag wird der<br />

Entwurf für zwei Teilprozesse der Station Sortieren beschrieben und umgesetzt.<br />

Abschließend wird das Ergebnis der Automatisierung der Teilprozesse durch einen<br />

modellbasierten Entwurf bewertet, was die Umsetzbarkeit und Effizienz, sowie die<br />

Portierbarkeit auf andere Zielsysteme betrifft.<br />

SCHLAGWÖRTER Automatische Codegenerierung / Automatisierung / modellbasierter<br />

Entwurf / Matlab/Simulink / Stateflow<br />

Applying a Model-based Design –<br />

Automation of Sub-processes in a Bottle Filling Plant<br />

For the automation of the sorting station of a bottle filling plant, a model-based design<br />

was produced using MATLAB/Simulink®, Stateflow® and a toolbox for automatic<br />

code generation. The M1-System from Bachmann was used as the target system. Two<br />

sub-processes of the sorting station are described. The results of the automation of<br />

the sub-processes using a model-based design are evaluated in terms of feasibility,<br />

efficiency and portability to other target systems.<br />

KEYWORDS automatic code generation / automation / model-based design /<br />

Matlab/Simulink / Stateflow<br />

70<br />

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

7-8 / 2014


PERCY STEFAN STELTER, BERND BÜCHAU, GERALD GRÖBE, Fachhochschule Stralsund<br />

Eine Flaschenabfüllanlage, die aus vier unterschiedlichen<br />

Stationen besteht, soll automatisiert<br />

werden. Für die Station Sortieren wird ein<br />

modellbasierter Entwurf mittels Matlab/Simulink,<br />

Stateflow und einer erforderlichen Toolbox<br />

zur automatischen Codegenerierung durchgeführt,<br />

um diese Methode für diesen Anwendungsfall zu erproben<br />

[3]. Um dies verwirklichen zu können, muss ein<br />

geeignetes Automatisierungssystem zum <strong>Einsatz</strong> kommen.<br />

Als geeignetes Zielsystem bietet sich das M1-System<br />

der Firma Bachmann an.<br />

1. AUSGANGSSITUATION<br />

Die Flaschenabfüllanlage ist in vier Stationen unterteilt.<br />

Zu diesen gehören<br />

die Station Abfüllen<br />

die Station Sortieren<br />

die Station Recycling<br />

die Station Puffern und Handhaben<br />

Die Stationen werden in der angegebenen Reihenfolge<br />

durchlaufen. Der Gesamtprozess ist als Rundlaufprozess<br />

vorgesehen. Bild 1 gibt einen groben Überblick<br />

über die Flaschenabfüllanlage und deren Stationen.<br />

Der Beginn des Rundlaufprozesses ist die Station Abfüllen<br />

(Position 1 in Bild 1). In dieser Station werden<br />

die Flaschen mit zwei unterschiedlichen Flüssigkeiten<br />

gefüllt und nach dem Befüllen mit einem Schraubdeckel<br />

verschlossen.<br />

Nach der Station Abfüllen werden die Flaschen über<br />

Transportbänder der Station Sortieren (Position 2 in<br />

Bild 1) zugeführt. In dieser werden die Flaschen auf<br />

zwei Bändern sortiert und zwischengepuffert. Anschließend<br />

werden die Flaschen über Transportbänder<br />

zur Station Recycling (Position 3 in Bild 1) befördert.<br />

In der Station Recycling werden die Deckel der Flaschen<br />

durch einen Roboter entfernt und die Flüssigkeit<br />

abgesaugt. Die Flüssigkeit wird zur Station Abfüllen<br />

gepumpt, dort in einem Behälter aufgefangen, um erneut<br />

in Flaschen abgefüllt zu werden. Die Deckel werden<br />

ebenfalls über die Station Puffern und Handhaben<br />

(Position 4 in Bild 1) der Station Abfüllen zugeführt.<br />

Nach der Station Recycling werden die Flaschen über<br />

Transportbänder wieder der Station Abfüllen zugeführt.<br />

Zum Unterbrechen des Rundlaufprozesses befindet<br />

sich auf dem Transportband zur Station Abfüllen<br />

eine Auffangvorrichtung, mit der leere Flaschen aufgefangen<br />

und gepuffert werden.<br />

1.1 Prozessbeschreibung der Station Sortieren<br />

In Bild 2 ist das Technologieschema der Station Sortieren<br />

dargestellt. Der Prozess besteht aus den sechs Systemkomponenten<br />

Einlaufband, Sortierband 1, Sortierband 2,<br />

Zwischenband 1, Zwischenband 2 und Auslaufband.<br />

Einlaufband<br />

Die gefüllten und verschlossenen Flaschen werden von<br />

der Station Abfüllen an die Station Sortieren übergeben<br />

und laufen über das Einlaufband in die Station ein.<br />

Am Einlaufband befinden sich eine Lichtschranke, ein<br />

RFID-Sensor und eine Weiche.<br />

Durchläuft eine Flasche die Lichtschranke S-1B1, die<br />

sich am Anfang des Einlaufbandes befindet, wird der<br />

nachfolgende RFID-Sensor für eine definierte Zeit aktiv<br />

geschaltet. Der RFID-Sensor erfasst die im Flaschenlabel<br />

kodierte Kennung der vorbeilaufenden Flasche und<br />

bestimmt dadurch den Zustand (Inhalt). Durch die Zustandsbestimmung<br />

wird die Weiche gesteuert.<br />

Befindet sich Flüssigkeit 1 in der Flasche oder ist bei<br />

der Zustandsbestimmung ein Fehler aufgetreten, wird<br />

die Flasche durch die Weiche auf das Sortierband 1<br />

geleitet. Befindet sich in der Flasche die Flüssigkeit 2,<br />

wird die Flasche auf das Sortierband 2 gelenkt.<br />

Sortierband 1<br />

Die gefüllten und verschlossenen Flaschen werden<br />

durch die Weiche auf das Sortierband 1 beziehungsweise<br />

auf das Sortierband 2 geleitet. Am Sortierband 1<br />

befinden sich drei Lichtschranken und ein Stopper.<br />

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

7-8 / 2014<br />

71


HAUPTBEITRAG | AALE<br />

Signalisiert die Lichtschranke S-2B2, dass sich vor dem<br />

Stopper 1 eine Flasche befindet und signalisiert die<br />

Lichtschranke S-2B5, dass sich hinter dem Stopper 1<br />

keine Flasche befindet, wird die Flasche nach einer<br />

definierten Zeit ausgegeben. Der Stopper 1 ist mechanisch<br />

so konstruiert, dass sich immer nur eine Flasche<br />

ausgeben lässt.<br />

Durchläuft eine Flasche die Lichtschranke S-2B1, die<br />

sich am Anfang des Sortierbandes 1 befindet, wird das<br />

Einlaufband angehalten. Diese Funktion dient zur Verhinderung<br />

eines Flaschenstaus auf dem Sortierband 1.<br />

Signalisiert die Lichtschranke S-2B1, dass sich dort<br />

keine Flasche mehr befindet, wird das Einlaufband<br />

wieder eingeschaltet.<br />

Meldet die Lichtschranke S‐1B1 am Einlaufband und<br />

die Lichtschranke S‐2B2 vor Stopper 1 keine Flasche,<br />

wird das Sortierband 1 nach einer definierten Zeit abgeschaltet.<br />

Erst beim Durchlauf einer Flasche durch<br />

eine der beiden Lichtschranken oder Betätigung des<br />

Tasters Start am Bedienpanel, wird das Sortierband 1<br />

wieder gestartet.<br />

Sortierband 2<br />

Die Funktionen von Sortierband 1 und Sortierband 2<br />

sind identisch mit den dazugehörigen drei Lichtschranken<br />

(S-3B2, S-3B5 und S-3B1) und dem Stopper 2.<br />

Zwischenband 1<br />

Das Zwischenband 1 ist das Transportband zwischen<br />

den Sortierbändern 1 und 2 und dem Zwischenband 2.<br />

Wurde eine Flasche aus einem der Sortierbänder ausgegeben,<br />

wird dies durch die Lichtschranke S-2B5 beziehungsweise<br />

S‐3B5 erkannt und das Zwischenband 1<br />

für eine definierte Zeit eingeschaltet – dies gilt auch<br />

nach Drücken des Tasters Start.<br />

Zwischenband 2<br />

Das Zwischenband 2 ist das Transportband zwischen<br />

dem Zwischenband 1 und dem Auslaufband. Die Funktionen<br />

vom Zwischenband 2 sind gleich denen von<br />

Zwischenband 1 mit den dazugehörigen beiden Lichtschranken<br />

S‐2B5 und S‐3B5.<br />

Auslaufband<br />

Das Auslaufband ist das Transportband zwischen dem<br />

Zwischenband 2 und der Station Recycling. Die Funktionen<br />

vom Auslaufband sind gleich denen von Zwischenband<br />

1 mit den dazugehörigen beiden Lichtschranken<br />

S‐2B5 und S‐3B5. Das Auslaufband übergibt<br />

die gefüllten und verschlossenen Flaschen an die Station<br />

Recycling.<br />

2. ENTWICKLUNGSUMGEBUNG FÜR<br />

MODELL BASIERTEN ENTWURF<br />

Dieser Abschnitt befasst sich mit der funktionalen Beschreibung<br />

des M1-Systems der Firma Bachmann, das<br />

für den modellbasierten Entwurf geeignet ist [4]. Konventionelle<br />

Automatisierungssysteme, die ausschließlich<br />

eine herstellerspezifische Entwicklungsumgebung<br />

beinhalten, unterstützen dies nicht.<br />

Mit dem M1-System ist die Modellierung mittels Matlab/Simulink<br />

und Stateflow möglich. Die Implementierung<br />

erfolgt über den Real-Time Workshop und das<br />

M-Target for Simulink (Toolbox zur automatischen<br />

Codegenerierung). Der Vorteil bei diesem System ist,<br />

dass sich der im M-Target for Simulink generierte Code<br />

direkt auf das Zielsystem laden lässt, wie in Bild 3 dargestellt<br />

[5].<br />

Eine weitere Alternative ist die entsprechende Entwicklungsumgebung<br />

von Siemens für PC-basierte Controller,<br />

die einen nahezu durchgängigen Entwicklungsprozess<br />

bietet, wie Bild 3 zeigt. Allerdings sind hier<br />

noch Zwischenschritte erforderlich, um den generierten<br />

Quellcode ablauffähig in den PC-basierten Controller<br />

zu portieren [6].<br />

Eines haben alle angebotenen Systeme für den modellbasierten<br />

Entwurf gemeinsam: Für die Konfiguration<br />

des Automatisierungssystems ist die herstellerspezifische<br />

konventionelle Entwicklungsumgebung erforderlich.<br />

Im Fall des Automatisierungssystems von<br />

Bachmann handelt es sich um das SolutionCenter.<br />

3. AUTOMATISIERUNGSSYSTEM IM PROZESS SORTIEREN<br />

Um alle Funktionen der Station Sortieren der Flaschenabfüllanlage<br />

bedienen zu können, wird das M1-System<br />

aus mehreren Komponenten zusammengestellt. Zu diesen<br />

gehören:<br />

Laststromversorgung (NT255)<br />

Prozessormodul (MPC270)<br />

Profibus-DP-Master-Modul (DPM200)<br />

CANopen-Master-Modul (CM202)<br />

digitales Ein- und Ausgabemodul (DIO248)<br />

Bild 4 gibt einen Überblick über das eingesetzte M1-<br />

System und dessen Anbindung an die Station Sortieren<br />

der Flaschenabfüllanlage.<br />

4. VORGEHENSWEISE BEIM M1-SYSTEM<br />

Für den modellbasierten Entwurf sind drei Schritte<br />

durchzuführen:<br />

1 | Modellierung: Bei der Modellierung wird ein Modell<br />

der Anlagesteuerung mittels Matlab/Simulink<br />

und Stateflow erzeugt. Dieses Modell beinhaltet<br />

alle Funktionen des Prozesses.<br />

2 | Implementierung: Mittels Real-Time Workshop<br />

wird aus der Modellierung ein C++ Code generiert.<br />

Dieser Code wird automatisch im M-Target<br />

für Simulink (Toolbox zur automatischen Codegenerierung)<br />

in ein Programm für das Zielsystem<br />

umgewandelt.<br />

3 | Übertragung des Quellcodes in das Zielsystem: Der<br />

generierte Code wird auf das M1-System übertragen.<br />

72<br />

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

7-8 / 2014


BILD 1: Schematische Darstellung des Materialflusses<br />

der Flaschenabfüllanlage<br />

BILD 3: Entwicklungsumgebungen für<br />

den modellbasierten Entwurf von<br />

Bachmann (links) und Siemens (rechts)<br />

BILD 2: Technologieschema der Station Sortieren<br />

in der Draufsicht<br />

BILD 4: Komponentenstruktur des M1-Systems<br />

der Station Sortieren<br />

BILD 5: Struktur des<br />

modellbasierten Entwurfs<br />

für die Station Sortieren<br />

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

7-8 / 2014<br />

73


HAUPTBEITRAG | AALE<br />

5. ENTWURF UND UMSETZUNG<br />

Dieser Abschnitt befasst sich mit der Automatisierung<br />

ausgewählter Teilprozesse der Station Sortieren. Für<br />

den Entwurf müssen die Teilprozesse der Anlage inklusive<br />

der übergeordneten Koordination und der<br />

Funktionalität des Bedienpanels dieser Station modelliert<br />

werden, wie in Bild 5 dargestellt.<br />

Die Koordination der Teilprozesse beinhaltet die<br />

Kommunikation über Profinet mit den benachbarten<br />

Stationen der Flaschenabfüllanlage, die in Form eines<br />

Subsystems modelliert werden muss. In gleicher Weise<br />

muss für das Einlaufband der RFID-Sensor und für das<br />

Auslaufband der Antrieb mit dem CAN-Bus-Interface<br />

modelliert werden. Das Bedienpanel und die Zwischenbänder<br />

1 und 2 beinhalten lediglich Sensoren und Aktoren,<br />

die über die IO-Baugruppen angesteuert werden<br />

müssen und sind somit ebenso einfach wie die Sortierbänder<br />

zu modellieren.<br />

In diesem Beitrag werden exemplarisch das Bedienpanel<br />

und die Sortierbänder 1 und 2 modelliert.<br />

5.1 Automatisierung des Bedienpanels<br />

Das Bedienpanel hat folgende fünf Bedienelemente:<br />

Taster Start mit integriertem Leuchtmelder<br />

Taster Stop<br />

Taster Reset mit integriertem Leuchtmelder<br />

Taster Not-Aus-Quittierung<br />

Schalter Not-Aus<br />

Durch das in Bild 6 gezeigte Petri-Netz wird ein Überblick<br />

über die Funktionen zur Koordination der Station<br />

Sortieren über das Bedienpanel gegeben. Dieses Petri-<br />

Netz ist den Petri-Netzen zur Automatisierung der Sortierbänder<br />

1 und 2 übergeordnet.<br />

Not-Aus-Gerät<br />

Im Petri-Netz von Bild 6 und im Signalflussplan von<br />

Bild 7 wird der Begriff Not-Aus-Gerät verwendet. Das<br />

Not-Aus-Gerät besteht aus einem Not-Aus-Schalter und<br />

einem Not-Aus-Quittierungs-Taster am Bedienpanel,<br />

sowie dem Sicherheitsschaltgerät. Wurde am Bedienpanel<br />

der Not-Aus-Schalter betätigt, wird über das Sicherheitsschaltgerät<br />

mechanisch das digitale Ein-/<br />

Ausgangsmodul DIO248 von der Spannungsversorgung<br />

getrennt. Dadurch werden alle Ausgänge des Moduls<br />

spannungslos geschaltet und ein Fehler im M1-System<br />

erzeugt, der den Programmablauf unterbricht. Erst<br />

nach dem Entriegeln des Not-Aus-Schalters am Bedienpanel<br />

und der Quittierung über den Not-Aus-Quittierungs-Taster<br />

wird das Ein-/Ausgangs-Modul über<br />

das Sicherheitsschaltgerät wieder aktiv geschaltet.<br />

Dadurch liegt der entstandene Fehler nicht weiter im<br />

Automatisierungssystem vor und der Programmablauf<br />

wird fortgesetzt.<br />

Die Implementierung für die Steuerung der Station<br />

Sortieren über das Bedienpanel mittels Matlab/Simulink<br />

und Stateflow zeigen die Bilder 7 und 8. Die beiden<br />

Zustandsautomaten haben die gleiche Funktion und<br />

dienen der Erzeugung eines digitalen 2 Hz-Signals für<br />

die Blinkfunktion der Leuchtmelder, die in den Tastern<br />

integriert sind.<br />

In Simulink gibt es keine standardisierten Bausteine.<br />

Deshalb wurden alle verwendeten RS-Flip-Flops der<br />

Bilder 7 und 10 durch das Zusammenfügen von Simulink-Bausteinen<br />

erstellt, wie dies in der unteren rechten<br />

Ecke von Bild 7 dargestellt ist.<br />

Den Zustandsautomaten im Bild 7 werden über den<br />

oberen Eingang die Ereignisse und über den seitlichen<br />

Eingang die Bedingung aus Simulink übergeben. Der<br />

Wechsel von einem Zustand in einen anderen geschieht<br />

nur, wenn ein Ereignis auftritt und gleichzeitig die Bedingung,<br />

die mit dem Ereignis verknüpft ist, erfüllt ist.<br />

Die Bedingung wird in eckigen Klammern am Ereignis<br />

angegeben, wie Bild 8 zeigt. Sofern mit einem Ereignis<br />

keine Bedingung verknüpft ist, wird direkt beim Auftreten<br />

des Ereignisses der Zustand gewechselt.<br />

Jeder Zustandsautomat benötigt ein Start-Ereignis,<br />

um in den Anfangszustand zu gelangen. Bei diesem<br />

Beispiel ist das Start-Ereignis E_Ein1. Alle Ereignisse<br />

der Zustandsautomaten 1 und 2 sind identische Rechtecksignale<br />

mit der Frequenz 2 Hz und werden durch<br />

die beiden Pulse-Generatoren erzeugt.<br />

Im oberen Drittel von Bild 7 wird die Bedingung Blinken<br />

des Zustandsautomaten 1 erzeugt. Die Bedingung<br />

ist aktiv, wenn der vorgeschaltete RS-Flip-Flop gesetzt<br />

ist. Zum Setzen dieses RS-Flip-Flops werden die Signale<br />

Not-Aus-Gerät, Error CAN-Motor und Taster Stop<br />

ausgewertet.<br />

Weist das Signal Not-Aus-Gerät eine negative Flanke<br />

auf (im Normalbetrieb ist das Signal Not-Aus-Gerät ein<br />

1-Signal) oder weist das Signal Error CAN-Motor eine<br />

positive Flanke auf (im Normalbetrieb ist das Signal<br />

Error CAN-Motor ein 0-Signal) oder liegt das Signal<br />

Taster Stop nicht an (im Normalbetrieb ist das Signal<br />

Taster Stop ein 1-Signal, da der Taster als Öffner konstruiert<br />

ist), wird der RS-Flip-Flop gesetzt. Das vierte<br />

Signal, das auf den oberen Oder-Baustein geführt ist,<br />

erzeugt bei der Erstinbetriebnahme für eine Sekunde<br />

ein 1-Signal. Dadurch wird ebenfalls der RS-Flip-Flop<br />

gesetzt. Durch das Setzen wird die Bedingung Blinken<br />

des Zustandsautomaten 1 aktiv geschaltet und der<br />

Leuchtmelder des Taster Reset beginnt mit einer Frequenz<br />

von zwei Hz zu blinken.<br />

In den unteren zwei Dritteln von Bild 7 wird die Bedingung<br />

Blinken des Zustandsautomaten 2 erzeugt. Die<br />

Bedingung ist aktiv, wenn der vorgeschaltete RS-Flip-<br />

Flop gesetzt ist.<br />

Zum Setzen dieses RS-Flip-Flops muss zunächst<br />

das Signal Taster Reset aktiv werden. Dies geschieht<br />

durch das Betätigen des Tasters am Bedienpanel. Infolge<br />

der Bedienung wird der Merker Merker Reset<br />

aktiv, wodurch die Weiche und die Stopper 1 und 2<br />

in die Grundstellung verfahren. Sind diese in der<br />

Grundstellung, wird dies durch die Signale Weiche<br />

Stellung Sortierband 1, Stopper 1 in Grundstellung<br />

und Stopper 2 in Grundstellung signalisiert. Befindet<br />

74<br />

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

7-8 / 2014


BILD 7: Modellierung der<br />

Funktionen zur Koordination<br />

der Station Sortieren<br />

über das Bedienpanel<br />

mit Matlab/Simulink<br />

u n d S t a t e fl o w<br />

BILD 6: Petri-Netz der Funktionen zur Koordination<br />

der Station Sortieren über das Bedienpanel<br />

BILD 8: Modellierung der Funktionen<br />

zur Koordination der Station Sortieren<br />

über das Bedienpanel mit Stateflow<br />

sich alles in der Grundstellung, wird der Merker Merker<br />

Reset inaktiv, der RS-Flip-Flop vor dem Zustandsautomaten<br />

2 wird gesetzt und der RS-Flip-Flop vor<br />

dem Zustandsautomaten 1 wird zurückgesetzt. Durch<br />

das Setzen wird die Bedingung Blinken des Zustandsautomaten<br />

2 aktiv geschaltet und der Leuchtmelder<br />

des Taster Start beginnt mit einer Frequenz von 2 Hz<br />

zu blinken.<br />

Die letzte Funktion der logischen Verknüpfungen aus<br />

Bild 7 ist das Starten der Anlage. Blinkt der Leuchtmelder<br />

des Taster Start und wird der Taster Start betätigt,<br />

führt dies zum Setzen eines weiteren RS-Flip-Flops.<br />

Infolge dessen wird der Merker Merker Anlage Start/<br />

Stop aktiv und das Blinken des Leuchtmelders wird in<br />

ein Dauerleuchten überführt.<br />

Alle Ein- und Ausgangssignale des Modells in Bild 7<br />

sind digitale Ein- und Ausgangssignale des M1-Systems<br />

mit Ausnahme der Merker Merker Anlage Start/Stop<br />

und Merker Reset. Diese beiden Merker sind Schnittstellen<br />

zu weiteren Teilprozessen der Station Sortieren.<br />

5.2 Automatisierung der Sortierbänder 1 und 2<br />

Das in Bild 9 aufgeführte Petri-Netz gibt einen Überblick<br />

über die Steuerung der Sortierbänder 1 und 2 und ist dem<br />

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

7-8 / 2014<br />

75


HAUPTBEITRAG | AALE<br />

BILD 9: Petri-Netz zur<br />

Steuerung der Sortierbänder 1 und 2<br />

BILD 10: Modellierung mit<br />

Matlab/Simulink und Stateflow<br />

Petri-Netz mit den Funktionen zur Koordination der Station<br />

Sortieren über das Bedienpanel, siehe Bild 6, untergeordnet.<br />

Das bedeutet, wird in der Station am Bedienpanel<br />

der Taster Stop oder der Schalter Not-Aus betätigt,<br />

wird die Abfolge in diesem Petri-Netz unterbrochen und<br />

in den Ausgangszustand Anlage Aus gesprungen.<br />

Die Implementierung für die Steuerung der Sortierbänder<br />

1 und 2 ist in Bild 10 und 11 dargestellt. Die<br />

Ansteuerung der Sortierbänder erfolgt über den Zustandsautomat,<br />

siehe Bild 11. Über den oberen Eingang<br />

des Zustandsautomaten werden Ereignisse aus Simulink<br />

übergeben. Da es keine Bedingungen gibt, erfolgt ein<br />

Zustandswechsel direkt beim Auftreten eines Ereignisses.<br />

Der Zustandsautomat benötigt ein Start-Ereignis,<br />

um in den Anfangszustand Z_Aus zu gelangen. Bei diesem<br />

Beispiel ist das Start-Ereignis E_Reset, das bei der<br />

Betätigung des Taster Reset am Bedienpanel erzeugt<br />

wird. Alle weiteren Ereignisse werden in den logischen<br />

Verknüpfungen des Modells, siehe Bild 10, erzeugt.<br />

In der Mitte von Bild 10 werden die Ereignisse<br />

E_Start und E_Stop generiert. Wird der Taster Start am<br />

Bedienpanel betätigt, führt dies zum Setzen des RS-<br />

Flip-Flops. Daraus folgt unmittelbar das Ereigniss<br />

E_Start, wodurch im Zustandsautomaten in den Zustand<br />

Z_Band Ein gewechselt wird. Dieser Wechsel<br />

führt zum Anlauf der Sortierbänder. Weist das Signal<br />

Merker Anlage Start/Stop ein 0-Signal auf, wird der<br />

RS-Flip-Flop zurückgesetzt. Dadurch wird das Ereignis<br />

E_Stop generiert und im Zustandsautomat wird in den<br />

Zustand Z_Aus gewechselt. In diesem Zustand sind die<br />

Sortierbänder ausgeschaltet.<br />

Im unteren Teil von Bild 10 werden die Ereignisse<br />

E_BandAus und E_BandEin generiert. Dazu werden die<br />

Signale Taster Start, Lichtschranke am Einlaufband<br />

(S-1B1 in Bild 2), Lichtschranke vor Stopper 1 (S-2B2)<br />

und Lichtschranke vor Stopper 2 (S-3B2) ausgewertet.<br />

Weist eines dieser Signale ein 1-Signal auf, wird das<br />

Ereignis E_BandEin aktiv. Befindet sich der Zustandsautomat<br />

im Zustand Zustand Z_Band Aus kommt es<br />

durch dieses Ereignis zum Wechsel in den Zustand<br />

Z_Band Ein. Mit dem Auftreten des Ereignisses<br />

E_BandEin wird gleichzeitig die Einschaltverzögerung<br />

aktiv geschaltet. Ist die eingestellte Zeit der Einschaltverzögerung<br />

abgelaufen, erzeugt dies das Ereignis<br />

E_BandAus. Dieses Ereignis hat einen Wechsel des Zustandsautomaten<br />

von Z_Band Ein nach Z_Band Aus<br />

zur Folge. In diesem Zustand sind die Sortierbänder<br />

ebenfalls ausgeschaltet.<br />

Treten die Ereignisse E_BandAus und E_BandEin im<br />

Zustand Z_Aus auf, hat dies keinen Zustandswechsel<br />

zur Folge. Das Signal Merker Anlage Start/Stop kommt<br />

aus dem Modell zur Steuerung der Anlage über das Bedienpanel,<br />

siehe Bild 7. Alle weiteren Signale des Modells<br />

in Bild 10 sind digitale Ein- und Ausgangssignale.<br />

BILD 11: Modellierung mit Stateflow<br />

ZUSAMMENFASSUNG UND AUSBLICK<br />

Im Beitrag wurde gezeigt, dass mit dem M1-System von<br />

Bachmann und deren Toolbox M-Target for Simulink<br />

76<br />

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

7-8 / 2014


für Matlab/Simulink ein durchgängiger modellbasierter<br />

Entwurf möglich ist; abgesehen von den recht langen<br />

Einarbeitungszeiten in eine solche Entwicklungsumgebung.<br />

Von Nachteil ist, dass für den Entwurf keine<br />

genormten Symbole für die Objekte zur Modellierung<br />

zur Verfügung stehen, wodurch die Lesbarkeit<br />

erschwert wird. Andererseits ergibt sich durch die<br />

Vielfalt an Objekten in Matlab/Simulink ein Vorteil, da<br />

für jedes Problem beliebige Modelle gebildet werden<br />

können, um diese zu lösen.<br />

Der modellbasierte Entwurf kann nahezu unabhängig<br />

vom gewählten Zielsystem vorgenommen werden, was<br />

ein großer Vorteil ist, weil – wenn alle Hersteller den<br />

modellbasierten Entwurf unterstützen würden – der<br />

Entwurf auf unterschiedliche Zielsysteme portiert werden<br />

könnte. Die Konfiguration des Zielsystems muss<br />

aber grundsätzlich mit der herstellerspezifischen Entwicklungsumgebung<br />

vorgenommen werden.<br />

Defizite beim modellbasierten Entwurf ergeben sich<br />

aus dem Fehlen entsprechender Modellbibliotheken für<br />

die unterschiedlichen Sensoren, Aktoren, sowie der<br />

unterschiedlichen Kommunikationssysteme und herstellerspezifischen<br />

Peripheriegeräten. Zur Zeit müssen<br />

dafür noch eigene Modelle erstellt beziehungsweise mit<br />

einem herstellerspezifischen Werkzeug der Entwurf<br />

vorgenommen werden. In naher Zukunft wird es sicher<br />

entsprechende Angebote geben.<br />

MANUSKRIPTEINGANG<br />

21.10.2013<br />

REFERENZEN<br />

Im Peer-Review-Verfahren begutachtet<br />

[1] Stelter, P. S.: Substitution eines konventionellen<br />

Automatisierungssystems auf der Basis eines<br />

modellbasierten Entwurfs in einer Flaschenabfüllanlage.<br />

Bachelorarbeit 2013<br />

[2] Stelter, P. S., Büchau, B., Gröbe, G.: Substitution<br />

eines konventionellen Automatisierungssystems auf<br />

der Basis eines modellbasierten Entwurfs in einer<br />

Flaschenabfüllanlage. In: Tagungsband AALE 2013,<br />

S. 155-165. DIV, 2013<br />

[3] MathWorks: http://www.mathworks.de<br />

[4] Büchau, B., Gröbe, G.: Auswahl einer Infrastruktur<br />

für den modellbasierten Entwurf in Forschung,<br />

Entwicklung und Lehre, In: Tagungsband AALE 2011,<br />

S. 317-324, Oldenbourg Industrieverlag, 2011<br />

[5] Bachmann electronic GmbH: M-Target for Simulink ® ,<br />

Systemübersicht, Bachmann electronic GmbH,<br />

10.2012<br />

[6] Siemens AG: Integration und Aufruf von Simulink<br />

Subsystemen mit STEP 7 und WinAC ODK am<br />

Beispiel einer PID Regelung WinAC S2O (Simulink<br />

to ODK) Wizard STEP 7, WinAC ODK, Applikationsbeschreibung;<br />

WinAC S2O Wizard, Version 1.0.1;<br />

Beitrags-ID: 56969417; 2012<br />

AUTOREN<br />

PERCY STEFAN STELTER (B.Sc.)<br />

(geb. 1987) ist Elektroingenieur.<br />

Er hat bis 2013 Elektrotechnik an der<br />

Fachhochschule Stralsund studiert.<br />

Das im Beitrag vorgestellte Thema<br />

wurde im Rahmen seiner Bachelor-<br />

Thesis bearbeitet. Zur Zeit studiert er<br />

Elektrotechnik im Master-Studiengang<br />

an der Fachhochschule Stralsund.<br />

Fachhochschule Stralsund,<br />

Zur Schwedenschanze 15, D-18435 Stralsund,<br />

Tel. +49 (0) 157 88 20 83 71,<br />

E-Mail: percy.s.stelter@fh-stralsund.de<br />

Prof. Dr.-Ing. BERND BÜCHAU<br />

(geb. 1957) ist Elektroingenieur.<br />

Er hat Elektrotechnik an der Fachhochschule<br />

Hamburg und der Universität<br />

Bremen studiert, wo er bei Prof.<br />

Dr. D. Silber promovierte. Nach einer<br />

Industrietätigkeit im Bereich Software-<br />

Engineering für Automatisierungsund<br />

medizinische Systeme ist er seit<br />

1993 Professor für Prozessrechentechnik an der Fachhochschule<br />

Stralsund. Seine Arbeitsschwerpunkte sind die<br />

industriellen Kommunikationssysteme und der Entwurf<br />

komplexer Automatisierungssysteme. Zur Zeit ist er Dekan<br />

des Fachbereiches Elektrotechnik und Informatik der<br />

Fachhochschule Stralsund und Sprecher des wissenschaftlichen<br />

Beirats des VFAALE.<br />

Fachhochschule Stralsund,<br />

Zur Schwedenschanze 15, D-18435 Stralsund,<br />

Tel. +49 (0) 3831 45 66 25,<br />

E-Mail: bernd.buechau@fh-stralsund.de<br />

Dipl.-Ing. (FH) GERALD GRÖBE<br />

(geb. 1966) studierte Technische<br />

Informatik an der Fachhochschule<br />

Stralsund. Seit 1994 ist er Mitarbeiter<br />

der Fachhochschule Stralsund und<br />

in den Bereichen Automatisierungstechnik<br />

und grafische Datenverarbeitung<br />

tätig. Zur Zeit arbeitet er auf<br />

den Gebieten der industriellen Kommunikationsysteme<br />

und dem modellbasierten Entwurf von<br />

Automatisierungssystemen.<br />

Fachhochschule Stralsund,<br />

Zur Schwedenschanze 15, D-18435 Stralsund,<br />

Tel. +49 (0) 3831 45 66 42,<br />

E-Mail: gerald.groebe@fh-stralsund.de<br />

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

7-8 / 2014<br />

77


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 />

Kirstin Sommer<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 />

Dipl.-Ing. Thomas Grein<br />

Prof. Dr.-Ing. Hartmut Haehnel<br />

Dipl.-Ing. Tim-Peter Henrichs<br />

Dr.-Ing. Jörg Kiesbauer<br />

Dipl.-Ing. Gerald Mayr<br />

Dr.-Ing. Josef Papenfort<br />

Igor Stolz<br />

Dr. Andreas Wernsdörfer<br />

Dipl.-Ing. Dieter Westerkamp<br />

Prof. Dr.-Ing. Michael Weyrich<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 />

Jürgen Franke (verantwortlich)<br />

Telefon + 49 (0) 89 203 53 66 10<br />

E-Mail: franke@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> – Automatisierungs technische<br />

Praxis“ erscheint monatlich mit Doppelausgaben<br />

im Januar/Februar und Juli/August.<br />

Bezugspreise:<br />

Abonnement jährlich: € 519,– + € 30,–/ € 35,–<br />

Versand (Deutschland/Ausland);<br />

Heft-Abonnement + Online-Archiv: € 704,70;<br />

ePaper (PDF): € 519,–; ePaper + Online-Archiv:<br />

€ 674,70; Einzelheft: € 59,– + Versand;<br />

Die Preise enthalten bei Lieferung in EU-<br />

Staaten die Mehrwertsteuer, für alle übrigen<br />

Länder sind es Nettopreise. Mitglieder der<br />

GMA: 30% Ermäßigung auf den Heftbezugspreis.<br />

Bestellungen sind jederzeit über den Leserservice<br />

oder jede Buchhandlung möglich.<br />

Die Kündigungsfrist für Abonnement aufträge<br />

beträgt 8 Wochen zum Bezugsjahresende.<br />

Abonnement-/Einzelheftbestellung:<br />

DataM-Services GmbH, Leserservice <strong>atp</strong><br />

Herr Marcus Zepmeisel<br />

Franz-Horn-Str. 2, 97082 Würzburg<br />

Telefon + 49 (0) 931 417 04 59<br />

Telefax + 49 (0) 931 417 04 94<br />

leserservice@di-verlag.de<br />

Verantwortlich für den Anzeigenteil:<br />

Inge Spoerel<br />

Telefon + 49 (0) 89 203 53 66 22<br />

E-Mail: spoerel@di-verlag.de<br />

Kirstin Sommer (Key Account)<br />

Telefon + 49 (0) 89 203 53 66 36<br />

E-Mail: sommer@di-verlag.de<br />

Angelika Weingarten (Key Account)<br />

Telefon + 49 (0) 89 203 53 13<br />

E-Mail: weingarten@di-verlag.de<br />

Es gelten die Preise der Mediadaten 2014<br />

Anzeigenverwaltung:<br />

Brigitte Krawczyk<br />

Telefon + 49 (0) 89 203 53 66 12<br />

E-Mail: krawczyk@di-verlag.de<br />

Art Direction / Layout:<br />

deivis aronaitis design | dad |<br />

Druck:<br />

Druckerei Chmielorz GmbH,<br />

Ostring 13,<br />

D-65205 Wiesbaden-Nordenstadt<br />

Gedruckt auf chlor- und<br />

säurefreiem Papier.<br />

Die <strong>atp</strong> wurde 1959 als „Regelungstechnische<br />

Praxis – rtp“ gegründet.<br />

DIV Deutscher Industrieverlag<br />

GmbH München<br />

Die Zeitschrift und alle in ihr enthaltenen<br />

Beiträge und Abbildungen sind urheberrechtlich<br />

geschützt. Mit Ausnahme der gesetzlich<br />

zugelassenen Fälle ist eine Verwertung ohne<br />

Ein willigung des Verlages strafbar.<br />

Gemäß unserer Verpflichtung nach § 8<br />

Abs. 3 PresseG i. V. m. Art. 2 Abs. 1c DVO<br />

zum BayPresseG geben wir die Inhaber<br />

und Beteiligungsverhältnisse am Verlag<br />

wie folgt an:<br />

DIV Deutscher Industrieverlag GmbH,<br />

Arnulfstraße 124, D-80636 München.<br />

Alleiniger Gesellschafter des Verlages<br />

ist die ACM-Unternehmensgruppe,<br />

Ostring 13,<br />

D-65205 Wiesbaden-Nordenstadt.<br />

ISSN 2190-4111<br />

DIE AUSGABE 9 / 2014 DER<br />

ERSCHEINT AM 04.09.2014<br />

MIT DEM SCHWERPUNKT<br />

„ENERGIE- UND KOSTENEFFIZIENZ IN<br />

UND DURCH AUTOMATION“<br />

Sicherheitsgerichteter<br />

Stellantrieb<br />

Adaptives Steuerungsund<br />

Regelungskonzept<br />

eines autarken Kraftwerks<br />

Anforderungs- und<br />

Testfall-Codesign.<br />

Formalisierung und<br />

Testfall-Generierung<br />

in der Praxis<br />

Ein „smart system“<br />

für die zukünftige<br />

Ver- und Entsorgung von<br />

Wasser und Abwasser<br />

in Megacities<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 />

78<br />

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

7-8 / 2014


Erreichen Sie die Top-Entscheider<br />

der Automatisierungstechnik.<br />

Sprechen Sie uns an wegen Anzeigenbuchungen<br />

und Fragen zu Ihrer Planung.<br />

Inge Spoerel: Telefon +49 (0) 89 203 53 66-22<br />

E-Mail: spoerel@di-verlag.de


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 € 389,25 zzgl. Versand<br />

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

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

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

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

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

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

Firma/Institution<br />

Vorname, Name des Empfängers<br />

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

Land, PLZ, Ort<br />

Antwort<br />

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

Postfach 91 61<br />

97091 Würzburg<br />

Telefon<br />

E-Mail<br />

Branche / Wirtschaftszweig<br />

Telefax<br />

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

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

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

9161, 97091 Würzburg.<br />

✘<br />

Ort, Datum, Unterschrift<br />

PAATPE2014<br />

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

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.

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!