atp edition Industrie 4.0 ohne modellbasierte Softwareentwicklung (Vorschau)
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
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.