05.05.2014 Aufrufe

atp edition Industrie 4.0 ohne modellbasierte Softwareentwicklung (Vorschau)

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

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

5 / 2014<br />

56. Jahrgang B3654<br />

DIV Deutscher <strong>Industrie</strong>verlag GmbH<br />

Automatisierungstechnische Praxis<br />

<strong>Industrie</strong> <strong>4.0</strong> <strong>ohne</strong> <strong>modellbasierte</strong><br />

<strong>Softwareentwicklung</strong> | 22<br />

Engineering-Effizienz<br />

automatisch messen | 32<br />

Redundanz für verfügbare<br />

Systeme | 42<br />

Schutzzielorientiertes Design<br />

der Sicherheitsleittechnik | 54


Rund um die Uhr<br />

erstklassig informiert<br />

• das innovative Online-Medium<br />

• Nachrichten gezielt recherchieren<br />

• die ideale Ergänzung zu <strong>atp</strong> <strong>edition</strong><br />

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

Automatisierung<br />

auf den Punkt<br />

Noch schneller informiert mit dem Newsletter <strong>atp</strong>!update<br />

Jetzt für den Newsletter anmelden:<br />

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

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

• Branche<br />

• Veranstaltungen<br />

• Forschung<br />

• Produkte<br />

update


EDITORIAL<br />

Wir sind auf gutem Weg<br />

Ist unsere Automatisierungstechnik reif für „<strong>Industrie</strong> <strong>4.0</strong>“, die intelligente<br />

und damit effizientere Fabrik der Zukunft? Diese Frage war Gegenstand<br />

einer Podiumsdiskussion im Forum Industrial IT auf der diesjährigen Hannover<br />

Messe. Mein Eindruck: Technologisch durchaus, konzeptionell noch<br />

nicht ganz. Meine Überzeugung: Der Weg dorthin führt nur über die modulare<br />

Automatisierung.<br />

Da sind die Bemühungen des ISA-106 Technical Reports hilfreich, Strukturen<br />

vorzuschlagen und Definitionsbarrieren zu überwinden. Da helfen die<br />

Anforderungen der Namur-Empfehlung 148 Nutzern und Anbietern von<br />

Automatisierungstechnik, ein gemeinsames Verständnis zu entwickeln und<br />

die Brücke vom Abstrakten zum Konkreten zu schlagen. Da helfen auch die<br />

Diskussionen, die aktuell zwischen den Fachverbänden geführt werden.<br />

Noch sind nicht alle Aufgaben gelöst: ein ganzheitlicher Ansatz ist notwendig,<br />

ja „alternativlos“. Herstellerneutralität, etwa in Form übergreifender<br />

Zustandsmodelle, muss gewährleistet sein. Dabei darf Automatisierung die<br />

Realisierung von „<strong>Industrie</strong> <strong>4.0</strong>“ nicht ausbremsen, darüber herrscht Einigkeit.<br />

Erreichen können wir dies nur gemeinsam. Bevor Geräte kommunizieren,<br />

müssen zunächst Menschen miteinander reden: Automatisierer, Anlagenbauer,<br />

Verfahrenstechniker, Betreiber.<br />

Ganzheitlich vorzugehen und dabei der eigenen Kernkompetenz treu zu<br />

bleiben bedeutet also, rasch weitere Akteure rund um den Prozess einzubeziehen.<br />

Das betrifft zunächst vorrangig den Anlagenbau, um zügig den Schritt<br />

in die Produktionsrealität zu machen, um Konzepte und Modelle praktisch<br />

zu erproben. Gemeinsam mit der Verfahrenstechnik muss es gelingen, einen<br />

kontinuierlichen Entwicklungsprozess anzustoßen, in dem sich konzeptionelle<br />

und technologische Aspekte gegenseitig befruchten. Kundenindividuelle<br />

Massenproduktion und Plattformstrategien wie in der Fertigungsindustrie<br />

könnten ein gangbarer Weg sein, um in einer modularen Zukunft individuelle<br />

Anlagen rasch, systematisch und damit kosteneffizient zu automatisieren.<br />

Zunächst sollten Fallbeispiele gewählt werden, bei denen eine Modularisierung<br />

besonders aussichtsreich, das heißt sowohl wirtschaftlich l<strong>ohne</strong>nd als auch<br />

technologisch zeitnah umsetzbar erscheint. Relativ frei – aus modularen (!)<br />

Untereinheiten – konfigurierbare Mehrzweckanlagen der Spezial- beziehungsweise<br />

Feinchemie sind in dieser Hinsicht besonders attraktiv. Wann es schließlich<br />

gelingt, auch komplexe verfahrenstechnische Einheiten modular zu betrachten<br />

und zu automatisieren, wird die Zukunft zeigen. Können Sie sich zum<br />

Beispiel jetzt bereits einen Cracker modularisiert vorstellen?<br />

TIM-PETER<br />

HENRICHS,<br />

Head of Industrial Automation<br />

Business Development,<br />

Yokogawa Deutschland GmbH<br />

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

5 / 2014<br />

3


INHALT 5 / 2014<br />

VERBAND<br />

6 | Verband der Chemischen <strong>Industrie</strong> begrüßt<br />

Kompromiss der EU bei der EEG-Umlage<br />

Erneuerbare-Energien-Gesetz (EEG):<br />

VDI sieht Belastung von Eigenstromerzeugern kritisch<br />

Seminar: <strong>Industrie</strong>lle Bildverarbeitung<br />

im Umfeld moderner Anforderungen<br />

7 | Konferenz „Industrial IT Security 2014“<br />

FORSCHUNG<br />

8 | Startschuss für „Ruhr Master School of<br />

Applied Engineering“ gefallen<br />

Achema-Kongress: Beiträge gesucht<br />

Call for Experts: Automation der Automation<br />

9 | Alexander Verl verantwortet seit Anfang April<br />

Technologie-Marketing bei Fraunhofer<br />

BRANCHE<br />

10 | BASF hört auf die guten Ideen von Mitarbeitern<br />

und spart 50 Millionen Euro ein<br />

VDE-Trendreport: Deutschland bleibt Innovationstreiber, aber…<br />

11 | Hannover Messe: SAG GmbH und Keba AG<br />

sichern sich <strong>Industrie</strong>preise<br />

RUBRIKEN<br />

3 | Editorial<br />

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

4<br />

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

5 / 2014


PRAXIS<br />

12 | Aus der Ferne warten:<br />

Stillstandzeiten verhindern und teure<br />

Vor-Ort-Einsätze vermeiden<br />

14 | Vöslauer Mineralwasser modernisiert<br />

die 40-Bar-Drucklufterzeugung<br />

16 | In der Sortier- und Verteiltechnik setzen<br />

Anwender auf individuelle Systemlösungen<br />

18 | Optimierter Brandschutz durch moderne<br />

Klappen mit angepasstem Stellantrieb<br />

20 | Dank Abwärmenutzung bei Gussteil-<br />

Herstellung vermindert Automobilzuliefer<br />

CO2-Emmissionen<br />

Produkte,<br />

Systeme<br />

und Service<br />

für die<br />

Prozessindustrie?<br />

Natürlich.<br />

HAUPTBEITRÄGE<br />

22 | <strong>Industrie</strong> <strong>4.0</strong> <strong>ohne</strong> <strong>modellbasierte</strong><br />

<strong>Softwareentwicklung</strong><br />

O. NIGGEMANN<br />

32 | Engineering-Effizienz<br />

automatisch messen<br />

R. DRATH, C. MESSINGER, B. SCHRÖTER, N. LI, G. GUTERMUTH<br />

42 | Redundanz für verfügbare Systeme<br />

T. GAMER, S. STATTELMANN<br />

54 | Schutzzielorientiertes Design<br />

der Sicherheitsleittechnik<br />

Y. DING<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 />

maßgeschneiderte Leitsysteme<br />

sowie erstklassigen Service bietet?<br />

Lesen Sie mehr unter:<br />

www.abb.de/<br />

prozessautomatisierung<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 />

UTZ TILLMANN,<br />

Hauptgeschäftsführer<br />

des Verbandes<br />

der Chemischen<br />

<strong>Industrie</strong> begrüßt<br />

die Entlastung<br />

energie intensiver<br />

Branchen im EU-<br />

Kompromiss. Bild: VCI<br />

Verband der Chemischen <strong>Industrie</strong> begrüßt<br />

Kompromiss der EU bei der EEG-Umlage<br />

Ohne den jetzigen Kompromiss<br />

hätten unsere Unternehmen<br />

eine bis zu 25-fache Mehrbelastung<br />

im Vergleich zu heute schultern<br />

müssen. Dies hätte ihrer Wettbewerbsfähigkeit<br />

massiv geschadet“,<br />

sagt Utz Tillmann, Hauptgeschäftsführer<br />

des Verband der Chemischen<br />

<strong>Industrie</strong> e.V (VCI). In einer<br />

Erklärung des Verbandes vom<br />

8. April 2014.<br />

Umso erfreulicher ist für ihn die<br />

Entscheidung der EU zur Entlastung<br />

energieintensiver Branchen.<br />

Der Verband der Chemischen <strong>Industrie</strong> sieht im von<br />

Bundeswirtschaftsminister Gabriel verkündeten Kompromiss<br />

mit der EU zu den Beihilfeleitlinien einen<br />

großen Schritt zum Erhalt der Wettbewerbsfähigkeit<br />

der Branche. „Das Ergebnis ist ein wichtiger politischer<br />

Erfolg für den Chemiestandort Deutschland.<br />

Viele Arbeitsplätze in der drittgrößten <strong>Industrie</strong>branche<br />

wurden gesichert, indem die extrem hohen Zusatzbelastungen<br />

abgewendet sind, wie die EU sie geplant<br />

hatte“, so Tillmann weiter. Tillmann äußerte sich<br />

auch positiv zu den Vorgaben im Kabinettsentwurf,<br />

nach denen für die industrielle Eigenstromerzeugung<br />

weiter der volle Bestandsschutz gilt. Für die Chemie<br />

verbleiben unter anderem beim Thema Neuanlagen<br />

noch Unsicherheiten, die im parlamentarischen Verfahren<br />

gelöst werden sollten.<br />

(ahü)<br />

VERBAND DER CHEMISCHEN INDUSTRIE E.V. (VCI),<br />

Mainzer Landstraße 55,<br />

D-60329 Frankfurt am Main,<br />

Tel. +49 (0) 69 255 60, Internet: www.vci.de<br />

Erneuerbare-Energien-Gesetz (EEG): VDI sieht<br />

Belastung von Eigenstromerzeugern kritisch<br />

Kritisch hingegen sieht der VDI (Verband Deutscher<br />

Ingenieure) die Pläne der Bundesregierung, Eigenstromerzeuger<br />

künftig an der EEG-Umlage zu beteiligen.<br />

„Die Belastungen gefährden die Wirtschaftlichkeit<br />

neuer Anlagen. Sie stellen damit das Erreichen<br />

der Ausbauziele für die erneuerbaren Energien in<br />

Frage, <strong>ohne</strong> dass durch die Beteiligung die Stromkosten<br />

für Endverbraucher sinken würden“, sagt Ralph<br />

Appel, Direktor des VDI.<br />

Zudem trage der Gesetzentwurf dem Systemgedanken<br />

ungenügend Rechnung. „Das EEG ist bislang darauf<br />

ausgerichtet, durch Anreize die Technologieentwicklung<br />

zu unterstützen“, so Appel. Um die Effizienz des<br />

Energiesystems zu erhöhen, müssen systemische Zusammenhänge<br />

stärker berücksichtigt und die einzelnen<br />

Energiemärkte und -technologien besser miteinander<br />

vernetzt werden. Vor allem die Entwicklung und der<br />

Ausbau der Netze sowie der Speicher, die zentrale und<br />

dezentrale Energieerzeugung, das Lastmanagement sowie<br />

die Kopplung des Strom- mit anderen Energiesystemen,<br />

wie Gas- und Wärmenetze, sollen besser aufeinander<br />

abgestimmt werden.<br />

(ahü)<br />

VDI VEREIN DEUTSCHER INGENIEURE E.V. (VDI),<br />

VDI-Platz 1, D-40468 Düsseldorf,<br />

Tel. +49 (0) 211 621 40,<br />

Internet: www.vdi.de<br />

6<br />

Seminar: <strong>Industrie</strong>lle Bildverarbeitung<br />

im Umfeld moderner Anforderungen<br />

Einsatz- und Anwendungsmöglichkeiten, Anforderungen,<br />

Grundlagen und Entwicklungen der industriellen<br />

Bildverarbeitung stehen im Mittelpunkt des<br />

Seminars zur industriellen Bildverarbeitung am<br />

8. und 9. Mai 2014 in Frankfurt am Main. Wie sie<br />

Rationalisierungsdruck, 100-Prozent-Kontrolle und<br />

Rückverfolgbarkeit für Ihre Produkte gewährleisten<br />

können, vermittelt das Seminar. Danach wissen sie<br />

mit welchen etablierten Methoden der Bildverarbeitung<br />

Sie Prüfaufgraben lösen können und welchen<br />

Einfluss das Zusammenspiel der einzelnen System-<br />

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

5 / 2014<br />

komponenten und die Datenübertragung auf die Güte<br />

der Bildverarbeitungslösung haben. Die Leitung der<br />

Tagung übernehmen Prof. Dr. Christoph Heckenkamp<br />

und Prof. Dr. Thomas Netzsch.<br />

(ahü)<br />

VDI WISSENSFORUM GMBH,<br />

Kundenzentrum, Postfach 10 11 39,<br />

D-40002 Düsseldorf, Tel. +49 (0) 211 621 42 01,<br />

E-Mail: wissensforum@vdi.de,<br />

Internet: www.vdi-wissensforum.de


Konferenz „Industrial<br />

IT Security 2014“<br />

EINE<br />

AUSSTELLUNG<br />

begleitet die<br />

Fachkonferenz<br />

am 7. und 8.<br />

Mai 2014.<br />

Bild: VDI<br />

Wie können Sie verhindern, dass Malware oder<br />

Cyberangriffe Ihre Produktion lahmlegen?<br />

Dazu will die 2. VDI-Fachkonferenz „Industrial IT<br />

Security 2014“ am 7. und 8. Mai 2014 in Frankfurt<br />

am Main Antworten liefern. Fachexperten von <strong>Industrie</strong>,<br />

Verband und Politik referieren aus ihrer<br />

Alltagspraxis. Holger Junker vom Bundesamt für<br />

Sicherheit in der Informationstechnik (BSI) informiert<br />

zur Eröffnung über den korrekten Schutz der<br />

Anlage. Unter der Leitung von Prof. Dr. Michael<br />

Waidner vom Fraunhofer-Institut für Sichere Informationstechnologie<br />

SIT werden danach Fragen<br />

beantwortet, wie etwa:<br />

Wie erkennen Sie die Bedrohungen und<br />

Schwachstellen Ihres Produktionsnetzwerkes?<br />

Was für Chancen und Risiken bietet <strong>Industrie</strong><br />

<strong>4.0</strong> für Ihre Produktion?<br />

Was können Normen zur Sicherheit Ihrer<br />

Produktions- und Automatisierungssysteme<br />

beitragen?<br />

Welche wirkungsvollen Schutzmaßnahmen<br />

und Lösungsansätze gibt es?<br />

Am Vortag der Konferenz finden der Spezialtag<br />

„Rechtsfragen der IT-Sicherheit in Produktionsumgebungen“<br />

sowie der Spezialtag „IT-Sicherheit in<br />

der <strong>Industrie</strong> – Erste-Hilfe-Kurs gegen Cyberbedrohungen“<br />

statt. Am nachfolgenden Tag „<strong>Industrie</strong>lle<br />

IT-Sicherheit – Gefahren und Schutzmöglichkeiten“<br />

bietet sich ebenfalls die Möglichkeit zur<br />

Weiterbildung.<br />

(ahü)<br />

VDI WISSENSFORUM GMBH,<br />

Kundenzentrum, Postfach 10 11 39,<br />

D-40002 Düsseldorf, Tel. +49 (0) 211 621 42 01,<br />

E-Mail: wissensforum@vdi.de,<br />

Internet: www.vdi.de/IT-Security


FORSCHUNG<br />

Startschuss für „Ruhr Master School of<br />

Applied Engineering“ gefallen<br />

Der Startschuss für den Aufbau einer gemeinsamen<br />

Masterausbildung im Ingenieurbereich der Fachhochschule<br />

Dortmund, der Hochschule Bochum und<br />

der Westfälischen Hochschule in Gelsenkirchen ist<br />

gefallen. Ziel der künftigen „Ruhr Master School of<br />

Applied Engineering“ der drei Hochschulen ist es, ein<br />

abgestimmtes regionales Portfolio von 10 bis 15 technisch<br />

orientierten Masterstudiengängen aufzulegen.<br />

Prof. Dr. Carsten Wolff, Prorektor für Studium, Lehre<br />

und Internationales der Fachhochschule Dortmund,<br />

entwickelte das Konzept mit und sieht die Partner damit<br />

auf einem zukunftsorientierten Weg: „Die drei<br />

Ruhr-Fachhochschulen wollen sich in der Masterausbildung<br />

durch ein enges Andocken an den Wissenschaftsbereich<br />

neu positionieren. Unser Ziel ist der<br />

Transfer von neuesten wissenschaftlichen Erkenntnissen<br />

in die Anwendung.“ Am Ende der gemeinsamen<br />

Ausbildung stehen Ingenieure mit hoher Anwendungskompetenz.<br />

Zum Angebot können auch englischsprachige<br />

und berufsbegleitende Formate gehören. Typische<br />

Achema-Kongress: Beiträge gesucht<br />

Themen für künftige Studienangebote ergeben sich aus<br />

den Profilen der Hochschulen: Nachhaltige Energieversorgung,<br />

Sicherheit in der Kommunikation und medizintechnische<br />

Anwendungen sind Beispiele für spezialisierte<br />

Master-Angebote.<br />

Ein Rahmenprogramm mit Schlüsselkompetenzen,<br />

Internationalität, Projekten und Summer Schools soll das<br />

Portfolio ergänzen und abrunden. Leisten soll die Kooperation<br />

vor allem den vereinfachten Übergang aus den<br />

Bachelorstudiengängen der beteiligten Hochschulen in<br />

Masterstudiengänge der „Ruhr Master School“. Gemeinsam<br />

können die Hochschulen außerdem die Vielfalt der<br />

Masterstudiengänge steigern, da sich dann auch für eher<br />

spezialisierte Masterstudiengänge genügend Interessenten<br />

finden. Die Stiftung Mercator unterstützt das Projekt<br />

mit einer Fördersumme von 750 000 Euro. (ahü)<br />

FACHHOCHSCHULE DORTMUND,<br />

Sonnenstraße 96, D-44139 Dortmund,<br />

Tel. +49 (0) 231 911 20, Internet: www.fh-dortmund.de<br />

Beiträge zu den Themen Energiewende, Globalisierung,<br />

Öko- und Prozesseffizienz oder Bioökonomie<br />

mit Praxisbezug zur <strong>Industrie</strong> sucht der Achema-Kongress<br />

für 2015. Die Themengebiete Innovative Prozessanalytik,<br />

<strong>Industrie</strong>lles Wassermanagement und Biobased<br />

World stehen dabei besonders im Mittelpunkt.<br />

Mit etwa 800 Vorträgen bietet der Achema-Kongress<br />

den Überblick über die Bandbreite der Prozesstechnik<br />

ab. Mit rund 3800 Aussteller aus über 50 Ländern und<br />

etwa 170 000 Besucher ist nach Angaben des Veranstalters<br />

Dechema zu rechnen. Die Achema findet vom 15.<br />

bis 19. Juni 2015 in Frankfurt am Main statt. (ahü)<br />

DECHEMA AUSSTELLUNGS-GMBH,<br />

Theodor-Heuss-Allee 25, D-60486 Frankfurt am Main,<br />

Tel. +49 (0) 69 756 41 00, Internet: www.achema.de/congress<br />

Call for <strong>atp</strong> experts: Automation der Automation<br />

DIE AUSGABE 56(11) DER ATP EDITION<br />

widmet sich dem Thema Automation<br />

der Automation. Größere Anlagen, höhere<br />

Auflagen, mehr Iterationen, weniger<br />

Personal und weniger Zeit sind aktuelle<br />

Herausforderungen für die Automation.<br />

In bestimmten Branchen und Projekten<br />

kann dieser Teufelskreis durch Automation<br />

der Automation durchbrochen werden.<br />

Erste erfolgreiche Ansätze sind in<br />

Gebäude-, Fertigungs- und Prozessautomation<br />

zu beobachten. In Ausgabe<br />

56(11) diskutieren wir Lösungs-ansätze,<br />

praktische Erfahrungen, Widerstände<br />

und Projekterfolge in Theorie und Praxis.<br />

Wir bitten Sie bis zum 5. Juli 2014 zu diesem<br />

Themenschwerpunkt einen gemäß<br />

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

ausgearbeiteten Hauptbeitrag per E-Mail<br />

an urbas@di-verlag.de einzureichen.<br />

Die <strong>atp</strong> <strong>edition</strong> ist die hochwertige Monatspublikation<br />

für Fach- und Führungskräfte<br />

der Automatisierungsbranche. In<br />

den Hauptbeiträgen werden die Themen<br />

mit hohem wissenschaftlichem und technischem<br />

Anspruch und vergleichsweise<br />

abstrakt dargestellt. Im Journalteil werden<br />

praxisnahe Erfahrungen von Anwendern<br />

mit neuen Technologien, Prozessen<br />

oder Produkten beschrieben.<br />

Alle Beiträge werden von einem Fachgremium<br />

begutachtet. Sollten Sie sich selbst<br />

aktiv an dem Begutachtungsprozess beteiligen<br />

wollen, bitten wir um kurze<br />

Rückmeldung. Für weitere Rückfragen<br />

stehen wir Ihnen selbstverständlich gerne<br />

zur Verfügung.<br />

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

Leon Urbas, Aljona Hartstock<br />

CALL FOR<br />

Aufruf zur Beitragseinreichung<br />

Thema: Automation der Automation<br />

Kontakt: urbas@di-verlag.de<br />

Termin: 05. Juli 2014<br />

8<br />

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

5 / 2014


Alexander Verl verantwortet seit Anfang April<br />

Technologie-Marketing bei Fraunhofer<br />

Prof. Alexander Verl, Institutsleiter des Fraunhofer<br />

Instituts für Produktionstechnik und Automatisierung<br />

IPA, tritt am 1. April 2014 sein Amt als Vorstand<br />

Technologiemarketing und Geschäftsmodelle bei der<br />

Fraunhofer-Gesellschaft an. Ziel des neu geschaffenen<br />

Postens soll es sein, die Interessen von bestimmten<br />

Branchen zu bündeln und diese mit dem Leistungsportfolio<br />

von Fraunhofer abzugleichen, um konkrete<br />

Angebote zu entwickeln.<br />

Prof. Dr.-Ing. Alexander Verl (1966) startete nach seinem<br />

Studium der Elektrotechnik als Entwicklungsingenieur<br />

bei Siemens ins Berufsleben. Seine Dissertation<br />

zur nichtlinearen Gelenkregelung eines Leichtbauroboters<br />

schrieb er am DLR-Institut für Robotik und<br />

Systemdynamik. Er gründete 1997 die Amatec Robotics,<br />

die er acht Jahre als Geschäftsführer und Gesellschafter<br />

leitete. 2005 wurde seine Firma als Tochterunternehmen<br />

von der Kuka Roboter GmbH übernommen.<br />

Die von ihm maßgeblich entwickelte Inline-Messtechnik<br />

für den Karosseriebau ist heute weltweit bei<br />

vielen Autobauern im Einsatz.<br />

Nach der Selbstständigkeit wurde Alexander Verl<br />

2005 Direktor am Institut für Steuerungstechnik der<br />

Werkzeugmaschinen und Fertigungseinrichtungen<br />

ISW der Universität<br />

Stuttgart. 2006 trat er am<br />

Fraunhofer IPA die Nachfolge von<br />

Prof. Dr.-Ing. Rolf-Dieter Schraft<br />

an und leitete das Institut bis zu<br />

seinem Wechsel in den Fraunhofer-<br />

Vorstand seit 2011 gemeinsam mit<br />

Prof. Dr.-Ing. Thomas Bauernhansl.<br />

An der Universität Stuttgart<br />

hatte Verl auch den Vorstandsvorsitz<br />

der Graduiertenschule für Advanced<br />

Manufacturing Engineering<br />

in Stuttgart inne, einem Promotionsprogramm<br />

innerhalb der<br />

Exzellenzinitiative des Bundes<br />

und der Länder.<br />

(ahü)<br />

ALEXANDER VERL<br />

ist seit dem 1. April<br />

2014 im Vorstand der<br />

Fraunhofer-Abteilung<br />

Technologiemarketing<br />

und Geschäftsmodelle.<br />

Bild: Fraunhofer-Gesellschaft<br />

ZENTRALE DER FRAUNHOFER-GESELLSCHAFT,<br />

Hansastraße 27c, D-80686 München,<br />

Tel. +49 (0) 89 12 05 40 00,<br />

Internet: www.fraunhofer.de<br />

E I N L A D U N G<br />

Messtechnik Regeltechnik Steuerungstechnik Prozessleitsysteme<br />

Mittwoch, 4. Juni 2014<br />

8:00 bis 16:00 Uhr<br />

Smidt-Arena<br />

Bismarckstraße 125<br />

51373 Leverkusen<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 />

5 / 2014<br />

9


BRANCHE<br />

BASF hört auf die guten Ideen von Mitarbeitern<br />

und spart 50 Millionen Euro ein<br />

DAS TEAM in einem BASF-Betrieb zur Pflanzenschutzmittelherstellung<br />

optimierte den Produktionsprozess, sodass rund<br />

1,5 Millionen Euro gespart werden konnten. Bild: BASF<br />

Knapp 50 Millionen Euro gespart hat die BASF, weil<br />

sie Ideen ihrer Mitarbeiter umgesetzt hat. Im vergangenen<br />

Jahr sind nach Angaben des Konzerns weltweit<br />

23 000 Verbesserungsvorschläge umgesetzt worden. Insgesamt<br />

hatten die Mitarbeiter 42 000 Ideen eingereicht.<br />

In Ludwigshafen seien insgesamt 31 Millionen Euro<br />

durch gute Ideen eingespart worden.<br />

Das Team eines Betriebs, der Wirkstoffe für Pflanzenschutzmittel<br />

herstellt, hat beispielsweise mit drei aufeinander<br />

folgenden Ideen insgesamt 1,5 Millionen Euro<br />

gespart. In der Anlage werden zwei Produkte hergestellt,<br />

eins im Winter und ein anderes im Sommer. Bei<br />

jeder Produktionsumstellung muss die Anlage aus Qualitätsgründen<br />

gereinigt werden. Bisher dauerte die Umstellung<br />

etwa sechs Wochen. Vor zwei Jahren nahmen<br />

die Mitarbeiter schichtübergreifend alle Prozesse unter<br />

die Lupe: Abwasseraufbereitung, Aufwärm- und Abkühlprozesse,<br />

Stoffkreisläufe sowie Fahrweisen. Ihre<br />

Verbesserungsideen setzten sie nach und nach um. Jetzt<br />

dauert die Umstellung nur noch zwei statt sechs Wochen<br />

und es werden größere Mengen der beiden Produkte<br />

hergestellt. Viel Zeit wurde zum Beispiel beim<br />

Überprüfen der gesäuberten Behälter auf Rückstände<br />

gespart. Dank eines eigenen Geräts werden die Proben<br />

jetzt direkt im Betrieb analysiert und das Warten auf<br />

die Ergebnisse aus dem Zentrallabor fällt weg. Außerdem<br />

sorgt ein Umstellungskoordinator für einen reibungslosen<br />

Ablauf des Gesamtprozesses. „Er arbeitet<br />

schichtübergreifend und ist Ansprechpartner für alle<br />

beteiligten Mitarbeiter und Gewerke. Dadurch werden<br />

die vielen verschiedenen Aktivitäten besser koordiniert<br />

und effizient umgesetzt“, sagt Dr. Harald Bernard, Leiter<br />

des Betriebes. Für die Gesamtleistung bekam das<br />

Team 130 000 Euro Prämie.<br />

(ahü)<br />

BASF SE,<br />

Carl-Bosch-Str. 38, D-67056 Ludwigshafen,<br />

Tel. +49 (0) 621 600, Internet: www.basf.com<br />

VDE-Trendreport: Deutschland<br />

bleibt Innovationstreiber, aber…<br />

ENERGIEEFFIZIENZ<br />

ist eines der Trendthemen,<br />

die Deutschland<br />

zum weltweiten<br />

Innovationstreiber<br />

macht.<br />

Bild: Rainer Sturm/pixelio.de<br />

Die diesjährigen Ergebnisse des Trendreports vom<br />

Verband der Elektrotechnik Elektronik Informationstechnik<br />

e.V. (VDE) sind da. Die Befragung unter<br />

1300 VDE-Mitgliedsunternehmen und Hochschulen<br />

ergab, dass Deutschland Innovationsführer im Bereich<br />

der Elektrotechnik bleibt. Treiber in der Entwicklung<br />

seien, nach Angaben des Verbandes Anfang<br />

April, Energieeffizienz und intelligente Stromnetze,<br />

Elektromobilität, Medizintechnik sowie <strong>Industrie</strong> <strong>4.0</strong>.<br />

Weiterhin wurde festgestellt, dass Unternehmen der<br />

Elektro- und IT-Branche 2014 ihre Investitionen in<br />

Forschung und Entwicklung auf hohem Niveau halten<br />

oder sogar erhöhen. Berufsperspektiven für Elektroingenieure<br />

bleiben weiterhin gut.<br />

Allerdings nehme der Wettbewerb um die besten<br />

Köpfe zu. Unternehmen und Hochschulen bemängeln<br />

personelle Engpässe. Sechs von zehn Befragten kritisieren<br />

die Ausstattung von Forschung und Lehre und<br />

befürworten Bürokratieabbau.<br />

(ahü)<br />

VDE-VERBANDSGESCHÄFTSSTELLE,<br />

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

Tel. +49 (0) 69 630 80,<br />

Internet: www.vde.de<br />

10<br />

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

5 / 2014


Hannover Messe: SAG GmbH und Keba AG<br />

sichern sich <strong>Industrie</strong>preise<br />

Kanzlerin Angela Merkel warnte zur Eröffnung der<br />

diesjährigen Hannover Messe am 6. April 2014 davor,<br />

dass Deutschland im internationalen Wettbewerb<br />

der <strong>Industrie</strong> abgehängt werden könnte. Gegen diesen<br />

vermeintlichen Trend steuern die Veranstalter der internationalen<br />

<strong>Industrie</strong>messe mit der Verleihung des<br />

Hermes Awards. Außerdem wurde auf der Hannover<br />

Messe der Robotics Award vergeben. Die Keba AG sicherte<br />

sich mit einem neuartigen Roboterbediengerät<br />

den ersten Platz im Wettbewerb für angewandte Roboterlösungen<br />

vor der Fanuc Deutschland GmbH. In<br />

diesem Jahr wurde der Technologiepreis Hermes<br />

Award an die SAG GmbH übergeben.<br />

Die SAG GmbH erhält die Auszeichnung für ihr intelligentes<br />

Verteilnetzmanagement, mit dem ein konventionelles<br />

Niederspannungsnetz schrittweise zu<br />

einem Smart Grid umgerüstet werden kann. Die modulare,<br />

dezentrale und autarke Mess- und Regelsystemplattform<br />

besteht aus einer dezentralen Netzzustandserfassung<br />

unter Einbeziehung dezentraler intelligenter<br />

Software-Agenten. Die Einspeise- und Lastflusssituationen<br />

werden in Echtzeit kontrolliert. Bei Bedarf werden<br />

kritische Abweichungen durch Regelung der im<br />

Netz vorhandenen Betriebsmittel sowie der eingebundenen<br />

Erzeuger und Verbraucher ausgeglichen. So können<br />

in drei Ausbauschritten vom Stationsmonitoring<br />

über das Netzmonitoring bis hin zur Netzautomatisierung<br />

mit Ines vorhandene Netzkapazitäten optimal<br />

genutzt werden.<br />

Prof. Johanna Wanka, Bundesministerin für Bildung<br />

und Forschung, überreichte den Hermes Award am<br />

Sonntag vor der Messe-Eröffnung. „Die Energiewende<br />

ist ein gesamtgesellschaftliches Großprojekt. Für die<br />

erfolgreiche Umsetzung sind wegweisende Innovationen<br />

für einen intelligenten Netzumbau von großer<br />

Bedeutung, da sie Umwelt und Ressourcen schonen“,<br />

so die Ministerin in ihrer Laudatio anlässlich der Preisverleihung.<br />

„Das Votum der Jury war einstimmig. Dabei hat uns<br />

neben der technologischen Lösung auch der wirtschaftliche<br />

Aspekt überzeugt, da aufgrund der verbesserten<br />

Auslastung der bestehenden Netze auf einen Teil des<br />

kostenintensiven Netzausbaus verzichtet werden kann,<br />

<strong>ohne</strong> die Netzstabilität zu gefährden“, ergänzte Prof.<br />

Wolfgang Wahlster, Vorsitzender der Jury und Vorsitzender<br />

der Geschäftsführung des Deutschen Forschungszentrums<br />

für Künstliche Intelligenz (DFKI).<br />

Neben dem Gewinner SAG GmbH (Langen) waren<br />

auch die Bürkert Werke GmbH & Co. KG (Ingelfingen),<br />

KHS GmbH (Dortmund), Phoenix Contact GmbH & Co.<br />

KG (Blomberg), und Sensitec GmbH (Lahnau) nominiert.<br />

Der Gewinner des Robotics Award 2014 ist die Keba AG.<br />

Sie sicherte sich mit einem Roboterbediengerät den ersten<br />

Platz im Wettbewerb für angewandte Roboterlösungen vor<br />

der Fanuc Deutschland GmbH. Nachdem in diesem Jahr<br />

vier statt der üblichen drei Nominierten in das Rennen<br />

um den Award gingen, wurde erstmals der dritte Platz<br />

doppelt vergeben: Platz drei teilen sich die Robert Bosch<br />

GmbH sowie die Continental Reifen Deutschland GmbH<br />

gemeinsam mit Preccon Robotics GmbH. Niedersachsens<br />

Wirtschaftsminister Olaf Lies überreichte die Preise am<br />

Dienstag während der Hannover Messe. (ahü)<br />

DEUTSCHE MESSE AG,<br />

Messegelände, D-30521 Hannover,<br />

Tel. +49 (0) 511 890,<br />

Internet: www.hannovermesse.de<br />

DIE SAG GMBH<br />

gewann den Hermes<br />

Award auf der<br />

Hannover Messe<br />

2014. Er wurde<br />

überreicht von<br />

Johanna Wanka<br />

(rechts).<br />

Bild: Deutsche Messe<br />

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

5 / 2014<br />

11


PRAXIS<br />

Aus der Ferne warten: Stillstandzeiten verhindern<br />

und teure Vor-Ort-Einsätze vermeiden<br />

Internetbasierte Fernwartung bei weltweit 100 Rundtakt-Maschinen erfolgreich etabliert<br />

TOBIAS HALBRITTER aus dem<br />

Bereich Maschinen-IT und Software-<br />

Entwicklung ist für das Teleservice-<br />

System verantwortlich.<br />

DER IM SCHALTSCHRANK installierte<br />

Security-Router FL MGuard RS4000<br />

TX/TX VPN sorgt für sichere<br />

VPN-Verbindungen.<br />

DIE K.R. PFIFFNER GMBH stellt<br />

Rundtaktmaschinen zur Massenfertigung<br />

von Präzisionsteilen her.<br />

DIE PORTAL-STRUKTUR<br />

des Fernwartungssystems<br />

ermöglicht die einfache<br />

Anbindung von<br />

Zulieferunternehmen.<br />

DIE TELE-<br />

SERVICE-BOX<br />

dient zur<br />

temporären<br />

VPN-Anbindung<br />

von Kundenanlagen.<br />

Bilder: Phoenix<br />

Contact<br />

Alle 3 bis 60 Sekunden, je nach Komplexität, verlässt<br />

ein Werkstück die Rundtaktmaschine der K.R. Pfiffner<br />

GmbH. Um den reibungslosen Produktionsprozess<br />

mit hoher Verfügbarkeit sicherzustellen, ist ein 24-Stunden-Service<br />

des Maschinenbauers nötig. Nur so können<br />

im Fehlerfall schnell entsprechende Maßnahmen ergriffen<br />

werden, damit die Bearbeitungszentren nur für<br />

kurze Zeit außer Betrieb sind. Den sicheren Fernzugriff<br />

ermöglicht nun ein Security Router der Phoenix Contact<br />

Electronics GmbH.<br />

GUTE ERFAHRUNGEN MIT DER<br />

MGUARD-TECHNOLOGIE<br />

Die Rundtaktmaschinen produzieren jeweils mehr als<br />

300 000 Werkstücke pro Jahr. Die Stücke können faustgroß<br />

werden. 450 weltweit tätige Mitarbeiter des zur<br />

Pfiffner-Gruppe mit Sitz im schweizerischen Thalwil<br />

gehörenden Unternehmens stellen die Bearbeitungszentren<br />

her. Diese werden beispielsweise zur Massenfertigung<br />

von Präzisionsteilen für die Automobil-<strong>Industrie</strong><br />

verwendet. Beispiele bilden Einspritzsysteme<br />

oder Turbolader.<br />

„Ursprünglich wurde die Fernwartung durch analoge<br />

Modem-Verbindungen realisiert. Allerdings hat die<br />

Performance nicht mehr unseren Anforderungen genügt.<br />

Außerdem traten oft Verbindungsprobleme auf“,<br />

sagt Tobias Halbritter, der das Fernwartungssystem bei<br />

Pfiffner betreut und maßgeblich für die umgesetzte<br />

Struktur auf Basis sicherer VPN-Verbindungen (Vir tual<br />

Private Network) verantwortlich ist. Das Kernelement<br />

des neuen Fernwartungskonzepts ist der Security-Router<br />

FL MGuard RS4000 TX/TX VPN von Phoenix<br />

Contact, der in den Bearbeitungszentren verbaut ist.<br />

„Da wir die MGuard-Technologie mit integrierter Firewall-Funktionalität<br />

bereits zur Ankopplung unserer<br />

Anlagen an das Kundennetz nutzen, war es nur folgerichtig,<br />

dass wir das Gerät auch für den sicheren Fernzugriff<br />

einsetzen“, erklärt Halbritter.<br />

12<br />

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

5 / 2014


REDUZIERUNG DER WARTUNGSKOSTEN<br />

Die Vorteile des Internet-basierten Fernzugriffs: Für<br />

den Service-Techniker verhält sich die VPN-Verbindung<br />

so, als ob er direkt vor der Anlage sitzen würde.<br />

Das verkürzt die Reaktionszeiten im Wartungsfall<br />

deutlich. Darüber hinaus ist ein Vor-Ort-Einsatz<br />

meist nicht mehr notwendig, sodass erhebliche Wartungskosten<br />

eingespart werden. Auf diese Weise<br />

rechnen sich die Investitionen in die Teleservice-<br />

Lösung schnell.<br />

Falls der Service-Techniker doch einmal zum Kunden<br />

reisen muss, kann er seine Arbeit deutlich besser<br />

vorbereiten. „Ein häufig bei uns auftretendes Problem<br />

sind die Sprachbarrieren zwischen unseren Mitarbeitern<br />

und dem Personal des zum Teil auch im Ausland<br />

ansässigen Anwenders, weshalb Fehlermeldungen des<br />

Steuerungssystems oftmals falsch oder unvollständig<br />

kommuniziert werden. Durch den Direktzugriff auf die<br />

Meldungslisten entfallen diese Probleme“, erläutert<br />

Roland Schneider, Leiter der Elektrokonstruktion.<br />

KONTROLLE ÜBER DEN NETZWERKZUGANG<br />

Aktuell sind 100 Maschinen sowie mehr als 25 Service-<br />

Techniker in das System eingebunden. Durch das Betätigen<br />

eines Schlüsselschalters initiiert der Anwender<br />

im Wartungsfall den Aufbau des IPsec-Tunnels zum<br />

Pfiffner Remote Services Center. Anschließend hat der<br />

Wartungstechniker Zugriff auf die Anlage. Der Betreiber<br />

behält die Kontrolle über den Zugang zur Anwendung,<br />

was die Akzeptanz der Technologie steigerte.<br />

Der optionale externe Konfigurationsspeicher des<br />

FL MGuard erweist sich ebenfalls als hilfreich. Da die<br />

Pfiffner-Mitarbeiter die IP-Parameter des Kundennetzes<br />

im Vorfeld der Maschinenauslieferung noch nicht kennen,<br />

lässt sich die Konfiguration nachträglich per SD-<br />

Karte übertragen, <strong>ohne</strong> dass das Personal des Anwenders<br />

über spezielle Kenntnisse verfügen muss. Das gilt<br />

auch für den einfachen Gerätetausch im Fehlerfall.<br />

mit hier kein Adresskonflikt entsteht, wenn mehrere<br />

Rundtaktmaschinen gleichzeitig gewartet werden sollen,<br />

müssen die Adressen virtualisiert respektive in<br />

eigenständigen Adressbereichen abgebildet werden.<br />

So ist wieder für eine Eindeutigkeit gesorgt. Diese Anforderung<br />

wird in den MGuard-Routern durch 1:1-<br />

NAT (Network Address Translation) im VPN-Tunnel<br />

umgesetzt.<br />

TELESERVICE-BOX FÜR TEMPORÄRE ZUGRIFFE<br />

Weltweit sind rund 2 500 Pfiffner-Rundtaktmaschinen<br />

in Betrieb, wobei die meisten Anlagen netzwerktechnisch<br />

noch nicht erreichbar sind. Um im Service-<br />

Fall oder bei Umrüstarbeiten auch hier einen Fernzugriff<br />

zwecks Unterstützung des Technikers vor Ort zu<br />

ermöglichen, hat der Maschinenbauer eine Teleservice-Box<br />

entwickelt. Die Box umfasst zusätzlich zum<br />

Security-Router FL MGuard einen WLAN-Router FL<br />

WLAN 5100 von Phoenix Contact. Somit kann die<br />

temporäre Internet-Anbindung der Maschine entweder<br />

über Ethernet-Patchkabel oder durch Ankopplung<br />

an ein kundenseitiges WLAN-Netzwerk realisiert<br />

werden. Nach der Beendigung des Service-Einsatzes<br />

wird die Box einfach an den nächsten Wartungsort<br />

mitgenommen.<br />

FAZIT<br />

Die Verwendung einer Internet-basierten Fernwartung<br />

mit sicheren VPN-Verbindungen bringt sowohl dem<br />

Hersteller als auch dem Betreiber der Pfiffner-Bearbeitungszentren<br />

Vorteile. Dazu zählt neben der schnelleren<br />

Reaktion im Fehlerfall durch den direkten Zugriff<br />

auf die Anlage und damit der Minimierung von Stillstandzeiten<br />

ebenfalls die Reduzierung der Service-<br />

Kosten, weil kostspielige Einsätze vor Ort entfallen.<br />

Dies sind Kriterien, die insbesondere bei der Massenteil-Fertigung<br />

durch die Rundtaktmaschinen eine entscheidende<br />

Rolle spielen.<br />

ZUGRIFF BESCHRÄNKT AUF BESTIMMTE<br />

ANLAGENTEILE<br />

Die VPN-Zentrale ist bewusst nicht in das Pfiffner-<br />

Unternehmensnetzwerk integriert, sondern wird als<br />

Portal-System mit eigenem Internet-Zugang betrieben.<br />

So kann Pfiffner externen Zulieferern den sicheren Zugriff<br />

auf Teile der entsprechenden Kundenanlage einräumen,<br />

<strong>ohne</strong> diesen durch das eigene Kommunikationsnetz<br />

zu tunneln. Die Security-Funktion des<br />

MGuard-Routers – insbesondere die frei konfigurierbare<br />

Firewall innerhalb des VPN-Tunnels – erlaubt selektive<br />

Zugriffsbeschränkungen auf bestimmte Teile<br />

der Bearbeitungszentren.<br />

Aus netzwerktechnischer Sicht sind die Kundenanlagen<br />

mit identischen Adressbereichen konfiguriert.<br />

Das hat den Vorteil, dass sich einzelne Anlagenteile<br />

stets mit der gleichen IP-Adresse erreichen lassen. Da-<br />

AUTOR<br />

Dipl.-Ing. (FH) MICHAEL VETTER ist<br />

Technical Sales Network & Security bei<br />

Phoenix Contact in Blomberg.<br />

Phoenix Contact Deutschland GmbH,<br />

Flachsmarktstraße 8, D-32825 Blomberg,<br />

Tel. +49 (0) 5235 31 20 00,<br />

E-Mail: info@phoenixcontact.de<br />

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

5 / 2014<br />

13


PRAXIS<br />

Vöslauer Mineralwasser modernisiert<br />

die 40-Bar-Drucklufterzeugung<br />

Steuerung wählt die günstigste Kompressorkombination<br />

DIE GETRÄNKE-<br />

INDUSTRIE<br />

erwartet 2014 ein<br />

starkes Wachstum im<br />

Volumen.<br />

Bild: Comp Air<br />

NACH UNTER-<br />

SUCHUNGEN<br />

VON COMPAIR<br />

verbrauchen diese<br />

PET-Kompressoren<br />

mindestens 5 %<br />

weniger Energie als<br />

vergleichbare<br />

Verdichter.<br />

Bild: Comp Air<br />

DIPL.-ING. HERBERT SCHLOSSNIKL,<br />

Vostand Produktion, Technik bei der Vöslauer<br />

Mineralwasser: „Bis 2018 haben wir hier<br />

keinen Modernisierungsbedarf, und wenn<br />

der Bedarf überproportional wachsen sollte,<br />

können wir einfach den Redundanzkompressor<br />

zuschalten.“ Bild: Vöslauer<br />

Für die Getränkeindustrie war der Sommer 2013<br />

erfolgreich. Speziell die Mineralbrunnenunternehmen<br />

hatten allen Grund zur Freude bei einem Plus von<br />

30 % bereits im Juli 2013. Auch 2012 haben die Deutschen<br />

trotz des eher kühlen Sommers 1,7 % mehr Mineral-<br />

und Heilwasser getrunken als im Jahr zuvor. Der<br />

Pro-Kopf-Verbrauch von Mineral- und Heilwasser lag<br />

bei 137 Litern wie der Verband Deutscher Mineralbrunnen<br />

(VDM) mitteilte.<br />

ZWEI MILLIONEN PET-FLASCHEN PRO TAG<br />

Da heißt es technisch Aufrüsten – auch bei unseren<br />

Nachbarn in Österreich. In der PET-Technologie ist Bewegung:<br />

Vöslauer Mineralwasser, Marktführer für Mineralwasser<br />

in Österreich, hat die Drucklufterzeugung<br />

für die PET-Flaschen-Produktion modernisiert und den<br />

Systemanbieter Comp Air damit beauftragt, zwei<br />

40-Bar-Kompressoren durch eine energieeffiziente, ölfrei<br />

verdichtende Maschine der Marke Belliss & Morcom<br />

zu ersetzen. Ebenso wie Comp Air gehört B&M zur<br />

Gardner Denver-Gruppe.<br />

Das Unternehmen ist mit einem Marktanteil von über<br />

41 % Österreichs größter Mineralwasserhersteller und<br />

gehört zu Ottakringer Getränke. Es beschäftigt rund<br />

180 Mitarbeiter und füllt pro Tag bis zu zwei Millionen<br />

PET-Flaschen ab, die Jahresproduktion beträgt über<br />

3 Millionen Hektoliter. Basis aller Erzeugnisse ist Mineralwasser<br />

aus einer artesischen Quelle, das in zirka<br />

660 Metern Tiefe lagert und einen sehr ausgewogenen<br />

Mineralgehalt aufweist.<br />

NIEDRIGE DREHZAHL FÜR RUHIGEN LAUF<br />

Einer der Gründe für die Erneuerung der Drucklufterzeugung<br />

war, die Energieeffizienz zu verbessern. In der<br />

PET-Flaschenproduktion werden die angelieferten<br />

daumengroßen Preforms mit einem Druckstoß von<br />

40 Bar auf die gewünschte Größe aufgeblasen. Vöslauer<br />

hat für diese Aufgabe mehrere Hochgeschwindigkeits-Streckblasmaschinen<br />

im Einsatz, die große Mengen<br />

Druckluft benötigen – wobei es in den letzten Jahren<br />

durch die Anschaffung neuer Maschinen schon gelang,<br />

den Druckluftbedarf um rund 25 % auf 5 000 m 3 /h zu<br />

reduzieren.<br />

Für die benötigte Druckluftmenge empfahlen die<br />

Comp-Air-Ingenieure den Einsatz eines dreistufigen<br />

ölfrei arbeitenden WH 29 H3N von Belliss & Morcom,<br />

14<br />

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

5 / 2014


Herausforderung<br />

Automatisierungstechnik<br />

dessen drei doppeltwirkende Zylinder in W-Form angeordnet<br />

sind. Dieses Design, das speziell für die PET-<br />

Produktion entwickelt wurde, schafft durch die niedrige<br />

Drehzahl eine wichtige Voraussetzung für den<br />

ruhigen, schwingungsarmen Lauf. Deshalb benötigen<br />

die Verdichter kein spezielles Fundament.<br />

ÜBERGEORDNETE STEUERUNG<br />

Die in Bad Vöslau installierte Maschine liefert maximal<br />

1950 m3/h Druckluft in das 40-Bar-Netz – und das mit<br />

hoher Wirtschaftlichkeit. Nach Untersuchungen von<br />

Comp Air verbrauchen diese PET-Kompressoren mindestens<br />

5 % weniger Energie als vergleichbare Verdichter.<br />

Dazu trägt das doppelwirkende Verdichtungsprinzip<br />

ebenso bei wie die Zweistufenregelung mit Vollund<br />

Halblast sowie der direkt angeflanschte 385 kW-<br />

Elektromotor.<br />

Da alle Kompressoren in ein gemeinsames Netz speisen,<br />

bot es sich an, mit der Modernisierung der Station<br />

eine übergeordnete Steuerung zu installieren, die die<br />

einzelnen Verdichter bedarfsgerecht zu- und abschaltet.<br />

Deshalb gehörte zum Lieferumfang eine Gesamtsteuerung,<br />

die in vielen Werksluftnetzen im Einsatz ist<br />

und vor allem bei höheren Druckbereichen die Energieeffizienz<br />

der Station verbessert. „Wir setzen prinzipiell<br />

drei Kompressoren ein, der vierte bleibt nur als<br />

Redundanzmaschine für Wartungsarbeiten am Netz.<br />

Die Steuerung sorgt dafür, dass immer die wirtschaftlichste<br />

Kompressorkombination die benötigte Druckluft<br />

liefert“, sagt Walter Goisser, Technischer Leiter bei<br />

Vöslauer Mineralwasser.<br />

Der Mineralwasserhersteller ist mit der modernisierten<br />

40-Bar-Station gut vorbereitet auf das geplante<br />

Wachstum. „Bis 2018 haben wir hier keinen Modernisierungsbedarf,<br />

und wenn der Bedarf überproportional<br />

wachsen sollte, können wir einfach den Redundanzkompressor<br />

zuschalten“, sagt Giosser.<br />

AUTOR<br />

JOSEF HUBER<br />

ist Niederlassungsleiter<br />

und Mitglied der<br />

Geschäftsführung bei<br />

der Comp Air in Linz.<br />

Comp Air GmbH,<br />

Im Südpark 207, A-4030 Linz,<br />

Tel. +43 732 320 88 00,<br />

Internet: www.compair.de<br />

Mit dem <strong>atp</strong>-award werden zwei Autoren der <strong>atp</strong> <strong>edition</strong> für<br />

hervorragende Beiträge ausgezeichnet. Ziel dieser Initiative<br />

ist es, Wissenschaftler und Praktiker der Automatisierungstechnik<br />

anzuregen, ihre Ergebnisse und Erfahrungen in Veröffentlichungen<br />

zu fassen und die Wissenstransparenz in der<br />

Automatisierungstechnik zu fördern. Teilnehmen kann jeder<br />

Autor der zum Zeitpunkt der Veröffentlichung nicht älter als<br />

35 Jahre ist. Nach Veröffentlichung eines Beitrags ist der Autor,<br />

wenn er die Bedingung erfüllt, automatisch im Pool. Die<br />

Auswahl des Gewinners übernimmt die <strong>atp</strong>-Fachredaktion.<br />

Derjenige Autor, der im Autorenteam der jüngste ist, erhält<br />

stellvertretend für alle Autoren die Auszeichnung. Der Preis<br />

wird in zwei Kategorien ausgelobt: <strong>Industrie</strong> und Hochschule.<br />

Die Kategorien ermittlung ergibt sich aus der in dem Beitrag<br />

angegebenen Adresse des jüngsten Autors.<br />

Veröffentlichungen – Beitrag zum Wissenspool im<br />

Fachgebiet Automatisierungstechnik<br />

Die Entwicklung eines Wissensgebietes erfolgt durch einen<br />

kooperativen Prozess zwischen wissenschaftlicher Grundlagenforschung,<br />

Konzept- und Lösungsentwicklung und Anwendung<br />

in der Praxis. Ein solcher Prozess bedarf einer gemeinsamen<br />

Informationsplattform. Veröffentlichungen<br />

sind die essentielle Basis eines solchen Informationspools.<br />

Der <strong>atp</strong>-award fördert den wissenschaftlichen Austausch<br />

im dynamischen Feld der Automationstechnik. Nachwuchsinge<br />

nieure sollen gezielt ihre Forschungen präsentieren<br />

können und so leichter den Zugang zur Community erhalten.<br />

Der Preis ist mit einer Prämie von jeweils 2000€ dotiert.<br />

Die Auswahl erfolgt in zwei Stufen:<br />

Voraussetzung für die Teilnahme ist die Veröffentlichung<br />

des Beitrags in der <strong>atp</strong> <strong>edition</strong>. Jeder Aufsatz, der als Hauptbeitrag<br />

für die <strong>atp</strong> <strong>edition</strong> eingereicht wird, durchläuft das<br />

Peer-Review-Verfahren. Die letzte Entscheidung zur Veröffentlichung<br />

liegt beim Chefredakteur. Wird ein Beitrag veröffentlicht,<br />

kommt er automatisch in den Pool der <strong>atp</strong>-award-<br />

Bewerber, vorausgesetzt einer der Autoren ist zum Zeitpunkt<br />

der Veröffentlichung nicht älter als 35 Jahre. Ausgezeichnet<br />

wird der jüngste Autor stellvertretend für alle Autoren der<br />

Gruppe. Eine Jury aus Vertretern der <strong>atp</strong>-Fachredaktion<br />

und des -Beirats ermittelt schließlich den Gewinner in den<br />

jeweiligen Kategorien Hochschule und <strong>Industrie</strong>.<br />

Der Rechtsweg ist ausgeschlossen.<br />

Beiträge richten Sie bitte an:<br />

DIV Deutscher <strong>Industrie</strong>verlag GmbH<br />

Herrn Prof. Leon Urbas<br />

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

Arnulfstraße 124 • 80636 München<br />

Tel. +49 (0) 89 203 53 66-58 • E-Mail: urbas@di-verlag.de<br />

Beachten Sie die Autorenhinweise der <strong>atp</strong> <strong>edition</strong> für<br />

Hauptbeiträge unter folgendem Link:<br />

http://www.<strong>atp</strong>-online.de<br />

Bitte senden Sie Ihre Beiträge an: urbas@di-verlag.de


PRAXIS<br />

In der Sortier- und Verteiltechnik setzen<br />

Anwender auf individuelle Systemlösungen<br />

Maßgeschneiderte automatisierte Lösungen: Einheitliche Standards verkürzen die Projektlaufzeiten<br />

Der Trend zur Automatisierung setzt sich in der<br />

Intralogistik weiter fort. Denn Anwender wollen<br />

mit ihren Anlagen und Systemen rationeller und sicherer<br />

arbeiten. Gleichzeitig sollen Mitarbeiter von<br />

monotonen und körperlich schweren Arbeiten entlastet<br />

werden. Die Beumer Group entwickelt Systemlösungen<br />

in den Bereichen Förder- und Verladetechnik,<br />

Palettier- und Verpackungstechnik sowie Sortier- und<br />

Verteilanlagen. Diese stattet das Unternehmen je nach<br />

Kundenanforderung mit effizienten Automatisierungslösungen<br />

aus.<br />

AUFEINANDER ABGESTIMMTE SYSTEME<br />

Unternehmen aus unterschiedlichen Branchen setzen<br />

dabei immer häufiger auf Systemlösungen, die speziell<br />

auf ihre individuellen Bedürfnisse zugeschnitten sind.<br />

„Die Anwender wollen nicht mehr nur eine Anlage haben,<br />

sie wollen eine Kombination mehrerer Anlagen,<br />

die optimal aufeinander abgestimmt sind“, sagt Franz-<br />

Josef Kleigrewe, Automatisierungsleiter bei der Beumer<br />

Group. Dazu gehören Sortier- und Verteilanlagen, die<br />

beispielsweise in Distributionszentren eingesetzt werden.<br />

Um schnelle Auslieferungen an die Kunden gewährleisten<br />

zu können, sind effiziente Prozesse erforderlich.<br />

Kommen die Produkte am Wareneingang an,<br />

werden sie abgeladen und auf Paletten gestapelt. Mitarbeiter<br />

legen die Waren auf Flachgurtförderer, die sie<br />

einem Liniensorter zuführen. Dieser kann sie direkt<br />

zum Versand-Sorter leiten, zur Einschleuseinheit des<br />

Vorsortierers oder direkt ins Lager – wie im Nike China<br />

Logistics Center (CLC) in Taicang.<br />

BEI NIKE IN CHINA<br />

In Jiangsu befindet sich das größte Distributionszentrum<br />

des Sportartikelherstellers in Asien. Alle Lieferungen<br />

von Kleidung und Schuhen für das chinesische<br />

Festland werden über Anlagen des Intralogistik-Herstellers<br />

abgewickelt. Bei Bedarf nehmen Mitarbeiter<br />

die Produkte aus dem Lager und legen sie in die Kunststoffschalen<br />

einer Förderanlage. Diese transportiert die<br />

Schalen zu einem weiteren Förderer. Die Schalen sowie<br />

die Kartons mit den Chargen aus dem Vorsortierer<br />

werden zusammengeführt und geleert. Die Mitarbeiter<br />

legen die Artikel anschließend auf einen Quergurtsorter.<br />

Dieser sortiert die Waren in den Kunststoffschalen<br />

automatisch in festgelegte Behälter, die im Kippbereich<br />

ausgeschüttet werden. Von dort aus werden die Artikel<br />

über ein System von Flachgurtförderern zu den Mitarbeitern<br />

transportiert, die diese manuell auf den Endsortierer<br />

legen. Kommissioniert wird mit Pick-by-<br />

Voice. Als Systemintegrator steht Beumer seinen Kunden<br />

von der Planung bis zur Inbetriebnahme zur Seite.<br />

Ein Ansatz ist eine modulare Anlagenkonzeption mit<br />

hochautomatisierter Sortiertechnik. Die Systemlösungen<br />

kombiniert das Unternehmen dabei aus verschiedenen<br />

Bausteinen. „Systeme und Anlagen, die<br />

DIE MITARBEITER des Beumer Customer<br />

Supports übernehmen vor Ort die Installation<br />

sowie die Inbetriebnahme.<br />

wir nicht im Programm haben, wie zum Beispiel Scanner,<br />

kaufen wir von ausgewählten Zulieferern und integrieren<br />

sie in unsere Lösungen“, sagt Kleigrewe.<br />

ERFAHRUNGSWERTE ZÄHLEN<br />

Damit Beumer die Anwender angemessen betreuen<br />

kann, hat die Firma in den einzelnen Gruppengesellschaften<br />

sowie am Standort Beckum Teams gebildet,<br />

die sich speziell um Automatisierungslösungen kümmern.<br />

Mittlerweile sind mehr als 200 Mitarbeiter für<br />

diesen Bereich beschäftigt. Die Mitarbeiter begleiten<br />

die Projekte von der Anfrage bis zur Übergabe an den<br />

Kunden. Zuerst erstellen die Spezialisten einen Systementwurf.<br />

Passt dieser, geht es an die Umsetzung.<br />

Die Mitarbeiter übernehmen die Elektroinstallationen<br />

und integrieren die Maschinen- und Anlagensteuerungen.<br />

Teil des Systems ist zudem eine graphische<br />

Darstellung der Prozesse auf einer Benutzeroberfläche.<br />

Zwischen den verschiedenen Betriebsebenen<br />

werden Informationen zum Beispiel<br />

über ERP- und MES-Systeme übertragen.<br />

Im Beumer-eigenen Technikum in Beckum sind verschiedene<br />

Sortier- und Verteilanlagen aufgebaut. Die<br />

Mitarbeiter können hier mehrere Tests durchführen,<br />

um die Anlage auf besondere Anforderungen der Anwender<br />

anzupassen. „Dabei helfen uns wertvolle Erfahrungen,<br />

die wir in zahlreichen Projekten weltweit<br />

16<br />

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

5 / 2014


ZU IHREN<br />

AUFGABEN<br />

gehören<br />

außerdem die<br />

Elektroinstallationen<br />

sowie die<br />

Integration der<br />

Maschinenund<br />

Anlagensteuerungen.<br />

DIE HOCH-<br />

LEISTUNGS-<br />

SORTIER-<br />

ANLAGE<br />

LS-4000<br />

DIE STEUERUNG<br />

der einzelnen<br />

Maschinen<br />

ist mit einer<br />

systemweiten<br />

Transparenz des<br />

W o r k fl o w s<br />

verbunden.<br />

DER E-TRAY<br />

SORTER kommt<br />

weltweit in<br />

Post- und<br />

Verteilzentren<br />

zum Einsatz.<br />

Bilder: Beumer Group<br />

sammeln konnten“, sagt Kleigrewe. Die Feinarbeit übernehmen<br />

anschließend die Mitarbeiter vor Ort bei der<br />

Installation und Inbetriebnahme.<br />

EINHEITLICHE STANDARDS<br />

„Die Ausgangssituation sieht häufig so aus: Je größer<br />

eine Anlage ist und je mehr Systeme integriert sind,<br />

desto mehr Steuerungssysteme sind auch im Einsatz,<br />

die aufeinander abgestimmt werden müssen“, erläutert<br />

der Automatisierungsleiter. Bei Beumer wurden<br />

im Lauf der Jahre zum Beispiel vier Steuerungssysteme<br />

entwickelt. „Um bei der Entwicklung flexibler<br />

zu sein und auch eine schnellere Inbetriebnahme zu<br />

ermöglichen, ist es unser Ziel, bei allen Entwicklungen<br />

auf ein einheitliches Antriebskonzept sowie<br />

einheitliche Maschinen- und Anlagensteuerungen<br />

zu setzen“, sagt Kleigrewe. „Förderelemente oder<br />

Schnittstellendefinitionen für die horizontale und<br />

vertikale Kommunikation bieten wir schon aus dem<br />

Baukasten an.<br />

Sind die Anlagen in Betrieb genommen, schulen Mitarbeiter<br />

im Kundenservice die Maschinenbediener<br />

und das Wartungspersonal. Denn nur so können die<br />

Anlagen mit einer maximalen Betriebszeit laufen. Dabei<br />

werden die Maschinenbediener auf den neuesten<br />

Stand gebracht und neue Mitarbeiter an die Systeme<br />

herangeführt. „Automatisierte Lösungen eignen sich<br />

besonders bei kontinuierlichen Prozessen, wenn beispielsweise<br />

Anlagen rund um die Uhr sieben Tage die<br />

Woche laufen“, empfiehlt Kleigrewe. „Unternehmen<br />

sparen somit Mitarbeiter ein, die sie an anderen Stellen<br />

einsetzen können. Damit haben sich automatisierte<br />

Lösungen in kurzer Zeit amortisiert.“<br />

AUTORIN<br />

Beumer Group GmbH & Co. KG,<br />

Oelder Str. 40, D-59269 Beckum,<br />

Tel. +49 (0) 252 12 40,<br />

E-Mail: beumer@beumergroup.com<br />

REGINA SCHNATHMANN<br />

ist Director Communications<br />

and Public Relations<br />

bei der Beumer Group.<br />

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

5 / 2014<br />

17


PRAXIS<br />

Optimierter Brandschutz durch moderne<br />

Klappen mit angepasstem Stellantrieb<br />

Klappen-Modelle mit freiem Querschnitt: Energieeffizienz und bessere Zustandsüberwachung<br />

Damit sich in brennenden Gebäuden giftige Gasen,<br />

Rauch und Flammen nicht über die Lüftungskanäle<br />

ausbreiten, müssen die in der Lüftungsanlage verbauten<br />

Brandschutzklappen einwandfrei funktionieren.<br />

Bei der Geba Bartholomäus GmbH sorgen angepasste<br />

Stellantriebe in den Brandschutzklappen des<br />

Typs GBK-K 90 EU für zuverlässiges Funktionieren. Die<br />

dazugehörige Schalt- und Bewegungstechnologie der<br />

Gruner AG ermöglicht das motorisierte Öffnen und<br />

Schließen der Klappen sowie die Ansteuerung über die<br />

Gebäudeleittechnik. Die LEDs und Thermofühler sowie<br />

die kompakte Konstruktionsweise der stabilen Antriebe<br />

und der freie Querschnitt der Klappen vereinfachen<br />

die regelmäßige Wartung und reduzieren die Kosten<br />

von Installation und Revision.<br />

Durch die Sonderform <strong>ohne</strong> mittige Klappe ermöglichen<br />

die Geba-Modelle den leisen Betrieb sowie die<br />

Reduktion des Druckverlustes, wodurch Energie gespart<br />

und kleinere Rohrdurchmesser verwendet werden<br />

können. Seit 2013 ist das neue System nun europaweit<br />

zertifiziert.<br />

BRANDSCHUTZKLAPPEN LÖSEN<br />

THERMOELEKTRISCH AUS<br />

In der Regel sperren Brandschutzklappen mit einem<br />

Schmelzlot die Lüftungsrohre ab: „Steigt die Temperatur<br />

im Inneren der Brandschutzklappe durch heiße<br />

Brandgase über eine Temperatur von 72 ˚C, löst bei diesen<br />

Modellen das Schmelzlot unmittelbar aus und<br />

schließt die Klappe“, erklärt Gert Bartholomäus, Geschäftsführer<br />

der Geba Bartholomäus.<br />

Bei der GBK-K 90 EU mit Federrücklaufantrieb von<br />

Gruner hingegen erfolgt das Schließen der Klappe<br />

durch die thermoelektrische Auslöseeinrichtung: „Erreicht<br />

die Temperatur in der Luftleitung oder am Antrieb<br />

der Klappe den Wert von 72 ˚C oder fällt die Versorgungsspannung<br />

aus, wird die antriebsinterne Feder<br />

freigegeben, die dann die Tür im Lüftungskanal zudrückt“,<br />

so Bartholomäus. Der BLDC-Motor fungiert in<br />

dieser Situation als Bremse, um die Klappe und den<br />

Stellantrieb vor einem abrupten Zufallen zu schützen.<br />

GLEICHBLEIBENDE FUNKTIONALITÄT AUCH BEI 90 ˚C<br />

Die Klappen, die im Ernstfall die Lüftungskanäle verschließen,<br />

um Flammen und belastete Luft zurückzuhalten,<br />

müssen ihre Aufgabe unter extremen Belastungen<br />

verlässlich erfüllen. Dieser Einsatz stellt hohe Ansprüche<br />

an die Widerstandsfähigkeit und Leistung der elektrischen<br />

Stellantriebe. Sie müssen beispielsweise eine manuelle<br />

Schaltung ermöglichen, um die Lüftung präventiv<br />

zu blockieren, bevor das Feuer sie erreicht.<br />

„Wir fertigen alle wichtigen Bauteile aus Stahl, damit<br />

trotz Hitzeeinwirkung das Drehmoment des Motors erhalten<br />

bleibt“, erklärt Robert Frank, Key Account Manager<br />

bei der Gruner. „Temperaturen von bis zu 90 ˚C sind<br />

so über längere Zeit kein Problem.“ Die Feder ist ebenfalls<br />

hitzebeständig und übersteht mehr als 60 000 Revisionszyklen<br />

<strong>ohne</strong> Spannungsnachlass. „Im Rahmen<br />

der Brandprüfungen wurde die Klappe über den Gruner-Stellmotor<br />

10 000-mal geöffnet und geschlossen,<br />

<strong>ohne</strong> dass es zu einer Beeinträchtigung der Motorleistung<br />

kam“, bestätigt Bartholomäus.<br />

Gleichzeitig achteten die Entwickler der jüngsten<br />

Stellantrieb-Generation auf eine kompakte Bauweise.<br />

Indem weniger mechanische und elektromechanische<br />

Komponenten verbaut wurden, ließ sich der Verschleiß<br />

verringern und Standzeit sowie Zuverlässigkeit des Geräts<br />

erhöhen. Unter anderem sparte die Bremswirkung<br />

des Motors die mechanische Bremse. Die Gruner-Stellantriebe<br />

besitzen außerdem eine hohe Drehmomentdichte.<br />

Je nach Klappengröße reichen die verfügbaren<br />

Motordrehmomente von 3 bis 20 Nm bei einem Drehwinkel<br />

von 95 ˚.<br />

Zudem wurde der Abstand der Klappenachse zur<br />

Brandwand verkleinert. „Dadurch wird das gesamte System<br />

kompakter“, so Frank. Der Stellantrieb sitzt direkt<br />

auf dem Verschlusssystem <strong>ohne</strong> teure und fehleranfällige<br />

Übertragungsmechaniken. „Bei der Entscheidung<br />

für Gruner war für uns sehr wichtig, dass der Motor<br />

flexibel so angepasst werden konnte, wie er für unsere<br />

Brandschutzklappe ideal war“, erklärt Bartholomäus.<br />

Dabei wurde auf kleine Details Wert gelegt: Die Wellenadaption<br />

beispielsweise wurde so abgewandelt, dass<br />

der Antrieb spielfrei angebracht werden konnte.<br />

ZUSTÄNDE ODER DEFEKTE LEICHT<br />

VON AUSSEN SICHTBAR<br />

Gegenüber den einfachen Systemen mit Schmelzlot bildet<br />

vor allem die Funktionsanzeige der Gruner-Antriebe<br />

einen deutlichen Vorteil. Der Thermoschalter zeigt mit<br />

seinen LEDs den Zustand der Klappe an, was die Sicherheit<br />

und Fehlerdiagnose erheblich erleichtert. Ist der<br />

Antrieb bereit und die Brandschutzklappe geöffnet,<br />

leuchtet eine grüne Diode. Rotes Licht weist darauf hin,<br />

dass der Verschluss-Taster gedrückt wurde und die<br />

Klappe geschlossen ist. Sind beide LEDs dunkel, ist das<br />

Schmelzlot geschmolzen oder es liegt aufgrund eines<br />

Defekts keine Betriebsspannung an. Durch diese sichtbare<br />

Unterscheidung lassen sich Störungen schnell und<br />

direkt am Antrieb aufdecken. Auch die Inbetriebnahme<br />

wird dank der klaren Funktionssignale vereinfacht.<br />

„Besonders interessant war für uns die Prüfplakette<br />

auf der thermischen Auslösung, die sich verfärbt, sobald<br />

ein Defekt vorliegt“, so Bartholomäus. „Der Temperaturmesspunkt<br />

wechselt die Farbe, sobald er auf über 72 ˚C<br />

erhitzt wird. Ohne eine derartige Anzeige ist von außen<br />

nicht ersichtlich, ob die Temperatursicherung möglicherweise<br />

defekt ist“, erläutert Frank. „Der Messpunkt<br />

dagegen verhindert, dass die Sicherung unbemerkt<br />

durchschmelzen kann.“ Zudem lässt sich der Temperaturfühler<br />

anschließend separat austauschen. Dadurch<br />

muss nicht der ganze Antrieb ausgewechselt werden.<br />

18<br />

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

5 / 2014


DIE STELLANTRIEBE ermöglichen das motorisierte<br />

Öffnen und Schließen der Klappen sowie<br />

die Ansteuerung über die Gebäudeleittechnik.<br />

Bild: Geba Bartholomäus<br />

ZWEI LEDS in Rot und Grün zeigen<br />

den Zustand von Antrieb und Klappe<br />

an. Grün heißt „geöffnet und betriebsbereit“,<br />

Rot bedeutet „per Knopfdruck<br />

geschlossen“. Leuchtet keine Diode,<br />

fehlt die Betriebsspannung, etwa weil<br />

das Schmelzlot durch gebrannt ist.<br />

Bild: Gruner<br />

DAMIT IN BRENNENDEN GEBÄUDEN<br />

die Verbreitung von giftigen Gasen, Rauch<br />

und Flammen über die Lüftungskanäle<br />

verhindert wird, müssen die<br />

Brandschutzklappen funktionieren.<br />

Bild: Paul-Georg Meister/pixelio.de<br />

SIND DIE KLAPPEN mit Stellantrieben<br />

versehen, lässt sich die<br />

Revision per Knopfdruck erledigen,<br />

was Zeit spart und die bislang<br />

benötigten Revisionsöffnungen<br />

überflüssig macht. Bild: Gruner<br />

REVISION WENIGER ZEIT- UND ARBEITSINTENSIV<br />

Auch bei der regelmäßigen Wartung und Prüfung der Anlagen<br />

hat der Stellantrieb klare Vorteile gegenüber einem<br />

einfachen System mit Schmelzlot. Bei herkömmlichen Modellen<br />

wird die Klappe zu diesem Zweck zwar per Knopfdruck<br />

geschlossen, kann aber nur von Hand wieder geöffnet<br />

werden. Eine zeit- und kostenintensive Arbeit, die an jedem<br />

einzelnen Brandschutzabschnitt durchgeführt werden<br />

muss. „Sind die Klappen mit Stellantrieben versehen,<br />

lässt sich auch die Revision per Knopfdruck erledigen,<br />

was Zeit spart und die bislang benötigten Revisionsöffnungen<br />

überflüssig macht“, erklärt Frank.<br />

Zukünftig kann das ganze System außerdem über ein<br />

intelligentes Bus-System (Modbus) gekoppelt werden.<br />

„Bisher wurde über die Steuerung nur die Stromversorgung<br />

der Klappe beziehungsweise des Stellmotors sichergestellt<br />

und einmal im Monat eine Revision durchgeführt.<br />

Über Modbus kann jetzt eine Kommunikation<br />

zur Klappe hergestellt werden, und zwar zentral vom<br />

Steuerpult oder Schaltschrank aus“, erläutert Frank.<br />

So wird beispielsweise die Winkelstellung der Klappe<br />

im System angezeigt und der Bediener erhält eine<br />

Rückmeldung über Öffnungs- und Schließvorgänge des<br />

Klappenblattes. „Damit können dann auch Testsequenzen<br />

für den Motor erstellt werden, die anschließend<br />

eigenständig ablaufen. Eine Revision vor Ort ist<br />

nicht mehr notwendig.“<br />

FAZIT<br />

Nicht nur der Antrieb, sondern auch die Sonderform<br />

der Klappe trägt dazu bei, Wartungsaufwand und Kosten<br />

zu minimieren. „Brandschutzklappen verfügen in<br />

der Regel über eine Schmetterlingsklappe, die sich mitten<br />

im Luftstrom befindet und damit Widerstände und<br />

Geräusche aufbaut“, erklärt Bartholomäus. „GBK-K 90<br />

wurde jedoch so konstruiert, dass sie <strong>ohne</strong> diese<br />

Klappe auskommt.“<br />

Der freie Querschnitt sorgt für eine turbulenzarme<br />

Luftströmung und damit für ein ruhigeres Wohnklima.<br />

Auch die Druckverluste fallen geringer aus, wodurch<br />

Energie eingespart und kleinere Rohrdimensionen verwendet<br />

werden können. „Darüber hinaus gibt es kaum<br />

Staubanhaftungen, was eine hohe Sicherheit und lange<br />

Reinigungsintervalle garantiert. Auch der Revisionsaufwand<br />

wird vereinfacht“, so Bartholomäus weiter.<br />

Das Schutzsystem aus Klappe und Antrieb wurde<br />

2010 entwickelt und erhielt 2013 nach abgeschlossener<br />

Brandprüfung die europäische Zulassung.<br />

AUTORIN<br />

IRIS GEHARD ist Fachjournalistin in<br />

München mit Spezialisierung im Bereich<br />

Gebäudetechnik.<br />

Gruner AG,<br />

Buerglestr. 15-17, D-78564 Wehingen,<br />

Tel. +49 (0) 7426 94 80, E-Mail: info@gruner.de,<br />

Internet: www.gruner.de<br />

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

5 / 2014<br />

19


PRAXIS<br />

Dank Abwärmenutzung bei Gussteil-Herstellung<br />

vermindert Automobilzuliefer CO 2 -Emmissionen<br />

Lösungspaket von Endress+Hauser hilft dabei, Vorgaben der Monitoring-Verordnung einzuhalten<br />

EIN TECHNIKER kalibriert die Messstellenkomponenten<br />

des Thermoölkreislaufes.<br />

Danach führt er eine Gesamt-<br />

Messunsicherheitsberechnung durch.<br />

Bild: Endress+Hauser<br />

IN SCHMELZÖFEN entstehen extreme Temperaturen.<br />

Die Abwärmenutzung bei der GF Automotive reduziert<br />

die CO 2-Emission enorm. Bild: Georg Fischer<br />

Kohlendioxid (CO 2 ) verstärkt den Treibhauseffekt<br />

und trägt zur globalen Erderwärmung bei. Es gilt,<br />

Emissionen zu vermindern. Mit Unterzeichnung des<br />

Kyoto-Protokolls hat sich die EU verpflichtet, aktiv<br />

dazu beizutragen – angestrebt ist eine Reduktion um<br />

20 Prozent bis 2020, verglichen mit 1990. Der Emissionshandel<br />

fordert von den Unternehmen die kontinuierliche<br />

Überwachung und Ermittlung des CO 2<br />

-<br />

Ausstoßes. Ein weiterer Baustein ist die jährliche<br />

Emissionsberichterstattung: Betreiber emissionshandelspflichtiger<br />

Anlagen müssen ihren Ausstoß seit<br />

Januar 2013 entsprechend der Monitoring-Verordnung<br />

(MVO) der EU-Kommission und Anhang 2 des<br />

Treibhausgas-Emissionshandelsgesetzes (TEHG) ermitteln<br />

und im anlagenspezifischen Überwachungsplan<br />

beschreiben.<br />

VERSCHÄRFTE ANFORDERUNGEN<br />

Mit Inkrafttreten der MVO haben sich die Anforderungen<br />

an die Messgenauigkeit verschärft. Durch regelmäßige<br />

Überprüfungen müssen Anlagenbetreiber<br />

nachweisen, dass die Gesamtunsicherheiten die<br />

Grenzwerte der geforderten Ebene einhalten. In der<br />

Praxis hat das unmittelbare Auswirkungen auf die<br />

Qualität der Messungen und deren bestimmungsgemäßen<br />

Einsatz, die kontinuierliche Überprüfung der<br />

eingesetzten Überwachungsmethoden, einhergehend<br />

mit der Qualitätssicherung für die verwendeten Messgeräte<br />

(Kalibrierung, Justierung, Prüfung). Ein Leitfaden<br />

der Deutschen Emissionshandelsstelle (DEHSt)<br />

unterstützt bei der Erstellung der Überwachungspläne.<br />

Ein Augenmerk richtet sich auf die Auswahl geeigneter<br />

Messinstrumente für die emissionsrelevanten<br />

Stoffmengen die Unsicherheitsbewertung von<br />

kalibrierten Messgeräten sowie zu treffende Maßnahmen<br />

bei Abweichungen von den MVO-Vorgaben.<br />

DAS LÖSUNGSPAKET<br />

Bei der Erfüllung der Vorgaben unterstützt das MVO-<br />

Lösungspaket von Endress+Hauser. Das Paket besteht<br />

20<br />

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

5 / 2014


aus der Kombination praxisbewährter Messtechnik,<br />

akkreditierter Kalibrierdienstleistungen sowie Leistungen<br />

für eine Messunsicherheitsbetrachtung.<br />

Für die Volumenstrommessung flüssiger oder gasförmiger<br />

Brennstoffe, die direkte Messung von Abgasströmen<br />

sowie die Bestimmung von Durchflussmengen<br />

in Energiekreisläufen, steht eine Vielzahl praxisbewährter<br />

Messverfahren zur Verfügung. So ist die<br />

Vortexmessung nach dem Wirbelablöseprinzip als<br />

äußerst robustes und bewährtes System mit hoher<br />

Langzeitstabilität prädestiniert für die zuverlässige<br />

Messung in Dampfanwendungen. Für sehr große<br />

Nennweiten sind Blenden und Staudrucksonden mit<br />

Differenzdruckmessungen gängig. Kommt es auf<br />

höchste Genauigkeiten, direkte Massemessung und<br />

Eichfähigkeit an, bieten Coriolis-Durchflussmessungen<br />

die ideale Lösung.<br />

Muss der Nachweis der Messunsicherheit durch regelmäßige<br />

Kalibrierung erbracht werden, kann<br />

Endress+Hauser alle Prozessmessgrößen sowohl vor<br />

Ort als auch im Werk gemäß ISO/IEC 17025 kalibrieren<br />

und per Zertifikat dokumentieren – unabhängig vom<br />

Hersteller für sämtliche Gerätetypen und Fabrikate,<br />

rückführbar und zertifiziert. Die Leistungen erstrecken<br />

sich von der Kalibrierung einzelner Messstellen<br />

bis zur Implementierung einer kompletten Kalibrier-<br />

Managementlösung.<br />

Bei zusammengesetzten Messstellen, etwa einer<br />

Staudrucksonde mit Differenzdruckmessung und Temperaturkompensation<br />

sowie nachgeschaltetem Energierechner,<br />

stellt sich die Frage nach der Gesamtunsicherheit<br />

der Messung unter Prozessbedingungen. Eine<br />

Gesamtgenauigkeitsberechnung, vereinfacht oder individuell,<br />

berücksichtigt alle prozessrelevanten Einflussfaktoren.<br />

Der Betreiber erhält ein Berechnungszertifikat<br />

und kann so die Qualität seiner Messstellen<br />

lückenlos, nach gängigen Standards dokumentieren<br />

und nachweisen.<br />

BEI GF AUTOMOTIVE<br />

Die Division GF Automotive, die Gussteile für die Automobilindustrie<br />

entwickelt und produziert, hat in ihrem<br />

Nachhaltigkeitsbericht 2011 ein Ziel veröffentlicht:<br />

Die CO 2 -Emissionen aus der Produktion sollen um mindestens<br />

20 Prozent reduziert werden. 11 000 Tonnen<br />

CO 2 können durch Abwärmenutzung aus Schmelzöfen<br />

pro Jahr vermieden werden. Die Abwärme wird mittels<br />

Thermoölkreislauf durch ein angrenzendes Lebensmittelwerk<br />

genutzt, rund zwei Drittel des kompletten Energiebedarfs<br />

werden so abgedeckt. Da der Standort<br />

Singen erstmalig am Emissionshandel teilnimmt, müssen<br />

Abwärmemengen dokumentiert werden. Der Kalibrierservice<br />

von Endress+Hauser führte bei den betroffenen<br />

Messstellen eine Bewertung hinsichtlich geeigneter<br />

Kalibrierverfahren durch. Nach Abstimmung mit<br />

GF Automotive erfolgte die Kalibrierung der Kompo-<br />

nenten sowie eine Vergleichsmessung mittels Ultraschall-Messverfahren.<br />

Zusätzlich zu den Kalibrierzertifikaten<br />

erhielt Georg Fischer eine Gesamtgenauigkeitsberechnung.<br />

Die Kalibrierungen und Berechnungen<br />

sollen nun in regelmäßigen Abständen erfolgen.<br />

So ist GF Automotive gerüstet, um alle Tätigkeitsdaten<br />

rückführbar dokumentieren zu können.<br />

AUTOR<br />

THOMAS KAUFMANN ist<br />

Marketingmanager<br />

Life Cycle Management<br />

bei Endress+Hauser<br />

in Weil am Rhein.<br />

Endress+Hauser Messtechnik GmbH + Co. KG,<br />

Colmarer Straße 6, D-79576 Weil am Rhein,<br />

Tel. +49 (0) 7621 97 59 07,<br />

E-Mail: thomas.kaufmann@de.endress.com<br />

An der Hochschule Merseburg ist im Fachbereich Informatik und Kommunikationssysteme<br />

ab dem 01. April 2015 folgende Stelle zu besetzen:<br />

Professur (W2)<br />

Prozessautomation/Gebäudeautomation<br />

Der/Die zukünftige Stelleninhaber/-in soll die Themengebiete Prozessautomation, Prozessleittechnik/Geräte<br />

und Anlagen sowie Gebäudeautomation in Lehre und Forschung<br />

des Fachbereiches vertreten. Wünschenswert wäre die Wahrnehmung der Lehrgebiete<br />

Regelungstechnik sowie Modellbildung/Simulation.<br />

Der/Die zukünftige Stelleninhaber/-in muss die Einstellungsvoraussetzungen gemäß § 35<br />

HSG LSA erfüllen. Gesucht wird eine Persönlichkeit mit entsprechender Qualifikation und<br />

einschlägiger Berufspraxis im Bereich der Prozessautomation und/oder der Gebäudeautomation.<br />

Die Bereitschaft zum Einsatz in der Forschung, im berufsbegleitenden Studium,<br />

in der Weiterbildung und für Bedarfe der anderen Fachbereiche ist notwendig. Wegen der<br />

voranschreitenden Internationalisierung der Lehre sollten die Lehrveranstaltungen auch in<br />

englischer Sprache durchgeführt werden können.<br />

Die aktive Mitarbeit in den Gremien der Hochschulselbstverwaltung wird erwartet.<br />

Die Höhe der Besoldung richtet sich nach den für Beamte und Beamtinnen des Landes<br />

Sachsen-Anhalt geltenden Bestimmungen. Zusätzlich zur Grundbesoldung können bei<br />

überdurchschnittlichen Leistungen Leistungsbezüge erlangt werden.<br />

Die Hochschule Merseburg strebt eine Erhöhung des Anteils von Frauen im Wissenschaftsbereich<br />

an und fordert Frauen nachdrücklich auf, sich zu bewerben. Bewerbungen<br />

von Wissenschaftlerinnen und Wissenschaftlern aus dem Ausland sind willkommen.<br />

Bewerbungen Schwerbehinderter werden bei gleicher Eignung und Befähigung bevorzugt<br />

berücksichtigt.<br />

Bewerbungen mit Lebenslauf, Darstellung des beruflichen und wissenschaftlichen<br />

Werdegangs, Schriftenverzeichnis und Verzeichnis der<br />

bisherigen Lehrtätigkeiten werden bis zum 05. Juni 2014 erbeten<br />

an: Hochschule Merseburg, Dekanin des Fachbereiches<br />

Informatik und Kommunikationssysteme Frau Prof. Dr.<br />

Monika Trundt, Geusaer Straße, 06217 Merseburg<br />

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

5 / 2014<br />

21


HAUPTBEITRAG<br />

<strong>Industrie</strong> <strong>4.0</strong> <strong>ohne</strong> <strong>modellbasierte</strong><br />

<strong>Softwareentwicklung</strong><br />

Und warum es <strong>ohne</strong> Modelle nicht gehen wird...<br />

<strong>Industrie</strong> <strong>4.0</strong> versucht die Handhabung von komplexen Produktionsanlagen zu verbessern<br />

und eine flexible und adaptive Produktion umzusetzen. Aktuell liegt die<br />

Hauptschwierigkeit dieser Szenarien bei der Automationssoftware, deren Erstellung<br />

zeitaufwändig und fehleranfällig ist. Zur Lösung dieses Problems werden dabei zwei<br />

Hauptansätze verfolgt: die <strong>modellbasierte</strong> <strong>Softwareentwicklung</strong> und die intelligente<br />

Automation, das heißt die Verwendung wissensbasierter Lösungsansätze. Der<br />

Beitrag vergleicht beide Ansätze anhand dreier Phasen: der Planungsphase, der<br />

Betriebsphase und der Anlagenumbauphase.<br />

SCHLAGWÖRTER Intelligente technische Systeme / <strong>Industrie</strong> <strong>4.0</strong> / Modellbasierte<br />

<strong>Softwareentwicklung</strong> für die Automation<br />

<strong>Industrie</strong> <strong>4.0</strong> without Model-Based Software Development –<br />

And why Models will be Decisive<br />

The efficient handling of complex production systems and the implementation of a<br />

more flexible and adaptable production lies at the heart of Industry <strong>4.0</strong>. Currently,<br />

smart manufacturing scenarios face one main bottleneck – the creation and configuration<br />

of the automation software is time-consuming and error-prone.<br />

There are two main solutions for this problem: (i) model-based software development<br />

and (ii) intelligent automation, i.e. the use of new knowledge-based solution<br />

approaches. This article compares these solutions by applying them to three phases<br />

of the life-cycle, the planning phase, the operation phase and the plant reconfiguration<br />

phase.<br />

KEYWORDS intelligent technical systems / cyber-physical systems /<br />

model based software development for automation<br />

22<br />

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

5 / 2014


OLIVER NIGGEMANN, Fraunhofer IOSB-INA<br />

Auf den ersten Blick gibt es wenig Einigkeit<br />

über den Inhalt von <strong>Industrie</strong> <strong>4.0</strong> und cyber-physischen<br />

Systemen: Je nach persönlicher<br />

Vergangenheit der Experten stehen<br />

mal die Information im Mittelpunkt (Internet<br />

der Dinge), mal die Methoden (wie Selbstdiagnose,<br />

Selbstkonfiguration) oder die Systemfähigkeiten<br />

(intelligente technische Systeme). Bewegen<br />

wir uns weg von der technischen Ebene hin zu den<br />

ursprünglichen Fragestellungen, so wird das Bild<br />

homogener: Der zentrale Begriff ist die Komplexitätsreduktion<br />

[3]. Offensichtlich nehmen immer mehr<br />

Menschen den Umgang mit der heutigen Produktions-<br />

und Automatisierungstechnik als zu komplex,<br />

zu fehleranfällig und zu unflexibel war. Beispiele<br />

sind der Automatisierer, der Anforderungen bezüglich<br />

Inbetriebnahmezeiten, Energieeinsparungen<br />

und Zuverlässigkeit nicht in angemessener Zeit vereinbaren<br />

kann, der Werksleiter, der die Anforderungen<br />

betreffend hoher Variabilität bei kleinen Stückzahlen<br />

(Stichwort: Losgröße 1) nicht mehr erfüllt,<br />

oder der Wartungsingenieur, der komplexe Fehler auf<br />

Systemebene nicht mehr in angemessener Zeit repariert.<br />

In jedem Fall besteht das Ziel in der Reduktion<br />

der vom Menschen wahrgenommen Komplexität bei<br />

Beibehaltung der Komplexität der Produktions- und<br />

Automatisierungstechnik. Insofern steht, und dies<br />

ist ein weiteres Merkmal von <strong>Industrie</strong> <strong>4.0</strong>, immer der<br />

Mensch im Mittelpunkt dieser Arbeiten.<br />

Die klassische Antwort der Informatik, auch für die<br />

Automation, auf diese Fragen besteht im Frontloading<br />

und speziell in der <strong>modellbasierte</strong>n <strong>Softwareentwicklung</strong><br />

[10,12-16]. Bei diesen Ansätzen erlauben Modellierungswerkzeuge<br />

dem Experten, sein Wissen bezüglich<br />

der zu entwickelnden Software auf einem für ihn<br />

angenehmen Niveau zu formalisieren, das heißt zu<br />

modellieren. Angenehm ist ein Niveau, wenn Modellierungsniveau<br />

und das Niveau des mentalen Modells<br />

des Menschen, also sein inneres Bild der Software,<br />

nahe beieinander liegen. Der Begriff Frontloading beschreibt<br />

dabei das dadurch erhoffte Tauschgeschäft:<br />

So verlangt die Modellbildung initial mehr Zeit und<br />

Aufwand, allerdings verringern sich später im Prozess<br />

Aufwände und Probleme, vor allem durch die bessere<br />

Spezifikation, durch die Möglichkeit der frühen virtuellen<br />

Systemüberprüfung, zum Beispiel mittels Simulation<br />

und durch die Möglichkeit der Codegenerierung<br />

Aufwände und Probleme. In der Summe ergibt<br />

sich für viele Anwendungsszenarien eine signifikante<br />

Verbesserung des Entwicklungsprozesses [12-16].<br />

Bild 1 zeigt einen typischen Ablauf der <strong>modellbasierte</strong>n<br />

<strong>Softwareentwicklung</strong>: Der Experte spezifiziert<br />

auf möglichst abstrakte, für ihn angenehme Weise, die<br />

Software. Auf Basis dieser Modelle werden die Automatisierungssoftware<br />

und die entsprechende Konfiguration<br />

der Automation generiert. Die <strong>modellbasierte</strong><br />

<strong>Softwareentwicklung</strong> zielt aber, im Gegensatz zur Modellentwicklung<br />

im Allgemeinen, immer auf eine Beschreibung<br />

der Software ab. Dies gilt auch, falls die<br />

Softwaremodelle durch Ergänzung von Prozessteilen,<br />

von Hardwaretopologie und von Basissoftware zu<br />

Systemmodellen [33, 34] erweitert werden, im Allgemeinen<br />

wird auch bei diesen Ansätzen die Software<br />

manuell modelliert.<br />

Je häufiger Anlagen und damit die Automation geändert<br />

werden, desto häufiger muss dieser Engineering-Zyklus<br />

durchlaufen werden. Des Weiteren verbleibt<br />

alles Wissen bezüglich der korrekten Automation,<br />

wie Systemwissen und Steuerungswissen, beim<br />

Experten. Das heißt, eine Zunahme der Systemkomplexität<br />

muss sich in einer Zunahme der Modellierungskomplexität<br />

niederschlagen. Neue <strong>modellbasierte</strong><br />

Ansätze können diese Zunahme abschwächen aber<br />

nicht grundsätzlich verhindern.<br />

Eine Alternative zur <strong>modellbasierte</strong>n <strong>Softwareentwicklung</strong><br />

ist die intelligente Automation: Hier beschreibt<br />

der Experte nicht mehr den Ablauf der Automation,<br />

sondern nur noch das Automationsziel. Das<br />

Ziel des Engineerings ist nicht mehr die Definition des<br />

Wie, sondern des Was. Klassische Produktionsziele sind<br />

Produktmerkmale, Durchsatz oder der maximale Energieverbrauch.<br />

Dieses Vorgehen entspricht dem Übergang<br />

von der klassischen, prozeduralen Automation<br />

hin zu einer zukünftigen deskriptiven Automation.<br />

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

5 / 2014<br />

23


HAUPTBEITRAG<br />

Da sich das Automationsziel, anders als der Automationsablauf,<br />

auch bei Anlagenumbauten wie zum Beispiel<br />

dem Austausch eines Anlagenmoduls, zumeist<br />

nicht ändert, ist der Experte bei diesem Ansatz nicht<br />

mehr ständig beteiligt. Darüber hinaus ist es einfacher,<br />

das Automationsziel, zum Beispiel in Form einer Beschreibung<br />

des finalen Produktes, festzulegen, als den<br />

kompletten Automationsablauf zu beschreiben. Hierdurch<br />

erfolgt eine Reduktion der vom Experten wahrgenommenen<br />

Komplexität.<br />

Bild 2 zeigt den Unterschied zwischen diesen beiden<br />

Ansätzen im Fall eines Anlagenumbaus, also bezüglich<br />

Anforderungen wie Adaptivität und Flexibilität. Während<br />

im Fall der <strong>modellbasierte</strong>n <strong>Softwareentwicklung</strong><br />

der Mensch bei jeder Änderung involviert ist, reagiert<br />

die deskriptive Automation zumeist automatisch <strong>ohne</strong><br />

Mitwirkung des Experten auf Änderungen.<br />

In den letzten Jahren sind immer mehr Entwicklungsprozesse<br />

in den Vordergrund der Forschung gerückt,<br />

die Prozess- und Produktmodelle in den Vordergrund<br />

stellen, die folglich deskriptiv arbeiten. Hierzu<br />

haben die Bemühungen zur Standardisierung solcher<br />

Modelle beigetragen [26, 27]. In verschiedenen Arbeiten<br />

wurden solche Modelle im Kontext von <strong>Industrie</strong> <strong>4.0</strong><br />

zur Erhöhung der Adaptivität der Automation eingesetzt<br />

[8, 28-30]. Ein verwandter Ansatz sind Agentensysteme<br />

[23-25], bei denen allerdings nicht nur die<br />

Beschreibung des Produktionszieles, sondern auch<br />

algorithmische Aspekte der Selbstorganisation betrachtet<br />

werden.<br />

1. VERGLEICH PLANUNGS- UND INBETRIEB-<br />

NAHMEPHASE<br />

Im Folgenden werden die zuvor beschriebenen gegensätzlichen<br />

Ansätze anhand mehrerer Forschungsprojekte<br />

verglichen, und zwar für den Anwendungsfall der<br />

Planungs- und Inbetriebnahme. Das vom Europäischen<br />

Fonds für regionale Entwicklung (EFRE) geförderte<br />

Projekt Initial [19] versucht mittels <strong>modellbasierte</strong>r<br />

<strong>Softwareentwicklung</strong>smethoden und Simulation die<br />

Inbetriebnahme zu verkürzen. Das vom Bundesministerium<br />

für Forschung und Bildung (BMBF) unterstützte<br />

Projekt Efa [20] geht anders vor: In diesem Ansatz<br />

modelliert der Benutzer nur die Anforderungen an<br />

die Automatisierungslösung, die Lösung selbst wird<br />

automatisch generiert.<br />

Das Initial-Projekt entwickelt einen <strong>modellbasierte</strong>n<br />

Ansatz zur Planung von Automatisierungssystemen.<br />

BILD 2: Vergleich der<br />

modell basierten <strong>Softwareentwicklung</strong><br />

und der<br />

deskriptiven Automation<br />

Frontloading und <strong>modellbasierte</strong> <strong>Softwareentwicklung</strong><br />

Engineeringtool<br />

Deskriptive Automation<br />

Engineeringtool<br />

Zyklus des<br />

Anlagenumbaus<br />

Modellierung<br />

durch<br />

die Experten<br />

Experten<br />

modellieren<br />

Engineeringtool<br />

erstellt<br />

Modell<br />

...<br />

vol = get_sensor(<br />

press = get_sensor(<br />

if (vol > 10.4 && press<br />

warning(“Pressure<br />

...<br />

Code<br />

Automatismus<br />

durch die intelligente<br />

Automation<br />

Beschreibung<br />

der Produktionsziele<br />

Zyklus<br />

des Anlagenumbaus<br />

PLC<br />

Plattform<br />

PLC PLC<br />

wird ausgeführt<br />

...<br />

vol = get_sensor(<br />

press = get_sensor(<br />

if (vol > 10.4 && press<br />

warning(“Pressure<br />

...<br />

Code<br />

generiert<br />

Code generator<br />

Produktionsanlage<br />

Produktionsanlage<br />

BILD 1: Ein typischer Ablauf der <strong>modellbasierte</strong>n<br />

<strong>Softwareentwicklung</strong><br />

24<br />

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

5 / 2014


Dieser beinhaltet ein Strukturmodell, das heißt ein Modell<br />

der Struktur der Produktionsanlage (zum Beispiel<br />

Module und deren Verschaltung) und der Automatisierungstechnik<br />

(beispielsweise Steuerungen einschließlich<br />

Software, Sensoren, Aktoren, Netzwerke). Bild 3<br />

zeigt ein solches Initial-Strukturmodell. Dieses Strukturmodell<br />

lässt sich als AutomationML-Datei [17] importieren<br />

und abspeichern. Zusätzlich werden für Teile<br />

des Strukturmodells Verhaltensmodelle hinterlegt. Für<br />

die Anlagenmodule geschieht dies in der Modellierungssprache<br />

Modelica, für die Steuerungsanteile wird<br />

realer IEC 61131-Code benutzt.<br />

Im Initial-Projekt werden diese Modelle für verschiedene<br />

Aufgaben verwendet: Zum einen dienen die Modelle<br />

als Methode der Absprache und der Kommunikation<br />

zwischen den beteiligten Parteien. Zum anderen<br />

können die Modelle auf einem PC simuliert und so<br />

frühzeitig Automatisierungsfehler entdeckt werden. Es<br />

ist auch möglich, in einer Hardware-in-the-Loop-Simulation<br />

eine reale Steuerung an eine simulierte Anlage<br />

anzuschließen und so die reale Steuerung vor Inbetriebnahme<br />

zu überprüfen. Weitere Details zum Initial-<br />

Projekt finden sich in [1, 2].<br />

Einen völlig anderen Ansatz verfolgt das Efa-Projekt:<br />

In diesem Fall spezifiziert der Experte nur die Anforderungen<br />

an das zu entwerfende Automatisierungssystem,<br />

wie in Bild 4 zu sehen. Auf der linken Seite<br />

definiert der Experte die Anforderungen an den zu<br />

automatisierenden Prozess, hier eine fliegende Säge.<br />

Das System generiert daraus automatisch die Automationslösung<br />

inklusive Hardwaretopologie und Softwareblöcken.<br />

In Bild 5 werden die beiden Ansätze verglichen: Für<br />

den Automatisierer, den Systemintegrator oder beim<br />

Betreiber ist der Aufwand für den deskriptiven Ansatz<br />

erheblich geringer, da nicht mehr die Lösung sondern<br />

nur noch das Ziel beschrieben werden muss. Hieraus<br />

folgt, dass der Automatisierer sich beim deskriptiven<br />

Ansatz auf Prozesswissen fokussieren kann, während<br />

er beim <strong>modellbasierte</strong>n Ansatz erhebliches Wissen<br />

über die IT, die Software und die Automatisierungstechnik<br />

besitzen muss.<br />

Auf der anderen Seite muss zuvor ein Werkzeugentwickler<br />

das nötige Wissen über den Entwurfsprozess<br />

formalisieren und in Form eines Werkzeugs dem Automatisierer<br />

zur Verfügung stellen. Darüber hinaus ist<br />

Wissen über Produktionsmodule und Automatisierungsgeräte<br />

notwendig. Dieses Wissen muss vom Anlagen-<br />

oder Gerätehersteller beziehungsweise vom<br />

Werkzeughersteller modelliert werden. Der Aufwand<br />

BILD 3: Der modell basierte Engineering-<br />

Ansatz im Initial-Projekt<br />

generieren<br />

Prozessbeschreibung, hier fliegende Säge<br />

Automationslösung für fliegende Säge<br />

Plattform und<br />

Inbetriebnahme<br />

Aufwand<br />

Modellbasierte<br />

Software-Entwicklung<br />

Automatisierer: hoch<br />

Werkzeughersteller: wie bislang<br />

Wissen über Prozess, Automation<br />

Software und IT notwendig<br />

Kommunikation über Lösungswege<br />

Deskriptives<br />

Vorgehen<br />

Automatisierer: niedrig<br />

Werkzeughersteller: hoch<br />

Prozess- und Produktwissen im Fokus<br />

BILD 4: Der<br />

Konfigurationsansatz<br />

im<br />

Efa-Projekt<br />

Ansprüche<br />

an Auto matisierer<br />

Kommunikation<br />

und Absprachen<br />

Simulation<br />

und Test<br />

Test der Steuerung als SIL und HIL<br />

möglich<br />

hohe Ansprüche an Anlagenmodell<br />

Kommunikation über Ziele und Produkte<br />

Test der Steuerung nicht möglich<br />

Test sollte aufgrund der<br />

SW-Synthese unnötig sein<br />

BILD 5: Vergleich der<br />

beiden Ansätze für<br />

die Planung und die<br />

Inbetriebnahme<br />

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

5 / 2014<br />

25


HAUPTBEITRAG<br />

für die deskriptive Automation fällt aber nur einmal an<br />

und nicht bei jedem Anlagenentwurf und bei jeder Inbetriebnahme.<br />

Ein erheblicher Unterschied ergibt sich für die Absicherung<br />

der Programmierung: Beim <strong>modellbasierte</strong>n<br />

Ansatz läuft alles auf eine virtuelle Inbetriebnahme<br />

hinaus; die Steuerung wird, real oder als Code, gegen<br />

eine Simulation der Anlage getestet. Dies funktioniert<br />

nur unter der Annahme, dass ein gutes, mit der Realität<br />

abgeglichenes Anlagenmodell existiert. Genau an diesem<br />

Punkt liegt aber das Problem: Im Allgemeinen haben<br />

weder Systemintegrator noch Betreiber die Zeit und<br />

die Ressourcen, um solche Modelle zu entwickeln. Eine<br />

Alternative ist es, dass Maschinen- und Anlagenbauer<br />

Modelle ihrer Anlagen mitliefern und diese später über<br />

Austauschformate wie AutomationML zu einem Gesamtmodell<br />

integrieren. Allerdings ergeben sich hierbei<br />

diverse Probleme:<br />

1 | Für verschiedene Zwecke wie SPS-Programmierung<br />

oder Erstellung der Leitsysteme sind unterschiedliche<br />

Modelle notwendig, das heißt, es<br />

werden nicht nur ein Modell sondern diverse Modelle<br />

benötigt.<br />

2 | Eine Modellparametrisierung ist nur mit Wissen<br />

über das Gesamtsystem möglich. Dies setzt aber<br />

voraus, dass der Systemintegrator oder der Betreiber<br />

über das notwendige Wissen verfügt und,<br />

zwecks Abgleich zwischen Modell und Realität,<br />

auch das Systemverhalten vermessen kann.<br />

3 | Aktuell ist der Business Case für die Maschinenund<br />

Anlagenbauer unklar.<br />

Frontloading und <strong>modellbasierte</strong><br />

<strong>Softwareentwicklung</strong><br />

Engineeringtool<br />

Deskriptive Automation<br />

BILD 6: Vergleich der<br />

beiden Ansätze für die<br />

Anomalieerkennung und<br />

Diagnose<br />

Modellierung<br />

durch<br />

die Experten<br />

Diagnoseregeln<br />

Beschreibung<br />

der<br />

Diagnoseziele<br />

Ausgabe der<br />

Analyseergebnisse<br />

0[51;0] 6[1;0]<br />

Silo 1 (Min) an<br />

(2767...2767)<br />

Förderband aus<br />

(237...237)<br />

Automatismus<br />

durch die intelligente<br />

Automation<br />

Vergleich<br />

Silo 1 (Min) aus<br />

3[42;0]<br />

Förderband an<br />

(1663...4401)<br />

Förderband aus<br />

(1344...3352)<br />

4[42;0]<br />

Sauger aus<br />

(1530...4306)<br />

Vorhersage<br />

Messung<br />

1[48;0,1] 2[42;0] 5[43;41]<br />

Sauger an<br />

Sauger an<br />

(3393...17676)<br />

(85979...85979)<br />

Produktionsanlage<br />

Modell<br />

des Normalverhaltens<br />

Lernen<br />

Produktionsanlage<br />

BILD 7: Ein gelernter Automat mit einem unerwarteten<br />

Ereignis, zum Beispiel verursacht durch einen SW-Fehler<br />

Betrieb<br />

(Anomalieerkennung)<br />

Modellbasierte Software-Entwicklung<br />

Deskriptives Vorgehen<br />

BILD 8:<br />

Vergleich<br />

für den<br />

Betriebsfall<br />

Aufwand<br />

Ansprüche an<br />

Automatisierer<br />

Vollständigkeit<br />

Automatisierer: hoch<br />

Werkzeughersteller: wie bislang<br />

Automatisierer braucht ein vollständiges<br />

Verständnis aller Abhängigkeiten im System<br />

Experte muss alle Anomalie<br />

vorausdenken<br />

nur solche Situationen werden erkannt, an<br />

die der Benutzer gedacht hat<br />

Automatisierer: niedrig,<br />

Analyseziele müssen formalisiert werden<br />

Werkzeughersteller: hoch<br />

Qualitäts- und Analyseziele müssen bekannt<br />

und formalisiert sein<br />

vollständig, wenn Beobachtungen<br />

vollständig<br />

26<br />

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

5 / 2014


Im Fall der deskriptiven Automation existieren keine<br />

simulationsfähigen Anlagenmodelle, das heißt, ein Modellerstellungs-<br />

und Parametrisierungsproblem gibt es<br />

in der Form nicht. Stattdessen muss einmalig das Wissen<br />

über die automatische Erzeugung der Steuerungssoftware<br />

aus der Beschreibung des Automationszieles<br />

modelliert werden. Diese Synthese-Frage ist bislang<br />

nicht vollständig erforscht und stellt die größte Herausforderung<br />

bei der Umsetzung des deskriptiven Ansatzes<br />

dar. Das Efa-Projekt setzt hierzu zum Beispiel<br />

die Steuerungssoftware kompositionell aus fertigen<br />

Bausteinen, also Software-Komponenten in Form von<br />

IEC 61131-Funktionsblöcken, zusammen. Hierzu werden<br />

Methoden des Constraint Solving zur Konsistenzsicherung<br />

der Anforderungen und zur Berechnung von<br />

unbekannten Systemgrößen verwendet. Regelsysteme<br />

wählen dann die passende Automationstopologie aus<br />

und bilden die Software auf der Hardware ab. Das Ergebnis<br />

bilden mehrere Lösungsvarianten, welche nach<br />

Zielkriterien wie Preis bewertet werden.<br />

Sollte diese Software-Synthese gelöst werden, entfällt<br />

der Bedarf an Tests durch eine Simulation, da nun<br />

statt der Software die Software-Generierung abgesichert<br />

werden kann. Dies ist analog zum Compilerbau,<br />

bei welchem nicht das Kompilat, sondern der Compiler<br />

getestet wird.<br />

2. VERGLEICH FÜR DIE BETRIEBSPHASE<br />

In der Betriebsphase stellen sich Fragen zur Erkennung<br />

von Anomalien, von suboptimalen Energieverbräuchen<br />

oder von Verschleiß [4-7]. Aktuell löst der Experte<br />

diese Fragen zumeist durch das manuelle Kodieren<br />

von festen Regeln im Automationscode, siehe linke<br />

Seite von Bild 6. Diese Regeln schließen von Symptomen<br />

auf Anomalien oder Optimierungsbedarf [9].<br />

Hierzu müssen alle Anomalien vorausgedacht werden.<br />

Im Kontext von <strong>Industrie</strong> <strong>4.0</strong> mit dem Anspruch auf<br />

Unterstützung für häufige Anlagenumbauten bedeutet<br />

dies, dass diese Regeln häufig manuell bearbeitet werden<br />

müssen.<br />

Ein anderer Nachteil von manuellen Diagnoseregeln<br />

ergibt sich aus der Komplexität auf Systemebene: Während<br />

es für einzelne Aggregate noch möglich ist die<br />

Symptom Anomalie Regeln manuell aufzustellen, ist<br />

dies aufgrund der Kombinatorik für Systeme mit vielen<br />

Abhängigkeiten nicht mehr möglich. Im schlimmsten<br />

Fall muss die Software zwischen allen Kombinationen<br />

von Symptomen differenzieren.<br />

Modellbasierte Ansätze, siehe rechte Seite von Bild<br />

6, gehen daher anders vor [4-6]: Sie vergleichen die Vorhersagen<br />

eines Verhaltensmodells mit den Beobachtungen<br />

des Systems. Ergeben sich Diskrepanzen wie<br />

ein schlechter Energieverbrauch, so wird der Benutzer<br />

darüber informiert.<br />

Allerdings stellt sich die Frage, woher das Verhaltensmodell<br />

kommt. Eine manuelle Modellierung führt<br />

zu allen im Abschnitt 1 behandelten Nachteilen. Aus<br />

diesem Grund geht das BMBF-Projekt Ava [21] anders<br />

vor: Die Modelle werden in Form von zeitbehafteten<br />

hybriden Automaten automatisch anhand von Systembeobachtungen<br />

gelernt. Bild 7 zeigt ein Beispiel: Ein<br />

Verhaltensmodell für ein Modul der Lemgoer Modellfabrik,<br />

siehe Foto in Bild 7, wurde automatisch anhand<br />

von Systembeobachtungen erlernt. Solche Lernverfahren<br />

für Automaten sind ein aktuelles Forschungsgebiet.<br />

Interessant sind für die Automation dabei Verfahren,<br />

die nur Positivbeispiele verwenden. Für große Systeme<br />

existieren Verfahren, die die Anzahl der Zustände minimieren,<br />

zum Beispiel ein Verfahren zum Lernen von<br />

zeitbehafteten Automaten [32] und aus dem Ava-Projekt<br />

ein Verfahren für hybride Automaten [8]. Andere Verfahren<br />

arbeiten mit dem gegebenen Zustandsraum der<br />

IO-Signale [31].<br />

Das Anomalieerkennungssystem vergleicht nun gelerntes<br />

Modell und Systemverhalten: Während der<br />

Zustände 0 bis 4 in Bild 7 verhalten sich Modell und<br />

System identisch, im Zustand 4 tritt aber ein unbekanntes<br />

Signal auf. Dieses wird als Anomalie dem<br />

Benutzer mitgeteilt. In diesem Beispiel liegt ein Programmierfehler<br />

vor. Der Benutzer gibt also nur noch<br />

deskriptiv vor, welche Art von Anomalie (beispielsweise<br />

Zeit-, Energie- oder Sensoranomalie) ihn interessiert<br />

und mit welcher Empfindlichkeit das System<br />

reagieren soll.<br />

Bild 8 zeigt den Vergleich: Da im Fall der deskriptiven<br />

Automation der Automatisierer nur noch die Analyseziele<br />

formuliert, schneidet die deskriptive Automation<br />

klar besser ab. Ein Wermutstropfen bleibt aber: Das<br />

Vorgehen fällt und steigt mit der Möglichkeit, Verhaltensmodelle<br />

automatisch zu erlernen. Erste Ergebnisse<br />

zeigen, dass dies für reale Anlagen möglich ist [8, 18,<br />

31]. Das Thema bleibt aber ein Forschungsgegenstand,<br />

und es ist noch ein weiter Weg hin zu einer kommerziellen<br />

Umsetzung in Werkzeugen.<br />

3. VERGLEICH FÜR DIE UMBAUPHASE<br />

Die Umbauphase wurde eingangs schon kurz erwähnt.<br />

In der <strong>modellbasierte</strong>n <strong>Softwareentwicklung</strong>, siehe<br />

linke Seite von Bild 2, läuft ein Anlagenumbau bislang<br />

zumeist wie folgt ab: Nachdem der mechanische Anlagenumbau<br />

abgeschlossen ist, werden neue Geräte<br />

wie Sensoren, Aktoren und Steuerungen im Netzwerk<br />

angeschlossen. Dies beinhaltet zumeist eine Umkonfiguration<br />

des Netzwerkes. Nun müssen alle angeschlossenen<br />

Steuerungen ebenfalls geändert werden,<br />

um die neue Netzwerkkonfiguration zu berücksichtigen<br />

und um neue Kommunikationsbeziehungen, zum<br />

Beispiel zu neuen Anlagenmodulen, aufzubauen. Oft<br />

werden Steuerungsalgorithmen angepasst und Parameter<br />

geändert, wie Zykluszeiten in den Steuerungen.<br />

Des Weiteren erfolgt eine Anpassung in höheren<br />

Schichten, wie OPC-Servern, Leittechnik und MES-<br />

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

5 / 2014<br />

27


HAUPTBEITRAG<br />

Systemen. All diese Schritte sind mit einem hohen<br />

Entwicklungs- und Testaufwand verbunden. Selbst<br />

bei Verwendung höherwertiger Modelle [14, 16], aus<br />

denen sich viele dieser Einstellungen generieren lassen,<br />

verbleibt ein manueller Engineering-Aufwand in<br />

jedem Umbauzyklus.<br />

Die deskriptive Automation, rechte Seite Bild 2, geht<br />

anders vor. Sie beschreibt nur das gewünschte Endprodukt.<br />

Bei vielen Anlagenumbauten, wie dem Austausch<br />

eines Produktionsmoduls, bleibt dieses Ziel konstant,<br />

das heißt, eine manuelle Änderung der Automation ist<br />

nicht notwendig. In anderen Fällen, wie der Variation<br />

des Produkts muss nur die Produktbeschreibung angepasst<br />

werden. In jedem Fall verringert sich der Aufwand<br />

erheblich.<br />

Solche Ansätze erforscht aktuell das vom BMBF geförderte<br />

Spitzenclusterprojekt itsowl-IV [22]. Bild 9<br />

zeigt das Vorgehen bei diesem Projekt: Der Experte modelliert<br />

nicht mehr die Automationssoftware. Stattdessen<br />

modelliert er das Endprodukt und den Prozess. Der<br />

Prozess besteht dabei aus typisierten Prozessschritten,<br />

wobei jeder Prozessschritt als Ein- und Ausgaben Zwischenprodukte<br />

und Ressourcen aufweist. Aus dieser<br />

Beschreibung wird die Automationssoftware automatisch<br />

generiert, zum Beispiel in Form einer Verschaltung<br />

und Parametrisierung von vorgegebenen Softwarekomponenten.<br />

Bild 10 zeigt die beiden Ansätze für diesen Fall: Anstatt<br />

die Softwareänderungen in allen Modellen, wie<br />

zum Beispiel nach IEC 61131, einzupflegen, formalisiert<br />

der Experte beim deskriptiven Ansatz nur das<br />

Produkt und, wie im Fall des Projektes itsowl-IV, auch<br />

den Prozess. Hierdurch entfällt der Testaufwand. Die<br />

Vorteile des deskriptiven Ansatzes basieren auf der<br />

abgesicherten und getesteten Generierung der Software<br />

auf Basis der Produkt- und Prozessmodelle. Hierzu<br />

müssen entsprechende Modelle entweder von den<br />

Maschinen- und Anlagenbauern oder von den Werkzeugherstellern<br />

kommen. Des Weiteren müssen die<br />

Werkzeug- und Gerätehersteller die neuen Verfahren<br />

umsetzen. Genau hier liegen die aktuellen Fragestellungen<br />

der Forschung. Im Projekt itsowl-IV werden<br />

BILD 9: Generierung von<br />

Automatisierungssoftware<br />

anhand einer Produkt- und<br />

Prozessbeschreibung<br />

BILD 10: Vergleich der<br />

beiden Ansätze für den Fall<br />

des Anlagenumbaus<br />

Anlagenumbau Modellbasierte Software-Entwicklung Deskriptives Vorgehen<br />

Aufwand<br />

Ansprüche an<br />

Automatisierer<br />

Testaufwand<br />

Automatisierer: hoch, da viele manuelle Aktionen in<br />

den Engineeringwerkzeugen notwendig sind<br />

Werkzeughersteller/Anlagenbauer/<br />

Gerätehersteller: wie bislang<br />

Experte muss über IT-, Netzwerk-, Software-,<br />

Automations- und Prozesswissen verfügen<br />

Automatisierer: alle betroffenen<br />

Steuerungen müssen i. A. neu getestet werden<br />

Werkzeughersteller: wie bislang<br />

Automatisierer: niedrig<br />

Werkzeughersteller/Anlagenbauer/<br />

Gerätehersteller: hoch, da (i) Methoden aufwendig<br />

und (ii) Prozess- und Produktmodelle nötig sind<br />

Experte muss Produkt und<br />

zum Teil den Prozess kennen<br />

Automatisierer: gering, wenn Software-<br />

Generierung abgesichert ist<br />

Werkzeughersteller: hoch<br />

28<br />

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

5 / 2014


derzeit als Lösung Planungsalgorithmen und fallbasierte<br />

Ansätze untersucht.<br />

FAZIT<br />

Die <strong>modellbasierte</strong> <strong>Softwareentwicklung</strong> und die deskriptive<br />

Automation sind zwei grundverschiedene<br />

Ansätze zur Umsetzung von <strong>Industrie</strong> <strong>4.0</strong>. Während der<br />

erste Ansatz Methoden entwickelt, damit ein Experte<br />

die Software möglichst bequem und sicher modellieren<br />

kann, setzt der deskriptive Ansatz auf eine Beschreibung<br />

des Produktziels. Die Software wird dabei aber<br />

nicht modelliert sondern generiert.<br />

Beim deskriptiven Ansatz spielen ebenfalls Modelle<br />

eine zentrale Rolle. Sie beschreiben nun aber das<br />

Produkt, zum Teil den Prozess, und sie spezifizieren<br />

Optimierungsziele, wie Durchsatz und Energieverbrauch.<br />

Da sie aber die Software nicht statisch modellieren,<br />

kann der dadurch gewonnene Freiraum zur<br />

Umsetzung von Adaptivität (Abschnitt 1 und 2), von<br />

Qualitätsverbesserung (Abschnitt 2) und von Aufwandsoptimierung<br />

beim Engineering (Abschnitt 1<br />

und 3) genutzt werden. Denn genau in diesem Freiraum<br />

zwischen deskriptiv beschriebenem Produktionsziel<br />

Was und fixer Ablaufsteuerung in der Automation<br />

Wie arbeiten wissensbasierte Methoden, wie<br />

Selbstkonfiguration, Selbstdiagnose und Selbstoptimierung.<br />

Die behandelten Beispiele verdeutlichen, dass die<br />

<strong>modellbasierte</strong> <strong>Softwareentwicklung</strong> reifer und weiter<br />

entwickelt ist. Zur Umsetzung der deskriptiven<br />

Automation muss die Forschung noch diverse offene<br />

Forschungsfragen lösen: 1. Die Formalismen für Produkte,<br />

Prozesse und Optimierungsziele sind noch<br />

Forschungsgegenstand und noch nicht standardisiert.<br />

2. Es fehlen Methoden zum automatischen Modelllernen.<br />

3. Auf Basis der deskriptiven Beschreibung muss<br />

die Automationssoftware automatisch generiert werden.<br />

Hier fehlen abgesicherte Methoden der Softwa-<br />

REFERENZEN<br />

[1] Faltinski, S., Niggemann, O., Moriz, N., Mankowski, A.:<br />

AutomationML: From Data Exchange to System Planning and<br />

Simulation. In: Tagungsband IEEE International Conference<br />

on Industrial Technology (ICIT), S. 378-383. IEEE 2012<br />

[2] Graeser, O., Kumar, B., Moriz, N., Maier, A., Niggemann, O.:<br />

AutomationML as a Basis for Offline- and Realtime-Simulation.<br />

In: Tagungsband 8th International Conference on<br />

Informatics in Control, Automation and Robotics (ICINCO),<br />

S. 359-368. IEEE 2011<br />

[3] VDMA: Management summary 2012 - importance of information<br />

and automation technology in the products of manufacturing<br />

systems, engineering and plant engineering. VDMA 2012<br />

[4] Isermann, R.: Model-based fault detection and diagnosis<br />

- status and applications. In: Tagungsband 16th IFAC<br />

Symposium on Automatic Control in Aerospace, S. 71-85.<br />

IFAC 2004<br />

[5] Struss, P., Ertl, B.: Diagnosis of bottling plants - first success<br />

and challenges. In: Tagungsband The 20th International<br />

Workshop on Principles of Diagnosis (DX). 2006<br />

[6] Christiansen, L., Fay, A., Opgenoorth, B., Neidig, J.: Improved<br />

Diagnosis by Combining Structural and Process Knowledge.<br />

In: Tagungsband IEEE Conference on Emerging Technologies<br />

& Factory Automation ETFA, S. 1-8. IEEE 2011<br />

[7] Windmann, S., Jiao, S., Niggemann, O., Borcherding, H., A:<br />

Stochastic Method for the Detection of Anomalous Energy<br />

Consumption in Hybrid Industrial Systems. In Tagungsband<br />

IEEE 11th International Conference on Industrial Informatics<br />

- INDIN. IEEE 2013<br />

[8] Niggemann, O., Stein, B., Vodencarevic, A., Maier, A.:<br />

Learning behavior models for hybrid timed systems.<br />

In: Tagungsband Twenty-Sixth Conference on Artificial Intelligence<br />

(AAAI-12), S. 1083-1090. AAAI 2012<br />

[8] Li, H., Yin, B., Li, N., Guo, J.: Research of fault diagnosis method of analog<br />

circuit based on improved support vector machines. In: Tagungsband 12nd<br />

International Conference on Industrial Mechatronics and Automation<br />

(ICIMA), S. 494 –497. IEEE 2010<br />

[10] Stahl, T., Völter, M., Efftinge, S.: Modellgetriebene <strong>Softwareentwicklung</strong>.<br />

Techniken, Engineering, Management. DPunkt-Verlag 2007<br />

[11] Cannata, A., Karnouskos, S., Taisch, M.: Energy efficiency driven process<br />

analysis and optimization in discrete manufacturing. In: Tagungsband<br />

35th Annual Conference of IEEE Industrial Electronics IECON ‚09,<br />

S. 4449-4454. IEEE 2009<br />

[12] Maurmaier, M.: Leveraging model-driven development for automation<br />

systems development, Emerging Technologies and Factory Automation.<br />

In: Tagungsband IEEE International Conference on Emerging Technologies<br />

and Factory Automation (ETFA), S. 733-737. IEEE 2008<br />

[13] Streitferdt, D., Wendt, G., Nenninger, P., Nyssen, A., Lichter, H.: Model<br />

Driven Development Challenges in the Automation Domain, Computer<br />

Software and Applications. In: Tagungsband 32nd Annual IEEE International<br />

Computer Software and Applications Conference COMPSAC ‚08,<br />

S. 1372-1375. IEEE 2008<br />

[14] Papakonstantinou, N., Sierla, S., Koskinen, K.: Object oriented extensions<br />

of IEC 61131–3 as an enabling technology of software product lines. In:<br />

Tagungsband IEEE 16th Conference on Emerging Technologies & Factory<br />

Automation (ETFA), S.1-8. IEEE 2011<br />

[15] Thramboulidis, K., Frey, G.: An MDD process for IEC 61131-based<br />

industrial automation systems. In: Tagungsband IEEE 16th Conference on<br />

Emerging Technologies & Factory Automation (ETFA), S. 1-8. IEEE 2011<br />

[16] Witsch, D., Vogel-Heuser, B.: Close integration between UML and IEC<br />

61131-3: New possibilities through object-oriented extensions.<br />

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

5 / 2014<br />

29


HAUPTBEITRAG<br />

AUTOR<br />

Prof. Dr. OLIVER NIGGEMANN (geb. 1971)<br />

ist seit 2008 Professor der Informatik am<br />

Institut Industrial IT (inIT) der Hochschule<br />

OWL. Er studierte Informatik in<br />

Paderborn, wo er 2001 auch promovierte.<br />

Er ist auch stellvertretender Leiter des<br />

Fraunhofer-Anwendungszentrums<br />

Industrial Automation (IOSB-INA) in<br />

Lemgo. Seine aktuellen Forschungsschwerpunkte<br />

liegen im Einsatz von Methoden der künstlichen<br />

Intelligenz und des maschinellen Lernens im Gebiet<br />

der industriellen Automation.<br />

regenerierung. Es ist unklar, wie eine Migration von<br />

der klassischen Engineering-Kette hin zu einer Werkzeugkette<br />

der deskriptiven Automation gelingen kann.<br />

Dies liegt unter anderem daran, dass eine Verlagerung<br />

von Aufwand weg vom Automatisierer und hin zu den<br />

Maschinen- und Anlagenbauern, den Geräte- und den<br />

Werkzeugherstellern geschehen muss. Diese Bestrebung<br />

lohnt, da dadurch der Aufwand nur noch einmalig<br />

an zentralen Stellen entsteht und nicht mehr<br />

neu bei jedem Betreiber.<br />

MANUSKRIPTEINGANG<br />

05.12.2013<br />

Im Peer-Review-Verfahren begutachtet<br />

Fraunhofer-Anwendungszentrum Industrial Automation (IOSB-INA),<br />

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

Tel. +49 (0) 5261 702 59 90,<br />

E-Mail: oliver.niggemann@iosb-ina.fraunhofer.de<br />

REFERENZEN<br />

In: Tagungsband IEEE Conference on Emerging Technologies & Factory<br />

Automation ETFA, S. 1-6. IEEE 2009<br />

[17] Drath, R., Weidemann, D., Lips, S., Hundt, L., Lüder, A., Schleipen, M.:<br />

Datenaustausch in der Anlagenplanung mit AutomationML. Springer 2010<br />

[18] Niggemann, O., VodenÐareviÐ, A., Maier, A., Windmann, S., Kleine Büning,<br />

H.: A Learning Anomaly Detection Algorithm for Hybrid Manufacturing<br />

Systems. In: Tagungsband The 24th International Workshop on Principles<br />

of Diagnosis (DX). 2013<br />

[19] Initialprojekt NRW Innovationszentrum Industrial IT − Höhere Produktivität<br />

durch den <strong>modellbasierte</strong>n Entwurf und Betrieb von komplexen<br />

Automatisierungssystemen: http://www.hs-owl.de/init/research/<br />

projects/b/filteroff/139/single.html<br />

[20] EfA: Entwurfsmethoden für Automatisierungssysteme mit Modellintegration<br />

und automatischer Variantenbewertung: http://www.hs-owl.de/init/<br />

research/projects/b/filteroff/209/single.html<br />

[21] AVA: Abstraktion von Verhaltensmodellen für Anlagen des Maschinenbaus<br />

aus Messungen in verteilten Automatisierungssystemen:<br />

http://www.hs-owl.de/init/research/projects/b/filteroff/231/single.html<br />

[22] Spitzencluster it’s OWL Projekt itsowl-IV: Clusterquerschnittsprojekt<br />

Intelligente Vernetzung: http://www.hs-owl.de/init/research/projects/b/<br />

filteroff/213/single.html<br />

[23] Pech, Stephan: Software Agents in Industrial Automation Systems.<br />

IEEE Software vol. 30, S. 20-24. IEEE 2013<br />

[24] Mubarak, H., Göhner, P.: Einsatz von Agenten für das Selbstmanagement von<br />

Automatisierungssystemen. In: Tagungsband Multikonferenz Wirtschaftsinformatik<br />

MKWI 2010, S. 167-168. Universitätsverlag Göttingen 2010<br />

[25] Schraufstetter, M., Vogel-Heuser, B.: Konzept zur Erhöhung der Flexibilität von<br />

Produktionsanlagen durch den Einsatz rekonfigurierbarer Anlagenkomponenten<br />

und echtzeitfähiger Softwareagenten. In: Informatik aktuell: Echtzeit 2011<br />

- Herausforderungen durch Echtzeitbetrieb, S. 121-130. Springer 2011<br />

[26] Felleisen, M., Ulrich, A., Fay, A., Enste, U., Polke, B.: Formalisierte<br />

Prozessbeschreibung in der praktischen Anwendung. 1. Teil:<br />

Erstellen einer Prozessbeschreibung nach VDI/VDE-Richtlinie 3682.<br />

Automatisierungstechnische Praxis Heft 9/2009, S. 46-51, 2009<br />

[27] Döbrich, U., Heidel, R.: Modell zur Beschreibung cyber-physischer<br />

Systeme - Modellierung mit Merkmalen unterstützt<br />

<strong>Industrie</strong> <strong>4.0</strong>. <strong>atp</strong> <strong>edition</strong> 12/2013, S. 38-45, 2013<br />

[28] Pfrommer, J., Schleipen, M., Beyerer, J.: Fähigkeiten adaptiver<br />

Produktionsanlagen. <strong>atp</strong> <strong>edition</strong> 11/2013, S. 42-49, 2013<br />

[29] Angelsmark, O., Malec, J., Nilsson, K., Nowaczyk, S., Prosperi,<br />

L.: Knowledge Representation for Reconfigurable Automation<br />

Systems. In: Tagungsband International Conference on Robotics<br />

and Automation (ICRA-07) Workshop on Semantic Information<br />

in Robotics, S. 1-9. IEEE 2007<br />

[30] Kainz, G., Keddis, N., Pensky, D., Buckl, C., Zoitl, A., Pittschellis,<br />

R., Kärcher, B.: AutoPnP – Plug-and-produce in der Auto mation:<br />

Wandelbare Fabrik als cyberphysisches System. <strong>atp</strong> <strong>edition</strong><br />

04/2013, S.42-49, 2013<br />

[31] Schneider, S., Litz, L.: Automatische Fehlerdiagnose SPSgesteuerter<br />

Anlagen - Von der Beobachtung zu den Fehlerkandidaten.<br />

<strong>atp</strong> <strong>edition</strong> 07-08/2013, S.54-61, 2013<br />

[32] Verwer, S.: Efficient Identification of Timed Automata: Theory<br />

and Practice. Dissertation, Delft University of Technology 2010<br />

[33] Kleiner, S., Kramer, C.: Model based Design with System<br />

Engineering Based on RFLP V6. Smart Product Engineering,<br />

S. 93-102. Springer Verlag 2013<br />

[34] Niggemann, O., Stroop, J.: Models for Model‘s Sake. In:<br />

Tagungsband 30th International Conference on Software<br />

Engineering (ICSE) - Experience Track on Automotive Systems,<br />

S. 561-570. IEEE 2008<br />

30<br />

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

5 / 2014


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 <strong>Industrie</strong>verlag GmbH, Arnulfstr. 124, 80636 München<br />

WISSEN FÜR DIE<br />

ZUKUNFT<br />

Vorteilsanforderung per Fax: +49 Deutscher 931 <strong>Industrie</strong>verlag / 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 <strong>ohne</strong> 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 <strong>Industrie</strong>verlag oder vom Vulkan-Verlag per Post, per Telefon, per Telefax, per E-Mail, nicht über interessante, fachspezifische Medien und Informationsangebote informiert und beworben werde.<br />

Diese Erklärung kann ich mit Wirkung für die Zukunft jederzeit widerrufen.


HAUPTBEITRAG<br />

Engineering-Effizienz<br />

automatisch messen<br />

Definition, Erfassung und Visualisierung<br />

Engineering ist ein wesentlicher Kostenfaktor in der Automatisierung. Daher suchen<br />

<strong>Industrie</strong> und Akademia gemeinsam nach Methoden, um die Engineering-Effizienz<br />

zu erhöhen. Leider ist es nicht möglich, solche Methoden objektiv, systematisch,<br />

reproduzierbar und vergleichbar zu bewerten, weil sich Engineering-Effizienz bisher<br />

einer systematischen Messung entzieht. Dieser Beitrag schlägt erstmals einen Ansatz<br />

zur automatischen Messung und Visualisierung der Effizienz von Engineering-Methoden<br />

vor, der in Engineering-Werkzeuge eingebettet werden kann. Im Fokus steht<br />

dabei die Bewertung der Engineering-Methode, nicht des Menschen. Das Konzept<br />

ist auf beliebige Engineering-Werkzeuge übertragbar.<br />

SCHLAGWÖRTER Engineering / Effizienz / Methoden / Konzepte / Effizienzmessung<br />

Automatically Measuring Engineering Efficiency –<br />

Definition, Registration and Visualisation<br />

Engineering is a key cost driver in automation. Therefore, both manufacturers and<br />

researchers are looking for ways to improve engineering efficiency. Unfortunately,<br />

it is not possible to examine new methods in an objective, systematic, reproducible<br />

or comparable way without being able to measure engineering efficiency. This contribution<br />

describes a novel approach for the automatic measurement and visualization<br />

of engineering efficiency which can be directly embedded in engineering tools.<br />

The present concept focuses on the engineering method rather than the efficiency<br />

of an individual engineer. It is applicable for any engineering tools.<br />

KEYWORDS Engineering / efficiency / measurement<br />

32<br />

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

5 / 2014


RAINER DRATH, CHRISTIAN MESSINGER, BEN SCHRÖTER, NUO LI,<br />

GEORG GUTERMUTH, ABB-Forschungszentrum Ladenburg<br />

Effizienz ist in vielen Bereichen des täglichen<br />

Lebens als Indikator für Fortschritt nicht mehr<br />

wegzudenken. Seien es der Wirkungsgrad von<br />

Solarzellen, die Akkulaufzeit von Handys, die<br />

Reichweite von Elektroautos, die Lichtausbeute<br />

von LED, der Kraftstoffverbrauch von Motoren, die<br />

Qualität von Meetings – selbst die Qualität des Schlafes<br />

oder von Erziehungsmethoden für Kinder sind Ziel von<br />

Effizienzverbesserungen. Das gilt ebenso für die Automatisierung.<br />

Die Anlagenplanung und ihre Durchführung ist aufwendig<br />

und mit über 50 Prozent der Kosten von Automatisierungsprojekten<br />

sehr kostenintensiv [1]. In jeder<br />

Planungsphase sind Ingenieure mit ihren jeweiligen<br />

Software-Werkzeugen beteiligt und arbeiten verzahnt<br />

mit Kollegen, Kunden, Subunternehmen und Lieferanten.<br />

Der Prozess erfordert eine umfangreiche Orchestrierung<br />

von Arbeitsabläufen, Mitarbeitern und Software-Werkzeugen.<br />

Das Erreichen hoher Qualität unter<br />

knappen zeitlichen und finanziellen Bedingungen birgt<br />

immer das Risiko verspäteter Inbetriebnahmen und<br />

geringer Margen. Allein um diesen Prozess zu beherrschen,<br />

definieren viele Systemintegratoren standardisierte<br />

Methoden, Werkzeuge und Workflows.<br />

Im Mittelpunkt stehen daher Bemühungen, die Kosten<br />

zu senken und die Wettbewerbsfähigkeit zu erhöhen.<br />

Neue Konzepte oder Normen zur Verbesserung der Engineering-Effizienz<br />

wie <strong>modellbasierte</strong> Ansätze [2,3], wissensbasierte<br />

Unterstützung [3-5], Automatisierung von<br />

Planungsaufgaben [6,7] oder zur Verbesserung der Interoperabilität<br />

[8-12] könnten sich jedoch deutlich leichter<br />

etablieren, wenn ihre Effizienzgewinne objektiv nachweisbar<br />

wären. Wie soll aber der Vorteil von Engineering-<br />

Methoden objektiv und systematisch mit existierenden<br />

Werkzeugen und Workflows bewertet werden, wenn sich<br />

die Effizienz einer systematischen Messung entzieht?<br />

1. DIE SCHWIERIGKEIT EINER OBJEKTIVEN MESSUNG<br />

Auf den ersten Blick ist Engineering-Effizienz leicht<br />

verständlich: Höhere Effizienz bedeutet dieselbe Engineeringaufgabe<br />

bei gleichem Ergebnis schneller und/<br />

oder kostengünstiger als vorher zu bewerkstelligen.<br />

Dies klingt überzeugend, ist aber bei näherer Betrachtung<br />

keineswegs einfach. Weil Engineering eine Wertschöpfungskette<br />

verwobener Aktivitäten darstellt, die<br />

eine Vielzahl technischer Disziplinen und Werkzeuge<br />

in Interaktion mit Personen unterschiedlicher Ausbildung<br />

und Denkschulen einschließt, hat Engineering-<br />

Effizienz viele Facetten und Hebel. Eine neue Methode<br />

kann beim Engineering scheinbar Zeit einsparen, erhöht<br />

jedoch unbemerkt den Zeitverbrauch oder das<br />

Risiko einer anderen Aktivität. Wird höhere Effizienz<br />

beim Programmieren, zum Beispiel durch sorgfältigere<br />

Dokumentation oder gründlicheres Testen reinvestiert,<br />

bleibt die höhere Effizienz verborgen.<br />

Das Optimum der Engineering-Effizienz bildet das<br />

gelegentlich geforderte Zero-Engineering. Die bestmögliche<br />

Umsetzung wäre eine Anlage von der Stange. Aber<br />

in der Realität sind Anlagen häufig Unikate und das<br />

zugehörige Engineering erfordert kreatives Austüfteln<br />

von Speziallösungen und Kompromissen statt Lösungen<br />

von der Stange. Individuell durchdachtes Engineering<br />

lohnt sich, denn jahrzehntelange Funktion und Profitabilität<br />

einer Anlage gelingen nur mit gutem Engineering.<br />

Insbesondere der Faktor Mensch, wie zum Beispiel das<br />

Verhalten des Kunden, die Qualifikation der Ingenieure,<br />

ihre Kommunikationskultur und individuelle Arbeitsweisen<br />

und Lernkurven, beeinflussen erheblich die<br />

Engineering-Effizienz. Viele dieser weichen Faktoren<br />

sind nicht messbar. Aus diesen Gründen ist die Messung<br />

der Engineering-Effizienz bis heute ungelöst und die<br />

Wirksamkeit neuer Methoden ist schwer zu beziffern.<br />

Dieser Beitrag schlägt einen Ansatz zur Messung vor.<br />

2. ASPEKTE DES ENGINEERING<br />

Aufgrund der Vielzahl von Arbeiten zur Verbesserung<br />

der Engineering-Effizienz sind typische Einflussfaktoren<br />

bereits bekannt. Der GMA FA 6.12 diskutiert im<br />

Rahmen des VDI/VDE 3695 [13] wesentliche Hebel und<br />

Aspekte mit hohem Einfluss auf Engineering-Effizienz.<br />

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

5 / 2014<br />

33


HAUPTBEITRAG<br />

Den dort vorgeschlagenen Kategorien folgend, werden<br />

von den Autoren fünf Faktoren behandelt, die die Effizienz<br />

beeinflussen.<br />

2.1 Hebel der Engineering-Effizienz<br />

a) Hebel Workflow<br />

Der Engineering-Workflow beschreibt den Rahmen zur<br />

Abwicklung des Engineering. Deren Effizienz wird beeinflusst<br />

von den verwendeten Prozessmodellen, der<br />

Komplexität des Workflows, der Anpassbarkeit an interne<br />

Geschäftsprozesse, die Zahl der Workflow-Schritte, beteiligte<br />

Personen und Werkzeuge sowie ihre Schnittstellen,<br />

die Zahl der vorgesehenen Schleifen, die Nutzerführung<br />

und das Wissen über die Abhängigkeiten zwischen<br />

den Aktivitäten. Ein wichtiger Teilaspekt ist das Änderungsmanagement.<br />

Viele Kunden ändern oder entwickeln<br />

ihre Spezifikationen während des Projektes. Änderungen<br />

in einer späten Phase können aufwändige Schleifen erzwingen,<br />

gefolgt von einer Welle an Iterationen in der<br />

gesamten Wertschöpfungskette. Der Hebel Workflow ist<br />

daher oft verborgen, aber von besonderer Bedeutung.<br />

b) Hebel Methoden<br />

Der methodische Werkzeugkasten des Ingenieurs zielt<br />

auf das wie des Engineering: Er umfasst zum Beispiel<br />

Beschreibungssprachen oder Wiederverwendungskonzepte.<br />

Quellen für Wiederverwendung können vergangene<br />

Projekte, das Kopieren/Einfügen innerhalb<br />

eines Projektes, Bibliotheken, wiederverwendbares<br />

Fachwissen oder Erfahrungen sein. Effiziente Wiederverwendung<br />

beinhaltet etliche Fragestellungen: Sind<br />

kundenspezifische Bibliotheken verfügbar? Welche<br />

Qualität haben die Artefakte? Welche Standards werden<br />

eingesetzt? Wie oft werden Vorlagen verwendet und<br />

in welchem Verhältnis steht deren Nutzung zur Entwicklung<br />

und Wartung der Vorlagen?<br />

c) Hebel Werkzeuge<br />

Die Nutzung von Software-Werkzeugen im Engineering<br />

ist Standard. Werkzeughersteller differenzieren ihre<br />

Werkzeuge durch Funktionalität und adressieren hierbei<br />

ganz wesentlich die Effizienz. Hierbei gibt es eine Vielfalt<br />

von Aspekten: Zeit zum Lernen des Tools, Zeit zum<br />

Erstellen und Suchen von Lösungen, Zeit zur Navigation,<br />

Zeit zum Datenaustausch, Werkzeugperformance, Projektstrukturierung<br />

bei zeitgleicher Bearbeitung durch<br />

mehrere Bediener, Usability, den Grad der Selbsterklärung,<br />

oder spezielle Effizienzfunktionen für Experten<br />

wie Plausibilitätsprüfungen, Undo, Hilfesysteme, Änderungsmanagement,<br />

Wizards und viele mehr.<br />

d) Hebel Organisation und Mensch<br />

Die Art, wie ein Projektteam strukturiert, räumlich<br />

verteilt und mit Mitarbeitern versehen ist, beeinflusst<br />

die Effizienz ebenfalls stark. Ein eingespieltes Team<br />

kann ein Projekt viel routinierter abwickeln als ein<br />

neues Team unerfahrener Kollegen. In der Praxis haben<br />

viele Teams einen Lead-Ingenieur und ein heterogenes<br />

Team unterschiedlicher Qualifikationsniveaus mit diffusen<br />

Auswirkungen auf die Effizienz. Weitere Aspekte<br />

der Erfahrung sind eine gute Balance von Wissen über<br />

alle Engineeringphasen hinweg, die Arbeitsauslastung,<br />

der Motivationsgrad oder die Kommunikationsfähigkeit.<br />

Auf höherer Ebene gilt für organisatorische, räumliche<br />

oder sprachliche Grenzen ähnliches.<br />

e) Hebel Kunde und Vertrag<br />

Die Profitabilität eines Projektes kann von diesem Aspekt<br />

mehr abhängen als von jedem anderen Aspekt. In<br />

der Praxis wird ein typischer Engineeringvertrag auf<br />

Basis des Preises unterschiedlicher Anbieter geschlossen.<br />

Aber viele Kunden ändern oder detaillieren ihre<br />

Spezifikationen während des Projektverlaufes – mit den<br />

oben beschriebenen Effekten. Die Engineering-Wertschöpfungskette<br />

reagiert sehr empfindlich auf Änderungen<br />

von Kundenanforderungen. Sinnvolle, vertragliche<br />

Vereinbarungen zum Change- oder Claimmanagement<br />

sind daher entscheidend.<br />

Die Vielzahl der Hebel und Unteraspekte verdeutlicht,<br />

dass Engineering-Effizienz von technischen und<br />

ebenso von organisatorischen, rechtlichen, kulturellen,<br />

wissensbedingten und kundenspezifischen Aspekten<br />

abhängt. Hinweise zur Ermittlung der Effizienz einer<br />

Organisation werden in [13] nur qualitativ anhand von<br />

Merkmalen gegeben, eine automatisch ausführbare<br />

Messmethode wird nicht verfolgt.<br />

2.2. <strong>Industrie</strong>lle Ansätze<br />

In der Praxis wird die Engineering-Effizienz zunächst<br />

über die gesamten Personalkosten eines Projektes ermittelt<br />

[14]. Dieser Ansatz funktioniert bei ähnlichen Projekten,<br />

bietet jedoch keine Vergleichbarkeit, weil er stark von der<br />

Projektgröße abhängt. Zudem sind keine Aussagen über<br />

die Effizienz einer bestimmten Methode ableitbar.<br />

Damit Effizienz vergleichbar wird, muss sie auf einen<br />

Bezugspunkt normalisiert werden. Ein in der Prozessautomatisierung<br />

verbreiteter Ansatz ist Effizienz = Anzahl<br />

der Signale (I/Os) pro Zeit, häufiger noch der Kehrwert:<br />

Zeit pro I/O [14]. Dieser Ansatz ist unabhängig von<br />

der Größe (gemessen in I/O) eines Projektes und umfasst<br />

sämtliche harten und weichen Faktoren eines Projektes<br />

im Methodenraum der Projektabwicklung. Methodisch<br />

ließe sich dieses Konzept für jede andere Form von typischen<br />

Engineering-Artefakten anwenden, beispielsweise<br />

Loops pro Zeit oder Zeit pro Loop. Der Nachteil<br />

ist dennoch fundamental: Die Komplexität eines I/O<br />

oder Loops fällt unterschiedlich aus und ist nicht immer<br />

vergleichbar. Beispielsweise benötigt ein Safety-Signal<br />

deutlich mehr Engineering als ein normales binäres<br />

Signal. Weiterhin ist entscheidend, ob die Liefergrenze<br />

nur das Programmieren der Funktionslogik oder das<br />

Gesamtsystem von Bedienoberfläche bis zur Installation<br />

der Geräte umfasst. Auch eine FDA-gerechte Dokumentation<br />

beeinflusst das Ergebnis erheblich.<br />

34<br />

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

5 / 2014


Effizienz ist folglich nicht nur durch Engineering-<br />

Methoden beeinflusst, die wir messen und verbessern<br />

möchten, sondern durch eine Vielzahl von Einflüssen<br />

im Umfeld eines von Menschen durchgeführten Prozesses.<br />

Mit den genannten Ansätzen greift die Effizienzmessung<br />

zu kurz. Sie sind gebunden an den Typ und die<br />

Größe der Projekte und erfordern detaillierte Hintergrundinformation<br />

zu ihrer Interpretation. Eine objektive<br />

und automatische Messung sowie ein belastbarer<br />

Vergleich unterschiedlicher Engineering-Methoden<br />

sind damit nicht möglich.<br />

2.3 Zielstellung der Arbeit<br />

Der im Beitrag vorgestellte Ansatz versteht sich als Mittel<br />

zur Bewertung und Förderung neuer Engineering-<br />

Methoden. Ziel dieser Arbeit ist die Entwicklung eines<br />

verallgemeinerbaren und automatisierbaren Ansatzes<br />

zur Messung von Engineering-Effizienz innerhalb von<br />

Software-Werkzeugen, mit dem sich die Vorteile unterschiedlicher<br />

Engineering-Methoden, Workflows oder<br />

anderer Hebel vergleichen lassen. Der Schwerpunkt<br />

dieser Arbeit liegt deshalb in der Bewertung der Engineering-Methode,<br />

nichtmessbare Einflüsse sollen bestmöglich<br />

neutralisiert werden. Es geht nicht darum,<br />

Engineering-Teams zu bewerten, sondern um eine Entscheidungshilfe<br />

bei der Einführung neuer Methoden.<br />

Die Beschränkung auf Software ist notwendig, denn<br />

automatisches Messen erfordert computerauswertbaren<br />

Zugriff auf Information, die es ermöglicht, den Engineeringfortschritt<br />

über die Zeit zu verfolgen. Die Messung<br />

soll reproduzierbare Ergebnisse liefern, auf andere<br />

Werkzeuge übertragbar sein und die Bewertung einzelner<br />

Aspekte erlauben. Die Anwendbarkeit der Methode<br />

soll sich universell auf alle werkzeugunterstützten Phasen<br />

des Engineering anwenden lassen, siehe Bild 1.<br />

3.1 Laborbedingungen<br />

Um die Abhängigkeit von der Projektgröße und der Art<br />

von Engineering-Artefakten zu eliminieren, schlagen die<br />

Autoren die Messung eines repräsentativen Benchmark-<br />

Projektes unter Laborbedingungen vor, siehe auch [14],<br />

das den kompletten Umfang einer Methode umfasst und<br />

alle typischen Engineering-Aktivitäten enthält. Eine<br />

wichtige These des Ansatzes besteht darin, unerwünschte<br />

Einflüsse wie Erfahrung, Lernkurven, Unsicherheiten<br />

im Umgang mit dem Werkzeug, Suchen oder Fehlermachen<br />

zu eliminieren und die Messung auf das Messobjekt<br />

zu fokussieren, indem die Durchführung des Benchmark-Projektes<br />

von einer ausreichenden Zahl von Ingenieuren<br />

solange wiederholt wird, bis ein hoher Routinegrad<br />

erreicht ist – erst dann beginnt die Messung. (Durch<br />

Erfassung der Projektwiederholungen lassen sich sogar<br />

Aussagen über die Lernkurve machen, denn manche<br />

Methoden sind besser lernbar als andere. Dieser Aspekt<br />

wird in Teil 2 des Beitrags noch ausführlicher behandelt.)<br />

Die Ergebnisse der so erfolgten Messung werden<br />

durch den Rahmen des Benchmark-Projektes objektiv<br />

und vergleichbar. In der Praxis lassen sich die Ergebnisse<br />

nur auf Projekte ähnlichen Typs übertragen.<br />

3.2 Messaufbau<br />

Die Messung erfordert ein Engineering-Werkzeug (oder<br />

mehrere), das im Rahmen des Benchmark-Projektes<br />

benötigt wird, eine Auswertesoftware, die während<br />

der Abarbeitung des Benchmarkprojektes Zugriff auf<br />

3. MESSUNG DER ENGINEERING-EFFIZIENZ<br />

Eine sinnvolle Messung von Effizienz erfordert das Fokussieren<br />

auf ein Messobjekt und zugleich das Eliminieren<br />

unerwünschter Einflüsse. Als Messobjekt wird<br />

ein Ansatz zur Verbesserung der Engineering-Effizienz<br />

verstanden, zum Beispiel eine neue Engineering-Methode,<br />

ein neuer Workflow, verbesserte Usability, ein<br />

neues Werkzeug oder eine neue Technologie. Anschließend<br />

sind alle unerwünschten Freiheitsgrade zu beschränken<br />

beziehungsweise zu normieren: die Projektgröße,<br />

die Art der Engineering-Artefakte, die Fertigkeit<br />

und Lernkurve des planenden Ingenieurs und der Einfluss<br />

von Fremdaktivitäten außerhalb des Messobjektes.<br />

Im Ergebnis wird reproduzierbar die bestmögliche<br />

Engineering-Effizienz, also der Grenzwert der Verbesserungspotenziale<br />

einer Methode ermittelt. Diese Messwerte<br />

sind in der Praxis nur im Bestfall erreichbar,<br />

erlauben aber einen zuverlässigen Vergleich.<br />

BILD 1: Phasen des Engineering nach [1]<br />

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

5 / 2014<br />

35


HAUPTBEITRAG<br />

die Engineering-Daten besitzt, eine Gruppe von Ingenieuren,<br />

die die Bearbeitung des Projektes durchführen<br />

sowie das Messobjekt (zum Beispiel eine Engineering-Methode),<br />

dessen Effizienz gemessen werden soll.<br />

Durch mehrfaches Üben des Benchmark-Projektes<br />

muss vor der Messung ein höchstmöglicher Routinegrad<br />

bezüglich des Werkzeuges, des Benchmark-Projektes<br />

und des Messobjekts sichergestellt werden.<br />

3.3 Erfassung der Projektkomplexität<br />

In einem Engineering-Werkzeug werden manuell oder automatisch<br />

Engineering-Artefakte erzeugt, beispielsweise<br />

Funktionsbausteine, grafische Elemente, Schrittketten,<br />

Hardwaremodule, globale Signalvariablen. Die Art der Artefakte<br />

hängt vom Werkzeug und vom Projekt ab. Da die<br />

Artefakte untereinander Abhängigkeiten besitzen, bedeuten<br />

mehr Artefakte in Näherung mehr Komplexität. Die Komplexität<br />

eines Projektes kann durch Zählen dieser Artefakte<br />

abgeschätzt werden und gilt für den Zeitpunkt der Messung.<br />

Diese Zahlen lassen sich als Vektor darstellen und<br />

vergleichen. Dieses Maß ist universell, weil es die werkzeugspezifische<br />

Vielfalt von Artefakten abbildet. Mehrere<br />

Messungen erfassen den Projektfortschritt über die Zeit.<br />

3.4 Absolute und relative Effizienz<br />

Betrachten wir einen Experten, der ein Funktionsblockdiagramm<br />

mit 20 Blöcken routiniert aber händisch innerhalb<br />

von fünf Minuten erzeugt und konfiguriert. Sein<br />

Kollege nutzt eine andere Methode: Er instanziiert binnen<br />

einer Minute eine Vorlage mit 25 Funktionsblöcken<br />

und löscht händisch fünf davon. Im Ergebnis kommen<br />

beide Experten zum selben Ergebnis, aber der zweite<br />

Kollege hat 5x weniger Zeit benötigt. Wer ist effizienter?<br />

Absolut betrachtet, ist der zweite Experte 5x effizienter.<br />

Relativ hingegen, innerhalb seiner Methode, hat der erste<br />

Experte geradlinig <strong>ohne</strong> jede Änderung gearbeitet, hocheffizient,<br />

<strong>ohne</strong> Verbesserungspotenziale. Der zweite Experte<br />

hingegen musste die Vorlage modifizieren, um sein<br />

Ziel zu erreichen. Innerhalb seines Methodenraumes<br />

war der erste Experte optimal effizient, wohingegen der<br />

zweite noch Verbesserungspotenziale besitzt.<br />

Die Autoren unterscheiden deshalb zwei grundsätzliche<br />

Arten der Effizienz: (a) die absolute Effizienz über<br />

unterschiedliche Methoden hinweg und (b) die relative<br />

Effizienz innerhalb eines Methodenraumes, die ein<br />

Maß für Verbesserungspotenziale darstellt.<br />

Auf den ersten Blick scheint die absolute Effizienz<br />

wichtiger, weil ihre Ergebnisaussagen global gültig<br />

sind. So haben manche Engineering-Methoden die Effizienz<br />

so verbessert, dass die Optimierung der alten<br />

Methode müßig wäre. Beispielsweise ist die massenhafte<br />

Generierung von Steuerungslogik mit Hilfe von<br />

Vorlagen bekanntermaßen viel effizienter als das händische<br />

Programmieren von Grund auf. Bei näherer Betrachtung<br />

ist jedoch die relative Effizienz von erhellender<br />

Bedeutung: Die Zahl bahnbrechender neuer<br />

Engineering-Methoden ist begrenzt und viele bedeutsame<br />

Methoden sind längst in Engineeringwerkzeugen<br />

verfügbar. Die Differenzierung erfordert die effiziente<br />

Ausführung der Engineering-Methoden, denn sie lassen<br />

sich effizient oder ineffizient umsetzen. Hier kommt<br />

die Methodenqualität und die Usability der beteiligten<br />

Werkzeuge zum Tragen. Der im Beitrag vorgeschlagene<br />

Ansatz verfolgt daher ausdrücklich beide Ansätze.<br />

3.5 Messung der absoluten Effizienz<br />

Absolute Effizienz wird gemessen, indem die Anzahl<br />

aller wesentlichen Engineeringartefakte (nicht nur I/O<br />

oder Loop, sondern auch Geräte, Funktionsbausteine,<br />

Diagramme) und die zugehörige Engineering-Zeit ermittelt<br />

werden. Da das Engineering von Artefakten in<br />

vielfältiger Hinsicht Zeit verbraucht, ist sicherzustellen,<br />

nur diejenige Zeit zu betrachten, die tatsächlich<br />

für die Erzeugung der zu messenden Engineering-Ergebnisse<br />

benötigt wird. Die Messung darf nur über die<br />

relevante Zeit pro Artefakt oder Aktivität erfolgen. Alle<br />

übrige Zeit ist zu detektieren und vorerst außer Acht zu<br />

lassen. Daraus lässt sich für jedes Artefakt die absolute<br />

Größe Zeit-pro-Artefakt ermitteln. Der vorgestellte Ansatz<br />

definiert die absolute Effizienz als Vektor all dieser<br />

Größen. Dieser lässt sich zeilenweise zwischen Engineering-Methoden<br />

vergleichen. Die absolute Effizienz<br />

ist somit methodenunabhängig. Alle hierfür benötigte<br />

Information ist automatisch im Werkzeug messbar.<br />

3.6 Messung der relativen Effizienz<br />

Relative Effizienz ist innerhalb eines Methodenraumes<br />

interessant. Sie gibt Auskunft darüber, wie effizient eine<br />

Methode bei routinemäßiger Ausführung ist. Methodenbedingte<br />

Ungeradlinigkeiten werden dadurch aufgedeckt.<br />

Ein geradliniges Vorwärtsengineering und Voranschreiten<br />

beim Erzeugen neuer Daten ist ein Indikator für eine<br />

effiziente Ausführung einer Engineeringmethodik, wohingegen<br />

das Ändern bereits zuvor geplanter Daten Ineffizienz<br />

bedeutet. Engineeringschleifen führen beispielsweise<br />

konzeptionell zu Zeitverlust. Das lässt sich messen.<br />

Die Obergrenze der relativen Effizienz wird in dem<br />

vorgestellten Ansatz dann erreicht, wenn eine Engineering-Aufgabe<br />

nach einer initialen Konfiguration <strong>ohne</strong><br />

jede nachträgliche Modifikation gelöst wird. Die bestmögliche<br />

relative Effizienz ist folglich ein Geradeaus-<br />

Engineering <strong>ohne</strong> Zweitmodifikationen.<br />

Die Autoren schlagen vor, relative Effizienz zu messen,<br />

indem die Anzahl von Nachfolge-Modifikationen in Engineering-Artefakten<br />

ermittelt wird, die zuvor bereits geplant<br />

wurden. Sie ist nur vergleichbar innerhalb desselben<br />

Methodenraumes, kann aber beispielsweise für unterschiedliche<br />

Werkzeuge untersucht werden. Für den Vergleich<br />

von Messungen ist zu beachten, dass bei unterschiedlichen<br />

Methoden nur die absolute Effizienz ver-<br />

36<br />

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

5 / 2014


gleichbar ist. Bei gleicher Methodik ist zusätzlich die relative<br />

Effizienz vergleichbar, gerade über Werkzeuge<br />

hinweg. So lässt sich die Auswirkung von Usability verschiedener<br />

Softwarewerkzeuge endlich objektiv bewerten.<br />

4. VORSCHLAG ZUR VISUALISIERUNG<br />

Eine Schlüsselfrage lautet: Wie lässt sich Effizienz grafisch<br />

abbilden und wie könnte ein Effizienzcockpit<br />

aussehen? Hierfür ist den Autoren aus der Literatur und<br />

Praxis keine Darstellung bekannt. Im Folgenden schlagen<br />

wir eine Reihe von Diagrammen vor, die Effizienz<br />

visuell greifbar darstellen und insbesondere Verbesserungen<br />

verständlich herausheben können.<br />

4.1 Darstellung der Projektkomplexität<br />

Projektkomplexität ist ein Vektor, der zeilenweise die<br />

absolute Anzahl der erzeugten Engineering-Artefakte<br />

zu einem Zeitpunkt enthält. Die Projektkomplexität ist<br />

selbst noch kein Maß für die Effizienz, aber sie ist die<br />

Basis für weitere Betrachtungen. Da im Projektverlauf<br />

neue Artefakte hinzukommen, ändert sich die Projektkomplexität<br />

mit der Zeit.<br />

Als geeignete grafische Darstellung wird ein Spinnendiagramm<br />

gemäß Bild 2 (Chart I) vorgeschlagen. Dieses Beispiel<br />

zeigt alle Artefakte: Steuerungen, Aktoren, Sensoren,<br />

grafische Elemente, Signale, Funktionsblöcke, Funktionsblockdiagramme<br />

und Schrittketten. Chart II zeigt die Komplexität<br />

desselben Projektes zu einem späteren Zeitpunkt.<br />

Zur Veranschaulichung von Veränderungen schlagen die<br />

Autoren eine Quotientenbildung aus Chart I und Chart II<br />

vor: Chart III demonstriert das Hervorspringen der Unterschiede.<br />

Diese Form der grafischen Darstellung ist universell<br />

und für jedes Werkzeug anwendbar: Die Auswahl der<br />

Artefakte ist jedoch anwendungsspezifisch und erfolgt mit<br />

der Entwicklung des Benchmark-Projektes.<br />

BILD 2: Visualisierung von Projektkomplexität<br />

4.2 Projektfortschritt über die Zeit<br />

Projektfortschritt ist die Änderung der Projektkomplexität<br />

über die Zeit, verursacht durch Hinzufügen oder<br />

Löschen von Artefakten. Zur Messung wird dazu in regelmäßigen<br />

Abständen der Vektor der aktuellen Projektkomplexität<br />

ermittelt. Bild 3 zeigt den Projektfortschritt<br />

in einem Diagramm: Jedem Artefakt sowie der Summe<br />

aller Artefakte ist jeweils eine Kurve zugeordnet. Phasen<br />

hoher Effizienz führen zu starkem Wachstum der Kurven,<br />

während geringe Effizienzphasen durch ein Innehalten<br />

oder gar Rückgang der Kurven erkennbar sind.<br />

Eine Interpretation dieser Kurven muss sorgfältig erfolgen.<br />

Fortschritt und Stillstand können zusammengehören,<br />

wenn beispielsweise ein Bulk-Import erfolgte und<br />

die erzeugten Artefakte noch verschaltet werden müssen.<br />

Eine Plateauphase oder ein moderater Rückschritt<br />

sind dann keine unproduktiven Zeiten, sondern gehören<br />

BILD 3: Fortschrittsdiagramm (absolute Zahlen)<br />

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

5 / 2014<br />

37


HAUPTBEITRAG<br />

BILD 4: Visualisierung<br />

der absoluten Effizienz<br />

BILD 5: Modifikationsdiagramm<br />

BILD 6: Aktivitäten-Diagramm<br />

zwingend zur Engineering-Methode. Dennoch gilt:<br />

Rückschritte weisen auf Verbesserungspotenziale hin.<br />

4.3 Absolute Effizienz<br />

Die absolute Effizienz basiert auf der Projektkomplexität,<br />

betrachtet jedoch nicht die Anzahl, sondern den durchschnittlichen<br />

Zeitverbrauch pro Artefakt. Dieser Vektor<br />

lässt sich ebenso in einem Spinnendiagramm visualisieren.<br />

Dieses Diagramm ist für die Ermittlung individueller<br />

Lernkurven anwendbar, aber nur für ein Benchmark-Projekt<br />

unter routinierten Messbedingungen reproduzierbar.<br />

Bild 4 zeigt dies für ein Benchmark-Projekt unter Verwendung<br />

verschiedener Methoden in zwei Spinnendiagrammen<br />

Chart I und Chart II. Die ermittelte Zeit ist die indi-<br />

viduell zu den Artefakten zugeordnete Zeit. Das dritte<br />

Spinnendiagramm beinhaltet wiederum den Quotienten<br />

beider Diagramme und visualisiert die Effizienzverbesserungen<br />

durch die neue Methode. Das Ergebnis ist überraschend:<br />

Das Diagramm kann den Einfluss der neuen Methode<br />

auf das gesamte Projekt abbilden. Für einige Artefakte<br />

sind Verbesserungen sichtbar, während sich für<br />

andereArtefakttypen Verschlechterungen ergeben.<br />

4.4 Relative Effizienz<br />

Modifikationen von bereits geplanten Artefakten werden<br />

als grundsätzlich destruktiv angenommen, beispielsweise<br />

das Löschen eines Funktionsblocks oder<br />

eines Sensors oder die Neujustierung von Parametern.<br />

38<br />

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

5 / 2014


Konfiguration (HMI), I/O Kommunikationskonfiguration<br />

(FDI), Systemadministration (Setup), Idle, None,<br />

External, Navigation zwischen Tools oder Ansichten,<br />

Check-Out (Testing) und Debugging. Das Diagramm ist<br />

eine wertvolle Quelle zur Evaluierung von Effizienz.<br />

Es zeigt Potenziale in der Erfahrung des Ingenieurs, mit<br />

der Usability, mit der Werkzeugperformance oder mit<br />

der Fragmentierung der Aktivitäten auf. In realen Projekten<br />

ist die Interpretation von Pausezeiten schwierig<br />

– es ist nicht entscheidbar, ob es unproduktive Zeiten<br />

sind, ob derzeit am Whiteboard gearbeitet wurde oder<br />

ob eine Unterbrechung durch einen Kollegen stattfand.<br />

In einem Benchmarkprojekt sind unter Laborbedingungen<br />

Pausezeiten als Produktivzeiten anzusehen.<br />

4.6 Wiederverwendung<br />

BILD 7: Wiederverwendungsdiagramm<br />

Dieser Indikator zeigt die Anzahl von Wiederverwendungen<br />

über die Zeit (Bild 7). Er erhöht sich, sobald ein<br />

Bibliothekselement instanziiert oder über Copy-and-paste<br />

innerhalb eines oder zwischen zwei Projekten, dupliziert<br />

wird. Dieser Indikator hilft, die Wiederverwendungsrate<br />

von Artefakten oder Bibliothekselementen zu analysieren.<br />

Dies erleichtert beispielsweise die Verwendungsraten einzelner<br />

Artefakte einzustufen oder geeignete Kandidaten<br />

für Bibliothekselemente zu identifizieren.<br />

4.7 Häufigkeit von Kommandoaufrufen<br />

BILD 8: Kommandodiagramm<br />

Während der Benutzung eines Engineering-Werkzeuges<br />

wählt der Bediener Menüeinträge (Kommandos) aus,<br />

um verschiedene Aktivitäten zu starten. Dieser Indikator<br />

(Bild 8) stellt die Benutzungsanzahl solcher Kommandos<br />

grafisch dar. So lassen sich wichtige Funktionen<br />

identifizieren und das hilft, den Zugriff und die<br />

Usability populärer Funktionen zu verbessern.<br />

ZUSAMMENFASSUNG<br />

Wird die Modifikationsrate über die Zeit abgetragen,<br />

entsteht ein Diagramm nach Bild 5, das die Anzahl<br />

modifizierter oder gelöschter Artefakte im Vergleich<br />

zum letzten Messpunkt zeigt. Dies ist ein Maß für die<br />

relative Effizienz. Gut sichtbar sind Perioden hoher Änderungsaktivitäten<br />

– ein Indikator für Verbesserungspotenziale.<br />

Die ideale Modifikationskurve liegt konstant<br />

bei Null, sie zeigt maximale relative Effizienz.<br />

4.5 Zeitlicher Verlauf von Aktivitäten<br />

Der Zeitverbrauch lässt sich darüber hinaus pro Aktivität<br />

ermitteln und gemäß Bild 6 darstellen. Im abgebildeten<br />

Beispiel werden folgende Aktivitäten unterschieden:<br />

Steuerungslogikengineering (Logic), HMI-<br />

Dieser Beitrag versteht sich als Konzept zur Bewertung<br />

und Förderung neuer Engineering-Methoden und stellt<br />

einen systematischen Ansatz vor, deren Effizienz und<br />

Kundennutzen innerhalb eines Werkzeuges oder einer<br />

Werkzeugkette objektiv und vergleichbar messen und<br />

visualisieren zu können. Dies soll den Transfer von<br />

Ideen aus der Wissenschaft in die Praxis unterstützen.<br />

Die Messung erfolgt unter Laborbedingungen und<br />

nicht im laufenden Projekt – dadurch werden unerwünschte<br />

Fremdeinflüsse auf die Effizienz sowie Überwachungsbedenken<br />

eliminiert. Die Einführung eines<br />

Benchmark-Projektes und das routinierte Ausführen des<br />

Engineering reduzieren den Einfluss des Menschen und<br />

führen zu tatsächlich vergleichbaren Ergebnissen. Die<br />

ermittelten Effizienzaussagen sind unter diesen Randbedingungen<br />

reproduzierbar, vergleichbar und entsprechen<br />

einem Engineering unter Optimalbedingungen.<br />

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

5 / 2014<br />

39


HAUPTBEITRAG<br />

AUTOREN<br />

Dr.-Ing. RAINER DRATH (geb. 1970) ist Program Manager<br />

im ABB Forschungszentrum Deutschland in Ladenburg.<br />

Er beschäftigt sich mit der Entwicklung neuer Konzepte<br />

und Methoden zur Verbesserung des Engineering von<br />

Automatisierungssystemen.<br />

ABB Forschungszentrum Ladenburg,<br />

Wallstadter Str. 59, D-68526 Ladenburg,<br />

E-Mail: rainer.drath@de.abb.com<br />

Dipl. Phys. GEORG GUTERMUTH (geb. 1969) ist Gruppenleiter<br />

im ABB Forschungszentrum Deutschland in Ladenburg.<br />

Er beschäftigt sich mit der Verbesserung von<br />

Workflows, Werkzeugen und Methoden des Engineering<br />

von Automatisierungs- sowie elektrischen Systemen.<br />

ABB Forschungszentrum Ladenburg,<br />

Wallstadter Str. 59, D-68526 Ladenburg,<br />

E-Mail: georg.gutermuth@de.abb.com<br />

Dipl. Inf. CHRISTIAN MESSINGER (geb. 1983) ist Scientist<br />

im ABB Forschungszentrum Deutschland in der Abteilung<br />

„Industrial Software and Applications“ und beschäftigt<br />

sich vor allem mit der Entwicklung und Verbesserung von<br />

Automation-Engineering Software.<br />

ABB Forschungszentrum Ladenburg,<br />

Wallstadter. Str. 59, D-68526 Ladenburg,<br />

E-Mail: christian.messinger@de.abb.com<br />

Dr. NUO LI (geb. 1981) ist wissenschaftliche Mitarbeiterin<br />

im ABB Forschungszentrum Deutschland in Ladenburg.<br />

Ihre Themenschwerpunkte liegen in der Anwendung von<br />

Software Engineering Technologien zur Verbesserung des<br />

Engineering Prozesses.<br />

ABB Forschungszentrum Ladenburg,<br />

Wallstadter Str. 59, D-68526 Ladenburg,<br />

E-Mail: nuo.li@de.abb.com<br />

Dr.-Ing. BEN SCHRÖTER (geb. 1977) ist Mitarbeiter der<br />

Entwicklung von speicherprogrammierbaren Steuerungen<br />

innerhalb der ABB Automation Products GmbH. Sein<br />

Arbeits schwerpunkt ist die Weiterentwicklung von<br />

PC-basierten Engineering-Werkzeugen im Umfeld der<br />

Fabrikautomatisierung.<br />

ABB Automation Products GmbH,<br />

Eppelheimer Straße 82, D-69123 Heidelberg,<br />

E-Mail: ben.schroeter@de.abb.com<br />

Doch ein Einsatz unter realen Bedingungen ist ebenso<br />

sinnvoll. Werden die dort ermittelten Messergebnisse<br />

mit Messungen aus dem Labor verglichen, ist die Differenz<br />

ein Wegweiser für Verbesserungspotenziale.<br />

Die kontinuierliche statistische Projektauswertung<br />

unter optimalen Laborbedingungen und die automatische<br />

Erzeugung der vorgeschlagenen Diagramme verspricht<br />

einen erhellenden, detaillierten und konkreten<br />

Einblick in den Engineering-Prozess.<br />

Bezüglich des Hebels Workflow aus Abschnitt 2.1 a<br />

hilft dieser Ansatz bei der Identifizierung von Modifikationszeiten<br />

nach einer Änderungsanforderung. Basierend<br />

auf den gemessenen Zeiten lassen sich beispielsweise<br />

Aussagen über die finanziellen und zeitlichen<br />

Auswirkungen von Änderungswünschen des<br />

Kunden treffen.<br />

Auch den Hebel Methoden aus Abschnitt 2.1 b deckt<br />

dieser Ansatz ab. Die Qualität und Kompatibilität von<br />

Artefakten wird im Modifikationsdiagramm gut sichtbar,<br />

die Anzahl der Wiederverwendungen wird direkt<br />

gemessen, das Verhältnis zwischen Wartung und Wiederverwendung<br />

von Artefakten ist ableitbar.<br />

Den Hebel Werkzeuge aus Abschnitt 2.1 c deckt dieser<br />

Ansatz ebenfalls gut ab. Alle Effizienzfunktionen eines<br />

Werkzeuges werden im Rahmen des Benchmarkprojektes<br />

erfasst, die Anwendung derselben Engineering-<br />

REFERENZEN<br />

[1] G. Gutermuth: Engineering, In Hollender, M. (Hrsg): Colla -<br />

borative Process Automation Systems, S. 156-182. ISA 2010<br />

[2] E. Estévez, M. Marcos: Automatic Model-driven approach<br />

for designing industrial control systems. Lecture Notes in<br />

Computer Science. 0302-9743 (Print) 1611-3349 (Online).<br />

Vol. 4758/2007, 2007, pp: 284-287. Springer<br />

[3] Li, F.; Gilz, T.; Steinhauer, M.; Vogel-Heuser, B.; Eigner, M.;<br />

Shea, K.: Supporting the multi-domain plant engineering<br />

process using engineering knowledge from formalized<br />

model-based libraries. In: International Conference on<br />

Production Research (ICPR), Stuttgart, 2011<br />

[4] S. Runde, A. Fay: Software Support for Building Automation<br />

Requirements Engineering - An Application of Semantic<br />

Web Technologies in Automation. IEEE Transactions on<br />

Industrial Informatics, 2011. DOI: 10.1109/TII.2011.2166784<br />

[5] Wiesner A et.al.: Wissensbasierte Integration und<br />

Konsolidierung von heterogenen Anlagenplanungsdaten.<br />

<strong>atp</strong> <strong>edition</strong>, 2010, 52(4), 48-58<br />

[6] M. Mertens and U. Epple. Plant Asset Management Functions<br />

driven by Property Models. IEEE Int. Conf. on Emerging<br />

Technologies and Factory Automation (ETFA), 2009<br />

[7] W. Schäfer, H. Wehrheim: The Challenges of Building<br />

Advanced Mechatronic Systems, In: Proc. “2007 Future of<br />

Software Engineering – Int. Conf. on Software Engineering”,<br />

Washington, DC, 2007, pp. 72-84<br />

40<br />

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

5 / 2014


www.<strong>atp</strong>-<strong>edition</strong>.de<br />

Jetzt bestellen!<br />

Methode in einem anderen Werkzeug würde die<br />

toolabhängigen Effizienzunterschiede aufdecken.<br />

Bezüglich des Hebels Organisation und Mensch<br />

aus Abschnitt 2.1 d definiert diese Metrik Regeln,<br />

wie die Lernkurve aus der Messung eliminiert wird,<br />

oder wie die Lernkurve experimentell explizit erfasst<br />

werden kann.<br />

Der Hebel Kunde und Vertrag aus Abschnitt 2.1 e<br />

hingegen wird kaum berücksichtigt, weil die Messung<br />

nur die Effizienz im Rahmen eines Werkzeuges<br />

oder einer Werkzeugkette messen kann. Da ein signifikanter<br />

Anteil der gesamten Automatisierungsplanung<br />

von der Angebotsphase bis zur Inbetriebnahme<br />

keinen Werkzeugbezug hat, kann er nicht in<br />

die Messung eingeschlossen werden. Probleme in<br />

diesem Bereich werden aber mit Sicherheit zu einer<br />

hohen Modifikationsrate führen.<br />

Der Ansatz deckt eine Vielzahl von werkzeugbezogenen<br />

Effizienzaspekten ab und stellt sie in Diagrammen<br />

vorteilhaft dar. Der Ansatz ist leicht auf<br />

andere Engineering-Werkzeuge portierbar und gibt<br />

eine solide Grundlage für die Definition und Berechnung<br />

spezifischer Engineering-Effizienz-KPI.<br />

Die Referenzklasse für die<br />

Automatisierungstechnik<br />

<strong>atp</strong> <strong>edition</strong> ist das Fachmagazin für die Automatisierungstechnik.<br />

Die Qualität der wissenschaftlichen Hauptbeiträge<br />

sichert ein strenges Peer-Review-Verfahren. Bezug zur<br />

automatisierungstechnischen Praxis nehmen außerdem<br />

die kurzen Journalbeiträge aus der Fertigungs- und Prozessautomatisierung.<br />

Sichern Sie sich jetzt diese erstklassige Lektüre! Als<br />

exklusiv ausgestattetes Heft oder als praktisches ePaper<br />

– ideal für unterwegs, auf mobilen Endgeräten oder zum<br />

Archivieren.<br />

Wählen Sie einfach das Bezugsangebot, das Ihnen zusagt:<br />

als Heft, ePaper oder Heft + ePaper!<br />

MANUSKRIPTEINGANG<br />

1<strong>4.0</strong>1.2014<br />

Im Peer-Review-Verfahren begutachtet<br />

[8] Drath R., Fay A., Barth M.: Interoperabilität von<br />

Engineering-Werkzeugen. In: at - Automatisierungstechnik<br />

9/2011, S. 598–607, Oldenbourg-Verlag, 2011<br />

[9] Drath R., Schröter B., Hoernicke M.: Datenkonsistenz im<br />

Umfeld heterogener Engineering-Werkzeuge. In:<br />

Automation 2011, VDI-Berichte 2143, S. S. 29–32,<br />

Langfassung auf Tagungs-CD (13 Seiten), VDI-Verlag, 2011<br />

[10] IEC 62714-1 CD norm draft AutomationML Architecture,<br />

www.iec.ch, 2011<br />

[11] T. Moser, S. Biffl: Semantic Tool Interoperability for<br />

Engineering Manufacturing Systems, In: Proceedings of<br />

the “IEEE Conference on Emerging Technologies and<br />

Factory Automation (ETFA)”, 2010, pp. 1-8<br />

[12] ISO 15926. Industrial automation systems and integration<br />

- Integration of life-cycle data for process plants<br />

including oil and gas production facilities<br />

[13] VDI-GMA 6.12: Engineering of industrial plants – Evaluation<br />

and optimization. VDI/VDE Richtlinie 3695, Parts 1-5,<br />

Berlin, Germany, 2010-2013<br />

[14] Gutermuth G.: Engineering Effizienz – eine wissenschaftliche<br />

Betrachtung. Präsentation im GMA-Arbeitskreis<br />

“durchgängiges Engineering”, VDI-Bezirksverein Bayern<br />

Nordost e.V., Germany, https://www.researchgate.net/<br />

publication/260417184_Engineering_bei_ ABB_eine_<br />

wissenschaftliche_Betrachtung, 11.7.2012<br />

<strong>atp</strong> <strong>edition</strong> erscheint in der DIV Deutscher <strong>Industrie</strong>verlag GmbH, Arnulfstr. 124, 80636 München


HAUPTBEITRAG<br />

Redundanz für<br />

verfügbare Systeme<br />

Design und Analyse<br />

Verfügbarkeit ist in der Automation ein nicht zu vernachlässigender Aspekt bei Design<br />

und Betrieb von Systemen. Ausfälle können zu unvorhergesehenen Problemen führen<br />

und verursachen meist hohe Kosten. Daher werden Redundanzkonzepte häufig in<br />

industriellen Applikationen und Systemen angewandt. Um derartige Konzepte entwerfen<br />

sowie effizient und effektiv umsetzen zu können, geben die Autoren im Beitrag<br />

auf Basis hierarchisch strukturierter Designelemente Leitlinien zur Definition von<br />

Anforderungen sowie zu Auswahl und Design eines passenden Redundanzmusters.<br />

Am Beispiel von Software-basierter Standby-Redundanz werden außerdem existierende<br />

Implementierungsalternativen aufgezeigt und analytisch ausgewertet. Auch<br />

hierbei ergeben sich Leitlinien zur Auswahl einer geeigneten Alternative.<br />

SCHLAGWÖRTER Redundanz / Verfügbarkeit / Modellierung / Designleitlinien<br />

Redundancy for Highly Available Systems –<br />

Design and Analysis<br />

Availability is a key aspect during the design and operation of industrial automation<br />

systems. Failures not only result in unanticipated problems but also often cause<br />

high costs. Therefore redundancy is often applied in industrial applications and<br />

systems. Drawing on hierarchically structured design elements, this article provides<br />

guidelines for requirement elicitation as well as for decision support and design of<br />

a suitable redundancy pattern. This allows for a well-directed and informed redundancy<br />

design as well as efficient and effective redundancy implementation according<br />

to system specific requirements. Furthermore, an overview is presented of implementation<br />

alternatives for software-based standby redundancy, with an analytical<br />

evaluation and comparison of these techniques. Guidelines are derived for selecting<br />

an appropriate alternative.<br />

KEYWORDS redundancy / availability / modeling / design guidelines<br />

42<br />

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

5 / 2014


THOMAS GAMER, STEFAN STATTELMANN, ABB Corporate Research, Research Area Software<br />

Ausfallzeiten in industriellen Produktionsanlagen<br />

verursachen meist sehr hohe Kosten.<br />

Vision Solutions [1] unterscheidet dabei zwischen<br />

geplanten und ungeplanten Ausfallszeiten<br />

mit Kosten von 1,6 Millionen Dollar pro<br />

Stunde im Bereich Produktion und bis zu 2,8 Millionen<br />

Dollar pro Stunde in der Energiebranche. Hierbei wurden<br />

direkte und indirekte Kosten sowie geplante und<br />

ungeplante Ausfallszeiten erfasst. Derartig hohe Kosten<br />

für Ausfälle – unabhängig davon, ob diese geplant oder<br />

nicht geplant sind – sowie sinkende Kosten für moderne<br />

Hardware, zum Beispiel eingebettete Systeme oder Multicore-Prozessoren,<br />

führen dazu, dass eine erhöhte Verfügbarkeit<br />

immer häufiger als gegeben vorausgesetzt<br />

wird. Verfügbarkeit beschreibt dabei die Fähigkeit eines<br />

Systems, den Betrieb auch bei Auftreten von Ausfällen<br />

einzelner Systembestandteile fortzusetzen. Gemessen<br />

wird die Verfügbarkeit als Prozentwert der Zeit, die ein<br />

System betriebsbereit ist und seine Funktion ausführt.<br />

Maschinensicherheit (Safety) gemäß IEC 61508 [2] wird<br />

in diesem Beitrag nicht betrachtet. Verfügbarkeit wird<br />

während des Betriebs meist durch das Vorhandensein<br />

von Redundanz und Fehlertoleranz erreicht. Alternativ<br />

kann Fehlerursachenvermeidung zur Design-Zeit eines<br />

Systems die Verfügbarkeit ebenfalls erhöhen. Im Beitrag<br />

liegt der Fokus auf Verfügbarkeit im Fehlerfall während<br />

des Betriebs, das heißt auf Fehlertoleranz, da sich Ausfälle<br />

nie gänzlich ausschließen lassen.<br />

In der Literatur und in der praktischen Anwendung<br />

existiert eine Vielzahl von Redundanzmustern, um die<br />

Verfügbarkeit von Systemen zu erhöhen. Diese Redundanzmuster<br />

unterscheiden sich in ihren Eigenschaften<br />

und sind daher in unterschiedlichen Situationen und<br />

Gegebenheiten jeweils passend oder unpassend. Bei der<br />

Auswahl des anzuwendenden Redundanzmusters<br />

muss daher eine Wahl auf Basis der Anforderungen und<br />

Randbedingungen getroffen werden. Um dies optimal<br />

zu unterstützen, beschreiben wir Designelemente Software-basierter<br />

Redundanz. Diese sollen den Entscheidern<br />

als Leitlinien dienen und dabei helfen, eine klare<br />

Vorstellung zu bekommen, welche Anforderungen sie<br />

tatsächlich an eine Verfügbarkeitslösung haben, beziehungsweise<br />

über welche Schlüsselanforderungen sie<br />

sich Gedanken machen müssen. Anhand dieser Leitlinien<br />

kann schließlich ein für die jeweiligen Schutzziele<br />

– im Sinne der benötigten Verfügbarkeit – geeignetes<br />

Redundanzmuster gewählt werden.<br />

Im zweiten Teil des Artikels wird aufgezeigt wie, aufbauend<br />

auf der Entscheidung für ein bestimmtes Redundanzmuster,<br />

eine geeignete Implementierungsalternative<br />

(Optimierung) gewählt werden kann. Hierzu<br />

werden die Optimierungen anhand verschiedener Kriterien<br />

ausgewertet, zum Beispiel Last oder Vorhersagbarkeit.<br />

Daraus ergeben sich wiederum Leitlinien zur<br />

Auswahl eines zu den Schutzzielen, Anforderungen<br />

und Systemgegebenheiten passenden Verfahrens. Als<br />

Beispiel wird die Analyse für Optimierungen der Zustandssynchronisierung<br />

auf Basis des Redundanzmusters<br />

Warm Standby durchgeführt.<br />

1. LEITLINIEN AUF BASIS VON DESIGNELEMENTEN<br />

Im Beitrag werden vorrangig Software-basierte Redundanzmuster<br />

betrachtet, da diese gängige Anforderungen<br />

erfüllen, zum Beispiel eine günstige Verfügbarkeitslösung<br />

<strong>ohne</strong> spezielle Hardwarebausteine, hohe<br />

Flexibilität, gute Erweiterbarkeit und Verwendung in<br />

dynamischen sowie verteilten Umgebungen – erfüllen.<br />

Zudem konzentrieren sich die Ausführungen auf die<br />

Verfügbarkeit von Controllern in der Automatisierung,<br />

da hier die bekannten Redundanzmuster Anwendung<br />

finden. Dennoch sollten für ein hoch verfügbares System<br />

sämtliche Systembestandteile und die Gesamtsicht<br />

zusätzlich analysiert werden. Viele der präsentierten<br />

Leitlinien sind dabei auch auf Systemebene anwendbar.<br />

Außerdem sind die Designelemente durch ihre hierarchische<br />

Struktur einfach auf weitere Systembestandteile,<br />

zum Beispiel die Kommunikationspfade zwischen<br />

Feldgeräten und Controllern, erweiterbar.<br />

Software-basierte Redundanz ist dadurch definiert, dass<br />

das gesamte Redundanzmanagement, beispielsweise die<br />

Synchronisierung des internen Zustands oder das Umschalten<br />

im Fehlerfall, in Software auf der Anwendungs-<br />

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

5 / 2014<br />

43


HAUPTBEITRAG<br />

ebene implementiert ist und auf Standard-Hardware (commercial<br />

off-the-shelf, COTS) aufsetzt. Spezielle Hardware-<br />

Komponenten, beispielsweise Memory Snooping oder<br />

Watchdogs, werden nicht vorausgesetzt. Software-basierte<br />

Redundanz kann folglich dennoch auf redundante Hardware,<br />

das heißt auf redundanten Controllern, aufbauen.<br />

Basierend auf empirischen Beobachtungen in der Automatisierungsbranche<br />

wird im Folgenden als Fehlermodell<br />

angenommen, dass Ausfälle primär auf das<br />

Versagen der Stromversorgung und der Netzwerkkommunikation<br />

zurückzuführen sind. Zudem können,<br />

wenn auch deutlich seltener, Hardwarefehler von Controllern<br />

zu Ausfällen führen. Letzteres muss vor allem<br />

bedacht werden, wenn zukünftig verstärkt Standard-<br />

Hardwarekomponenten genutzt werden sollen, da diese<br />

die Fehlerwahrscheinlichkeit erhöhen [3]. Hierbei<br />

wird immer angenommen, dass ein Controller im Gesamten<br />

ausfällt; teilweise Hardwarefehler sind kein<br />

gängiges Szenario, da deren Auswirkungen auf die restliche<br />

Hardware und die Ausführung der Kontrollapplikationen<br />

nur sehr schwer vorhersagbar sind. Zudem<br />

werden Fehler als permanent angenommen. Insgesamt<br />

stellt die Fokussierung auf Controller-Redundanz im<br />

Kontext des vorgestellten Fehlermodells keine Einschränkung<br />

dar, da sämtliche Ausfälle dazu führen,<br />

dass ein redundanter Controller benötigt wird.<br />

1.1 Redundanzmuster und ihre Eigenschaften<br />

In der Literatur sowie in industriellen Lösungen sind<br />

zahlreiche Redundanzmuster zu finden, die eingesetzt<br />

werden, um die Verfügbarkeit eines Systems mittels Fehlertoleranz<br />

zu erreichen. Beispiele sind Triple-Triple-<br />

Redundanz in einer Boing 777 [4], Triple Modular Redundancy<br />

(TMR) mit Voting [5], eine Kombination aus verteiltem<br />

Voting und Designdiversität [6] oder Standby-<br />

Redundanz basierend auf einem Master/Slave-Ansatz [7].<br />

Die am meisten verbreiteten Redundanzmuster sind dabei<br />

N-Modular-Redundanz, zu deren Familie die bereits<br />

genannte Ausprägung TMR gehört, sowie Standby-Redundanz<br />

in den Ausprägungen Cold, Warm und Hot<br />

Standby. Letztere Varianten beziehen sich auf die Ausführung<br />

des Standby-Controllers, welcher erst im Fehlerfall<br />

gestartet wird (Cold), gestartet ist und synchronisiert<br />

wird <strong>ohne</strong> die eigentliche Applikation auszuführen<br />

(Warm) beziehungsweise die Applikation parallel zur<br />

aktiven Instanz auf Basis derselben Inputs ausführt (Hot).<br />

In BILD 1 werden beispielhaft die Redundanzmuster<br />

Standby-Redundanz, heterogene Standby-Redundanz<br />

sowie N-Modular-Redundanz gegenübergestellt. Bei<br />

Standby-Redundanz führen beide Controller dieselbe<br />

Applikation mittels identischer Implementierungen aus.<br />

Controller 1 übernimmt dabei die Rolle des aktiven Controllers,<br />

der andere die des Standby-Controllers. Zudem<br />

erfolgt eine periodische Synchronisierung der beiden<br />

Applikationen, ausgehend vom aktiven Controller. Die<br />

Synchronisierung bezieht sich, je nach Variante des<br />

Redundanzmusters, auf den Zustand einer Applikation<br />

(Warm Standby) oder die Ausführung der Applikation<br />

(Hot Standby). Die heterogene Standby-Redundanz<br />

führt, im Gegensatz zur Standby-Redundanz, dieselbe<br />

Applikation mittels unterschiedlicher Implementierungen<br />

aus. Die Implementierungen werden dabei meist<br />

durch verschiedene Entwicklerteams auf Basis derselben<br />

Spezifikation erstellt. Aufgrund der unterschied-<br />

BILD 1: Gegenüberstellung beispielhafter Redundanzmuster<br />

44<br />

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

5 / 2014


lichen Versionen können mit diesem Redundanzmuster<br />

auch Softwarefehler toleriert werden. Dabei hängt der<br />

Grad der Toleranz von Softwarefehlern vom Grad der<br />

Heterogenität der Softwareversionen sowie der Implementierung<br />

der Fehlererkennung ab. Abschließend ist<br />

in Bild 1 noch die N Modular-Redundanz dargestellt,<br />

welche auf mehreren Controllern dieselbe Applikation<br />

mittels identischer Implementierung ausführt. Alle Applikationsinstanzen<br />

kommunizieren ihre Outputs dann<br />

an eine zusätzliche Voting-Komponente, welche durch<br />

einen Vergleich der Ergebnisse ein korrektes Ergebnis<br />

definiert und dieses ausgibt. Die Fehlererkennung und<br />

-toleranz ist hierbei, im Gegensatz zu den bisherigen<br />

Mustern, implizit durch den Voter gewährleistet.<br />

Wie bereits erwähnt, lassen sich die unterschiedlichen<br />

Redundanzmuster über ihre Eigenschaften beschreiben.<br />

Beispielhaft wurde dies für die genannten Muster in<br />

BILD 1 durchgeführt. Standby-Redundanz zeichnet sich<br />

durch geringe Hardwarekosten und die Synchronisierung<br />

von Zustand zwischen aktiver und passiver Instanz<br />

aus. Hierbei können bei Software-basierter Redundanz<br />

akzeptable Umschaltzeiten im Bereich weniger Millisekunden<br />

erreicht werden; allerdings wird eine zusätzliche<br />

Fehlererkennung benötigt, um ein Umschalten<br />

auszulösen. Die heterogene Standby-Redundanz bietet<br />

zusätzliche Verfügbarkeit im Falle von Softwarefehlern,<br />

verursacht allerdings hohe Entwicklungskosten und<br />

eine höhere Komplexität, zum Beispiel bei der Zustandssynchronisierung.<br />

Im Gegensatz zu diesen beiden Verfahren<br />

existiert bei der N-Modular-Redundanz kein<br />

explizites Umschalten; ein Fehler wird also derart maskiert,<br />

dass der Prozess keine Auswirkungen bemerkt.<br />

Dies wird durch die zusätzliche Voter-Komponente erreicht.<br />

Bei diesem Verfahren werden jedoch mehr Hardwareinstanzen<br />

benötigt, um Fehler eindeutig zu erkennen<br />

und zu maskieren. Eine solche Beschreibung existierender<br />

Redundanzmuster, beispielsweise basierend<br />

auf [8], ermöglicht eine informierte Auswahl des passenden<br />

Musters bei gegebenen Anforderungen.<br />

1.2 Beschreibung des Lösungsraums durch<br />

Designelemente<br />

Die im Folgenden beschriebenen Designelemente dienen<br />

dazu, den Lösungsraum für ein verfügbares beziehungsweise<br />

fehlertolerantes System mit redundanten Controllern<br />

darzustellen. Die Designelemente umfassen dabei<br />

funktionale (zum Beispiel Zykluszeit) und nicht-funktionale<br />

Anforderungen (wie Transparenz) sowie das<br />

zugrunde liegende Fehlermodell, Eigenschaften der<br />

Infrastruktur und Redundanz-bezogene Eigenschaften.<br />

Dabei dienen die hierarchisch strukturierten Designelemente<br />

als Basis für Leitlinien für das detaillierte Design<br />

der eigenen Redundanzlösung sowie für die strukturierte<br />

Ableitung von Anforderungen. Wird beispielsweise<br />

als Resultat der Anwendung unserer Designelemente<br />

und Leitlinien festgestellt, dass eine verfügbare<br />

Applikation (1) eine hohe Anzahl Zustandsvariablen<br />

und I/O-Kanäle (> 200 k) besitzt, die jeweils komplett zu<br />

synchronisieren sind, (2) die Kommunikationsverbindung<br />

nicht zur ausschließlichen Nutzung für die Synchronisierung<br />

zur Verfügung steht, aber (3) sehr schnelle<br />

Umschaltzeiten (< 10 ms) benötigt werden, ist die<br />

Wahl des Redundanzmusters Warm Standby keine geeignete<br />

Entscheidung (stark vereinfachtes Beispiel unter<br />

BILD 2: Oberste<br />

Ebene der Designelemente<br />

für ein<br />

Software-basiertes<br />

Redundanzmuster<br />

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

5 / 2014<br />

45


HAUPTBEITRAG<br />

Anwendung weniger abgeleiteter Anforderungen.). In<br />

diesem Fall passen die in Abschnitt 1.1 beschriebenen<br />

Eigenschaften, siehe Bild 1, beispielsweise die benötigte<br />

Zustandssynchronisierung, nicht zu mittels Designelementen<br />

abgeleiteten Anforderungen und Schutzzielen.<br />

Die oberste Hierarchieebene der Designelemente einer<br />

Software-basierten Redundanzlösung für ein verfügbares<br />

System, siehe Bild 2, enthält die Eigenschaften<br />

Fehlermodell, Eigenschaften der Kontrollapplikation,<br />

Synchronisierung des Zustands einer Applikation, Umschaltung<br />

im Fehlerfall, Setup, Infrastruktur, Überwachung<br />

und Performanzmetriken. Diese Hauptelemente<br />

werden im Folgenden auf weiteren Hierarchieebenen<br />

verfeinert. Die Existenz einer weiteren Hierarchieebene<br />

wird dabei durch das Symbol ∞ dargestellt.<br />

Insgesamt gilt zu beachten, dass die in diesem Artikel<br />

dargestellten Designelemente nicht den Anspruch auf<br />

Vollständigkeit erheben, durch die Entstehung aus vielen<br />

fachlichen Diskussionen sowie der Anwendung in<br />

einem realen Projekt aber sicherlich einen sehr hohen<br />

Deckungsgrad aufweisen.<br />

Eine wichtige, zu definierende Eigenschaft beim Design<br />

einer Redundanzlösung ist das zugrunde liegende<br />

Fehlermodell. Dieses dient bei der Umsetzung der Verfügbarkeit<br />

als Grundannahme für die zu tolerierenden<br />

Fehler. Ein Beispiel für die Definition eines Fehlermodells<br />

wurde bereits zu Beginn von Abschnitt 1 gegeben. Ein<br />

Fehlermodell umfasst dabei im Allgemeinen Eigenschaften<br />

wie mögliche fehlerhafte Entitäten, Fehlerverhalten<br />

der Entitäten (zum Beispiel fail-stop oder fail-silent) oder<br />

die Anzahl zu tolerierender Fehler. Sollen beispielsweise<br />

permanente und zeitweilige Fehler toleriert werden, würde<br />

das Standby-Redundanzmuster im Extremfall zu ständigem<br />

Umschalten führen. N-Modular-Redundanz hingegen<br />

würde derartige Fehler transparent maskieren. Die<br />

Applikationseigenschaften beinhalten beispielsweise die<br />

Anzahl der internen Variablen und I/O-Kanäle, die Zykluszeit<br />

und Echtzeiteigenschaften.<br />

In BILD 3 wird die erste Verfeinerungsebene des Designelements<br />

Zustandssynchronisierung dargestellt.<br />

Zustandssynchronisierung ist eine redundanzbezogene<br />

Eigenschaft und vor allem für das Redundanzmuster<br />

Standby-Redundanz relevant. Unabhängig vom konkreten<br />

Redundanzmuster ist es jedoch in jedem Fall<br />

sinnvoll, sich über die hier genannten Eigenschaften<br />

der Zustandssynchronisierung Gedanken zu machen,<br />

um eine gezielte Entscheidung für ein bestimmtes Redundanzmuster<br />

treffen zu können. Außerdem lassen<br />

sich so die für die Verfügbarkeit relevanten Anforderungen<br />

der Applikation identifizieren, beispielsweise<br />

welche Zustandsvariablen oder I/O-Kanäle zwingend<br />

verfügbar sein müssen, oder in welchem zeitlichen Abstand<br />

die Verfügbarkeit sichergestellt werden muss.<br />

Dieses Designelement ist folglich sehr eng mit dem Element<br />

Eigenschaften der Applikation verknüpft.<br />

Eigenschaften auf dieser Hierarchieebene, welche<br />

noch weiter verfeinert werden, sind die Definition des<br />

Zustands der Applikation, Auslöser für eine Synchronisierung,<br />

die Häufigkeit der Synchronisierung sowie deren<br />

Ausführungsmodus. Weitere Eigenschaften sind die<br />

Vergabe einer Priorität für den Synchronisierungsprozess<br />

im Vergleich zu anderen laufenden Prozessen, wie<br />

zum Beispiel die Ausführung der Applikation, Kommunikationstreiber,<br />

Scheduling oder Überwachung. Zudem<br />

sollte die Ausführungsreihenfolge der Synchronisierung<br />

skizziert werden – beispielsweise wann ein Synchronisationspunkt<br />

spätestens angelegt werden oder wann<br />

dessen Verarbeitung und Senden erfolgen muss. Schließlich<br />

sollte eine Lastvorhersage vorgesehen sein, welche<br />

in Abhängigkeit von anderen Designelementen der Zustandssynchronisierung<br />

als Eingabe für die entsprechende<br />

Performanzmetrik verwendet wird.<br />

BILD 4 zeigt die unterste Hierarchieebene der Zustandssynchronisierung,<br />

welche die Eigenschaft Zustand<br />

weiter verfeinert, das heißt, hier sind die zu definierenden<br />

Eigenschaften für die Zustandssynchronisierung<br />

zu finden. Der relevante Zustand definiert sich über<br />

die Abdeckung, das heißt, welche Teile der Applikation<br />

für die Redundanz relevant sind. Dies können beispielsweise<br />

lediglich die Input-Kanäle der Applikation, die<br />

internen Variablen der Applikation selbst oder der gesamte,<br />

genutzte Speicherbereich sein. Der Zustand der<br />

Applikation lässt sich dabei weiter unterteilen in sämtliche<br />

Zustandsvariablen der Applikation, die Variablen<br />

eines bestimmten Teils der Applikation (Task) oder ausgewählte,<br />

wichtige Variablen. Hierbei muss entschieden<br />

werden, wie der zu synchronisierende Zustand bestimmt<br />

wird, das heißt, kann dieser automatisiert ausgewählt<br />

werden – zum Beispiel alle Zustandsvariablen oder gesamter<br />

Speicherbereich – oder muss die Definition manuell<br />

beziehungsweise auf Basis von Heuristiken erfolgen,<br />

zum Beispiel wenn nur wichtige Variablen synchronisiert<br />

werden sollen. Weitere Eigenschaften dieser Hierarchieebene<br />

der Designelemente sind die Größe des zu<br />

synchronisierenden Zustands, die auch von der Entscheidung<br />

abhängt, ob in jedem Durchlauf der gesamte<br />

Zustand oder nur die Veränderungen (differential state<br />

sync) synchronisiert werden. Zudem ist eine zu definierende<br />

Eigenschaft, ob spezielle Speicherbereiche, beispielsweise<br />

zur Vorverarbeitung eines Synchronisationspunktes,<br />

verwendet werden sollen.<br />

Abhängig von der gewählten Abdeckung und der Definition<br />

der Performanzmetriken müssen Design und<br />

Implementierung entsprechend gewählt werden. Leitlinien<br />

für eine solche Auswahl werden in Abschnitt 2<br />

am Beispiel von Warm Standby-Redundanz und existierenden<br />

Implementierungsalternativen aufgezeigt.<br />

Die Verfeinerung der weiteren in BILD 3 dargestellten<br />

Designelemente Auslöser, Häufigkeit und Modus ist<br />

in BILD 5 zusammengefasst. Auslöser für die Synchronisierung<br />

können weiter in intern und extern unterschieden<br />

werden, ebenso wird die Häufigkeit in synchron<br />

und asynchron unterschieden. Externe Events<br />

können beispielsweise eine asynchrone Synchronisierung<br />

auslösen; häufiger kann jedoch ein interner, synchroner<br />

und periodischer Auslöser erwartet werden.<br />

Der Ausführungsmodus der Synchronisierung kann<br />

blockierend, nicht blockierend, oder in einem hybriden<br />

Modus erfolgen. Beim blockierenden Modus können<br />

beispielsweise Bestätigungsnachrichten verwendet<br />

werden, um die Ausführung der Applikation auf dem<br />

aktiven Controller so lange zu verzögern bis sicherge-<br />

46<br />

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

5 / 2014


BILD 3:<br />

Haupteigenschaften<br />

der Zustandssynchronisierung<br />

in der ersten<br />

Hierarchieebene<br />

BILD 4:<br />

Zweite Hierarchieebene<br />

der Zustandssynchronisierung<br />

mit<br />

beschreibenden Eigenschaften<br />

für Zustand<br />

stellt ist, dass der Zustand auf dem redundanten Controller<br />

empfangen und korrekt verarbeitet wurde. Ein<br />

solcher Modus lässt sich beispielsweise verwenden,<br />

wenn sichergestellt werden soll, dass im Fehlerfall mit<br />

Sicherheit der letzte, konsistente Zustand auf dem<br />

Standby-Controller verfügbar ist.<br />

Aufgrund der besonderen Bedeutung als Leitlinien<br />

zur Ableitung von Anforderungen wird hier noch auf<br />

die Performanzmetriken eingegangen:<br />

Last: Die durch die Redundanzlösung verursachte,<br />

zusätzliche Prozessorlast ist eine der wichtigsten<br />

Metriken, da diese den Einfluss auf die eigentliche<br />

Ausführung der Applikation beinhaltet. Last und<br />

zusätzlicher Ressourcenbedarf wird bei der Betrachtung<br />

von Optimierungen in Abschnitt 2 ausführlicher<br />

behandelt.<br />

Vorhersagbarkeit / Beherrschbarkeit: Diese Metrik<br />

ist besonders wichtig bei der Beurteilung der Erfolgswahrscheinlichkeit<br />

der Umsetzung und<br />

wird stark durch die Komplexität einer Lösung<br />

b e e i n fl u s s t .<br />

Stoßfreiheit: Diese Metrik kann direkt auf die Anforderung<br />

abgebildet werden, ob eine Applikation<br />

eine ungewollte Veränderung der Outputs während<br />

des Umschaltens tolerieren kann oder nicht. Dementsprechend<br />

muss ein geeignetes Redundanzmuster<br />

<strong>ohne</strong> Umschaltzeit gewählt oder besonderes<br />

Augenmerk auf Design und Implementierung des<br />

Umschaltvorgangs gelegt werden.<br />

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

5 / 2014<br />

47


HAUPTBEITRAG<br />

Transparenz: Diese Metrik bezieht sich darauf, ob<br />

der Application Engineer beziehungsweise Operator<br />

Redundanz explizit konfigurieren muss oder ob<br />

die Verfügbarkeit <strong>ohne</strong> dessen Zutun erreicht werden<br />

kann. Eine vollständig transparente Lösung<br />

muss beispielsweise in der Lage sein, den Zustand<br />

autonom zu erkennen, zu verarbeiten und zu synchronisieren.<br />

Typischerweise existiert ein direkter<br />

Zusammenhang zwischen hoher Transparenz und<br />

reduzierter Beherrschbarkeit der Lösung.<br />

Umschaltzeit: Diese Metrik gibt an, wie lange das<br />

Umschalten im Fehlerfall maximal dauern darf,<br />

das heißt nach welcher Zeitdauer der redundante<br />

Controller den Prozess übernommen haben muss.<br />

Bei sehr geringen Umschaltzeiten sind meist Redundanzmuster<br />

mit Voting zu empfehlen, da einer<br />

Software-basierten Synchronisierung bestimmte<br />

Grenzen gesetzt sind.<br />

Bandbreite, Durchsatz und Latenz: Diese sind relevante<br />

Performanzmetriken im Zusammenhang<br />

mit Kommunikation. Sie stehen in enger Beziehung<br />

zur Synchronisierung von Zustand und sind daher<br />

sehr hilfreich bei der Entscheidung für ein konkretes<br />

Redundanzmuster.<br />

Skalierbarkeit: hier im Sinne von Anwendbarkeit<br />

einer Redundanzlösung auf unterschiedlichen<br />

Hardwareplattformen und -geräten mit den jeweiligen<br />

Randbedingungen, zum Beispiel Speicheroder<br />

CPU-Kapazität.<br />

In einer beispielhaften Anwendung der vorgestellten<br />

Leitlinien in einem realen Projekt wurden anhand der<br />

Designelemente die Eigenschaften und Anforderungen<br />

der Kontrollapplikation diskutiert, wobei die Designelemente<br />

eine klare Struktur für die Diskussion und<br />

Spezifikation der einzelnen Elemente vorgaben. Basierend<br />

auf der daraus resultierenden Spezifikation der<br />

Designelemente sowie der Performanzmetriken wurden<br />

konkrete Anforderungen abgeleitet. Dies ermöglichte<br />

die Auswahl eines geeigneten Redundanzmusters<br />

durch Abgleich der Spezifikation und Anforderungen<br />

mit den Eigenschaften existierender Redundanzmuster<br />

siehe Bild 1. Zudem liefert die Spezifikation der Designelemente<br />

bereits ein erstes Design der Redundanzlösung.<br />

Im Projekt wurde die Entscheidung für das Redundanzmuster<br />

Warm Standby getroffen.<br />

2. ANALYSE VON IMPLEMENTIERUNGSALTERNATIVEN<br />

Das Redundanzmuster Warm Standby zeichnet sich dadurch<br />

aus, dass zum Erreichen der Fehlertoleranz zwar<br />

zwei Controller verwendet werden, jedoch nur einer der<br />

Controller, der Primär-Controller, die Applikation aktiv<br />

ausführt. Der redundante Standby-Controller synchronisiert<br />

den Zustand des Primär-Controllers mit einer<br />

gewissen Verzögerung. Hierzu muss der Primär-Controller<br />

in regelmäßigen Abständen den Standby-Controller<br />

mittels Synchronisationspunkten über Änderungen sei-<br />

BILD 5: Zweite Hierarchieebene<br />

der Zustandssynchronisierung<br />

mit<br />

beschreibenden Eigenschaften<br />

für Auslöser,<br />

Häufigkeit und Modus<br />

BILD 6: Optimierung der<br />

Synchronisierung<br />

mittels Speicherkopie<br />

48<br />

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

5 / 2014


ner internen Daten informieren. Wird zum Beispiel anhand<br />

eines ausbleibenden Heartbeat-Signals erkannt,<br />

dass der Primär-Controller ausgefallen ist, kann der<br />

Standby-Controller anhand des synchronisierten Zustands<br />

der Applikation dessen Rolle übernehmen. Mögliche<br />

Implementierungsalternativen werden im Folgenden<br />

vorgestellt und mit Hilfe der Performanzmetriken<br />

aus dem vorherigen Abschnitt bewertet.<br />

2.1 Optimierungen für Warm Standby<br />

Für die häufig eingesetzte Standby-Redundanz, vor allem<br />

in der Ausprägung Warm Standby, hat die periodische<br />

Zustandssynchronisierung des internen Zustands den<br />

größten Einfluss auf die Performanzmetriken. Da dieser<br />

Beitrag vorrangig Software-basierte Redundanz betrachtet,<br />

steht die Nutzung von spezieller Hardwareunterstützung<br />

wie Memory Snooping oder der virtuellen Speicherverwaltung<br />

der CPU (MMU) nicht im Vordergrund. Jeweils<br />

verfügbare Hardwareeigenschaften lassen sich aber<br />

im Nachgang für eine optimierte Implementierung der<br />

Zustandssynchronisierung verwenden.<br />

Die nicht-optimierte Implementierung der Zustandssynchronisierung<br />

ist die vollständige Synchronisierung<br />

in jedem Kontrollzyklus. Dabei würde in jedem Zyklus<br />

der vollständige Speicher des Controllers beziehungsweise<br />

der synchronisierten Applikation an den Standby-Controller<br />

übertragen. Für komplexe Applikationen<br />

mit niedrigen Zykluszeiten und räumlich entfernt installierte<br />

Controller wird hierbei jedoch schnell die<br />

Grenze der Übertragungskapazität typischer Feldbusse<br />

erreicht. Selbst aktuelle Mehrkernprozessoren stoßen<br />

für Synchronisationsdaten von einigen Megabyte und<br />

Zykluszeiten im Bereich von Millisekunden schnell an<br />

die Grenzen dessen, was physikalisch an Daten übertragen<br />

werden kann. Da der für die Synchronisierung<br />

verwendete Kommunikationskanal auf Standard-Hardwarekomponenten<br />

(COTS) basieren soll und eventuell<br />

kein dezidierter Kommunikationskanal verwendet<br />

wird, ist die Optimierung der Synchronisierung ein<br />

wichtiges Designziel. Um dies zu erreichen, finden sich<br />

in der Literatur verschiedene Lösungsmöglichkeiten.<br />

Ein Verfahren erkennt mittels einer Speicherkopie und<br />

eines Bitvektors Zustandsänderungen. Dabei wird eine<br />

Kopie des erfolgreich synchronisierten Zustands neben<br />

dem eigentlichen Zustand vorgehalten. So können Änderungen<br />

durch einfachen Vergleich der Speicherzellen<br />

erkannt werden, wie in BILD 6 dargestellt. Die Position<br />

der geänderten Speicherzellen lässt sich in einem Bitvektor<br />

kompakt widergeben. Zur Synchronisierung des<br />

geänderten Zustands müssen lediglich der Bitvektor und<br />

die durch den Vergleich erkannten geänderten Speicherzellen<br />

übertragen werden [9]. Sofern für jedes Speicherwort<br />

ein eigenes Bit verwendet wird, ist hierdurch eine<br />

feingranulare Erkennung von Änderungen möglich.<br />

Um den zum Vorhalten der Zustandskopie nötigen Speicherverbrauch<br />

zu reduzieren, können statt einer vollständigen<br />

Speicherkopie auch Hash-Werte verwendet<br />

werden. Hierzu wird der Speicher in einzelne Bereiche<br />

unterteilt, für die jeweils ein Hash-Wert gespeichert wird<br />

[10]. Die sich daraus ergebende Verringerung des benötigten<br />

Speichers wird jedoch dadurch erkauft, dass anstelle<br />

eines einfachen Vergleichs komplexe Hash-Funktionen<br />

über den jeweiligen Speicherbereich berechnet<br />

werden müssen. Da die Hash-Werte sinnvollerweise für<br />

eine längere Folge zusammenhängender Speicherzellen<br />

berechnet werden, reduziert sich außerdem die Granularität,<br />

in der Änderungen erkannt werden können. Daraus<br />

wiederum ergibt sich eine Erhöhung der Datenmenge,<br />

die zur Synchronisierung übertragen werden muss.<br />

Techniken der statischen Codeanalyse bieten eine weitere<br />

Möglichkeit, Änderungen des Zustands einer Applikation<br />

automatisch zu erkennen [11]. Hierzu sind jedoch signifikante<br />

Änderungen an den Entwicklungswerkzeugen erforderlich.<br />

Als Alternative zur statischen Codeanalyse lassen<br />

sich Änderungen im Programmspeicher auch durch Techniken<br />

erkennen, die weniger tiefgreifende Anpassungen<br />

innerhalb der Entwicklungswerkzeuge erfordern. Wenn es<br />

zum Beispiel möglich ist, die durch einen Funktionsblock<br />

potenziell modifizierten Speicherzellen bei deren Aufruf zu<br />

identifizieren, so kann die Laufzeitumgebung, siehe Bild 7,<br />

diese, für die Applikation und den Applikationsentwickler<br />

transparent, als modifiziert markieren. Dies kann ebenfalls<br />

durch einen Bitvektor erfolgen, der aber automatisch aktuell<br />

gehalten wird und nicht mittels einer Speicherkopie<br />

berechnet werden muss. Für Applikationen, deren Code<br />

nicht in Binärform, sondern interpretiert auf dem Controller<br />

ausgeführt wird, ist die Umsetzung dieses Ansatzes<br />

besonders einfach. Um die Synchronisierung durchzuführen,<br />

müssen lediglich der Bitvektor und die geänderten<br />

Speicherzellen übertragen werden.<br />

Für nativ ausgeführte Applikationen gestaltet sich die<br />

Erkennung von Änderungen in der Praxis schwieriger,<br />

da im kompilierten Maschinencode an beliebigen Stellen<br />

auf den Speicher zugegriffen werden kann. Eine Möglichkeit,<br />

um dennoch jede Maschinenoperation, die auf<br />

den Speicher zugreift, beobachten zu können ist es, die<br />

Techniken der Codeinstrumentierung zu nutzen. Hierbei<br />

wird, entweder als Teil der Kompilierung oder als zusätzlicher<br />

Schritt nach der Generierung des Maschinencodes,<br />

für jeden Speicherzugriff zusätzlicher Code eingefügt.<br />

Dadurch kann für jeden Schreibzugriff auf den<br />

Speicher garantiert werden, dass dieser als geändert<br />

erkannt wird. Dies ermöglicht es, die Synchronisierung<br />

durch die automatische Pufferung aller Schreibzugriffe<br />

weiter zu optimieren. Anstatt eine Speicherzelle nur als<br />

modifiziert zu markieren, kann der Zugriff in einem speziellen<br />

Speicherbereich vollständig dupliziert und gepuffert<br />

werden. Wie in BILD 8 dargestellt, kann die Synchronisierung<br />

des Zustands dann durch Übertragung<br />

dieses Puffers erfolgen, was den nötigen Aufwand zur<br />

Synchronisierung potenziell weiter reduziert.<br />

2.2 Gegenüberstellung der Optimierungen<br />

Die beschriebenen Alternativen zur Implementierung<br />

der Zustandssynchronisierung wurden auf Basis der in<br />

Abschnitt 1.2 behandelten Performanzmetriken relativ<br />

zueinander bewertet. Das Ergebnis dieser Bewertung<br />

ist in TABELLE 1 dargestellt. Die durch das jeweilige<br />

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

5 / 2014<br />

49


HAUPTBEITRAG<br />

Verfahren erzeugte Last wird anhand des zur Synchronisierung<br />

nötigen Speicherverbrauchs und des Rechenaufwands<br />

charakterisiert. Die kommunikationsbezogenen<br />

Eigenschaften werden mit Hilfe der für die Synchronisationspunkte<br />

erforderlichen Datenmengen<br />

verglichen. Für alle Betrachtungen wird der Mehraufwand<br />

anhand einer abstrakten Kostenfunktion analysiert,<br />

die die Größe des zu synchronisierenden Zustands<br />

n, den tatsächlich geänderten Teil des Speichers<br />

c und teilweise verfahrensspezifische Parameter enthält.<br />

Die Betrachtung hinsichtlich Transparenz und<br />

Vorhersagbarkeit wurde zusammengefasst und erfolgt<br />

lediglich mittels der Attribute positiv, negativ und neutral.<br />

Die Skalierbarkeit der Verfahren wurde in gleicher<br />

Weise bewertet. Auf die Bewertung der Attribute Stoßfreiheit<br />

und Umschaltzeit wurde verzichtet, da diese<br />

nicht in direktem Zusammenhang mit der Optimierung<br />

der Synchronisierung stehen.<br />

Die zugrundeliegende Charakterisierung nimmt beispielsweise<br />

für das Verfahren zur Synchronisierung<br />

mittels Speicherkopie & Bitvektor an, dass einerseits<br />

eine Speicherkopie der Größe des Applikationszustands<br />

n und andererseits der Bitvektor gespeichert<br />

werden muss. Die Größe des Bitvektors hängt von n<br />

und der Größe eines Speicherbereichs b ab, dessen<br />

Änderung mit einem Bit kodiert wird. Unter der Annahme,<br />

dass n und b in Bytes (1 Byte = 8 Bit) angegeben<br />

sind, ergibt sich für die Größe des Bitvektors die<br />

Formel<br />

s = (1)<br />

In Summe folgert daraus für den zusätzlichen Speicherverbrauch<br />

also die Gesamtformel<br />

m = (2)<br />

BILD 7: Optimierung der Synchronisierung<br />

durch automatisch erzeugten Bitvektor<br />

BILD 8: Synchronisierung mittels Pufferung<br />

von Schreibzugriffen<br />

Verfahren<br />

Vollständige<br />

Synchronisierung<br />

Speicherkopie<br />

& Bitvektor<br />

Skalierbarkeit<br />

Speicherverbrauch<br />

Datenmenge<br />

(schlechtester<br />

Fall)<br />

Last Bandbreite, Durchsatz, Latenz Transparenz<br />

Rechenaufwand<br />

(Bestfall)<br />

Datenmenge<br />

Vorhersagbarkeit<br />

0 n n n + –<br />

2 * n c n + –<br />

Hashwerte n * f c c * b – 0<br />

Statische<br />

Codeanalyse<br />

Automatisch erzeugter<br />

Bitvektor<br />

Pufferung von<br />

Schreibzugriffen<br />

c n – +<br />

c + n c n 0 +<br />

c 2 * c c c 0 +<br />

TABELLE 1: Vergleich der<br />

Implementierungsalternativen<br />

Symbol<br />

n<br />

c<br />

b<br />

f<br />

Bedeutung<br />

Größe des Applikationszustandes (Bytes)<br />

Größe des pro Ausführungszyklus geänderten Speichers (Bytes)<br />

Granularität in der Änderungen verfolgt werden (Bytes)<br />

Berechnungsaufwand der verwendeten Hashfunktion<br />

50<br />

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

5 / 2014


Der zusätzliche Rechenaufwand entsteht dadurch,<br />

dass der komplette Zustand traversiert und auf Änderungen<br />

getestet werden und die Speicherkopie nach<br />

erfolgreicher Synchronisierung aktualisiert werden<br />

muss. Im Bestfall erkennt das Verfahren exakt den geänderten<br />

Speicherbereich. Da der konkrete Wert – und<br />

insbesondere die Relation zum Applikationszustand<br />

– applikationsspezifisch ist, wird die Größe des geänderten<br />

Speicherbereichs mit der Variable c (als Prozentsatz<br />

von n) dargestellt. Im schlechtesten Fall ist die<br />

Granularität, in der Änderungen erkannt werden, so<br />

ungenau, dass der vollständige Zustand übertragen<br />

werden muss. Die Formeln der anderen Verfahren lassen<br />

sich analog herleiten.<br />

Die Bewertung der Transparenz und Vorhersagbarkeit<br />

der Verfahren erfolgte anhand der algorithmischen<br />

Komplexität, insbesondere hinsichtlich der<br />

zur Implementierung notwendigen Datenstrukturen.<br />

Das Verfahren auf Basis von Hash-Werten erfordert<br />

beispielsweise dynamische Datenstrukturen, um Änderungen<br />

im Speicher zu verfolgen. Dies verursacht,<br />

dass der Algorithmus zur Erkennung von Zustandsänderungen<br />

einen internen Zustand besitzt, der insbesondere<br />

die zu übertragende Datenmenge beeinflusst.<br />

Dadurch hängt der tatsächliche Aufwand der<br />

Synchronisierung von den vorherigen Ausführungszyklen<br />

ab, was die Vorhersagbarkeit negativ beeinflusst.<br />

Zur Bewertung der Skalierbarkeit wurde betrachtet,<br />

ob sich die Verfahren gleichermaßen für<br />

Applikationen unterschiedlicher Komplexität sowie<br />

für Controller mit unterschiedlicher Rechenleistung<br />

eignen. Positiv hervorzuheben sind hier die Verfahren<br />

automatisch erzeugter Bitvektor und Pufferung von<br />

Schreibzugriffen. Beide Verfahren eignen sich für Controller<br />

mit geringerer Rechenleistung, da der durch<br />

die Verfahren erzeugte Rechenaufwand über den kompletten<br />

Ausführungszyklus verteilt wird. Da die Verfahren<br />

nur die tatsächlichen Änderungen übertragen,<br />

sind sie sehr gut verwendbar für Applikationen mit<br />

einer hohen Anzahl interner Variablen.<br />

Um die theoretischen Betrachtungen zu validieren,<br />

wurden die Optimierungen vollständige Synchronisierung,<br />

Speicherkopie & Bitvektor, automatisch erzeugter<br />

Bitvektor sowie Pufferung von Schreibzugriffen prototypisch<br />

implementiert und mit synthetischen Daten<br />

getestet. Diese mit einem Desktop-PC gemachten Experimente<br />

bestätigten die zuvor durchgeführte Bewertung<br />

dieser Verfahren.<br />

Um nun für einen konkreten Controller ein geeignetes<br />

Verfahren auszuwählen, müssen die Designelemente<br />

mit den Anforderungen in Einklang gebracht<br />

werden. Sofern die Anwendbarkeit der Verfahren im<br />

Rahmen der Anforderungen möglich ist, wird die Verfügbarkeit<br />

durch alle Verfahren gleichermaßen gewährleistet.<br />

Eine relative Bewertung der einzelnen<br />

Verfahren mit Hinblick auf die Erfüllung der Verfügbarkeitsanforderungen<br />

ist nur mit zusätzlicher Information<br />

über die Randbedingungen des Systems möglich.<br />

Hierunter fallen beispielsweise der Ausführungszyklus<br />

der Anwendung, die im Zyklus für Redundanz<br />

verfügbare Rechenzeit oder die in diesem Zeitfenster<br />

zwischen den redundanten Controllern übertragbare<br />

Datenmenge. Auf eine solche, relative Bewertung wurde<br />

verzichtet, da das Ziel der dargestellten Analyse die<br />

Maximierung der Verfügbarkeit unter den gegebenen<br />

Anforderungen war. Die unvollständige Erfüllbarkeit<br />

der Voraussetzungen für ein Verfahren dient deshalb<br />

als Ausschlusskriterium.<br />

Für ein konkretes System, in dem sowohl die zwischen<br />

den Controllern übertragbare Datenmenge als<br />

auch die auf dem Primär-Controller verfügbare Rechenleistung<br />

die Übertragung des von der Applikation<br />

verwendeten Speichers in jedem Fall ermöglichen,<br />

andererseits sehr hohe Anforderungen an Transparenz<br />

und Vorhersagbarkeit der Synchronisierung gestellt<br />

werden, sind vollständige Synchronisierung oder Speicherkopie<br />

& Bitvektor geeignete Verfahren. Anhand<br />

TABELLE 1 lässt sich eine solche Bewertung sehr einfach<br />

durchführen, indem die Verfahren mit Hilfe der<br />

wichtigsten Anforderung(en) sortiert werden, zum<br />

Beispiel Transparenz und Vorhersagbarkeit. Für die<br />

besten Verfahren kann anschließend bewertet werden,<br />

inwiefern die weiteren Eigenschaften zu den konkreten<br />

Anforderungen und Rahmenbedingungen passen.<br />

Für das Beispiel bedeutet dies, dass die Verfahren<br />

mit der höchsten Transparenz und Vorhersagbarkeit<br />

priorisiert werden und anschließend ein Verfahren<br />

gewhält wird, welches mit der in einem Ausführungszyklus<br />

konkret verfügbaren Rechenleistung und Kommunikationskapazität<br />

bestmöglich übereinstimmt. Die<br />

Tabelle dient folglich auch dazu, zwischen Verfahren<br />

abzuwägen, die anhand ihrer Anforderungen anwendbar<br />

wären. Ein mögliches Kriterium für die Entscheidung<br />

zwischen vollständiger Synchronisierung und<br />

dem Vorhalten einer Speicherkopie und eines Bitvektors<br />

wäre, ob die durch letzteres Verfahren ermöglichte<br />

Reduzierung der übertragenen Datenmenge im konkreten<br />

System einen messbaren Vorteil bringt. Für<br />

Applikationen mit nur wenigen internen Variablen ist<br />

dies beispielsweise nicht der Fall.<br />

Die in der Tabelle nicht dargestellten Voraussetzungen<br />

zur Anwendung der Verfahren, wie die Nachverfolgbarkeit<br />

aller schreibenden Speicherzugriffe innerhalb einer<br />

Applikation, können ebenfalls dazu dienen, gewisse<br />

Verfahren auszuschließen. Wie im Fall des Verfahrens<br />

mittels statischer Codeanalyse kann es auch vorkommen,<br />

dass eine vollständige Bewertung der Eigenschaften<br />

eines Verfahrens nicht möglich ist. Trotzdem kann<br />

die vorgestellte systematische Betrachtung dazu dienen,<br />

gewisse Designalternativen direkt auszuschließen.<br />

Insgesamt ist zu sehen, dass die Bewertung und Gegenüberstellung<br />

der Optimierungen in Verbindung mit<br />

den im vorigen Abschnitt abgeleiteten Anforderungen<br />

und Performanzmetriken eine sehr gute Grundlage für<br />

die Auswahl eines geeigneten Verfahrens bildet.<br />

FAZIT<br />

Im Beitrag wurden Leitlinien für den Entwurf eines<br />

verfügbaren Systems aufgezeigt. Die hierarchisch<br />

strukturierten Designelemente geben Hilfestellung bei<br />

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

5 / 2014<br />

51


HAUPTBEITRAG<br />

der Erstellung von Anforderungen sowie bei Entwurf<br />

und Implementierung einer Software-basierten Redundanzlösung.<br />

Die Gegenüberstellung von Optimierungen<br />

am Beispiel von Warm Standby-Redundanz zeigt, wie<br />

sich mit Hilfe der Anforderungen ein gewähltes Redundanzmuster<br />

gezielt optimieren lässt. Insgesamt wird<br />

dadurch ein durchgängiger Prozess zur Unterstützung<br />

bei Design und Implementierung eines Redundanzmusters<br />

zum Erreichen des Schutzziels Verfügbarkeit aufgezeigt,<br />

der eine strukturierte Vorgehensweise sowie<br />

eine informierte Entscheidung ermöglicht. Die Anwendbarkeit<br />

und die Vorteile wurden im Rahmen eines<br />

realen Designprojektes validiert.<br />

In künftigen Arbeiten könnten beispielsweise die<br />

Designelemente um Eigenschaften und Ebenen erweitert<br />

werden, welche für andere Systembestandteile<br />

beziehungsweise das Gesamtsystem zusätzlich relevant<br />

sind. Zudem ließe sich untersuchen, inwieweit<br />

der aufgezeigte strukturierte Designansatz auch im<br />

Kontext der Maschinensicherheit (Safety) hilfreich ist.<br />

DANKSAGUNG<br />

MANUSKRIPTEINGANG<br />

06.02.2014<br />

Im Peer-Review-Verfahren begutachtet<br />

Die Autoren danken Dr. Carlos Bilich und Dr. Stephan<br />

Sehestedt sehr herzlich für ihre Mitarbeit und wertvollen<br />

Beiträge zu unseren Arbeiten. Ein Dank geht<br />

außerdem an all unsere Kollegen, die diese Arbeit mit<br />

Rat und Tat hervorragend unterstützt haben.<br />

REFERENZEN<br />

AUTOREN<br />

[1] Vision Solutions, “Assessing the Financial Impact of<br />

Downtime.” Aug-2010<br />

[2] International Electrotechnical Commission (IEC),<br />

“IEC/EN 61508: Funktionale Sicherheit sicherheitsbezogener<br />

elektrischer/elektronischer/programmierbar<br />

elektronischer Systeme, Edition 2.0.”<br />

Apr-2010<br />

[3] C. R. K. Iyer, A. Avizienis, P. A. Avizienis, D. Barron,<br />

D. Powell, H. Levendel, and J. Samson, “COTS<br />

Hardware and Software in High-Availability<br />

Systems,” p. 120, Jun. 1999<br />

[4] Y. C. Yeh, “Triple-triple redundant 777 primary flight<br />

computer,” in IEEE, 1996, vol. 1, pp. 293–307<br />

[5] I. Thomm, M. Stilkerich, R. Kapitza, W. Schröder-<br />

Preikschat, and D. Lohmann, “Automated application<br />

of fault tolerance mechanisms in a component-based<br />

system,” Proc. 9th Int. Work. Java Technol.<br />

Real-Time Embed. Syst., pp. 87 – 95, Sep. 2011<br />

[6] J. H. Lala and L. S. Alger, “Hardware and software<br />

fault tolerance: a unified architectural approach,”<br />

in Fault-Tolerant Computing, 1988, pp. 240 – 245<br />

[7] R. Guerraoui and A. Schiper, “Software-based<br />

replication for fault tolerance,” Computer (Long.<br />

Beach. Calif)., vol. 30, no. 4, pp. 68–74, Apr. 1997<br />

[8] A. Armoush, “Design Patterns for Safety-Critical<br />

Embedded Systems,” RWTH Aachen University, 2010<br />

[9] M. Steiger, “Fault-Tolerant Turbine Controller,”<br />

ETH Zurich, 2008<br />

[10] S. Agarwal, R. Garg, M. Gupta, and J. Moreira,<br />

“Adaptive incremental checkpointing for massively<br />

parallel systems,” Proc. 18th Annu. Int. Conf.<br />

Supercomput., pp. 277–286, 2004<br />

[11] G. Bronevetsky and D. Marques, “Compilerenhanced<br />

incremental checkpointing,” in Languages<br />

and Compilers for Parallel Computing, Springer,<br />

2008, pp. 1–15<br />

Dr. THOMAS GAMER<br />

(geb. 1979) ist Senior<br />

Scientist am ABB Forschungszentrum<br />

in<br />

Ladenburg. Der Schwerpunkt<br />

seiner Arbeit liegt<br />

auf Softwarearchitekturen<br />

und Softwareengineering<br />

für zukünftige Automatisierungssysteme.<br />

Themenschwerpunkte liegen<br />

dabei auf fehlertoleranten Systemen, Gebäudeautomation<br />

und Remote Service-Lösungen.<br />

ABB AG Corporate Research Center Germany,<br />

Research Area Software,<br />

Wallstadter Str. 59, D-68526 Ladenburg,<br />

Tel. +49 (0) 6203 71 60 24,<br />

E-Mail: thomas.gamer@de.abb.com<br />

Dr. STEFAN STATTELMANN<br />

(geb. 1984) ist Scientist am<br />

ABB Forschungszentrum in<br />

Ladenburg. Der Schwerpunkt<br />

seiner Arbeit liegt auf<br />

Softwarearchitekturen und<br />

Softwareengineering für<br />

zukünftige Automatisierungssysteme,<br />

Fehlertoleranz,<br />

Echtzeitsystemen und formalen Methoden.<br />

ABB AG Corporate Research Center Germany,<br />

Research Area Software,<br />

Wallstadter Str. 59, D-68526 Ladenburg,<br />

Tel. +49 (0) 6203 71 62 83,<br />

E-Mail: stefan.stattelmann@de.abb.com<br />

52<br />

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

5 / 2014


<strong>atp</strong> Kompaktwissen<br />

Band 1 –<br />

Erfolgreiches Engineering<br />

Hrsg. F. 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. F. 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 />

<strong>Industrie</strong>lle Informationssicherheit<br />

Hrsg. L. Urbas, 1. Auflage 2014, 88 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. F. 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. F. 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. L. Urbas, 1. Auflage 2014, 112 Seiten, Broschur<br />

Buch für € 59,–<br />

ISBN 978-3-8356-7115-7<br />

DIV Deutscher <strong>Industrie</strong>verlag GmbH, Arnulfstr. 124, 80636 München<br />

www.di-verlag.de<br />

Jetzt bestellen!<br />

Bestellung per Fax: +49 (0) 201 Deutscher / 82002-34 <strong>Industrie</strong>verlag 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 <strong>ohne</strong> 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 <strong>Industrie</strong>verlag 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<br />

Schutzzielorientiertes Design<br />

der Sicherheitsleittechnik<br />

Top-down-Entwurf: Defence-in-Depth-Prinzip in KKW<br />

Um die höchsten Anforderungen an die Sicherheitsleittechnik in Kernkraftwerken<br />

(KKW) zu erfüllen, muss diese systematisch konzipiert und überprüfbar projektiert<br />

werden. Der Beitrag stellt einen schutzzielorientierten Designprozess vor, wobei<br />

gleichzeitig die Philosopie der gestaffelten Verteidigung (defence in depth) angewendet<br />

wird. Der Ansatz eignet sich für Neubauten wie den Europäischen Druckwasserreaktor<br />

(EPR) und für umfassende Nachrüstungen in Altanlagen. Dieser Designprozess<br />

wurde in nationalen wie internationalen leittechnischen Projekten erfolgreich<br />

eingesetzt.<br />

SCHLAGWÖRTER Schutzziele / Sicherheitsleittechnik / Gestaffelte Verteidigung /<br />

Kernkraftwerk / EPR<br />

Safety Objective Oriented Design of Digital Safety I&C –<br />

Defence in Depth in Nuclear Power Plants<br />

Safety instrumentation and control in nuclear power plants has to be systematically<br />

designed and revisable in order to meet the highest safety requirements. A safety<br />

objective oriented design process is presented in combination with the defence in<br />

depth philosophy. The approach is applicable for the construction of new plants like<br />

the European Pressurized Reactor (EPR) and for the comprehensive refurbishment<br />

of existing plants. Its success has been demonstrated in several domestic and international<br />

I&C projects.<br />

KEYWORDS safety objective / safety I&C / defence in depth / nuclear power plant / EPR<br />

54<br />

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

5 / 2014


YONGJIAN DING, Hochschule Magdeburg-Stendal<br />

Zum sicheren Betrieb einer kerntechnischen<br />

Anlage sind umfangreiche Schutz- und Sicherheitsmaßnahmen<br />

nötig. Diese lassen sich nach<br />

Art und Weise der Wirkung in passive und aktive<br />

Maßnahmen einteilen. Passive Maßnahmen<br />

sind mechanische und bautechnische Einrichtungen,<br />

die ihre Schutzfunktionen <strong>ohne</strong> Stelleinrichtungen<br />

erfüllen. Die aktiven Sicherheitsmaßnahmen<br />

ergänzen die passiven, indem wichtige Prozessgrößen<br />

durch die Leittechnik überwacht und gegebenenfalls<br />

automatisch beeinflusst werden. Die Maßnahmen arbeiten<br />

im Normalbetrieb, im Fall von Betriebsstörungen<br />

und beim Auftreten von Störfällen.<br />

In einem Kernkraftwerk der Leistungsklasse größer<br />

als 1000 MWe werden von der Leittechnik mehr als<br />

10 000 binäre und analoge Prozessvariablen verarbeitet,<br />

mehrere tausend Antriebe gesteuert. Der Designprozess<br />

zur Spezifikation der zugehörigen leittechnischen<br />

Funktionen und insbesondere der sicherheitstechnisch<br />

wichtigen Funktionen muss daher klar strukturiert und<br />

überprüfbar gestaltet werden. Zusätzlich muss Vorsorge<br />

getroffen werden, dass beim postulierten Versagen<br />

einzelner Sicherheitsfunktionen die Schutzziele der<br />

Anlage gewahr bleiben.<br />

1. LEITTECHNISCHE GESAMTSTRUKTUR<br />

IM KERNKRAFTWERK<br />

Um die gesamte leittechnische Funktionalität in<br />

einem Kernkraftwerk zu realisieren und einerseits die<br />

extrem hohe Zuverlässigkeit der Sicherheitsfunktionen,<br />

andererseits die möglichst hohe Verfügbarkeit<br />

der Anlagen für die Stromproduktion zu gewährleisten,<br />

sind für die Realisierung der Gesamtleittechnik<br />

mindestens zwei unterschiedliche Geräteplattformen<br />

erforderlich. Bild 1 zeigt eine leittechnische Struktur<br />

eines Kernkraftwerks basierend auf der Teleperm XS<br />

Plattform (TXS, Areva Deutschland) für die Sicherheitsleitechnik<br />

(links im Bild) sowie der SPPA T2000<br />

Plattform (SPPA T2000, Siemens) für die betriebliche<br />

Leittechnik (rechts im Bild).<br />

Die betriebliche Leittechnik (Operational I&C) dient<br />

der Führung der Prozessvariablen im Normalbetrieb.<br />

Sie umfasst im Wesentlichen Automatisierungsgeräte<br />

(AS) zur Erfassung der Prozessvariablen, zur Berechnung<br />

der Stellanforderungen sowie zur Steuerung der<br />

Antriebe; ferner einen Anlagenbus zum Austausch von<br />

Information zwischen den einzelnen Automatisierungsgeräten<br />

sowie zwischen Automatisierungsgeräten<br />

und den Bedien- und Beobachtungseinrichtungen<br />

(OM + Backup Panel) in der Hauptwarte eines Kernkraftwerkes.<br />

Die Sicherheitsleittechnik (Safety I&C) ist von der<br />

betrieblichen Leittechnik unabhängig und überwacht<br />

die wesentlichen Sicherheitsvariablen. Im Falle unzulässiger<br />

Abweichungen schaltet sie das KKW ab und<br />

hält es in einem sicheren Zustand. Die Sicherheitsleittechnik<br />

umfasst auch unabhängige Bedien- und Beobachtungseinrichtungen<br />

(Safety Control Panel) in der<br />

Hauptwarte, mit denen das Kernkraftwerk bei Versagen<br />

der betrieblichen Leittechnik in einen sicheren Zustand<br />

überführt und dort gehalten werden kann.<br />

Da eine Vielzahl von Antrieben über die betriebliche<br />

Leittechnik und über die Sicherheitsleittechnik angesteuert<br />

werden muss, bedarf es einer speziellen Logik,<br />

welche sicherstellt, dass Befehle der Sicherheitsleittechnik<br />

stets Vorrang vor den Befehlen der betrieblichen<br />

Leittechnik haben. Diese Logik wird durch eine<br />

eigene Gerätetechnik realisiert, welche in Bild 1 mit<br />

Priority Logic (Vorrangsteuerung) bezeichnet ist.<br />

Die Geräteplattform zur Realisierung der Sicherheitsleittechnik<br />

zeichnet sich durch die strenge anlagenunabhängige<br />

Typprüfung der Hardware- und Softwarekomponenten<br />

und wichtige built-in Sicherheitseigenschaften<br />

aus [2, 3]. Dadurch wird das anlagenspezifische<br />

Genehmigungsrisiko, aber ebenso der<br />

Genehmigungsaufwand deutlich verringert. Letzterer<br />

kann sich auf die Überprüfung der leittechnischen<br />

Funktionen und deren korrekte Implementierung (Redundanz-<br />

und Diversitätsgrad der Teilsysteme zur Sicherstellung<br />

der Fehlererkennung und Fehlertoleranz)<br />

einschließlich der zugehörigen Maßnahmen der Qualitätssicherung<br />

und Nachweisführung beschränken.<br />

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

5 / 2014<br />

55


HAUPTBEITRAG<br />

Da der Beitrag die Sicherheitsfunktionen im Fokus hat,<br />

behandeln die weiteren Betrachtungen den Designprozess<br />

zur Realisierung der Sicherheitsleittechnik.<br />

2. DER TOP-DOWN-DESIGNPROZESS<br />

Für einen Designprozess, bei dem die Spezifikation der<br />

leittechnischen Funktionen und deren Implementierung<br />

in einem Top-down Prozess aus den Schutzzielen<br />

eines KKW abgeleitet wird, ist es sinnvoll, in folgenden<br />

Schritten vorzugehen:<br />

1 | Festlegung der Schutzziele,<br />

2 | Identifizierung der zu beherrschenden Ereignisse,<br />

3 | Spezifizierung der erforderlichen verfahrenstechnischen<br />

und leittechnischen Funktionen,<br />

4 | Festlegung des Barrierenkonzeptes,<br />

5 | Festlegung der leittechnischen Architektur,<br />

6 | Validierung der Auslegung.<br />

Dieser systematische Designansatz wurde in großem<br />

Umfang erstmals beim Neubau eines KKW in Ostchina<br />

praktiziert [4, 5] und im Laufe der Zeit in zahlreichen<br />

Projekten von Areva kontinuierlich weiter entwickelt.<br />

Im Folgenden werden die Teilschritte beschrieben und<br />

anhand einer beispielhaften Neubauanlage vom Typ Europäischer<br />

Druckwasserreaktor (EPR) veranschaulicht.<br />

2.1 Festlegung der Schutzziele<br />

Die Schutzziele eines KKW leiten sich unmittelbar aus<br />

den Vorgaben der einschlägigen nationalen oder intenationalen<br />

Gesetzgebung (zum Beispiel des Atomgesetzes<br />

in Deutschland) ab, wonach Leben, Gesundheit<br />

und Umwelt/Sachgüter vor den Gefahren der Kernenergie<br />

und der schädlichen Wirkung ionisierender Strahlen<br />

zuverlässig zu schützen sind. Draus resultieren<br />

diese Schutzziele:<br />

a | Reaktivitätskontrolle: Unabhängig vom Betriebszustand<br />

eines KKW (Leistungsbetrieb oder<br />

Revisionsbetrieb; Normalbetrieb oder unter Störfallbedingungen)<br />

muss immer gewährleistet sein,<br />

dass die Kettenreaktion im Kern des Reaktors<br />

jederzeit unterbrochen und der Reaktor sicher abgeschaltet<br />

und im sicheren Zustand gehalten werden<br />

kann.<br />

b | Brennelementekühlung und Wärmeabfuhr: Sowohl<br />

im Leistungsbetrieb als auch im abgeschalteten<br />

Betrieb muss die Wärme aus dem Reaktorkern<br />

und aus dem Brennelementekühlbecken sicher<br />

und dauerhaft abgeführt werden.<br />

c | Sicherer Einschluß der Radioaktivität: Zur Sicherstellung,<br />

dass weder das Betriebspersonal noch<br />

die Kraftwerksumgebung der schädlichen Wirkung<br />

ionisierender Strahlen ausgesetzt werden,<br />

muss eine unerlaubte Freisetzung von Radioaktivität<br />

sicher verhindert werden. Dies gilt sowohl<br />

für den Normalbetrieb als auch im Falle des Auftretens<br />

der Auslegungsstörfälle.<br />

2.2 Identifizierung der zu beherrschenden Ereignisse<br />

Eine der wesentlichen Auslegungsgrundlagen von<br />

Kernkraftwerken sind postulierte Ereignisse und Bedingungen,<br />

für welche die Wirksamkeit der Schutzmaßnahmen<br />

nachgewiesen werden muss. Dies betrifft<br />

Ereignisse, die ihre Ursache innerhalb der Anlage haben<br />

(zum Beispiel das Versagen mechanischer Systeme,<br />

Feuer oder Kurzschlüsse) in gleichem Maße wie Ereignisse,<br />

die ihre Ursache außerhalb der Anlage haben<br />

(wie Naturkatastrophen, Absturz eines Flugzeuges). Da<br />

diese Ereignisse grundsätzlich das Potenzial haben, die<br />

oben genannten Schutzziele zu gefährden, bilden sie<br />

die Grundlage zur Auslegung der Sicherheitssysteme.<br />

Es ist Praxis, diese Ereignisse entsprechend der erwarteten<br />

Häufigkeit des Auftretens in Gruppen zusammenzufassen.<br />

In der EPR-Entwicklung werden<br />

diese Gruppen als Design Basis Conditions (DBC) bezeichnet<br />

wobei die Auslegung vier Gruppen unterscheidet:<br />

DBC 1: Normalbetrieb;<br />

DBC 2: Betriebliche Transienten/Störungen<br />

(Häufigkeit > 10 -2 /Reaktorjahr);<br />

DBC 3: Störfälle der Kategorie 1 (10 -3 / Reaktorjahr<br />

< Häufigkeit < 10 -2 /Reaktorjahr) und<br />

DBC 4: Seltene Störfälle der Kategorie 2 (Häufigkeit<br />

< 10 -3 /Reaktorjahr)<br />

Da mit der Eintrittshäufigkeit eines Ereignisses – bei<br />

gleichbleibendem Schadensausmaß beziehungsweise<br />

der Sicherheitsbedeutung des Ereignisses – auch dessen<br />

Risikobeitrag proportional ansteigt, fassen die so gebildeten<br />

Gruppen in erster Näherung Ereignisse mit vergleichbarem<br />

Risikobeitrag zusammen. Da in einer ausgewogenen<br />

Auslegung alle relevanten Ereignisse einen<br />

ähnlichen Beitrag zum Risiko liefern sollten, sind diese<br />

Gruppen der Ausgangspunkt für das Konzept der<br />

gestaffelten Verteidigung, Defence-in-Depth-Konzept.<br />

Neben diesen einzelnen Ereignissen werden bei<br />

Neubauprojekten von Reaktoren der Generation III<br />

beziehungsweise III+, wozu der EPR gehört, extrem<br />

seltene Kombinationen von Ereignissen in der Auslegung<br />

berücksichtigt. In der EPR-Entwicklung werden<br />

solche Ereigniskombinationen als Design Extension<br />

Conditions (DEC) bezeichnet, wobei folgende Gruppen<br />

unterschieden werden:<br />

DEC A und DEC B: Mehrfache Fehler beziehungsweise<br />

Szenarien mit extrem niedrigen Wahrscheinlichkeiten<br />

(Häufigkeit < 10 -4 / Reaktorjahr); die<br />

Unterscheidung des Typs A vom Typ B besteht darin,<br />

dass bei Ereignissen vom Typ DEC A noch zusätzlich<br />

ein Einzelfehler im betroffenen Sicherheitssystem<br />

unterstellt wird, beim Typ DEC B dagegen<br />

nicht;<br />

56<br />

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

5 / 2014


Schwere Störfälle: mit nennenswerten Kernschäden<br />

(Häufigkeit < 10 -6 /Reaktorjahr).<br />

Bei schweren Störfallen kommt es vor allem auf die<br />

Begrenzung des Schadensausmaßes an, indem die<br />

Freisetzung großer Mengen an Radioaktivität verhindert<br />

wird.<br />

Die DBC bilden in der EPR-Auslegung die Grundlagen<br />

für die deterministischen Akzeptanzkriterien und für<br />

die probabilistischen Nachweisziele bezüglich der<br />

Kernschmelzhäufigkeit beziehungsweise der Wahrscheinlichkeit,<br />

dass große Mengen an Radioaktivität<br />

freigesetzt werden.<br />

2.3 Spezifizierung der erforderlichen verfahrenstechnischen<br />

und leittechnischen Funktionen<br />

Die Einhaltung der unter 2.1 genannten Schutzziele<br />

erfordert für einen spezifischen Typ von Kernkraftwerken<br />

mehrere globale Sicherheitsfunktionen. So umfasst<br />

die Einhaltung des Schutzzieles Brennelementkühlung<br />

für einen Druckwasserreaktor unter anderem,<br />

dass der Reaktorkern stets mit Kühlmittel<br />

bedeckt ist,<br />

dass die an das Kühlmittel abgegebene Wärme<br />

zur Sekundärseite übertragen wird und<br />

dass die an die Sekundärseite abgegebene<br />

Energie an die finale Wärmesenke (zum Beispiel<br />

Turbine) übertragen wird.<br />

Die Einhaltung dieser globalen Sicherheitsfunktionen<br />

setzt voraus, dass die Integrität des Primärkreises und<br />

des Sekundärkreises gewährleistet ist. Das heißt, das<br />

Schutzziel Brennelementkühlung erfordert im Betrieb<br />

eines Druckwasserreaktors unter anderem die Einhaltung<br />

der globalen Sicherheitsfunktionen<br />

Kernbedeckung,<br />

Primärseitige Wärmeabfuhr,<br />

Sekundärdseitige Wärmeabfuhr,<br />

Überdruckabsicherung Primärseite,<br />

Überdruckabsicherung Sekundärseite.<br />

Die Einhaltung dieser globalen Sicherheitsfunktionen<br />

verlangt unterschiedliche verfahrenstechnische Systeme,<br />

die in den Betriebszuständen des Kernkraftwerks<br />

wirksam werden. So schließt beispielsweise die sekundärseitige<br />

Wärmeabfuhr die Bespeisung des Dampferzeugers<br />

ein, was je nach Betriebszustand des KKW durch<br />

die Hauptspeisepumpen,<br />

die Notspeisepumpen oder<br />

die An- und Abfahrpumpen<br />

erfolgen kann. Die Beiträge dieser verfahrenstechnischen<br />

Systeme zur Einhaltung globaler Sicherheitsfunktionen,<br />

wie etwa die Bespeisung der Dampferzeuger<br />

über die Hauptspeisepumpen um die sekundärseitige<br />

Wärmeabfuhr zu gewährleisten, werden im<br />

Folgenden als verfahrenstechnische Funktionen bezeichnet.<br />

Leittechnische Funktionen leisten einen Beitrag,<br />

um die verfahrenstechnischen Funktionen zu erfüllen,<br />

indem sie beispielsweise Antriebe so steuern,<br />

dass die wesentlichen Prozessvariablen in erlaubten<br />

Bereichen geführt werden. So erfordert die verfahrenstechnische<br />

Funktion Bespeisung des Dampferzeugers<br />

über die Hauptspeisepumpen unter anderem<br />

leittechnische Funktionen zur Regelung des Füllstands<br />

im Dampferzeuger, da die verfahrenstechnische<br />

Funktion nur dann sichergestellt wird, wenn<br />

sich der Füllstand im Dampferzeuger in einem spezifizierten<br />

Bereich befindet.<br />

Entsprechend dieser Systematik lässt sich die Spezifikation<br />

leittechnischer Funktionen in einem Prozess<br />

Safety I&C<br />

Operational I&C<br />

Safety<br />

Control<br />

Panel<br />

Engineering<br />

System<br />

SPACE<br />

Engineering<br />

System<br />

ES 680<br />

Process Control<br />

and Information<br />

System<br />

OM 690<br />

Backup<br />

Panel<br />

Reactor<br />

Protection<br />

System<br />

~<br />

Gateway<br />

Priority<br />

Logic<br />

~<br />

Plant bus<br />

Automation<br />

System<br />

AS 620<br />

~<br />

BILD 1:<br />

Leittechnische<br />

Struktur eines<br />

Kernkraftwerks [1]<br />

M<br />

Field<br />

M<br />

M<br />

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

5 / 2014<br />

57


HAUPTBEITRAG<br />

der sukzessiven Verfeinerung aus den globalen Schutzzielen<br />

eines Kernkraftwerkes ableiten, Bild 2. Dazu<br />

werden zunächst alle globalen Sicherheitsfunktionen<br />

(safety functions) für den betroffenen Kraftwerkstyp<br />

identifiziert, die für die Erfüllung der Schutzziele erforderlich<br />

sind. Das ist die erste Stufe der Verfeinerung<br />

(Level 1), die von den Experten für die Anlagensicherheit<br />

durchgeführt wird.<br />

In der zweiten Stufe der Verfeinerung (Level 2) werden<br />

alle verfahrenstechnischen Funktionen (process<br />

functions) identifiziert, die in den unterschiedlichen<br />

Betriebszuständen der Anlage nötig sind, um die globalen<br />

Sicherheitsfunktionen zu gewährleisten. Diese<br />

zweite Stufe der Verfeinerung erfordert dabei bereits,<br />

die unter Punkt 2.2 identifizierten zu beherrschenden<br />

Ereignisse zu berücksichtigen, da abhängig vom jeweiligen<br />

Ereignisablauf zur Gewährleistung einer globalen<br />

Sicherheitsfunktion unterschiedliche verfahrestechnische<br />

Funktionen benötigt werden. Diese zweite Stufe<br />

der Verfeinerung wird von Experten der Verfahrenstechnik<br />

durchgeführt. Sie erlaubt bereits eine vorläufige<br />

Einstufung der sicherheitstechnischen Bedeutung der<br />

verfahrenstechnischen Funktion.<br />

In einer dritten Stufe der Verfeinerung (Level 3)<br />

werden alle leittechnischen Funktionen (I&C functions)<br />

identifiziert und spezifiziert, die zur Sicherstellung<br />

der verfahrenstechnischen Funktionen verlangt<br />

werden. Das Ergebnis dieses Verfeinerungsschrittes<br />

ist eine konkrete verfahrenstechnische Aufgabenstellung<br />

an die Leittechnik, die vereinfachend als leittechnische<br />

Funktion bezeichnet wird, siehe Bild 3.<br />

Sie spezifiziert unter anderem, welche Prozessvariablen<br />

in welcher Qualität zu erfassen und durch welche<br />

Algorithmen daraus Stellbefehle zu erzeugen<br />

sind, unter welchen Bedingungen die Funktion erbracht<br />

werden muss (zum Beispiel nach Erdbeben<br />

oder Feuer) sowie die Anforderungen an das Zeitverhalten,<br />

an das Fehlerverhalten oder an die Unabhängigkeit<br />

von anderen Funktionen. Auch diese dritte<br />

Stufe der Verfeinerung wird von den Experten der<br />

Verfahrenstechnik durchgeführt, wobei in der Regel<br />

Leittechniker daran beteiligt sind.<br />

Im letzten Schritt der Verfeinerung (Level 4) wird die<br />

leittechnische Funktion um die implementierungsrelevanten<br />

Details ergänzt. Hierbei wird beispielsweise<br />

spezifiziert, wie sich die geforderte Funktionalität auf<br />

die Hardware verteilt. In diesem Schritt wird ebenso<br />

Funktionalität ergänzt, die ausschließlich für leittechnische<br />

Zwecke benötigt wird. Das ist beispielsweise<br />

zusätzliche Funktionalität, um Ausfälle in der Leittechnik<br />

zu erkennen und zu melden, um Reparaturund<br />

Wartungsmaßnahmen zu vereinfachen oder um<br />

wiederkehrende Prüfungen zu automatisieren.<br />

Dieser letzte Schritt wird von Experten der Leittechnik<br />

durchgeführt. Er ist aber erst dann möglich, wenn<br />

die Rolle der leittechnischen Funktionen im Konzept<br />

der gestaffelten Verteidigung bekannt und damit die<br />

leittechnische Architektur festlegt ist. Er ist somit ein<br />

wesentlicher Bestandteil der leittechnischen Systemauslegung.<br />

Vollständigkeitshalber werden noch Aspekte erwähnt,<br />

die beim leittechnischen Design berücksichtigt<br />

und dokumentiert werden müssen, <strong>ohne</strong> einzeln darauf<br />

einzugehen:<br />

Interfacedesign einschließlich der Mensch-Maschinen-Schnittstellen<br />

(HMI),<br />

das Konzept für Signalerfassung und Verteilung,<br />

das Alarmkonzept,<br />

das Vorrangkonzept (Sicherstellung, dass Befehle<br />

aus der Sicherheitsleittechnik stets Vorrang haben<br />

gegenüber denen aus der betrieblichen Leittechnik),<br />

das Stromversorgungskonzept,<br />

das EMV- und Erdungskonzept,<br />

das Konzept zur räumlichen und elektrischen Entkopplung<br />

der Redundanzen sowie Überspannungsschutz,<br />

das IT-Security-Konzept,<br />

das Service- und Wartungskonzept inklusive des<br />

Konfigurations- und Versionsmanagements,<br />

das Konzept zur wiederkehrenden Prüfung.<br />

2.4 Festlegung des Barrierenkonzeptes<br />

Die Grobstruktur des Barrierenkonzeptes wird durch<br />

das kerntechnische Regelwerk vorgegeben, indem unabhängige<br />

Funktionen für den Normalbetrieb, für die<br />

Störfallbeherrschung und für die Minimierung des<br />

Restrisikos gefordert werden. Aus der Rolle der verfahrenstechnischen<br />

Funktionen in den entsprechenden<br />

Zuständen der Anlage ergibt sich eine erste Zuordnung<br />

der leittechnischen Funktionen zu diesen Barrieren.<br />

Diese erste Zuordnung wird dann im Rahmen der Störfallanalysen<br />

verifiziert und gegebenenfalls modifiziert,<br />

indem Funktionen in eine andere Barriere verschoben<br />

oder mehrfach implementiert werden. Im Rahmen der<br />

Störfallanalyse wird für alle postulierten Ereignisse<br />

ermittelt, welche Funktionen zum Einhalten der globalen<br />

Sicherheitsfunktionen beitragen und in welchem<br />

Umfang dies geschieht.<br />

Ein Ergebnis dieser Analyse ist das Back-up-Konzept,<br />

bei dem für alle Ereignisabläufe ermittelt wird, welche<br />

Back-up-Funktionen kreditiert werden können, wenn<br />

primäre verfahrenstechnische oder leittechnische<br />

Funktionen versagen sollten, und in welcher Folge dies<br />

möglich ist.<br />

Damit alle postulierten Ereignisse einen vergleichbar<br />

geringen Beitrag zum Restrisiko beitragen, erfordern<br />

Ereignisse mit einer höheren Eintrittshäufigkeit gegebenenfalls<br />

auch mehrere Back-up-Funktionen.<br />

Bild 4 veranschaulicht ein derartiges Konzept der gestaffelten<br />

Verteidigung bestehend aus vier Barrieren in<br />

Anlehung an die Auslegung des EPR. Das Konzept ist<br />

in Form eines Diagrammes veranschaulicht, bei denen<br />

die Abszisse die Betriebszustände und die auslegungsrelevanten<br />

Ereignisse der Anlage – gruppiert nach deren<br />

Eintrittshäufigkeit – repräsentiert, während die Ordinate<br />

deren mögliche Auswirkungen auf die Anlage gestaffelt<br />

nach der Schwere aufzeigt. Die waagerechten<br />

58<br />

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

5 / 2014


Objectives<br />

Reactivity<br />

Cooling<br />

Release<br />

Safety<br />

Level 1<br />

Safety objectives<br />

Safety functions<br />

Process<br />

Level 2<br />

Related process functions<br />

Level 3<br />

Specification of I&C functions<br />

I&C<br />

Level 4<br />

Implementation of I&C functions<br />

BILD 2: Detaillierungsebenen der Funktionsspezifikation<br />

BILD 3:<br />

Beispielhafte Darstellung<br />

einer leittechnischen<br />

Funktion auf Ebene 3<br />

Balken in diesem Diagram stellen die unterschiedlichen<br />

Barrieren in Form einer Gruppe verfahrenstechnischer<br />

und leittechnischer Funktionen dar, durch die unzulässige<br />

Auswirkungen dieser Betriebszustände und Ereignisse<br />

auf die Anlage verhindert werden sollen. Die<br />

Länge der Balken repräsentiert dabei die Zuverlässigkeit<br />

der entsprechenden Funktionen.<br />

Barriere Normalbetrieb und vorbeugende Verteidigung<br />

(preventive line): Die Barriere Normalbetrieb<br />

und vorbeugende Verteidigung umfasst alle verfahrenstechnischen<br />

und leittechnischen Funktionen,<br />

die im Normalbetrieb (DBC 1 Ereignisse) und beim<br />

Auftreten von Betriebstransienten (DBC 2 Ereignissen)<br />

den störungsfreien Betrieb der Anlage und die<br />

Einhaltung der globalen Sicherheitsfunktionen<br />

gewährleisten.<br />

Hauptbarriere (main line): Die Hauptbarriere umfasst<br />

zum einen alle verfahrenstechnischen und<br />

leittechnischen Funktionen zur Einhaltung der<br />

globalen Sicherheitsfunktionen beim Auftreten<br />

von Störfällen (DBC 3/4 Ereignisse). Zum anderen<br />

bezieht sie alle verfahrenstechnischen und<br />

leittechnischen Funktionen zur Einhaltung der<br />

globalen Sicherheitsfunktionen mit ein, bei<br />

einem unterstellten Versagen der vorgelagerten<br />

Barriere in Überlagerung mit einem entsprechenden<br />

Ereignis. Das heißt, die Hauptbarriere<br />

beinhaltet Back-up-Funktionen, mit denen sich<br />

alle Ereignisse der vorgelagerten Barriere beherrschen<br />

lassen.<br />

Barriere Risikominimierung (risk reduction line):<br />

Die Barriere Risikominimierung umfasst verfahrenstechnische<br />

und leittechnische Funktionen zur<br />

Vermeidung schwerer Störfälle bei sehr seltenen<br />

Einwirkungen von außen und bei Auslegungsstörfällen<br />

in Überlagerung mit dem postulierten Versagen<br />

der Funktionen der Hauptbarriere, wobei<br />

allerdings ein höheres Schadenspotenzial toleriert<br />

wird. Dies wird im Diagram in Bild 4 dadurch ersichtlich,<br />

dass der entsprechende Balken auf der<br />

Ordinate höher angeordnet ist als der Balken der<br />

Hauptbarriere. Das besagt, die Barriere Risikominimierung<br />

beinhaltet alle für die Vermeidung<br />

schwerer Störfälle erforderlichen Back-up-Funktionen<br />

zur Hauptbarriere.<br />

Barriere Schwere Störfälle (severe accidents): Die<br />

Barriere Schwere Störfälle umfasst nur sehr wenige<br />

leittechnische Funktionen, im Wesentlichen zur<br />

Überwachung der Bedingungen im Containment.<br />

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

5 / 2014<br />

59


HAUPTBEITRAG<br />

2.5 Festlegung der leittechnischen Architektur<br />

Da Barrieren auch leittechnische Backup-Funktionen<br />

zu den Funktionen der unterlagerten Barriere enthalten,<br />

ist die Wirksamkeit des Konzeptes in Bezug auf das<br />

Versagen der Leittechnik nur dann sichergestellt, wenn<br />

jede Barriere in einem unabhängigen leittechnischen<br />

System implementiert wird. In diesem Sinne legt das<br />

Barrierekonzept die minimale Anzahl unabhängiger<br />

Systeme in der leittechnischen Architektur fest. Bild 5<br />

zeigt, wie sich das erläuterte Barrierenkonzept in der<br />

leittechnischen Architektur des EPR abbildet. Die Zuordnung<br />

der Teilsysteme der Leittechnik zu den Verteidigungslinien<br />

sieht so aus:<br />

Die Barriere Normalbetrieb und vorbeugende Verteidigung<br />

wird durch das Prozessautomatisierungssystem<br />

(PAS) sowie das Reaktorleistungsregel-<br />

und Begrenzungssystem (RCSL) realisiert,<br />

die Hauptbarriere wird durch das Reaktorschutzsystem<br />

(PS) sowie die Sicherheitsautomation (SAS)<br />

verwirklicht,<br />

die Barriere Risikominimierung wird durch die<br />

diversitäre Sicherheitsautomation (DAS) umgesetzt,<br />

und<br />

die Barriere Schwere Störfälle wird durch das<br />

Überwachungssytem (SA-I&C) erreicht.<br />

Dabei ist zu beachten, dass leittechnische Funktionen<br />

verschiedener Barrieren unabhängig voneinander arbeiten<br />

müssen und zur Beherrschung des Versagens<br />

wegen Fehler gemeinsamer Ursache (Common Cause<br />

Failure, CCF) die Leittechnik der Risikoreduktionslinie<br />

diversitär zur Technik in der Hauptverteidigungslinie<br />

ausgeführt wird.<br />

2.6 Designvalidierung<br />

Die fertig projektierten leittechnischen Funktionen<br />

müsssen überprüft werden, ob sie im Fall der zu beherschenden<br />

Ereignisse wirken. Grundlagen dafür sind<br />

Ergebnisse der Transientenanalyse unter Berücksichtigung<br />

der hydraulischen beziehungsweise mecha-<br />

Overall safety target<br />

Acceptance criteria<br />

Severe accidents<br />

Risk reduction line<br />

Preventive line<br />

Design basis categories<br />

Main line<br />

Reliability claim<br />

DBC 1/2 DBC 3/4 DEC A/B Severe<br />

accidents<br />

BILD 4:<br />

Konzept der<br />

gestaffelten<br />

Verteidigung mit<br />

vier Barrieren<br />

Design basis events<br />

Simplified I&C A<br />

BILD 5:<br />

Verteidigungslinien<br />

aus leittechnischer<br />

Sicht<br />

Level 0 Level 1 Level 2<br />

GW<br />

Process information and<br />

control system (PICS)<br />

GW<br />

PAS<br />

RCSL SAS PS DAS SA-I&C<br />

Digital<br />

PAC<br />

Digital<br />

Digital<br />

Digital<br />

GW<br />

PAC<br />

Hardwired<br />

PAC<br />

GW<br />

Digital<br />

Integrated<br />

primary HMI<br />

Dedicated<br />

secondary HMI<br />

PA<br />

C = Priority actuator control<br />

GW = Gateway<br />

Hardwired interface<br />

Network interface<br />

Preventive line<br />

Main line<br />

Risk<br />

reduction<br />

line<br />

Severe<br />

accidents<br />

60<br />

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

5 / 2014


nischen Einflüsse. Die deterministische CCF-Analyse<br />

soll die Robustheit der Leittechnik gegen potentenzielles<br />

systematisches Versagen aufzeigen. Eine Analyse<br />

des Diversitätsgrades, in [6] Dissimilaritätsgrade<br />

genannt, bestimmter leittechnischer Einrichtungen,<br />

insbesondere zwischen der Hauptverteidigungslinie<br />

und der Risikoreduktionslinie, ist zu empfehlen. Weiterhin<br />

muss die probabilistische Analyse die Ausgeglichenheit<br />

des leittechnischen Designs in Übereinstimmung<br />

mit den verfahrenstechnischen Zielwertevorgaben<br />

belegen [7].<br />

ZUSAMMENFASSUNG<br />

Das schutzzielorientierte Design der digitalen Sicherheitsleittechnik<br />

in modernen Kernkraftwerken wurde<br />

vorgestellt. Anhand des Beispiels eines EPR-Neubauprojekts<br />

wird der Top-down-Entwurfsprozess mit den<br />

Verfeinerungsschritten detailliert beschrieben. Die risikobasierte<br />

Ereignisgruppierung führt zu einer leittechnischen<br />

Struktur mit unabhängigen, gestaffelten<br />

Verteidigungslinien/Barrieren und sichert die Sicherheitsvorsorge<br />

auf dem Stand der Wissenschaft und<br />

Technik, um solche kerntechnischen Anlagen verantwortungsvoll<br />

bauen und betreiben zu können. Darüber<br />

hinaus könnte der systematische Ansatz auch auf andere<br />

<strong>Industrie</strong>anwendungen mit Sicherheitsrelevanz<br />

adaptiert werden.<br />

DANKSAGUNG<br />

Der Autor möchte sich ganz herzlich bei Herrn<br />

Dr. Arnold Graf von Areva Deutschland für seine<br />

wertvollen Verbesserungsvorschläge zum<br />

Beitragstext sowie die Überlassung einiger<br />

Werksbilder bedanken.<br />

MANUSKRIPTEINGANG<br />

10.01.2014<br />

Im Peer-Review-Verfahren begutachtet<br />

REFERENZEN<br />

AUTOR<br />

[1] Areva NP GmbH: TELEPERM XS - The Digital I&C<br />

System for Functions Important to Safety in Nuclear<br />

Power Plants. Areva, 2009<br />

[2] Bastl, W., Bock, H.-W.: German qualification and<br />

assessment of digital I&C systems important to<br />

safety. Reliability Engineering & System Safety 59(2),<br />

S. 163-170, 1998<br />

[3] Bock, H.-W., Graf, A.: Type-testing – The German<br />

approach to qualifying safety critical software.<br />

Nuclear Engineering International 1996<br />

[4] Ding, Y.: Automation of an entire nuclear power plant,<br />

taking Tianwan, China, as an Example. In: Tagungsband<br />

WANO-Workshop Computer based I&Csystems:<br />

necessity for continuous improvement,<br />

S. 48-60.WANO, 2001.<br />

[5] Xu, X., Li, Y., Ding, Y.: Design Optimization and<br />

Operational Experiences of Digital Safety I&C In<br />

Tianwan NPP / China. In: Tagungs-CD 2. Symposium<br />

Digital Safety I&C, S. 14-18. TÜV Nord Akademie,<br />

2010<br />

[6] Bühler, C.: Sicherheitsanalytik für den Einsatz neuer<br />

digitaler Sicherheitsleittechnik-systeme.<br />

atw – Internationale Zeitschrift für Kernenergie<br />

57 (5), S. 331-336, 2012<br />

[7] Ding, Y., Gu, C., Hauptmanns, U.: Zuverlässigkeitsuntersuchung<br />

und -berechnung rechnerbasierter<br />

Sicherheitsleittechnik in Kernkraftwerken, In:<br />

Tagungsband Entwurf komplexer Automatisierungssysteme<br />

2012, S. 217-226, ifak 2012<br />

Prof. Dr.-Ing. YONGJIAN<br />

DING (geb. 1959) ist<br />

Professor für Steuerungstechnik<br />

und Automatisierungssysteme<br />

und Direktor<br />

des Instituts für Elektrotechnik<br />

der Hochschule<br />

Magdeburg-Stendal. Er<br />

studierte Elektrotechnik an<br />

der Technischen Universität München und<br />

promovierte an der Fakultät für Elektrotechnik<br />

und Informationstechnik. Er war 17 Jahre in<br />

der <strong>Industrie</strong> tätig, unter anderem bei der<br />

Gesellschaft für Anlagen- und Reaktorsicherheit<br />

(GRS) mbH und deren Tochtergesellschaft<br />

Institut für Sicherheitstechnologie (ISTec)<br />

GmbH in Garching, bei Siemens KWU-N in<br />

Erlangen (heute Areva) und bei der E.On<br />

Kernkraft GmbH in Hannover. Er ist seit 2011<br />

Mitglied des Ausschusses für elektrische<br />

Einrichtungen der Reaktorsicherheitskommission<br />

der Bundesregierung (RSK-EE). Hauptarbeitsgebiete:<br />

Sicherheitsautomation und<br />

Zuverlässigkeitsanalyse.<br />

Hochschule Magdeburg-Stendal,<br />

Breitscheidstr. 2, D-39114 Magdeburg,<br />

Tel. +49 (0) 391 886 48 06,<br />

E-Mail: yongjian.ding@hs-magdeburg.de<br />

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

5 / 2014<br />

61


IMPRESSUM / VORSCHAU<br />

IMPRESSUM<br />

VORSCHAU<br />

Verlag:<br />

DIV Deutscher <strong>Industrie</strong>verlag GmbH<br />

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

Telefon + 49 (0) 89 203 53 66 0<br />

Telefax + 49 (0) 89 203 53 66 99<br />

www.di-verlag.de<br />

Geschäftsführer:<br />

Carsten Augsburger, Jürgen Franke<br />

Verlagsleiterin:<br />

Kirstin Sommer<br />

Spartenleiterin:<br />

Anne Purschwitz geb. Hütter<br />

Herausgeber:<br />

Dr.rer.nat. Thomas Albers<br />

Dr. Gunther Kegel<br />

Dipl.-Ing. Hans-Georg Kumpfmüller<br />

Dr.-Ing. Wilhelm Otten<br />

Beirat:<br />

Dr.-Ing. Kurt Dirk Bettenhausen<br />

Prof. Dr.-Ing. Christian Diedrich<br />

Prof. Dr.-Ing. Ulrich Epple<br />

Prof. Dr.-Ing. Alexander Fay<br />

Prof. Dr.-Ing. Michael Felleisen<br />

Prof. Dr.-Ing. Georg Frey<br />

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 />

Anne Purschwitz geb. Hütter (ahü)<br />

(verantwortlich)<br />

Telefon + 49 (0) 89 203 53 66 58<br />

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

Aljona Hartstock (aha)<br />

Telefon + 49 (0) 89 203 53 66 78<br />

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

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 <strong>Industrie</strong>verlag<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 <strong>ohne</strong><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 <strong>Industrie</strong>verlag 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 6 / 2014 DER<br />

ERSCHEINT AM 28.05.2014<br />

MIT DEM SCHWERPUNKT<br />

„LEBENSZYKLUSKOSTEN UND SERVICES<br />

IN DER AUTOMATION“<br />

Virtuelle Inbetriebnahme<br />

in der Prozessindustrie<br />

OPC UA für<br />

<strong>Industrie</strong> <strong>4.0</strong><br />

Ein Ansatz zur<br />

Messung von<br />

Engineering-Effizienz<br />

– Teil 2<br />

Aus aktuellem Anlass können sich die Themen<br />

kurzfristig verändern.<br />

LESERSERVICE<br />

E-MAIL:<br />

leserservice@di-verlag.de<br />

TELEFON:<br />

+ 49 (0) 931 417 04 59<br />

62<br />

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

5 / 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


Der Klassiker für die<br />

Prozessautomation geht<br />

ins 21. Jahrhundert<br />

Das Handbuch der Prozessautomation ist ein Standardwerk für die Planung<br />

verfahrenstechnischer Anlagen. In der 5., überarbeiteten Version geht es auf<br />

die Herausforderung bei der Digitalisierung der Anlage ein. Das Handbuch<br />

wurde von fast 50 Experten mit umfassenden Praxiskenntnissen gestaltet<br />

und deckt das gesamte Feld der Prozessautomatisierung ab.<br />

Hrsg.: K. F. Früh, U. Maier, D. Schaudel<br />

5. Auflage 2014<br />

740 Seiten, 170 x 240mm, Hardcover<br />

Erhältlich in 2 Varianten<br />

www.di-verlag.de<br />

DIV Deutscher <strong>Industrie</strong>verlag GmbH, Arnulfstr. 124, 80636 München<br />

Jetzt vorbestellen!<br />

Bestellung per Fax: +49 (0) 201 Deutscher / 82002-34 <strong>Industrie</strong>verlag GmbH oder | Arnulfstr. abtrennen 124 und | 80636 im München Fensterumschlag einsenden<br />

Ja, ich bestelle gegen Rechnung 3 Wochen zur Ansicht<br />

___ Ex.<br />

Handbuch der Prozessautomatisierung<br />

5. Auflage – ISBN: 978-3-8356-3372-8<br />

für € 199,90 (zzgl. Versand)<br />

Firma/Institution<br />

Vorname, Name des Empfängers<br />

___ Ex.<br />

Handbuch der Prozessautomatisierung<br />

mit interaktivem eBook (Online-Lesezugriff im MediaCenter)<br />

5. Auflage – ISBN: 978-3-8356-7119-5<br />

für € 259,90 (zzgl. Versand)<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 <strong>ohne</strong> 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 />

PAHBPA2014<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 <strong>Industrie</strong>verlag 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!