atp edition atp editionArbeitsabläufe in der Anlagenplanung optimieren (Vorschau)
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
9 / 2011
53. Jahrgang B3654
Oldenbourg Industrieverlag
Automatisierungstechnische Praxis
Fortschritt bei Simulation
von Montagemaschinen | 24
Life Cycle Support
per Simulator | 32
Arbeitsabläufe in der
Anlagenplanung optimieren | 40
Von Zäunen befreit | 52
EDITORIAL
Konzentration auf
das Wesentliche
Bei der Gestaltung automatisierter technischer Systeme werden in den verschiedenen
Phasen immer wieder mathematische Modelle erstellt, um zu
überprüfen, ob die gefundenen Lösungsansätze bestimmten Anforderungen im
Hinblick auf Zuverlässigkeit, Sicherheit und Wirtschaftlichkeit genügen. Diese
Modelle bilden wenige ausgewählte Teilaspekte des zu beschreibenden Systems
ab, vieles wird bewusst vernachlässigt. Gerade in den frühen Phasen der Entwicklung
wären sehr umfangreiche Modelle auch eher hinderlich denn nützlich,
da viele Details zu diesem Zeitpunkt wenn überhaupt nur vage bekannt sind. Die
Nützlichkeit von Modellen zeigt sich bei der Planung von technischen Systemen
häufig weniger in der vollständigen Abbildung möglichst vieler Teilaspekte der
Realität, als vielmehr darin, dass sie die zum Entscheidungszeitpunkt aktuelle
Fragestellung mit einer dem unternehmerischen Risiko angemessenen Genauigkeit
und einem für die Modellierung vertretbaren Aufwand beantworten können.
In dieser Ausgabe der atp edition wird in zwei Aufsätzen beispielhaft aufgezeigt,
wie die Aufwände bei der Erstellung, Pflege und Anpassung der Informations-
und Simulationsmodelle in den Griff bekommen werden können. Eine
zentrale Rolle spielt dabei die automatisierte Ableitung aus der in den Planungsprozessen
generierten Information. Deutlich wird aus den Beiträgen aber auch,
dass generische Lösungen noch nicht in Sicht sind. Hierzu sind noch eine Vielzahl
von Forschungs- und Entwicklungsarbeiten an der Schnittstelle von Theorie
und Praxis notwendig. Abgesehen von der wissenschaftlichen Weiterentwicklung
der mathematisch-technischen Lösungsansätze wird für die Überführung
in die Praxis von besonderer Bedeutung sein, ob es uns gelingt, durch eine nutzerfreundliche,
gebrauchstaugliche Gestaltung der Planungs-, Unterstützungsund
Hilfesysteme unsere Ingenieure zu befähigen, die Ergebnisse der Simulationsexperimente
trotz aller Automatisierung kritisch hinterfragen und bewerten
zu können. Hoffnungsfroh stimmt mich, dass diese zukunftsweisenden Entwicklungen
in der Automatisierungstechnik von einer Reihe von Fachausschüssen
und Arbeitskreisen von GMA und Namur aktiv mitgestaltet werden.
Die atp edition wird diesen Wandel in der automatisierungstechnischen Praxis
wissenschaftlich und praxisorientiert begleiten. Dabei muss sie sich selbst ebenfalls
kontinuierlich neu erfinden, um den hohen Qualitätsansprüchen ihrer Leser
gerecht zu werden. So finden Sie ab dieser Ausgabe mit etwa 6-monatigem
Vorlauf Aufrufe zur Beitragseinreichung zu aktuellen thematischen Schwerpunkten.
Die von Prof. Schiller eingeführte Fachredaktion wird weiter ausgebaut.
Zudem arbeiten wir intensiv daran, die Bearbeitungszeiten Ihrer Beiträge für die
atp edition zu verkürzen und die Sichtbarkeit in den einschlägigen Suchmaschinen
des Internets zu erhöhen.
PROF. DR.-ING.
LEON URBAS,
Chef redakteur atp edition
atp edition
9 / 2011
3
INHALT 9 / 2011
VERBAND
6 | Plant Asset Management in der Prozessindustrie
IEC 1906 Award geht an 14 deutsche Experten
FORSCHUNG
7 | Halbleiterkomponenten dreidimensional integrieren
Energie gewinnen bei kleinen Temperaturdifferenzen
BRANCHE
8 | AutomationML-Plugfest: Hart arbeiten statt feiern
atp-Themenschwerpunkte: Gestalten Sie mit!
Deutsche MSR-Hersteller bauen Marktanteil aus
9 | Spielerisch das Anlagenmanagement optimieren
Die Erwartungen werden deutlich zurück geschraubt
10 | Feuer und Flamme für edle Textiloberflächen
12 | Berührungslose Füllstandskontrolle optimiert das
Downstream Processing der Antigenherstellung
16 | Webbasierte Fernüberwachung visualisiert
Solarpark-Daten flexibel und transparent
20 | Komplexe Smart Grids effizient mit
Standard-Steuerungen automatisieren
4
atp edition
9 / 2011
HAUPTBEITRÄGE
24 | Fortschritt bei Simulation von Montagemaschinen
A. KUFNER, P. DREISS UND P. KLEMM
32 | Life Cycle Support per Simulator
H. KRAUSE, A. FRICK UND T. SCHIEFLOE
40 | Arbeitsabläufe in der Anlagenplanung optimieren
L. LIBUDA, G. GUTERMUTH UND S. HEISS
52 | Von Zäunen befreit
B. OSTERMANN, M. HUELKE UND A. KAHL
PRAXIS
60 | Robuste Laptops unterstützen die papierfreie und
lückenlose Dokumentation in der Pharmafertigung
RUBRIKEN
3 | Editorial
62 | Impressum, Vorschau
atp edition
9 / 2011
5
VERBAND
Plant Asset Management in der Prozessindustrie
Der VDI/VDE-GMA-Fachauschuss 6.23 „Plant Asset
Management“ arbeitet derzeit an einem Ergänzungsblatt
der Richtlinie VDI/VDE 26 51 Blatt 1 „Plant
Asset Management (PAM) in der Prozessindustrie –
Definition, Modell, Aufgabe, Nutzen“.
Mit Konzepten des Plant Asset Management entstehen
neue Möglichkeiten zum übergreifenden Management
von Produktionsanlagen – insbesondere in der
Prozessindustrie. Mittels Plant Asset Management
werden – im Idealfall – Informationen über die Produktionsfähigkeit
und die Effektivität des Einsatzes
aller Anlagenkomponenten ständig verfügbar gemacht,
sodass darauf basierende Optimierungen vorgenommen
werden können.
Ein Spezifikationsblatt, das eine sinnvolle Hersteller-Anwender-Kommunikation
ermöglicht und ein
Methodenblatt, das verschiedene Diagnosemethoden
beschreibt, werden derzeit erarbeitet. Interessenten
mit Praxisbezug können sich dem Fachausschuss anschließen.
MIT PLANT ASSET MANAGEMENT lässt sich das
übergreifende Management von Produktionsanlagen
optimieren. Bild: VDI/ Ernsting
VDI/VDE-GESELLSCHAFT
MESS- UND AUTOMATISIERUNGSTECHNIK (GMA),
VDI-Platz 1,
D-40468 Düsseldorf,
Telefon: +49 (0) 211 621 40,
Internet: www.vdi.de
IEC 1906 Award geht an 14 deutsche Experten
Die Internationale Elektrotechnische Kommission (IEC)
würdigt besonders aktive technische Experten in den
IEC-Gremien mit dem IEC 1906 Award. Der Preis wird an
Experten vergeben, die sich bei der Bearbeitung aktueller
Normungsprojekte besondere Verdienste erworben haben.
Vorschlagende für den IEC 1906 Award sind die TC-Vorsitzenden
und -Sekretäre.
„Wir sind sehr stolz, dass wir erneut einen führenden
Platz eingenommen haben. 14 von 124 Preisträgern
des IEC 1906 Award kommen aus Deutschland.
Mit ihrer Tatkraft tragen diese engagierten Experten
stark zum Ansehen der deutschen Normung auf nationaler,
europäischer und internationaler Ebene bei“,
so Dr. Bernhard Thies, Sprecher der Geschäftsführung
der DKE.
Folgende deutsche Experten werden ausgezeichnet:
Prof. Dr. Hans Otto Seinsch, Gottfried Wilhelm
Leibniz Universität Hannover, Hannover
(TC 2 „Rotating machinery“);
Dr. Utz Richter
(TC 29 „Electroacoustics“);
Dr. Jens Martin Seifert, Lapp Insulators
(TC 36 „Insulators“);
Peter Tolksdorf, VDE Prüf- und Zertifizierungsinstitut
(TC 61 „Safety of household and similar electrical
appliances“);
Siegfried Rudnik, Siemens AG
(TC 64 „Electrical installations and protection
against electric shock“);
Prof. Dr. Christian Diedrich, Ifak – Institut für
Automation und Kommunikation
(TC 65 „Industrial-process measurement and
control“);
Benno Grosser, Siemens AG
(TC 65 „Industrial-process measurement and
control“);
Dr. Klaus Bücher, Optosolar
(TC 82 „Solar photovoltaic energy systems“);
Dr. Oliver Mayer, GE Global Research
(TC 82 „Solar photovoltaic energy systems“);
Dr. Klaus Beissner, Physikalisch-Technische
Bundesanstalt (TC 87 „Ultrasonics“);
Dr. Arman Nyilas, Cryogenic Engineering &
Materials Expertise (TC 90 “Superconductivity“);
Rainer Taube, Taube Electronic
(TC 91 „Electronics assembly technology“);
Werner Haab, UL International Germany
(TC 108 „Safety of electronic equipment within the
field of audio/video, information technology and
communication technology“);
Prof. Dr. Christoph Busch, Fraunhofer-Institut für
Graphische Datenverarbeitung
(JTC 1 „ISO/IEC Joint Technical Committee for
Information Technology“).
DKE – DEUTSCHE KOMMISSION ELEKTROTECHNIK
ELEKTRONIK INFORMATIONSTECHNIK IM DIN UND VDE,
Stresemannallee 15, D-60596 Frankfurt am Main,
Tel. +49 (0) 69 630 80, Internet: www.dke.de
6
atp edition
9 / 2011
FORSCHUNG
Halbleiterkomponenten dreidimensional integrieren
Das Internet der Dinge beantwortet Fragen rund um den
Transportweg. Kleine Elektronikkomponenten, in denen
Sensoren und Sender fast unsichtbar integriert sind, machen
es möglich. Herzstück der Technologie sind Systeme, die
Komponenten in einem Minibaustein integrieren. Wissenschaftler
am Zentrum ASSID (All Silicon System Integration
Dresden), einem Ableger des Fraunhofer-Instituts für
Zuverlässigkeit und Mikroelektronik IZM in Berlin, arbeiten
an Verfahren rund um die 3D-Systemintegration.
„Derzeit bestehen Systeme aus unterschiedlichen Komponenten:
Prozessorchips, Speicher, Sensoren oder Transceiver.
Jede wurde bisher als ein einzelner Baustein behandelt.
Bei der 3D-Technologie werden alle Komponenten in
ein System integriert und bilden ein sogenanntes „Systemin-Package“,
sagt Jürgen Wolf, Standortleiter des IZM-ASSID.
So gefertigte Systeme sind leistungsstark, denn die Signale
werden schneller übertragen und verarbeitet. Gleichzeitig
vereinigen sie mehr Funktionen, sind kleiner und
lassen sich besser in Endgeräte integrieren. Durch die kom-
plexe Bauweise sind sie außerdem energiesparend. „Energy
Efficient System in Package“ nennen die Fraunhofer-
Forscher ihre Erfindung. Für die elektrische Verbindung
sorgen kupfermetallisierte Durchkontaktierungen, die
Through Silicon Vias (TSV).
Gefragt sind die Systeme überall da, wo es um rasche
und komplexe Signalverarbeitung geht. Das Zentrum AS-
SID besitzt eine komplette 300mm-Prozesslinie für die 3D-
Integration. Gegen IMEC in Belgien, die bislang größte
Konkurrenz des Dresdner Instituts, will sich ASSID mit
der besonderen Nähe zu Industriepartnern durchsetzen.
Derzeit sind in Dresden 32 Mitarbeiter beschäftigt. Die
Zahl soll aber auf 50 Mitarbeiter steigen. Am IMEC in
Belgien arbeiten 3000 Angestellte.
FRAUNHOFER-GESELLSCHAFT ZUR FÖRDERUNG
DER ANGEWANDTEN FORSCHUNG E.V.,
Hansastraße 27 c, D-80686 München,
Tel. +49 (0) 89 120 50, Internet: www.fraunhofer.de
Energie gewinnen bei kleinen Temperaturdifferenzen
Aus Wärme mit kleinen Temperaturdifferenzen entwickelt
ein neuartiger Stirlingmotor eine Bewegung, die sich in
elektrischen Strom umwandeln lässt. Im Rahmen seiner Bachelorarbeit
entwickelte Eric Timmermann an der Fakultät
Maschinen- und Energietechnik der Hochschule für Technik,
DER STIRLINGSMOTOR
nutzt Energie aus einer
geringen Temperaturdifferenz.
Das Projekt für eine
Bachelorarbeit wird nun in
seiner Erweiterung vom
Forschungsministerium
gefördert. Bild: HTWK Leipzig
Wirtschaft und Kultur Leipzig (HTWK) dieses neue Antriebsmodell.
Der Prototyp seiner Erfindung läuft bereits bei einer
Wassertemperatur von 45 °C. Das Verfahren eignet sich für
unerschlossene Einsatzgebiete im Rahmen der Nutzbarmachung
regenerativer Energiequellen. Anfang August startete
nun mehrjähriges Forschungsprojekt zur Weiterentwicklung.
Eric Timmermann, der inzwischen das Masterstudium Maschinenbau
(Profillinie Mechatronik) absolviert, ist als wissenschaftlicher
Mitarbeiter beteiligt. Das Projekt wird mit
rund 280 000 Euro vom Forschungsministerium gefördert.
HTWK LEIPZIG,
Karl-Liebknecht-Str. 132, D-04277 Leipzig,
Tel. +49 (0) 341 307 60, Internet: www.htwk-leipzig.de
TTH300. Erste
Wahl für hohe
Flexibilität bei
der Temperatur-
Messung
Für den Einsatz in HART-, PROFIBUS
und FOUNDATION Fieldbus-Netzwerken
entwickelt, bietet der leistungsstarke
Temperatur-Messumformer TTH300
höchste Flexibilität – Ihre erste Wahl.
www.abb.de/temperatur
ABB Automation Products GmbH
Tel.: 0800 111 44 11
Fax: 0800 111 44 22
E-Mail: vertrieb.messtechnik-produkte@de.abb.com
atpEDITION_TTH300_1_3.indd 1 28.06.11 11:32
atp edition
9 / 2011
7
BRANCHE
AutomationML-Plugfest: Hart arbeiten statt feiern
Mit einem „Plugfest“ will das Konsortium AutomationML
den Austausch von Planungsdaten mithilfe des
AutomationML-Datenformats testen. Bei der Veranstaltung
am 19. und 20. Oktober wird paarweise ein exemplarischer
Datenaustausch im neutralen AutomationML-
Datenmodell realisiert, um ein verbessertes Verständnis
für die Probleme beim Datenaustausch zu entwickeln.
Teilnehmen sollen Hersteller und Lösungsanbieter von
Werkzeugen, die über AutomationML-Schnittstellen verfügen
und insbesondere diejenigen, die nicht Mitglied des
Konsortiums sind. Das Plugfest findet statt im Science-to-
Business-Center, Centrum Industrial IT in Lemgo. AutomationML
befasst sich mit dem nahtlosen Datenaustausch
zwischen den verschiedenen Werkzeugen der unterschiedlichen
Phasen der Anlagenplanung. Dabei wurde
ein Format entwickelt, das alle Anlagendaten von der Topologie
über 3D-Geometrie und Kinematik bis hin zu Abläufen
und logischen Abhängigkeiten vereint.
AUTOMATIONML E.V. C/O IAF,
Universitätsplatz 2, D-39106 Magdeburg,
Tel.+ 49 (0) 391 671 18 26, Internet: www.automationml.org
atp-Themenschwerpunkte: Gestalten Sie mit!
DIE ATP EDITION wird künftig verstärkt thematische
Schwerpunkte setzen, zu denen wir Sie um Beitragsvorschläge
bitten. Im Heft 03/2012 möchten wir aktuelle und
perspektivische Entwicklungen von Informationssicherheit/IT-Security
in Wissenschaft und Praxis der Automatisierungstechnik
diskutieren. Zu diesem Spannungsfeld
zählen Themen wie Sicherheitsanalyse, Security in der
Kommunikation, die Gestaltung und Einführung von Security-Management-Systemen,
Standardisierungsprozesse
sowie Verantwortungs- und Ausbildungskonzepte.
Wir bitten Sie, bis zum 15. November gemäß atp-Autorenrichtlinien
ausgearbeitete Beitragsvorschläge per E-
Mail an urbas@oiv.de einzureichen. Die Autorenrichtlinien
senden wir Ihnen gerne zu (atp@oldenbourg.de). Ziel Ihres
Beitrags soll der Brückenschlag zwischen aktuellen Erkenntnissen
und Innovationen, methodischen Grundlagen
und künftigen Anwendungen in der industriellen
Praxis sein. Ansprechen soll Ihr Aufsatz technische Führungskräfte,
Entscheider und Key Experts der Automatisierungsbranche.
Alle Beiträge werden von einem Fachgremium
begutachtet. Möchten Sie sich aktiv an dem
Begutachtungsprozess beteiligen, nehmen Sie bitte Kontakt
mit uns auf.
Ihre Redaktion der atp edition
Leon Urbas, Gerd Scholz, Anne Hütter
Deutsche MSR-Hersteller bauen Marktanteil aus
Von 2000 bis 2010 hat Deutschland als Produzent für
Produkte und Lösungen der Mess-, Steuer- und Regeltechnik
(MSR-Technik) seinen Anteil der weltweiten Produktion
von sieben auf zehn Prozent ausgebaut – und
dabei Japan hinter sich gelassen. Michael Ziesemer, Vize-
DEUTSCHE MSR BAUT ANTEIL AUS: Innerhalb von zehn Jahren
konnte Deutschland seinen Anteil am weltweiten Markt für Mess-,
Steuer- und Regeltechnik deutlich ausbauen – die USA und Japan
sind die Verlierer. Quelle: ZVEI
Welt-Produktion 2000 in Mrd. € (Anteil in %) Welt-Produktion 2010 in Mrd. € (Anteil in %)
USA
USA
40 24
Japan
China
13 16
Deutschland
Deutschland
7 10
Großbritannien
Japan
6 6
Frankreich
105 Mrd. € Frankreich
118 Mrd. €
4 6
0 10 20 30 40 50 0 10 20 30 40 50
präsident des ZVEI und Vorsitzender des ZVEI-Fachbereichs
Messtechnik und Prozessautomatisierung, rechnet
vor: „Deutschland konnte mit einem Produktionsvolumen
von zwölf Milliarden Euro den dritten Platz hinter den
USA und China verteidigen. Die Produktionsanteile der
USA gingen von 40 auf 24 Prozent zurück, die von Japan
von 13 auf sechs Prozent. China konnte in diesem Zeitraum
den Anteil auf 16 Prozent stark ausbauen und hat
Japan von Platz zwei verdrängt.“
Stärken der deutschen Industrie seien die gut ausgebildeten
Fachkräfte, globaler Vertrieb und Service, hohe
Qualität der Produkte sowie technische Innovationskraft.
„In Deutschland ansässige Hersteller haben die richtigen
Trends erkannt. So haben sie zum Beispiel frühzeitig auf
die Anforderungen aus höherer Energieeffizienz und Klimaschutz
gesetzt“, begründet Ziesemer diesen Erfolg. Die
MSR-Technik macht zirka zehn Prozent des Gesamtumsatzes
der deutschen Elektroindustrie von 165 Milliarden
Euro im Jahr 2010 aus.
ZVEI - ZENTRALVERBAND ELEKTROTECHNIK- UND
ELEKTRONIKINDUSTRIE E.V.,
Lyoner Straße 9, D-60528 Frankfurt am Main,
Tel. +49 (0) 69 630 20, Internet: www.zvei.org
8
atp edition
9 / 2011
Spielerisch das Anlagenmanagement optimieren
TRAINING AM
SIMULATOR:
Im Online-Spiel
Plant-Manager
geht es darum
eine virtuelle
Anlage optimal
zu managen.
Bild: Siemens
Mit einem praxisnahen Online-Spiel können angehende
Ingenieure, aber auch gestandene Anlagenfahrer testen,
wie gut sie Anlagen managen können. Das Spiel Plantville
von Siemens richtet sich an Studenten und Bewerber,
aber auch an Siemens-Kunden und -Mitarbeiter (www.
plantville.com). Die Spieler verbessern darin Produktivität,
Effizienz und Nachhaltigkeit einer komplett simulierten
Fabrik. Plantville ist in englischer Sprache online
und hat inzwischen in mehr als 140 Ländern rund schon
16 000 registrierte Spieler.
Außer einem echten Anlagenmanager hat kaum jemand
eine Vorstellung von den Aufgaben und Herausforderungen
eines Anlageningenieurs. Daher hat Siemens Industry für
das Computerspiel Plantville drei typische Produktionsanlagen
ausgewählt: eine Flaschenabfüllanlage, eine Vitaminfabrik
und eine Eisenbahnfertigung. Ziel des Spiels ist,
Sicherheit, Qualität und Auslieferung der Anlagen zu verbessern.
Dazu müssen die Spieler zum Beispiel das Ener-
giemanagement oder die Mitarbeiterzufriedenheit optimieren
und können Siemens-Lösungen wie energiesparende
Servomotoren, Automatisierungssysteme oder Sprinkleranlagen
einsetzen. Sie können auch neue Mitarbeiter einstellen,
um die Produktivität zu erhöhen.
Eine vierte Anlage, eine „Fabrik des Jahres“, wird von
der Kunstfigur Pete vorbildlich geführt, die auch in das
Spiel einführt. Der Experte gibt den Teilnehmern immer
wieder Tipps. Pete verwendet dazu kurze Filme, Rätsel
oder Online-Chats im Plantville Café. Bei diesen Chats
leiten echte Anlagenexperten in regelmäßigen Abständen
Diskussionen zu Themen wie Maschinenoptimierung
oder Energieeffizienz. Zusätzlich können sich die Spieler
über Facebook, LinkedIn oder Twitter austauschen.
SIEMENS INNOVATIONNEWS,
Otto-Hahn-Ring 6, D-81739 München,
Tel. +49 (0) 89 63 64 58 99, www.siemens/innovationnews.de
Die Erwartungen werden deutlich zurück geschraubt
Erstmals sei eineinhalb Jahren verzeichnete die deutsche
Elektroindustrie im Juni einen Auftragsrückgang. Die
Bestellungen blieben acht Prozent unter ihrem Vorjahreswert.
„Allerdings hatte das Bestellwachstum im Juni letzten
Jahres mit einem Plus von 42 Prozent einen Höchstwert
erreicht“, unterstrich ZVEI-Chefvolkswirt Dr. Andreas
Gontermann. Aus dem Inland kamen im Juni 2011 drei
Prozent weniger Bestellungen als vor einem Jahr, aus dem
Ausland zwölf Prozent.
Noch im Mai waren die Bestellungen in der deutschen
Elektroindustrie „stark beeinflusst durch inländische
Großaufträge regelrecht explodiert“, so Gontermann. Sie
lagen 58 Prozent über dem Vorjahresniveau. Die Inlandsaufträge
hatten um 107 Prozent zugelegt, die Auslandsaufträge
um elf Prozent.
Im gesamten ersten Halbjahr 2011 haben die Auftragseingänge
ihren Vorjahresstand um 17 Prozent übertroffen.
Bei den Inlandsbestellungen belief sich das Plus auf 24
und bei den Auslandsbestellungen auf zehn Prozent.
„Offenbar auch vor dem Hintergrund der weltweit ungelösten
Schuldenprobleme ist das Geschäftsklima in der
deutschen Elektroindustrie im Juli dieses Jahres zum dritten
Mal in Folge gesunken“, so Dr. Gontermann. Zwar haben
die Elektrounternehmen die Einschätzung ihrer aktuellen
wirtschaftlichen Lage gegenüber Juni nur leicht nach unten
revidiert. Die Erwartungen für die kommenden sechs Monate
haben sich allerdings deutlicher abgeschwächt.
Hier fiel der Saldo aus positiven und negativen Beurteilungen
von 18 auf sechs Prozent. Dennoch: 94 Prozent der
Branchenfirmen bewerten ihre derzeitige Geschäftslage
als gut, sehr gut oder stabil. 88 Prozent der Firmen rechnen
mit gleich bleibenden oder weiter anziehenden Geschäften
im nächsten halben Jahr. Die Exporte der deutschen Elektroindustrie
blieben im Mai mit insgesamt 13 Milliarden
Euro noch auf Rekord-Kurs. „Dies war der höchste Ausfuhrwert,
der jemals in einem Mai erreicht wurde“, betonte
Gontermann.
ZVEI - ZENTRALVERBAND ELEKTROTECHNIK- UND
ELEKTRONIKINDUSTRIE E.V.,
Lyoner Straße 9, D-60528 Frankfurt am Main,
Tel. +49 (0) 69 630 20, Internet: www.zvei.org
atp edition
9 / 2011
9
anche
Feuer und Flamme für edle Textiloberflächen
Durchgängiges Automatisierungssystem steuert Seng-Anlagen präzise und zuverlässig
Von Stoffbahnen abstehende kleine Härchen oder Fäden
erschweren die Weiterverarbeitung der Stoffe und
können die Qualität des textilen Endprodukts beeinträchtigen.
Wird eine nicht faserfreie Textiloberfläche
beispielsweise bedruckt, wirkt das Druckbild verwaschen;
auch haftet Schmutz leichter an. Weltweit werden
Stoffe daher vor ihrer weiteren Verarbeitung mit Sengmaschinen
und Vorbehandlungsanlagen der Osthoff-
Senge GmbH vorbehandelt. Für die hohe Präzision, einen
reibungslosen Ablauf und die einfache Bedienung der
Maschinen sorgt ein durchgängiges Automatisierungssystem
von Lenze.
Mehr als 3000 Seng- und Vorbehandlungsstraßen des
in Wuppertal ansässigen Unternehmens Osthoff-Senge
sind weltweit im Einsatz, um abstehende Fasern von Geweben,
Gestricken oder technischen Textilien wie Glasgewebe
oder Fleece zu entfernen. Die dadurch gewonnene
hochglatte Oberfläche verleiht dem Stoff nicht nur
eine feine und klare Optik, sondern sie erleichtert auch
seine weitere Verarbeitung und Pflege, weil unter anderem
die Neigung zu verschmutzen sowie die Pilling-
Bildung reduziert werden.
OFFENE FLAMME BRENNT ABSTEHENDE FASERN AB
Das Prinzip des Sengens, in der Fachsprache auch Gasieren
genannt, ist seit Jahrhunderten gleich und denkbar
einfach: Mit hoher Geschwindigkeit wird das zu behandelnde
Gewebe an einer offenen (Gas-)Flamme vorbeigeführt
und die abstehenden Fasern und Flusen dabei abgebrannt.
Um hochqualitative Sengergebnisse zu erhalten,
muss der Sengvorgang in Flammintensität und Maschinengeschwindigkeit
optimal auf das zu bearbeitende Material
abgestimmt sein. Zudem muss die Flammintensität
während des Sengens nachgeführt werden können. Die
Sengflamme muss schließlich über die gesamte Stoffbahnbreite
hinweg möglichst homogen und stabil sein,
damit keine Unregelmäßigkeiten entstehen.
Für die Einhaltung dieser Anforderungen sind die Maschinen
und Anlagen von Osthoff-Senge weltweit anerkannt.
Die von dem Unternehmen entwickelte und durch
Patent geschützte Brennertechnologie erzeugt eine
1250 °C heiße Flamme. Damit können Textilien aus natürlichen,
regenerierten und synthetischen Fasern in
Sekundenbruchteilen von abstehenden Härchen und
anderem Überstand befreit werden.
KEINE ANLAGE GLEICHT DER ANDEREN
In der Regel wird dem Sengen ein Reinigungsschritt vorgeschaltet,
abschließend folgt ein weiterer Bearbeitungsvorgang,
um Aschereste und Verschmutzungen zu entfernen.
Auch andere Veredelungsschritte wie das Entschlichten,
das Imprägnieren oder das Kaltbleichen lassen
sich mit dem Sengen ideal verbinden.
„Weil es neben dem Sengen viele mögliche Vorbehandlungsprozesse
gibt, finden sich kaum zwei Anlagen, die
einander völlig gleichen“, erläutert Dipl.-Ing. Heiko Wilke.
Der Entwicklungsleiter von Osthoff-Senge betont: „Entsprechend
groß ist die Bandbreite der Anforderungen, die
wir an die Anlagensteuerung stellen müssen. In der Vergangenheit
konnten wir dieses Spektrum aus Kosten- beziehungsweise
Performance-Gründen nur mit mehreren
Steuerungsplattformen abdecken. Dies zog einen finanziellen
und zeitlichen Mehraufwand in puncto Engineering
und Wartung der Hard- und Software nach sich.“
Als es darum ging, eine neue Steuerungsplattform zu
entwickeln, lautete daher das erklärte Ziel, die verschiedenen
Anlagen in nur einer Steuerungsplattform abzubilden
und so Zeit und Kosten zu sparen.
UNIVERSELLES STEUERUNGSPROGRAMM
„Konkret heißt das, dass wir nur noch ein Steuerungsprogramm
und eine Visualisierungs- beziehungsweise
Maschinenbedienung realisieren wollten, Diese sollte
sich dann jeweils über eine Konfiguration an die bisher
ausgelieferten und zukünftigen Anlagen anpassen lassen“,
verdeutlicht Heiko Wilke. „Es lag nahe, Lenze in
die engere Wahl zu nehmen, denn wir haben bereits seit
Langem gute Erfahrungen mit der Antriebstechnik sowie
dem Service von Lenze gemacht. Außerdem bietet das
Unternehmen inzwischen auch komplette Automatisierungssysteme
an.“
In einer internen Evaluierung bei Osthoff-Senge konnte
sich Lenze gegen etwa zehn andere Anbieter durchsetzen.
Die externe Überprüfung durch einen renommierten
Engineering-Dienstleister, der die Technik einschließlich
der Preise detailliert untersuchte, kam zum
gleichen Ergebnis.
SCHNITTSTELLEN SORGEN FÜR FLEXIBILITÄT
Als Hardwareplattform für sein Anlagenkontroll- und
Überwachungssystem ‚Seng-Matic‘, das alle den Sengeffekt
beeinflussenden Parameter automatisch einstellt,
überwacht und regelt, nutzt Osthoff-Senge seitdem Geräte
aus der Embedded-Line-PC-Familie von Lenze. Auf
dem Gerät läuft eine Soft-PLC L-force Logic, die mit der
Engineering-Umgebung PLC Designer programmiert
wird. „Da der PLC Designer auf CoDeSys basiert und damit
praktisch keine Speicherbegrenzungen kennt, konnten
wir jedes denkbare Anlagenfeature in das universelle
Steuerungsprogramm aufnehmen. Auf die individuelle
Anlage werden dann nur jene Teile gespielt, die auch
tatsächlich gebraucht werden“, erklärt der Entwicklungschef
von Osthoff-Senge. „Obendrein müssen wir bei Lenze,
anders als bei vielen anderen Anbietern, nicht gleich
auf ein teureres Gerät mit mehr Rechenleistung oder eine
ganz andere Plattform umsteigen, nur weil eine Anwendung
mehr Speicher benötigt.“
Positiv beurteilt Wilke auch die Offenheit des Systems:
„CoDeSys verfügt über Schnittstellen, die wir genutzt
haben, um eigene Funktionen zu realisieren und auch
um manuell aufwendig zu erstellende Codes automatisiert
aus Excel-Listen zu generieren.“
VISUALISIERUNG FÜR INTUITIVE BEDIENUNG
Die hohe Flexibilität schätzt der Entwicklungsleiter auch
an VisiWinNET, dem Visualisierungssystem von Lenze:
„Die Entwicklungsumgebung ist vollständig in das Microsoft
Visual Studio integriert. Darum kann man Visualisierungs-
und Bedienanwendungen so umsetzen, dass
keine Wünsche offen bleiben.“ So hat Lenze nach den Vor-
10
atp edition
9 / 2011
gaben des Wuppertaler Maschinen- und Anlagenbauers
eine intuitiv bedienbare Oberfläche geschaffen. Sie erlaubt
es dem Bediener der Maschine, mittels Mausklick auf einer
bildlichen Darstellung der Gesamtanlage Unterfenster aufzurufen,
die den ausgewählten Anlagenteil im Detail anzeigen
und von dort aus seine Bedienung ermöglichen.
Die Ansteuerung der durchschnittlich fünf bis maximal
zehn Achsen der Anlagen übernehmen Umrichter
aus den Gerätefamilien 8200 vector und 9300 vector von
Lenze, die aus Kostengründen nicht über einen Bus, sondern
über digitale Ein- und Ausgänge mit der Steuerung
verbunden sind. Als I/O-System nutzt Osthoff-Senge das
modulare IP20-System von Lenze und verfügt damit über
ein durchgängiges Automatisierungssystem vom Umrichter
bis zur Visualisierung.
BLICK IN DIE ZUKUNFT
„Aufgrund der guten Erfahrungen mit der Antriebstechnik
hatten wir Lenze einen Vertrauensvorschuss eingeräumt,
als es um die Modernisierung unseres Anlagenkontroll-
und Überwachungssystems ‚Seng-Matic‘ ging“,
fasst Heiko Wilke zusammen. „Dieses Vertrauen wurde
nicht enttäuscht. Es hat sich gezeigt, dass wir uns wie
gewohnt auf den Support und die Technik des Unternehmens
verlassen können. Deshalb wollen wir auch zukünftig
auf Lenze bauen.“ Als weitere Schritte plant das Unternehmen
die Ablösung des bis dato verwendeten I/O-
Systems IP20-Modular durch das moderne I/O-System
1000 von Lenze.
Auch auf der Antriebsseite steigt Osthoff-Senge auf
aktuelle Varianten um: Die Umrichter 8200 beziehungsweise
9300 vector werden dann durch Geräte aus der
Umrichterfamilie Inverter Drives 8400 ersetzt. „Die bei
diesen Geräten schon in der Grundausstattung integrierte
CAN-Schnittstelle wird es uns ermöglichen, trotz des
in unserer Branche herrschenden hohen Kostendrucks
auf Bustechnik zur Einbindung der Umrichter umsteigen
zu können“, blickt der Entwicklungsleiter von Osthoff-
Senge in die nähere Zukunft.
Exakte Steuerung erforderlich: Eine Textilveredelungslinie
mit Seng-Station von Osthoff-Senge.
Bild 2:
„Wireless Control“
mit „Wired Energy“
Intuitiv BEdienbar: Die gelungene Visualisierung basiert auf
der flexiblen Umgebung VisiWinNET.
Autor
Bernd Wieners,
ist Key Account Manager
Automation bei Lenze.
Lenze SE,
Hans-Lenze-Str. 1,
D-31855 Aerzen
oBErflächenveredelung per Flamme: Beim Sengen werden
feinste Härchen und Fäden von der Oberfläche des Stoffes entfernt.
atp edition
9 / 2011
11
anche
Berührungslose Füllstandskontrolle optimiert das
Downstream Processing der Antigenherstellung
Impfstoffhersteller nutzt Ultraschallsensoren, um exakt zu bestimmen, wann Behälter geleert sind
Die Impfstoffproduktion von GlaxoSmithKline Biologicals
in Dresden wird durch berührungslos arbeitende
Ultraschall-Füllstandsensoren optimiert. Die Messeinrichtungen
erhöhen die Anlagensicherheit und verringern
Produktverluste.
Die berührungslose Füllstandüberwachung von Flüssigkeiten
spielt in vielen Bereichen der Prozessmesstechnik
und Automatisierung eine wichtige Rolle. Ultraschall-Füllstandsensoren
finden unter anderem Anwendung
bei hohen Drücken, aggressiven Medien oder speziellen
Reinheitsanforderungen. Letztere sind in der
pharmazeutischen und biotechnologischen Produktion
besonders hoch und bestimmend für die Auswahl der
Prozess- und Messtechnik. So entschied sich auch GlaxoSmithKline
Biologicals in Dresden (GSK), eine Tochtergesellschaft
von GSK Deutschland, für Ultraschallsensoren
zur präzisen Anzeige der Behälterentleerung
im Downstream Processing von Impfstoffen.
GSK stellt in Dresden Grippeimpfstoffe für den Weltmarkt
her. Das Unternehmen entwickelte und produzierte
beispielsweise auch den Impfstoff gegen die pan-
demische H1N1-Grippe frühzeitig am ostdeutschen
Standort. Die Produktionskapazität der GSK-Tochter
liegt bei 70 Millionen Impfdosen pro Jahr. Neben der
saisonalen Produktion komplettiert die Abfüllung und
Verpackung weiterer Flüssigimpfstoffe das Portfolio
des Dresdner Werks.
DIE WIRKSTOFFHERSTELLUNG
Das Ausgangsmaterial für die Herstellung des Grippeimpfstoffs
sind bebrütete Hühnereier. Aus Referenzvirenstämmen,
die von einem Labor der Weltgesundheitsorganisation
(WHO) bereitgestellt werden, präparieren die
Dresdener Experten lebende Krankheitserreger, sogenannte
Saatviren. Diese werden in die befruchteten Eier
gespritzt, die dann unter Wärmezufuhr mehrere Wochen
bebrütet werden. Das Impfvirus vermehrt sich in dieser
Zeit und reichert sich im Eiklar an. Nach Abziehen des
virushaltigen Eiweißes durchläuft dieses einen Reinigungsprozess.
Anschließend folgen die Separierung der
Viren und ihre Inaktivierung mit Hilfe von Chemikalien.
Die so entstandenen monovalenten Spaltviruslösungen
BERÜHRUNGSLOSE MESSUNG durch die Rohrwand: Der Ultraschallgrenzschalter
Sonocontrol 15 detektiert, ob eine Rohrleitung mit Flüssigkeit
oder Flüssiggas gefüllt ist oder nicht. Bild: Sonotec
DOWNSTREAM PROCESSING: Die Produkte jedes
einzelnen Reinigungs- und Separierungsschrittes werden
in Behältern gesammelt. Bild: GlaxoSmithKline Biologicals
12
atp edition
9 / 2011
| PC12-37bG |
Die Kompaktwunder
für den Schaltschrank.
enthalten nur noch die Bruchstücke der Virenhülle. Im
fertigen Impfstoff trainieren sie das menschliche Immunsystem
auf den jeweiligen Erreger, der dann keine Infektion
mehr hervorrufen kann.
Ein saisonaler Grippeimpfstoff besteht aus drei verschiedenen
Virusstämmen, die in einem definierten Verhältnis
gemischt werden. Die sich jährlich ändernde Zusammensetzung
gibt die WHO vor. Der fertige Wirkstoff
wird in Spritzen abgefüllt, länderspezifisch etikettiert
und verpackt. Bis dahin sind vom Eingang der Referenzstämme
im Dresdner Werk bis zur Auslieferung des fertigen
Grippeimpfstoffs rund sechs Monate vergangen.
KONTROLLE IM DOWNSTREAM PROCESSING
Die Biotechnologie bezeichnet den Reinigungs- und Separierungsprozess,
den das virushaltige Eiklar durchläuft,
als Downstream Processing. Die Produkte jedes
einzelnen Prozessschrittes werden in Behältern gesammelt.
Die Füllstände dieser Gefäße misst GSK mit
Schwimmer-Füllstandsonden. Diese sind typbedingt jedoch
nicht in der Lage, die Behälterentleerung anzuzei-
Halle 25, Stand E32
Halle 9,
Stand 9108
www.beckhoff.de/C6915
Die IPC-Serie C69xx für den Schaltschrankeinbau:
Kompakte, robuste Aluminiumgehäuse
3½-Zoll-Beckhoff-Motherboards mit On-Board-USV
C6915: Intel ® Atom, lüfterlos
C6925: Intel ® Celeron ® M ULV 1 GHz, lüfterlos
C6920: Intel ® Core Duo oder Core2 Duo
C6930: Intel ® Core Duo oder Core2 Duo,
On-Board-SATA-RAID-1-Controller
FüllstandskONTROLLE: Der Ultraschallsensor
zeigt die Behälterentleerung präzise an.
Bild: GlaxoSmithKline Biologicals
IPC
I/O
Motion
Automation
anche
gen. Für diesen Zweck benötigte GSK eine alternative
Messtechnik. 2007 begaben sich die Experten auf die
Suche nach einem passenden Füllstandmesser. „Im Rahmen
einer Internetrecherche stießen wir auf Sonotec.
Gleich bei unserem ersten gemeinsamen Termin fanden
die Ultraschallexperten eine geeignete Lösung für unsere
spezielle Anwendung“, erinnert sich Jörg Bellen, Support
Manager DSP 02 bei GSK in Dresden.
TEST IM PRODUKTIONSALLTAG
Die Spezialisten von Sonotec analysierten gemeinsam
mit Bellen und seinem Team die Messaufgabe. „Nach
Berücksichtigung aller anwendungsspezifischen Besonderheiten,
wie der Beschaffenheit der Tanks und der
Eigenschaften der Flüssigkeiten, fiel die Wahl auf unseren
Ultraschallgrenzschalter Sonocontrol 15“, erläutert
Diplom-Physiker Ingo Eckardt, zuständig für den Vertrieb
Prozessmesstechnik und Automatisierung bei
Sonotec. Jörg Bellen und sein Team konnte den Sensor
ausleihen und im Produktionsalltag testen. Das Ergebnis:
Sonocontrol 15 war der ideale Ultraschallsensor für die
berührungslose Füllstandkontrolle im Downstream
Processing der Antigenherstellung. Inzwischen setzt
GSK die Ultraschallgrenzschalter von Sonotec seit vier
Jahren erfolgreich zur Kontrolle der Behälterrestentleerung
ein. „Die guten Erfahrungen aus den ersten Tests
haben sich auch in der täglichen Praxis bestätigt. Die
Sensoren sind robust. Sie arbeiten absolut zuverlässig
und fehlerfrei“, sagt Jörg Bellen.
EINSATZ IN PHARMAZIE UND FEINCHEMIE
Der Ultraschallgrenzschalter Sonocontrol 15 detektiert
schnell und genau, ob eine Rohrleitung mit Flüssigkeit
oder Flüssiggas gefüllt ist oder nicht. Der Kompaktsensor
zur berührungslosen Messung durch die Rohrwand wird
vor allem in Anlagen der Pharmazie oder Feinchemie
eingesetzt. Wie auch bei GSK dient der Sensor in der
Pharmabranche häufig als Schalter zur Voll-/Leermeldung
an Rohrleitungen mit kleinen Nennweiten. „Der
Sensor ist außen am Rohr befestigt und unterscheidet
nach erfolgreichem Einlernen an dieser Position zwischen
Flüssigkeit und Gas/Luft“, erläutert Ingo Eckardt.
Besonders klar sind die Bedingungen dabei am senkrechten
Rohr. Am waagerechten Rohr kann sogar mit der
Wahl der Montageposition die Detektion verschiedener
Füllgrade von den ersten Gasblasen bis hin zu halb leer
realisiert werden. Das Sonocontrol 15 eignet sich zudem
für den Pumpenschutz, zur Überwachung von Abfüllanlagen
oder – wie bei GSK – der Kontrolle der Behälterrestentleerung.
Die Haupt-Einsatzgebiete sind
wässrige Produkte und Reinigungsflüssigkeiten
in der pharmazeutischen Industrie, Feinchemie
und Lebensmittelindustrie
aggressive und giftige Flüssigkeiten in der
chemischen Industrie
hochtoxische Spezialflüssigkeiten etwa in der
Halbleiterherstellung
Der Sensor zeichnet sich durch kurze Reaktions- und
Schaltzeiten aus. Die Gesamtkosten der Messstelle sind
niedrig, da keine Prozessanschlüsse erforderlich sind.
Darüber hinaus bietet Sonotec den Sensor optional auch
in einer Version für den Einsatz in explosionsgefährdeten
Bereichen an und realisiert zusätzlich zu den Standardprodukten
kundenspezifische Lösungen.
MONTAGE BEI LAUFENDEM BETRIEB
Der nachträgliche Einbau des Sensors bei GSK war nur
mit einem geringen Aufwand verbunden. „Die Sensoren
werden von außen am Rohr befestigt. Die vereinfachte
Montage des Zwei-Leiter-Systems kann sogar bei laufendem
Anlagenbetrieb erfolgen“, erklärt Ingo Eckardt. Da
weder der Ultraschall-Füllstandsensor noch die angeschlossene
Messtechnik mit dem Produkt in Berührung
kommen, konnten die GSK-Techniker den Messschalter
problemlos einem internen Change Control Prozess folgend
einbauen. Damit blieb die bestehende Reinigungsvalidierung
von der Nachrüstung unbeeinflusst. Auch
eine nachträgliche Versetzung des Ultraschallgrenzschalters
ist durch eine neue Rohrbefestigung aus Kunststoff
schnell und einfach möglich.
ENTLEERUNG WIRD EXAKT DETEKTIERT
Die zusätzliche Installation des Sonocontrol 15 in der
Behälterentleerung gestattet es GSK nun, den exakten
Zeitpunkt der vollständigen Entleerung zu detektieren.
„Die Kenntnis dieses Zeitpunkts ist für die nachfolgenden
Prozessschritte absolut entscheidend und wurde daher
in unserem Fall visualisiert“, erklärt Bellen. Besonders
zufrieden ist er darüber, dass mithilfe des neuen Sensors
die Anlagensicherheit erhöht und die Produktverluste
deutlich verringert werden konnten.
Autor
Dipl.-Kfr. MELANIE SCHMIDT
ist im Marketing von
Sonotec tätig.
Sonotec Ultraschallsensorik Halle GmbH,
Nauendorfer Straße 2,
D-06112 Halle (Saale),
Tel. +49 (0) 345 133 17 29,
E-Mail: m.schmidt@sonotec.de
14
atp edition
9 / 2011
Praxisseminar
12. + 13. oktober 2011
Anmeldung unter
www.26000seminar.de
ISO 26000
in der Praxis
Der Ratgeber zum Leitfaden für soziale
Verantwortung und Nachhaltigkeit
Eine Norm zur Verbesserung der Welt?
Nein, die ISO 26000 ist ein Leitfaden – nicht mehr, aber auch nicht weniger!
Auch wenn die ISO 26000 kein zertifizierbarer Managementsystem-Standard
und die Anwendung freiwillig ist, wird ihre Tragweite für Unternehmen
beträchtlich sein. Denn sie ist ein Leitfaden, der anhand von beispielhaften Verhaltensregeln
(Best Practices) Orientierung gibt, wie sich Organisationen verhalten
sollten, damit sie nach internationalem Verständnis als gesellschaftlich
verantwortungsvoll angesehen werden. Er stimmt sowohl mit den Richtlinien
der Vereinten Nationen UN als auch mit den Richtlinien der internationalen
Arbeitsorganisation ILO überein. Im besonderen Fokus dieses höchst aktuellen
Ratgebers steht das Wirtschaftsleben im Zeitalter der Globalisierung.
Hrsg.: K.-C. Bay
1. Auflage 2010, 228 Seiten, Hardcover
Oldenbourg Industrieverlag München
www.oldenbourg-industrieverlag.de
Optimieren Sie die gesellschaftliche Verantwortung in Ihrem Unternehmen mit der ISO 26000.
Informationen rund um die neue internationale Norm bietet Ihnen das Seminar „ISO 26000 in der Praxis“.
Wann: 12. und 13. Oktober 2011 in Grasbrunn bei München Referenten: Karl-Christian Bay, Wirschaftsprüfer I Rechtsanwalt,
Herausgeber des Buches „iso 26000 in der Praxis“, Dorothee Krull (Rechtsanwältin I Wirtschaftsjuristin), Mitautorin und Christian
Hellfritzsch, Diplom-Kaufmann, Mitautor. Reichen Sie vorab Ihre Fragen zur Norm ein unter: www.iso26000-praxisseminar.de
✁
Sofortanforderung per Fax: +49 (0)201 / 82002-34 oder im Fensterumschlag einsenden
Ja, ich bestelle gegen Rechnung 3 Wochen zur Ansicht
Ex.
ISO 26000 in der Praxis
1. Auflage 2010 – ISBN: 978-3-8356-3222-6
für € 49,90 (zzgl. Versand)
Die bequeme und sichere Bezahlung per Bankabbuchung wird
mit einer Gutschrift von € 3,- auf die erste Rechnung belohnt.
Firma/Institution
Vorname, Name des Empfängers
Straße/Postfach, Nr.
PLZ, Ort
Telefon
Telefax
Antwort
Vulkan Verlag GmbH
Versandbuchhandlung
Postfach 10 39 62
45039 Essen
Widerrufsrecht: Sie können Ihre Vertragserklärung innerhalb von zwei Wochen ohne Angabe von Gründen in
Textform (z.B. Brief, Fax, E-Mail) oder durch Rücksendung der Sache widerrufen. Die Frist beginnt nach Erhalt
dieser Belehrung in Textform. Zur Wahrung der Widerrufsfrist genügt die rechtzeitige Absendung des Widerrufs
oder der Sache an die Vulkan-Verlag GmbH, Versandbuchhandlung, Huyssenallee 52-56, 45128 Essen.
E-Mail
Branche/Wirtschaftszweig
Bevorzugte Zahlungsweise Bankabbuchung Rechnung
Bank, Ort
Bankleitzahl
Kontonummer
✘
Datum, Unterschrift PAISO12010
Nutzung personenbezogener Daten: Für die Auftragsabwicklung und zur Pflege der laufenden Kommunikation werden personenbezogene Daten erfasst und gespeichert. Mit dieser Anforderung erkläre ich mich damit einverstanden, dass ich vom
Oldenbourg Industrieverlag oder vom Vulkan-Verlag per Post, per Telefon, per Telefax, per E-Mail, nicht über interessante, fachspezifische Medienund Informationsangebote informiert und beworben werde. Diese Erklärung kann
ich mit Wirkung für die Zukunft jederzeit widerrufen.
anche
Webbasierte Fernüberwachung visualisiert
die Solarpark-Daten flexibel und transparent
Kontrollsystem stellt alle relevanten Informationen des Sonnenkraftwerks dar
Der Solarpark Zerre entstand in der Nähe von Cottbus
auf dem Gelände eines alten Kohlekraftwerks. Ende
letzten Jahres ging das letzte Teilfeld ans Netz, damit
ist die Maximalleistung der Anlage von 8 MWp erreicht
(Megawatt peak – Maßeinheit für die maximale Leistung).
Damit Betreiber und Investoren sicher sein können,
dass aus dem einfallenden Sonnenlicht stets das
Optimum an Energie herausgeholt wird, war eine webbasierte
Fernüberwachung gefragt, die jederzeit Einblick
in die Anlage gibt.
Federführend bei Planung und Bau des Solarparks
Zerre auf dem ehemaligen Kraftwerksgelände Trattendorf
war die German Solar AG. Der Solarpark wurde
innerhalb von acht Monaten auf einem 20 ha großen
Areal errichtet und besteht aus acht Teilparks, die jeweils
etwa 1 MWp liefern können. Auf einer bewährten
Holzständerkonstruktion aus märkischer Kiefer sind
in zwei Reihen insgesamt 40000 Solarmodule montiert.
564 Wechselrichter wandeln den erzeugten Gleichstrom
vor der Netzeinspeisung in Wechselstrom.
LÄUFT DIE ANLAGE OPTIMAL?
Die Energiemenge, die mit einer Solaranlage gewonnen
werden kann, ist nicht konstant. Verschiedene Faktoren
wie Sonnenstand, Bewölkungsgrad oder die Temperatur
der Solarmodule haben Einfluss auf die Energieausbeute.
Herauszufinden, ob eine Anlage unter den jeweils gegebenen
Umgebungsbedingungen gerade tatsächlich nicht
mehr Energie gewinnen kann oder ob ein Problem vorliegt,
ist daher nicht trivial.
Zur Funktionsüberwachung der Anlage setzt man
üblicherweise an den Wechselrichtern an. Durch Auslesen
aller Wechselrichter-Werte wie Gleich- und Wechselstrom
sowie Gleich- und Wechselspannung lässt sich
jeweils die aktuelle Leistung ermitteln. Im Solarpark
Zerre werden zudem Sonnen-Einstrahlung sowie Modul-
und Umgebungstemperaturen überwacht. Mit diesen
Werten kann man jederzeit darauf schließen, ob die
Anlage optimal läuft. Ist dies nicht der Fall, lässt sich
zudem ermitteln, wo genau im jeweiligen Teilpark ein
Problem vorliegt.
DATENSERVER PER UMTS ANGEBUNDEN
Bei der Prozessüberwachung und -visualisierung setzt
German Solar auf Lösungen der Webfactory GmbH aus
Buchen. Die Spezialisten für webbasiertes Bedienen, Visualisieren
und Informationsmanagement lieferten die
notwendige Hard- und Software für das Überwachen des
Solarparks. Pro Teilanlage ist eine SPS im Einsatz, die
die Sensorik zum Messen der Sonneneinstrahlung und
der Temperaturen verwaltet und die Daten an den Datalogger
der jeweiligen Teilanlage übergibt. Der eingesetzte
Datalogger, ein lüfterloser Industrie-PC für den Schaltschrankeinbau,
sammelt zudem die Daten der Wechselrichter.
Die zu überwachenden Wechselrichter werden
per RS485-Bus miteinander verbunden. Ein Umsetzer
wandelt die RS485-Daten für den Datenlogger ins Ethernet-Protokoll.
So lassen sich beliebig viele Wechselrich-
KOMPLEXE ÜBERWACHUNGSAUFGABE:
40 000 Solarmodule erzeugen Strom aus Sonnenlicht,
564 Wechselrichter wandeln die erzeugte Gleich spannung
in Wechselspannung. Bild: German Solar
ALLES UNTER KONTROLLE: Durch Auslesen aller
Wechselrichter-Werte wie Gleich- und Wechselstrom
sowie Gleich- und Wechselspannung lässt sich jeweils
die aktuelle Leistung ermitteln. Die Funktionsüberwachung
erfolgt webbasiert. Bild: Webfactory
16
atp edition
9 / 2011
ter an den Datalogger anschließen. Dieser eignet sich als
reiner Datensammler, kann aber auch gleich vor Ort Daten
auswerten.
Generell kann der Datalogger Informationen mit allen
gängigen SPS-Steuerungen über native Treiber oder
über eine OPC-Schnittstelle austauschen. Die Prozessdaten
werden in einer SQL-Datenbank gespeichert und
anschließend dem übergeordneten System zur weiteren
Verarbeitung zur Verfügung gestellt. Im Solarpark Zerre
wird die Datenübertragung zum zentralen Datenserver
per UMTS erledigt. Wo die nötigen Kabel vorhanden
sind, ist selbstverständlich auch eine leitungsgebundene
Übertragung möglich. Zusammen mit der Software
Webfactory 2010 Embedded lassen sich bei Bedarf Prozessdaten
aber auch vor Ort im Datalogger auswerten
und visualisieren. Störmeldungen werden direkt aus
dem Solarpark per E-Mail an den zuständigen Mitarbeiter
verschickt.
FÜR JEDEN DIE RICHTIGE INFORMATION
Die übersichtliche Darstellung der gesammelten Daten in
Form von KPI-Cockpits (Key Performance Indicator) übernimmt
das webbasierte Energie-Management-System
(EMS) von Webfactory. Dipl.-Ing. (FH) Harald Kallauke,
Projektmanager bei German Solar, erklärt dazu: „Uns war
wichtig, eine Software zu haben, mit der sich flexibel und
transparent alle relevanten Komponenten und Informationen
im Solarpark darstellen lassen.“ Während Investoren
im Wesentlichen interessiert, welche Erträge die Anlage
bringt, benötigt der Anlagenbetreiber oder der Instandhalter
detailliertere Informationen. So galt es im
Solarpark Zerre, über 20 verschiedene Sichten auf den
Prozess zur Verfügung zu stellen. „Hier bringt das eingesetzte
System klare Vorteile“, betont Kallauke. „Wer die
nötigen Berechtigungen hat, kann nach Einloggen in einem
Konfigurator einfach mit ein paar Mausklicks eine
bestimmte Sicht zusammenstellen. Meldet sich der jeweilige
Benutzer dieser Sicht dann an, wird er nicht mit allen
Informationen der Anlage überfrachtet, sondern erhält
eine übersichtliche Darstellung der für ihn relevanten
Daten.“ Wer an detaillierteren Informationen interessiert
ist, der kann via Internet sogar auf die Daten der Wechselrichter
zugreifen.
ROLLENBASIERTE BENUTZERZUGRIFFSSTEUERUNG
Generell ist das EMS ein Data Warehouse, es sammelt
Prozessinformationen von verschiedenen Anlagenteilen
an zentraler Stelle. Es stellt alle Prozessdaten, also beispielsweise
den Energieverbrauch oder die erzeugte Energie
einer Anlage, transparent dar. Denn erst so werden
Einspar- beziehungsweise Optimierungspotenziale sichtbar.
Die rollenbasierte Benutzerzugriffssteuerung ermöglicht
das unkomplizierte Erstellen verschiedener Sichten
mit unterschiedlichen Zugriffsrechten. Im Problemfall
kann der Anlagenbetreiber direkt per SMS, E-Mail oder
Sprachnachricht informiert werden. So ist eine schnelle
Reaktion möglich und Anlagenstillstände lassen sich
deutlich verkürzen.
Dank standardisierter Kommunikationsschnittstellen
kann das System im Gegensatz zu proprietären Fernüberwachungslösungen
Messdaten von unterschiedlichsten
Anlagensteuerungen auf einem Internetportal zusammenführen
und dort Prozessdaten in Echtzeit anzeigen.
Weil die Lösung webbasiert ist, wird zum Anzeigen der
Informationen keine zusätzliche Soft- und Hardware
benötigt, ein gängiger Webbrowser reicht aus.
Dank vollständig vektorbasierter Grafiken auf Basis
von Microsoft Silverlight, lässt sich die Visualisierung
verlustfrei an jede Bildschirmgröße anpassen. Mit dem
Report Designer können individuelle Berichte für die
detaillierte Auswertung aller Prozessdaten erstellt werden.
Eine flexible Struktur erlaubt nachträglich die
einfache Integration neuer Anlagen oder Anlagenteile.
Typische Einsatzgebiete finden sich nicht nur in Photovoltaikanlagen,
sondern auch beim Fernüberwachen
von Wasser- oder Windkraftwerken, Blockheizkraft-,
Geothermie- und Biogasanlagen sowie im Gebäude-
Management, der Produktion sowie im Einzelhandel
und in der Logistik.
Viele Anwender überzeugt nicht nur die Flexibilität
der webbasierten Software, sondern auch, dass sie mit
den Dataloggern und dem Energie-Management-System
die notwendige Hard- und Software zur webbasierten
Visualisierung einer Anlage aus einer Hand beziehen
können. Kallauke resümiert: „Wir haben uns nach eigenen
Recherchen und Empfehlungen von Partnern für
dieses Energie-Management-System entschieden, letzten
Endes auch deshalb, weil wir uns damit eine höhere
Effizienz bei Wartung und Service versprechen.
Gleichzeitig hat uns aber auch die gute Zusammenarbeit,
die Fachkompetenz des Projektverantwortlichen
sowie die Flexibilität, mit der auf Probleme reagiert
wurde, überzeugt.“
Autor
Dipl.-Ing. (FH) STEFAN
HAUCK ist Software Project
Manager bei der Webfactory
GmbH.
Webfactory GmbH,
Hollergasse 15, D-74722 Buchen,
Tel. +49 (0) 6281 523 33 60,
E-Mail: shauck@webfactory-world.de,
Internet: www.webfactory-world.de
atp edition
9 / 2011
17
anche
Komplexe Smart Grids effizient mit
Standard-Steuerungen automatisieren
Kostengünstige Lösung: Ein einziges System übernimmt die Automation einer Fernwirkstation
Für ein optimales Lastmanagement werden in Versorgungsnetzen
klassische Komponenten, wie Zähler und
Leistungsschalter, um neue Komponenten ergänzt. Das
wiederum erhöht die Anzahl der erforderlichen Datenpunkte.
Inzwischen übernehmen programmierbare Steuerungen
neben Automatisierungs- auch Fernwirkaufgaben
und kommunizieren über internationale Fernwirkprotokolle
gemäß IEC 60870 oder IEC 61850 mit der Leitstelle.
Diese modularen „Standard“-Steuerungen mit IEC-Kommunikation
bieten ein gutes Preisleistungsverhältnis und
vereinfachen die Automation von Infrastrukturnetzen.
Die Ursachen für neue Komponenten in Versorgungsnetzen
sind vielfältig. Einerseits fordert die Regulierungsbehörde
die Trennung der Energieerzeugung und
des Netzbetriebs. Anderseits führen dezentrale Energieeinspeisungen
durch Windkraft- und Photovoltaik-Anlagen,
Blockheizkraftwerken und Kraft-Wärme-Kopplungen
zu neuen Anforderungen hinsichtlich der Netzführung,
der Abrechnung und dem Lastmanagement.
Bislang automatisierten SPS-Steuerungen lediglich die
dezentralen Einheiten, jetzt sollen sie auch den Anlagenzustand
an die Leittechnik übermitteln und in Kontrollrichtung
Schaltbefehle umsetzen. Für diese Fernwirkaufgaben
stehen Kommunikationsprotokolle wie Modbus und
DNP3 sowie nach IEC 60870 und IEC 61850 mit ihren Subnormen
zur Verfügung. Diese Protokolle unterscheiden sich
sowohl technisch als auch in ihrer globalen Verbreitung.
Für die Schutz- und Leittechnik in elektrischen
Schaltanlagen der Mittel- und Hochspannungstechnik
ist im Jahr 2004 die Norm IEC 61850 als globaler Stan-
dard veröffentlicht worden. Bei dieser Kommunikation
sind die Funktionseinheiten über einen objektorientierten
Ansatz modelliert; im Gegensatz zu den anderen
Kommunikationsprotokollen, die signalorientiert arbeiten.
Das hat zur Folge, dass für neue Aufgabenbereiche
spezifische Erweiterungen geschaffen werden müssen.
Drei solcher Erweiterungen zur Überwachung und
Steuerung sind zurzeit definiert: IEC 61400-25 bei
Windenergieanlagen, IEC 61850-7-410 bei Wasserkraftwerke
und IEC 61850-7-420 bei einer verteilten Energieerzeugung
(Distributed Energy Resources) wie sie beispielsweise
durch Photovoltaikanlagen entsteht.
FERNWIRKPROTOKOLLE INTEGRIERT
Um dem Anwender zur Kommunikation mit der Leitstelle
eine normierte und einfach anwendbare Schnittstelle
zu bieten, hat Wago die Fernwirkprotokolle IEC 60870-
5-101/-104 und IEC 61850 in modulare Steuerungen des
Wago-I/O-Systems integriert. Diese Protokolle sind im
Falle der IEC 60870-5-101/-104 signalorientiert, das bedeutet:
Zwischen der Leittechnik und der modularen
Steuerung werden Meldungen, Messwerte, Bitmuster,
Zählwerte und (Stell-) Befehle jeweils mit und ohne Zeitstempel
ausgetauscht. Überträgt man diesen Ansatz auf
die IEC 61850, so entspräche er dem generischen Objekttyp
GGIO, als Basisobjekt.
Ein wesentlicher Mehrwert dieses Standards ist jedoch
das Vorhandensein von typisierten Objekten, beispielsweise
wenn ein Netztransformator, ein Rotor einer
Windkraftanlage oder eine Photovoltaikanlage automa-
In den modularen Steuerungen ist für beide Normen
(IEC 60870 und 61850) ein Konfigurationswerkzeug in CoDeSys
integriert. Damit wird die IEC-Kommunikation nur noch
parametriert und muss nicht mehr programmiert werden.
Über die CoDeSys-Programmierung wird der
entsprechende IEC-Konfigurator aufgerufen.
20
atp edition
9 / 2011
Sicher ist sicher
tisiert werden soll. Betrachtet man also auch alle Erweiterungen
zum IEC-61850-Standard, so kommen zu dem
generischen Objekttyp GGIO etwa 220 weitere spezifische
Objekttypen hinzu. Da der Hersteller von Steuerungen
nicht weiß, welche IEC-Objekttypen der Anwender
verwenden wird, müsste die Automatisierungslösung
alle spezifischen Objekte bedienen können, beispielsweise
ein YPTR-Objekt zur Integration von
Transformatoren. Die Wago-Lösung stellt dem Anwender
die normierte Schnittstelle zur Leittechnik zur Verfügung,
jedoch nicht die interne Logik der Objekttypen.
Schließlich ist es der Anwender, der das Know-how über
seine Applikation hat und die Logik implementiert.
Die Programmierung der Automatisierungsaufgabe
erfolgt mit CoDeSys (Code Development System) und
wird im programmierbaren Fernwirkcontroller oder
Kompakt-Industrie-PC (I/O-IPC) abgelegt. CoDeSys ist
ein offenes Programmiersystem nach dem internationalen
Standard IEC 61131-3 und stellt dem Anwender
5 Programmiersprachen zur Verfügung. Damit der
Anwender den Fernwirkcontroller (750-872) und die
I/O-IPCs (758-870 und 758-875) so einfach wie möglich
für die Kommunikation mit einer Leittechnik vorbereiten
kann, ist in CoDeSys ein Konfigurationswerkzeug
für beide Normen integriert (IEC 60870 und
61850). Mit diesem Werkzeug wird die IEC-Kommunikation
nur noch parametriert – sie muss nicht mehr
programmiert werden.
SKALIERBARE STEUERUNGEN
Modulare Steuerungen bringen zahlreiche Systemeigenschaften
mit, die auch in Smart-Grid-Projekten Vorteile
bieten. Der Anwender wählt die Steuerung zunächst hinsichtlich
seiner Leistungsanforderungen und Kommunikationsschnittstellen
aus. Dabei kann die Leistungsfähigkeit
der CPU von wenigen MHz für Überwachungsaufgaben
bis zur Pentium-Klasse im GHz-Bereich für komplexe
Regelungsaufgaben reichen.
Zur Kommunikation stehen Schnittstellen für Profibus,
Modbus oder auch KNX bereit, sodass die Steuerungen
auch als Gateways zwischen Fernwirktechnik und
Industrie- oder Gebäudeautomation eingesetzt werden
können. Je nach Einsatzort müssen auch die mechanischen
und klimatischen Anforderungen an das System
betrachtet werden. Die Federklemmtechnik ist eine vibrationssichere
und wartungsfreie Anschlusstechnik und
wird in allen Wago-Produkten eingesetzt. Viele Automatisierungskomponenten
sind für einen erweiterten Temperaturbereich
von -20 bis +60 °C erhältlich.
Zahlreiche Schiffszertifizierungen wie Germanischer
Lloyd (GL) bestätigen die Eignung in schwierigen Umgebungen,
wie sie im Schiff sowie im On- und Offshore-
Bereich vorherrschen. Den modularen Steuerungen
steht eine große Auswahl an I/O-Busklemmen zur Verfügung.
Sie reicht von hoch verdichteten 16-Kanal-Digitalklemmen,
die Platz im Schaltschrank einsparen,
über Spezialklemmen, wie die 3-Phasen-Leistungs-
Mit den in der EXIDA-Datenbank gelisteten
Stellventilen Typ 3241 von
SAMSON sind Sie immer auf der sicheren
Seite. Dank ihrer hohen zertifizierten
MTBF brauchen Sie sich um einen
Ausfall nicht zu sorgen.
Für noch mehr Sicherheit garantieren
die Stellungsregler der Baureihen 3730
und 3731. Mit ihrem zertifizierten Magnetventil
und dem induktiven Grenzkontakt
führen sie die Sprungantworttests
automatisch durch und dokumentieren
die Ergebnisse.
Gehen Sie auf Nummer sicher mit
SAMSON.
SAMSON AG • MESS- UND REGELTECHNIK
Weismüllerstraße 3 • 60314 Frankfurt am Main
Telefon: 069 4009-0 • Telefax: 069 4009-1507
E-Mail: samson@samson.de • www.samson.de
A01039DE
anche
Eine im Web-Server der Steuerung
speicherbare Visualisierung bietet vielfältige
Diagnosefunktionen.
Fernwirkcontroller 750-872 sowie die I/O-IPCs
758-870 und 758-875 unterstützen die IEC-Kommunikation
nach IEC 60870-5-101/-104 und IEC 61850.
messklemme zur energetischen Überwachung von
Transformatorstationen, bis hin zu eigensicheren Klemmen.
Durch die Programmierbarkeit des Automatisierungssystems
lassen sich auch Visualisierungen mit
CoDeSys erstellen, die direkt in den Web-Server der
Steuerung geladen werden.
PLATZBEDARF UND KOSTEN SINKEN
Dadurch bekommt der Endkunde eine komfortable
Diagnoseplattform für seine Lösung, auf die er mit jedem
Browser zugreifen kann. Der Fernwirkcontroller
und die I/O-IPCs unterstützen neben der klassischen
Automatisierungsaufgabe auch die international standardisierten
Fernwirkprotokolle nach IEC 60870-5-
101/-104 und IEC 61850. Durch das CoDeSys-Konfigurationswerkzeug
kann sich der Applikationsingenieur
voll auf die optimale Entwicklung seiner Automatisierungslösung
in einer gewohnten SPS-Entwicklungsumgebung
konzentrieren.
Die Anbindung an Smart Grids ist mit den Fernwirkprotokollen
bereits integriert. Da ein einziges System
die Automation einer Fernwirkstation übernimmt, reduzieren
sich der Platzbedarf, die Komplexität und die
Kosten pro Station.
Literatur
Autor
IEC61850 Part 7-4 Basic communication structure for
substation and feeder equipment – Compatible logical
node classes and data classes
IEC61850 Part 7-410 Communication networks and
systems for power utility automation – Hydroelectric
power plants – Communication for monitoring and
control
IEC61850 Part 7-420 Communication networks and
systems for power utility automation – Basic communication
structure – Distributed energy resources logical
notes
IEC61400 Part 25 Wind turbines – Communications for
monitoring and control of wind power plants
Dipl.-Inf. Martin Paulick
ist Produktmanager bei
Wago Kontakttechnik
GmbH & Co. KG.
Wago Kontakttechnik GmbH & Co. kg,
Hansastr. 27, D-32423 Minden,
Tel. +49 (0) 571 887 90 11,
E-Mail: martin.paulick@wago.com
22
atp edition
9 / 2011
atp edition
als Heft
oder
als ePaper
Die Referenzklasse für die
Automatisierungstechnik
Erfahren Sie auf höchstem inhaltlichen Niveau, was die
Automatisierungsbranche bewegt. Alle Hauptbeiträge
werden in einem Peer-Review-Verfahren begutachtet,
um Ihnen maximale inhaltliche Qualität zu garantieren.
Sichern Sie sich jetzt dieses erstklassige Lektüreerlebnis.
Als exklusiv ausgestattetes Heft oder als
praktisches ePaper – ideal für unterwegs, auf mobilen
Endgeräten oder zum Archivieren.
Gratis für Sie: Das Handbuch der Prozessautomatisierung
Die 4. Aufl age dieses Handbuch vermittelt in stringenter Struktur das essentielle Wissen zur
Planung automatisierungstechnischer Einrichtungen für verfahrenstechnische Anlagen und hat
sich in der Branche als Standardnachschlagewerk etabliert.
Für Qualität und Praxisnähe in der Darstellung steht das Autorenteam von 50 ausgewiesen und
anerkannten Experten auf Ihren Arbeitsfeldern.
atp edition erscheint in der Oldenbourg Industrieverlag GmbH, Rosenheimerstr. 145, 81671 München
Oldenbourg-Industrieverlag
www.atp-online.de
Vorteilsanforderung per Fax: +49 (0) 931 / 4170 - 492 oder im Fensterumschlag einsenden
Ja, ich möchte atp edition regelmäßig lesen. Bitte schicken Sie mir die Fachpublikation
□ als gedrucktes Heft für € 460,- zzgl. Versand (Deutschland: € 30,- / Ausland: € 35,-) pro Jahr
□ als ePaper (PDF-Datei als Einzellizenz) für € 460,- pro Jahr
Als Dankeschön erhalte ich das „Handbuch der Prozessautomatisierung“ gratis.
Nur wenn ich nicht bis von 8 Wochen vor Bezugsjahresende kündige, verlängert sich der
Bezug um ein Jahr.
Die sichere, pünktliche und bequeme Bezahlung per Bankabbuchung wird mit einer Gutschrift
von € 20,- auf die erste Jahresrechung belohnt.
Firma/Institution
Vorname/Name des Empfängers
Straße/Postfach, Nr.
Land, PLZ, Ort
Telefon
Telefax
Antwort
Leserservice atp
Postfach 91 61
97091 Würzburg
E-Mail
Branche/Wirtschaftszweig
Bevorzugte Zahlungsweise □ Bankabbuchung □ Rechnung
Bank, Ort
Bankleitzahl
✘
Kontonummer
Widerrufsrecht: Sie können Ihre Vertragserklärung innerhalb von 14 Tagen ohne Angabe von Gründen in Textform (Brief, Fax, E-Mail) oder durch
Rücksendung der Sache widerrufen. Die Frist beginnt nach Erhalt dieser Belehrung in Textform. Zur Wahrung der Widerrufsfrist genügt die rechtzeitige Datum, Unterschrift
PAATPE0311
Absendung des Widerrufs oder der Sache an den Leserservice atp, Postfach 91 61, 97091 Würzburg.
Nutzung personenbezogener Daten: Für die Auftragsabwicklung und zur Pfl ege der laufenden Kommunikation werden personenbezogene Daten erfasst, gespeichert und verarbeitet. Mit dieser Anforderung erkläre ich mich damit einverstanden, dass ich vom
Oldenbourg Industrieverlag oder vom Vulkan-Verlag □ per Post, □ per Telefon, □ per Telefax, □ per E-Mail, □ nicht über interessante Fachangebote informiert und beworben werde. Diese Erklärung kann ich mit Wirkung für die Zukunft jederzeit widerrufen.
hauptbeitrag
Fortschritt bei Simulation
von Montagemaschinen
Automatisierte Erstellung von Verhaltensmodellen
Dieser Beitrag befasst sich mit Verhaltensmodellen für die Hardware-in-the-Loop-Simulation
von Montagemaschinen. Für Komponenten, die über boolesche Variable mit der
Steuerung kommunizieren, werden Verhaltensmodelle automatisiert erstellt. Grundlage
der Modellerstellung ist die Definition von Basisfunktionen und die Extraktion von Wirkketten
aus dem Stromlaufplan. Die Umsetzung zeigt, dass sich durch die Automatisierung
der Aufwand zur Erstellung der Verhaltensmodelle signifikant reduzieren lässt.
SCHLAGWÖRTER Hardware-in-the-Loop-Simulation / Montagemaschine /
Verhaltensmodelle
HiL-Simulation of Assembly Machines –
Automatically built Behaviour Models
This paper focuses on the generation of behavior models for the Hardware-in-the-Loop-
Simulation of assembly machines. Models are built automatically for components, which
communicate with the controller by boolean variables. The modeling is based on the
definition of basic functions and the extraction of connections out of the wiring diagram.
The implementation shows that the effort to model behavior models can be reduced siginificantly.
KEYWORDS Hardware-in-the-Loop-Simulation / Assembly Machine /
Behaviour Models
24
atp edition
9 / 2011
Annika Kufner, Philipp Dreiss, Robert Bosch
Peter Klemm, Universität Stuttgart
Seit einigen Jahren überschreitet die Hardwarein-the-Loop-Simulation
auch im Anlagenbau die
Schwelle von der Forschung in die Industrieanwendung.
Der Nutzen der Hardware-in-the-
Loop-Simulation wurde bereits vielfach publiziert
[1, 2]. Den Schwerpunkt bildet die virtuelle Inbetriebnahme,
welche den Engineeringprozess verkürzt. Im Zuge
der Einführung der Hardware-in-the-Loop-Simulation in
der Industrie steht nun deren effiziente Durchführung im
Vordergrund. Der Aufwand für die Erstellung von Maschinenmodellen
darf den Nutzen der Simulation nicht
übersteigen. Durch die Wiederverwendung von Maschinenmodellen
kann der Aufwand reduziert werden. Dies
ist für Montagemaschinen jedoch nur im geringen Maße
möglich, da sie den Sondermaschinen zuzurechen sind.
Ein entscheidender Lösungsweg zur Reduktion des
Aufwands stellt bei Montagemaschinen die automatisierte
Erstellung von Maschinenmodellen dar. Hierfür
sollen die Engineeringdokumente verwendet werden, die
bereits in der Konstruktion erstellt wurden.
1. Modelle zur Hardware-in-the-Loop-Simulation
Zur Simulation müssen das Maschinenmodell und das
geometrische Modell erstellt werden (Bild 1).
Das Maschinenmodell ist das Abbild der Maschine gegenüber
der Steuerung. Zur Simulation wird auf Basis des
Maschinenmodells in jedem Zyklus der Steuerung der
Maschinenzustand berechnet. Erstens beinhaltet das Maschinenmodell
die Strukturierung der Maschine in Komponenten.
Komponenten definieren sich aus einem engen
funktionalen Zusammenhang ihrer Ein- und Ausgänge.
Zweitens enthält es die Verhaltensmodelle der Komponenten.
Ein Verhaltensmodell umfasst die logischen und physikalischen
Wirkzusammenhänge einer Komponente.
Das geometrische Modell ist im Kern das 3D-CAD-Modell
der Maschine. Zur Visualisierung der Bewegungen
erhält das geometrische Modell die Positionsdaten aus
den Berechnungen des Maschinenmodells. Somit lassen
sich die Bewegungsabläufe und der Materialfluss im geometrischen
Modell verarbeiten und visualisieren. Kollisionen
und die Positionen von Werkstücken an Sensoren
können dann mithilfe des geometrischen Modells erkannt
und an das Maschinenmodell übermittelt werden.
2. Komponenten einer Montagemaschine
In diesem Beitrag wird die automatisierte Erstellung der
Verhaltensmodelle für die Komponenten einer Maschine
betrachtet, da ihre manuelle Erstellung etwa 70 % des
gesamten Aufwands zur Simulation beansprucht.
2.1 Verhaltensmodelle für unterschiedliche Komponenten
Komponenten sind aus der Sicht der Verhaltensmodellierung
für die Hardware-in-the-Loop-Simulation in zwei
Gruppen einzuteilen.
Erstens gibt es eine Vielzahl an Komponenten, deren
Ansteuerung oder deren Zustand über binäre Signale ausgetauscht
werden. Die mit der Steuerung kommunizierenden
Bauteile einer solchen Komponente sind über ein
E/A-Modul an den Feldbus angeschlossen. Ein Beispiel
hierfür ist ein Vereinzler am Förderband. Er wird durch
eine Bauteilkombination von einem Ventil, einem Zylinder
und zwei Endschaltern realisiert. Sowohl das Ventil
als auch die Endschalter sind als binärer Eingang beziehungsweise
Ausgang an das E/A-Modul angebunden.
Zweitens befinden sich in Montagemaschinen Komponenten,
deren Kommunikationsprotokoll mit der Steuerung
aus Datenpaketen in herstellerdefinierten Datenstrukturen
besteht. Diese Komponenten werden durch
abgeschlossene Baueinheiten realisiert. Beispiele für
Baueinheiten sind Messgeräte, einzelne Montageprozesse
ausführende Geräte oder Achsen inklusive ihrer Antriebssteuerungen
(Bild 1). Zur Modellierung dieser Komponenten
müssen herstellerspezifische Angaben zur
Nachimplementierung des Protokolls und eine Systemidentifikation
zur Modellierung des Verhaltens herangezogen
werden. Diese Arbeitsschritte sind nicht automa-
atp edition
9 / 2011
25
Hauptbeitrag
tisiert durchführbar. Die Verhaltensmodelle für Baueinheiten
sind demzufolge manuell zu erstellen.
Obwohl eine Montagemaschine nur eine geringe Anzahl
an Komponenten aus Baueinheiten besitzt, erfordert
deren Verhaltensmodellierung denselben Aufwand wie
die der Vielzahl an Komponenten aus Bauteilen. Ziel dieser
Arbeit ist es, die Verhaltensmodelle für Bauteile automatisiert
zu erstellen. Um den Aufwand zur Modellerstellung
jedoch umfassend zu reduzieren, ist es erforderlich,
dass die Verhaltensmodelle für Baueinheiten vom
Lieferanten der Baueinheit bereitgestellt werden [6].
2.2 Klassifizierung von Komponenten mit binären Signalen
Die Ansteuerung der Aktoren oder die Abfrage der Sensoren
einer Komponente aus Bauteilen benötigt nur wenige
binäre Signale. Daher setzen diese Komponenten einfache
Funktionen um. Hinsichtlich der Behandlung bei der Modellierung
sind die Komponenten klassifizierbar. Eine
Komponente kann entweder der Klasse „Basisfunktion“
oder der Klasse „Multifunktion“ zugeordnet werden.
Basisfunktion
Bei den untersuchten Montagemaschinen hat sich gezeigt,
dass etwa 60 % - 80 % der binären Signale Komponenten
zugeordnet werden können, die eine Basisfunktion umsetzen.
Diese führen zum Beispiel das Öffnen und Schließen
eines Greifers, eines Vereinzlers oder auch das Heben
und Absenken einer Hubplattform aus. Basisfunktionen
werden in diesem Beitrag als standardisierte, deterministische
Funktionen definiert.
Signale werden einer Basisfunktion zugerechnet, sofern
zum einen die Signalausgänge im direkten Zusammenhang
mit den Signaleingängen, zumeist in pneumatischer,
mechanischer oder elektrischer Kopplung ste-
SPS
Feldbus
Schnittstelle
Simulations-PC
Maschinenmodell
Struktur
Verhalten
E/A-Modul
Montage-
Baueinheit
maschine
(Montageprozess)
reale Welt
Komponente
Verhaltensmodell
Baueinheit
(Antrieb)
Baueinheit
(Messgerät)
Positionsdaten
Kollisions-und
Sensordaten
Geometrisches Modell
virtuelle Welt
BILD 1: Aufbau einer
Hardware-in-the-
Loop-Simulation
für eine Montagemaschine
Legende:
E Eingangssignal
A Ausgangssignal
BILD 2: Zustandsgraph
und Bibliotheksbaustein
in
VirtuosM [5] für
eine Basisfunktion
26
atp edition
9 / 2011
hen. Die technologische Umsetzung spielt jedoch keine
Rolle. Zum anderen wird gefordert, dass die Reaktionszeit
der Ausgänge auf einen Flankenwechsel der Eingänge
nur geringsten Schwankungen unterworfen ist. Wenn
diese Bedingungen erfüllt sind, wird angenommen, dass
das Verhalten deterministisch ist.
Keine Basisfunktion besteht, wenn ein Signalausgang
mit einem Signaleingang über den Materialfluss verbunden
ist, sodass die Bewegung oder das Vorhandensein
des Werkstücks die Kopplung zwischen den Signalen
darstellt. Dann kann das Verhalten nicht mehr als deterministisch
angenommen werden.
Ein bereits erwähnter Vereinzler am Förderband wird
zum Beispiel durch eine Ventil-Zylinder-Endschalter-
Kombination realisiert, die einer Basisfunktion zuzuordnen
ist. Ein Näherungsschalter am Förderband, der die
vereinzelten Werkstücke detektiert, ist nicht mehr Teil
der Basisfunktion, da durch seine Verbindung mit der
Ansteuerung des Ventils über den Materialfluss keine
direkte Kopplung mehr besteht.
Multifunktion
Multifunktionen können unterschiedlichste, einfache
Funktionen umsetzten. Ihnen werden alle Signale zugeordnet,
die nicht den Basisfunktionen zugerechnet werden
können. Ein Steuer- und Statussignal einer Multifunktion
ist zum Beispiel ein:
Signal mit Anbindung an das geometrische Modell
Wie oben im Beispiel des Näherungsschalters beschrieben,
existieren Sensoren, die nicht den Basisfunktionen
zugeordnet werden können. Meistens
geben diese Sensoren die Position eines Werkstücks
an. Ihre Werte werden im geometrischen Modell ermittelt
und an das Maschinenmodell übergeben.
Signal der Sicherheitstechnik
Um den sicheren Betrieb der Maschine zu gewährleisten,
werden mehrere Signale abgeprüft. Bei den Ausgängen
des Maschinenmodells sind Sensoren zu modellieren,
die zum Beispiel die Verriegelung von Türen
angeben. Die Eingänge entsprechen Signalen zur
Schaltung von Lampen oder Anzeigen.
Signal als binärer Anschluss
Weitere Ein- und Ausgänge sind oftmals einzelne, binäre
Anschlüsse. Dies kann zum einen beispielsweise
der Anschluss an die zentrale Druckluftversorgung
sein. Zum anderen können Baueinheiten auch binäre
Ein- und Ausgänge besitzen. Diese zeigen zum Beispiel
die Erreichbarkeit einer Baueinheit an.
3. Automatisierte Modellerstellung
3.1 Mindestanforderung an die automatisierte Erstellung
Für eine fehlerfreie Simulation müssen die Ausgänge
des Maschinenmodells zur richtigen Zeit mit dem
richtigen Wert besetzt werden. Daher stellt eine logische
Modellierung mit Berücksichtigung des Zeitverhaltens
die Mindestanforderung dar [3]. Eine Modellierung
in einer größeren Modellierungstiefe würde
die physikalischen Wirkzusammenhänge der Komponenten
mit einbeziehen. Eine solche Modellierung
kann von der automatisierten Modellerstellung ohne
den Einsatz detaillierter Bibliotheksbausteine nicht
bewerkstelligt werden. Für einen Test des Steuerungsprogramms
und die Optimierung der Taktzeit durch
Änderungen des Ablaufs ist eine logische Modellierung
allerdings häufig ausreichend.
3.2 Informationsquellen
Die Verhaltensmodelle für die Komponenten aus Bauteilen
sollen anhand der vorhandenen Engineeringdokumente
automatisiert generiert werden. Hierfür werden die
E/A-Liste, der Stromlaufplan der Elektrokonstruktion und
eine folgend beschriebene Dokumentation der Basisfunktionen
herangezogen. Für die Extraktion von Informationen
aus einem integrierten Stromlauf- und Fluidplan wird
auf Schob et al. [4] verwiesen.
3.3 Basisfunktionen
Verhaltensmodelle für Basisfunktionen
Da für die Basisfunktionen ein deterministisches Verhalten
angenommen wird und sie zustandsbasierte Systeme
darstellen, bieten sich für deren logische Modellierung
Zustandgraphen an. Das Zeitverhalten wird integriert,
indem die Reaktionszeit die Dauer eines Zustandsübergangs
darstellt. Für jede Basisfunktion muss ein Zustandsgraph
modelliert werden. Die Zustandsgraphen
werden als ein Block in der Bibliothek der Simulationssoftware
abgelegt (Bild 2).
Basisfunktionen sind nicht unternehmensspezifisch,
da sie standardmäßig im Bau von Montagemaschinen
eingesetzt werden. In diesem Aspekt unterscheiden sich
die Zustandsgraphen für Basisfunktionen von den Bibliotheksbausteinen
für unternehmensspezifische Module
in anderen Arbeiten [6, 7].
Integration der Zustandsgraphen in das Maschinenmodell
In vielen Engineeringprozessen existiert eine Definition
der Basisfunktionen bereits in der Steuerungstechnik. In
der Regel stellt dann ein Funktionsbaustein zur Steuerungsprogrammierung
die Ansteuerung und Abfrage für
alle Basisfunktionen bereit. Der Funktionsbaustein wird
für alle Basisfunktionen, die in der Maschine verwendet
werden, konfiguriert. Dies wird je nach Engineeringprozess
in unterschiedlicher Art und Weise, aber zumeist in
einem zentralen Engineeringwerkzeug vorgenommen.
Wesentlich ist, dass durch die Konfiguration eine Zuordnung
von Basisfunktionen zu Signaleingängen und -ausgängen
deutlich wird und dies aus dem Engineeringwerkzeug
extrahiert werden kann. Die extrahierte Konfiguration
bildet die Informationsquelle für die Zuordnung
der Zustandsgraphen im Maschinenmodell.
Wenn keine Zuordnungsmöglichkeit durch vorhandene
Engineeringdokumente besteht, muss auf die Referenzkennzeichnung
nach IEC 81346-1 [8] zurückgegriffen
werden. Die Referenzkennzeichnung gibt die
Zuordnung von Signalen zu einer Komponente vor. Die
Kennzeichnung der Signaleingänge und -ausgänge einer
Komponente differiert im ersten Kennbuchstaben.
Der Kennbuchstabe bezeichnet die Art, welche in IEC
atp edition
9 / 2011
27
Hauptbeitrag
BILD 3:
Zwei Ausschnitte
aus einem
Stromlaufplan
mit eingetragenen
Verbindungen
81346-2 [8] festgelegt ist. Für signalverarbeitende Betriebsmittel
wie zum Beispiel Ventile lautet der Kennbuchstabe
„K“. Für Betriebsmittel, die mechanische in
elektrische Energie umwandeln, wie beispielsweise
Sensoren, lautet er „B“.
Die Auswahl eines Zustandsgraphen für eine Komponente
richtet sich nach deren Anzahl an Eingängen mit
dem Kennbuchstaben „K“ und deren Anzahl an Ausgängen
mit dem Kennbuchstaben „B“. Für eine Ventil-Zylinder-Endschalter-Kombination
(Bild 2) existieren zwei
Eingänge und zwei Ausgänge dieser Form. Das System
zur automatisierten Erstellung stellt dem Anwender alle
Zustandsgraphen zur Auswahl, die der Kombination der
Ein- und Ausgänge der Komponente entsprechen.
Für sieben unterschiedliche, produktspezifische Montagemaschinen
wurden 16 unterschiedliche Basisfunktionen
identifiziert, die auf 11 verschiedenen Kombinationen von
Ein- und Ausgängen aufbauen. Der Aufwand zur Auswahl
des passenden Zustandsgraphen ist demnach gering.
3.4 Multifunktionen
Verhaltensmodelle aus elektrischen Wirkketten
Im Folgenden werden die Inhalte automatisiert erstellter
Verhaltensmodelle für die Komponenten festgelegt, die
Multifunktionen umsetzen. Für deren Modellbildung zur
Hardware-in-the-Loop-Simulation genügt ebenfalls ein
Blockschaltbild aus logischen Elementen. Die Auswahl
und Verknüpfung der Blöcke richtet sich nach der elektrischen
Wirkkette, die im Stromlaufplan dokumentiert ist.
Es ergeben sich zwei Einschränkungen. In diesen Fällen
muss manuell modelliert werden.
1 | Für die Signale, die mit dem geometrischen Modell
gekoppelt sind, muss die Verknüpfung manuell realisiert
werden.
2 | Für den Anschluss an Baueinheiten über binäre
Signale gilt, dass aus dem Stromlaufplan allein das
Symbol „Geräteanschluss“ gelesen werden kann.
Für diesen Anschluss wird im Blockschaltbild automatisiert
ein nicht weiter spezifizierter Block
„Baueinheit“ eingesetzt. Der für den fehlerfreien
Ablauf der Simulation notwendige, logisch richtige
Ausgang dieses Blocks muss über eine manuelle
Modellierung erzeugt werden.
Generieren von Blockschaltbildern im Maschinenmodell
Gegenstand dieses Abschnittes ist es, die auf die Signalein-
und -ausgänge folgende elektrische Wirkkette in
das Blockschaltbild des Maschinenmodells zu übersetzen.
Dazu werden folgende Schritte festgelegt:
1 | Erstellen einer Verbindungsliste
2 | Relevante Verbindungen ermitteln
3 | Bildung von Wirkketten
4 | Übersetzen in Blockschaltbilder
zu 1 | Der Informationsgehalt des Stromlaufplans wird
durch die Erstellung einer Verbindungsliste aus der Elektrokonstruktion
extrahiert. Die Erstellung basiert auf einer
zu definierenden Vorlage, sodass die Verbindungsliste die
vollständige Betriebsmittelkennzeichnung mit Anschlussbezeichnung,
die Symbolfunktion des Quelle- und Zielelements
und den Potenzialtyp jeder Verbindung enthält.
zu 2 | In der Verbindungsliste befinden sich Verbindungen
jeglicher Art. Verbindungen, die nicht vom Potenzi-
28
atp edition
9 / 2011
Basisfunktion
BILD 4: Ergebnis der
Modellierung einer Basisfunktion
in Virtuos [5]
altyp Außenleiter „L“ sind, werden gefiltert. Daraufhin
verbleiben unter anderem noch Verbindungen, deren Elemente
nur über die Potentiallinie parallel miteinander
verbunden sind. Dies sind Verbindungen, die zur Versorgung
existieren und keinen Bestandteil der Wirkkette
darstellen (Bild 3). Um diese zu identifizieren, wird eine
separate Verbindungsliste erstellt, die allein die Verbindungen
enthält, die der 0V-Klemme oder dem Netzteil
entspringen. Diese Verbindungen werden von der Verbindungsliste
gelöscht.
zu 3 | Eine Wirkkette wird durch eine Kette an Elementen
dargestellt. Eine Kette wird durch die Verknüpfung
der Quelle-Ziel-Verbindungen gebildet. Eine Verknüpfung
bedingt, dass das Betriebsmittelkennzeichen und
die Anschlussbezeichnung eines Zielelements gleich
denen des Quellelements einer anderen Verbindung sind
oder umgekehrt. Neben den unverzweigten Wirkketten
existieren Besonderheiten:
Relais: Die Ketten werden nach Elementen mit der
Symbolfunktion „Spule“ durchsucht. Wenn eine
Spule gefunden wird, wird in allen anderen Ketten
nach Elementen gesucht, die zum einen das gleiche
Betriebsmittelkennzeichen wie die Spule und zum
anderen eine Symbolfunktion aus der Gruppe der
Kontakte besitzen. Die betroffenen Ketten werden von
dem eingesetzten Block „Spule“ aus verknüpft. Dieser
Block hat die Funktion eines Verteilerblockes.
Parallelschaltungen: Es liegt eine Parallelschaltung
vor, wenn ein Element mit derselben Betriebsmittelkennzeichnung
und Anschlussbezeichnung Quelle
zweier Verbindungen ist. Für den Fall, dass ein Element
in einer ersten Verbindung Ziel und in einer
zweiten Verbindung Quelle ist, muss die zweite Verbindung,
in der das Element die Quelle darstellt,
manipuliert werden. Die neue Quelle soll das Element
sein, das Quellelement der ersten Verbindung
ist (Bild 3). Nun ist das erste Quellelement Quelle
zweier Verbindungen. Diese Regel kann allerdings
nicht mehr angewandt werden, wenn eines der Elemente
nur eine Anschlussbezeichnung besitzt, wie
zum Beispiel bei einer Durchgangsklemme. Denn
diese ist auch bei einer Reihenschaltung sowohl Zielals
auch Quellelement einer Verbindung.
zu 4 | Die Elemente einer Kette sind Basis des Blockschaltbildes.
Eine Symbolfunktion eines Elements aus der Kette
wird direkt in einen Block übersetzt. Dazu wird eine
Übersetzungsliste benötigt, die die Funktionen der Symbole
im Stromlaufplan Blöcken aus der Bibliothek des
Simulationstools zuweist. Hierbei werden nur die für die
Wirkkette relevanten Funktionen übersetzt, also beispielsweise
Kontakte, aber keine Sicherungsschalter.
In Bild 3 befinden sich an der 24V-Potenziallinie nichtrelevante
Verbindungen nach Schritt 2. Die Spulen im
linken Abschnitt schalten die Schließer im rechten
Abschnitt (Schritt 3). Zudem beinhaltet der linke Ausschnitt
zwei Parallelschaltungen, die durch die ursprünglichen
Verbindungen und durch die manipulierten
Verbindungen gekennzeichnet sind (Schritt 3).
Die Parallelschaltung wird aber nicht im Blockschaltbild
dargestellt, da ihr paralleles Element eine Diode
ist, die zu den nicht relevanten Symbolfunktionen gehört
(Schritt 4).
atp edition
9 / 2011
29
Hauptbeitrag
Signal mit Anbindung an das geometrische Modell
Signal als binärer Anschluss an einer Baueinheit
Signal der Sicherheitstechnik
BILD 5: Ergebnis der
Modellierung für Multifunktionen
in Virtuos [5]
4. Umsetzung
Das vorgestellte Konzept zur automatisierten Modellerstellung
wurde in einem Modellierungstool realisiert. Im
Folgenden werden die Ergebnisse an einer Beispielmaschine
gezeigt.
Bei der automatisierten Modellerstellung werden
zuerst die Basisfunktionen identifiziert. Hierfür können
im betrachteten Engineeringprozess die Konfigurationen
eines Funktionsbausteins aus einem Engineeringwerkzeug
extrahiert werden. Des Weiteren
kann auf eine Bibliothek mit Zustandsgraphen wie in
Bild 2 zugegriffen werden. An der Beispielmaschine,
die 201 binäre Signale besitzt, wird automatisiert
identifiziert, dass 136 Signale (68 %) Basisfunktionen
umsetzen. Diesen werden automatisiert 39 Zustandsgraphen
zugeordnet.
Bild 4 zeigt das Ergebnis der automatisierten Modellerstellung
für eine Basisfunktion in der Simulationssoftware.
Autoren
Dipl. Wirtsch.-Ing. Annika
Kufner (geb. 1982) ist seit Mai
2008 externe Doktorandin am
ISW der Universität Stuttgart.
Sie absolvierte drei Jahre das
Bosch-Doktorandenprogramm.
Seit August 2011 ist Kufner
Research Scientist bei der
Robert Bosch Ltd. in Singapur.
Robert Bosch (SEA),
Pte Ltd, 11 Bishan Street 21, Singapore 573943,
E-Mail: annika.kufner@sg.bosch.com
Dr.-Ing. Philipp Dreiss
(geb. 1972) ist Projektleiter
für Condition Monitoring in
der zentralen Forschung und
Vorausentwicklung der Robert
Bosch GmbH. Zuvor war er
Forschungsreferent bei der
Europäischen Kommission.
Robert Bosch GmbH,
Robert-Bosch-Str. 2, D-71701 Schwieberdingen,
Tel. +49 (0) 711 811 14 74,
E-Mail: philipp.dreiss@de.bosch.com
30
atp edition
9 / 2011
Die verbleibenden Signale aus der E/A-Liste sind den
Multifunktionen zuzuordnen. Zu ihrer Modellierung
werden die elektrischen Wirkketten aus dem Stromlaufplan
herangezogen. Von den verbleibenden 65 Signalen
der Beispielmaschine decken sich die Betriebsmittelkennzeichnungen
von 28 Signalen (14 %) mit denen im
Stromlaufplan, sodass diese automatisiert modelliert
werden können.
Bei den meisten Signalen der Multifunktionen handelt
es sich um Eingänge beziehungsweise Ausgänge der Beispielmaschine,
deren Wirkkette ausschließlich aus einer
Verbindung zu einem Geräteanschluss oder einem Sensor
besteht. Für das Symbol „Geräteanschluss“ wird ein
Block „Baueinheit“ generiert. Wenn der Sensor mit dem
Materialfluss in Verbindung steht, ist er mit dem geometrischen
Modell zu verbinden Diese Verbindung wird
jedoch nicht automatisiert erstellt.
In Bild 5 sind die Ergebnisse der automatisierten Modellerstellung
in den beiden ersten Kästen beispielhaft
dargestellt.
Weitere, den Multifunktionen zugeordnete Signale
gehören der Sicherheitstechnik an. Der untere Kasten in
Bild 5 zeigt die automatisiert erstellte Modellierung der
Wirkkette aus dem Stromlaufplan in Bild 3. In diesem
Beispiel wird die Verknüpfung von einzelnen Wirkketten
über Relais zu einer gesamten Wirkkette deutlich.
tensmodelle erstellt werden. Davon wurden 68 % anhand
von Basisfunktionen und 14 % anhand des Verfahrens
für Multifunktionen modelliert.
Für die Verhaltensmodelle wird eine logische Modellierung
des Verhaltens gefordert. Diese Anforderung wird
bei der automatisierten Erstellung von Verhaltensmodellen
für binäre Signale, die Basisfunktionen umsetzen,
erfüllt. Deren Verhalten kann anhand von Zustandsgraphen
automatisiert logisch modelliert werden.
Zur logischen Verhaltensmodellierung der Multifunktionen
werden Informationen aus dem Stromlaufplan
extrahiert. Hierbei treten jedoch Einschränkungen
auf. Insbesondere Interaktionen mit dem Materialfluss
müssen im Maschinenmodell durch die Anbindung
einzelner Signale an das geometrische Modell
manuell modelliert werden.
Aufgrund der großen Abdeckung binärer Signale mit
automatisiert erstellten Verhaltensmodellen lässt sich
durch die Automatisierung trotz der Einschränkungen,
die zu einer manuellen Nachbearbeitung des Maschinenmodells
führen, etwa zwei Drittel des Aufwands bei
der Erstellung einsparen.
Manuskripteingang
01.02.2011
Im Peer-Review-Verfahren begutachtet
Zusammenfassung
Das vorgestellte Konzept betrachtet die Erstellung der
Verhaltensmodelle aller im Maschinenmodell abzubildenden
Komponenten und zeigt eine Lösung zur automatisierten
Erstellung für Komponenten auf, die über binäre
Signale kommunizieren.
Das Ziel der automatisierten Erstellung von Verhaltensmodellen
kann für fast alle binären Signale erreicht
werden. Ausgenommen sind lediglich die in der E/A-
Liste nicht normgerecht oder nicht mit dem Stromlaufplan
übereinstimmend bezeichneten Signale. Bei der
Beispielmaschine konnten für 82 % der Signale Verhal-
Prof. Dr.-Ing. PETER Klemm
(geb. 1950) ist seit 2002 stellvertretender
Leiter des Instituts
für Steuerungstechnik der
Werkzeugmaschinen und
Fertigungseinrichtungen (ISW)
der Universität Stuttgart.
Institut für Steuerungstechnik der Werkzeugmaschinen
und Fertigungseinrichtungen (ISW),
Universität Stuttgart,
Seidenstraße 36, D-70174 Stuttgart,
Tel. +49 (0) 711 68 58 24 20,
E-Mail: Peter.Klemm@isw.uni-stuttgart.de
Referenzen
[1] Scheifele, D., Eger, U., Röck, S., Sekler, P.: Potentiale
der Hardware-in-the-Loop-Simulation für Maschinen
und Anlagen. In: Verl, A., u.a. (Hrsg.): SPS/IPC/Drives,
27.-29. Nov. 2007, Nürnberg, S. 555-565
[2] reinhart, G., Wünsch, G.: Economic Application of
virtual commissioning to mechatronic production
systems. Production Engineering 1 (2007), H. 4, S.
371-379
[3] Kufner, A., Haug, K., Klemm, P.: Modellierung von
Montagemaschinen für die Hardware-in-the-Loop-
Simulation. In: Gausemeier, J., u.a. (Hrsg.): 7.
Paderborner Workshop Entwurf Mechatronischer
Systeme, 18.-19. März 2010, Paderborn, S. 115-126
[4] Schob, U., Böttcher, R., Blochwitz, T., Oelsner, O.,
Winter, M.: Model based virtual startup of automation
systems. In: Proceedings 7th Modelica Conference,
20.-22. Sept. 2009, Como, S. 790-797
[5] Simulationssoftware Virtuos, ISG GmbH, Stuttgart
[6] Kiefer, J., Ollinger, L., Bergert, M.: Virtuelle Inbetriebnahme
- Standardisierte Verhaltensmodellierung
mechatronischer Betriebsmittel im automobilen
Karosseriebau. atp – Automatisierungstechnische
Praxis 51 (2009) H. 7, S. 40-46
[7] reinhart, G., Hensel, T., Lindworsky, A., Spitzweg, M.:
Teilautomatisierter Aufbau von Simulationsmodellen.
wt Werkstattstechnik online 97 (2007), H. 9, S. 663-667
[8] ieC 81346-1:2009-07: Industrielle Systeme, Anlagen
und Ausrüstungen und Industrieprodukte - Strukturierungsprinzipien
und Referenzkennzeichnung, 2009
atp edition
9 / 2011
31
hauptbeitrag
Life Cycle Support
per Simulator
Erfolgreiche Umsetzung für Großanlagen
Im Bereich der Energietechnik werden Simulatoren vorrangig zum Training des Bedienpersonals
eingesetzt. Dabei sind jedoch große Einsparpotenziale erkennbar, wenn Simulatoren
bereits früh bei der Planung der Anlagen eingesetzt werden. Prozesssimulatoren
können wertvolle Aussagen über die Dimensionierung verschiedenster Hardwarekomponenten
liefern. Die virtuelle Inbetriebnahme prüft die Funktionsfähigkeit der Automatisierungslösung
und erlaubt eine (zumindest Grund-) Optimierung der Regelkreise vor der
tatsächlichen Inbetriebnahme. Aber auch im eigentlichen Betrieb ist ein Simulator sinnvoll
einsetzbar. So können geplante Änderungen an der Anlage und der Automatisierung
im Simulator gründlich erprobt und auf ihre Wirksamkeit hin untersucht werden.
SCHLAGWÖRTER DCS / Emulation / Virtuelle Inbetriebnahme / Life cycle Support
Life cycle support per simulator –
Successful implementation for large processes
The usage of simulators over the whole life cycle of a plant is a very important part of the
engineering process. Currently the usage is still different: whilst it is nearly common
practice in the area of process industry, in the energy generating industries simulators
are mainly used for operator training purposes. Large money saving potential has been
identified when using simulators as early as possible during the engineering of the plant.
Process simulators are able to give vital informations about the proper dimensioning of
hardware components and give hints how to optimize them with respect to their behaviour
during operation (e.g. controllability of valves or drives). The virtual commissioning
of the control application checks the functionality of the solution proposed and to perform
an – at least – base optimization of the control loops before starting the real commissioning.
During life time of the plant changes and further optimizations may be checked
thoroughly before implementation.
KEYWORDS DCS / Emulation / Virtual commissioning / Life cycle support
32
atp edition
9 / 2011
Herbert Krause, Secolon
Alexander FriCK, TORGRim SchiEFLOE, ABB
Die nördlichste und größte Erdgasverflüssigungsanlage
(Liquefied Natural Gas, LNG) auf der Insel
Melkøya in der Nähe von Hammerfest in Norwegen
wurde in den Jahren 2008/2009 in Betrieb
genommen [1]. Das Erdgas stammt aus den unterseeischen
Feldern Snøhvit, Albatross und Askeladd, die
etwa 150 km nordwestlich der Anlage in der Barents See
liegen. Der Vorrat an Erdgas wird auf 193 Mrd. m 3 geschätzt.
Dank der tiefen Temperaturen und neu entwickelter Prozesse,
wie zum Beispiel der Mixed Fluid Cascade (MFC),
wird im Vergleich zu anderen Anlagen ähnlicher Größe ein
sehr guter Wirkungsgrad erwartet [2]. Auch bei der Errichtung
der Anlage wurden neue Wege beschritten: Sie wurde
in Portugal auf einer Barke installiert und dann auf dem
Seeweg an ihren endgültigen Standort gebracht, siehe Bild 1.
Da die Inbetriebnahme einer solchen Anlage eine sehr
zeitaufwendige Aufgabe ist und da einige Prozesse überhaupt
zum ersten Mal zum Einsatz kamen, wurde entschieden,
so viel Planungs- und Engineering-Arbeit wie irgend
möglich vor der Inbetriebnahme der realen Anlage durchzuführen.
Aus diesem Grund beschlossen Statoil (als späterer
Betreiber) und Linde (als Planer), eine virtuelle Inbetriebnahme
der Anlage mit Hilfe eines „High Fidelity“-Simulators
durchzuführen. Ziel war es, das Training des Bedienpersonals
ein Jahr vor dem Start der Inbetriebnahme der realen
Anlage zu beginnen, möglichst viele Parameter einzustellen
und die Automatisierung weitestgehend zu testen.
1. Der Simulator
Der Simulator besteht aus verschiedenen dynamischen
Prozessmodellen, die von Kongsberg Maritime (ehedem
Fantoft Process Technologies, Sandvika, Norwegen) bereitgestellt
wurden, dem Bediensystem „Human System
Interface“ (HSI) des 800xA Systems von ABB, dem Engineering
Simulator, der das Verhalten der PM875-Komponenten
(ebenfalls ABB) emuliert, und einem Emulator des
Hima Fail Safe Systems.
Der Emulator der Controller (PM875) stellt hier eine
Eins-zu-eins-Kopie des Originalsystems bereit. Er kann
sehr leicht an Änderungen der Automatisierung angepasst
werden, da Emulator und Produktivsystem dieselben
Konfigurationsdaten nutzen.
Das Bediensystem wird als Standardprodukt eingesetzt,
allerdings erweitert um das simulatorspezifische
Produkt „800xA Simulator“, und wird vom Simulator
des Prozessmodells stimuliert. Dies stellt sicher, dass das
Bedienpersonal dasselbe „Look and Feel“ wie an der realen
Anlage vorfindet, was den Trainingseffekt weiter
steigert. Die Software 800xA Simulator verbindet und
synchronisiert alle Komponenten des Simulators. Die
Hardware ist auf VMWare-ESX-Servern komplett virtualisiert.
Dadurch wird der benötigte Platz und Energieaufwand
minimiert (siehe Bild 2).
1.1 Das Prozess-Modell
Das dynamische Modell umfasst sowohl den On-Shoreals
auch den Off-Shore-Bereich der Anlage [4]. Als Simulationswerkzeuge
werden D-SPICE (Dynamic Simulator
for Process, Instrumentation and Control Engineering) für
das Prozess-Modell und OLGA2000 für das Pipeline-
Modell eingesetzt [5]. Die Konfiguration erfolgt über eine
grafische Bedienoberfläche (siehe Bild 3).
1.2 Das Leitsystem
Als Leitsystem für die LNG-Anlage wird das System
800xA benutzt [6] [7] [8]. Hierbei handelt es sich um ein
Leitsystem für Großanlagen. Der aktive Teil AC 870P / Melody
ist ein Bus-basiertes System mit verteilten Bearbeitungsbaugruppen
(PM875). Die grundsätzliche Systemstruktur
ist in Bild 4 dargestellt.
Die Prozessgrößen werden über I/O-Baugruppen oder
MODBUS-Komponenten mit dem Prozess ausgetauscht.
Über den Hochgeschwindigkeits-Bus Fnet werden diese
Daten an die Controller übertragen. Die Kommunikation
zwischen den Controllern erfolgt über das Cnet (Control
Network). Die Daten für das Bedienen und Beobachten
atp edition
9 / 2011
33
Hauptbeitrag
BILD 1:
Die Snøhvit
Barke [3]
BILD 2: Virtualisierte Hardware
laufen über das Onet (Operation Network). Diese Netzwerke
wurden getrennt, um sicherzustellen, dass der
aktive Teil des Systems unter keinen Umständen durch
einen großes Datenaufkommen zum HSI beeinflusst
wird, wie das zum Beispiel bei einem Anlagenfehler passieren
kann, wenn viele Alarme in den Alarmlisten zur
Anzeige gebracht werden müssen. Es sind 18 Controller
im Einsatz und mehr als 10 000 Prozessgrößen werden
mit dem Prozess ausgetauscht.
Die Konfiguration des Leitsystems erfolgt über den „Engineering
Workplace“, der über das Onet mit den Controllern
verbunden ist. Änderungen in der Automatisierung
können nur hier vorgenommen werden („erzwungene Vorwärtsdokumentation“).
Die Konfiguration erfolgt durch
das Zeichnen von Funktionsplänen. Ein Beispiel für einen
benutzerdefinierten Funktionsbaustein zeigt Bild 5.
In den Funktionsplänen befinden sich die Eingangsgrößen
(Prozesssignale oder Parameter) auf der linken
Seite. Parameter können hierbei fest eingestellt sein (zum
Beispiel PARA), aus anderen Prozessgrößen berechnet
(beispielsweise R1) oder vom Bedienpersonal über die
Bedienoberfläche (HSI) geändert werden. Auf der rechten
Seite befinden sich die Ausgänge (Prozesssignale (OC)
und Status-Informationen (STA)).
Zur Unterstützung für die Inbetriebnahme und zur
Lokalisierung von Fehlfunktionen ist es möglich, in das
Leitsystem hineinzusehen und interne und globale Variablen
abzugreifen und darzustellen (siehe Bild 6).
1.3 Emulator des Leitsystems
Bei dem hier vorgestellten Simulator wird eine Kopie der
realen Bedienoberfläche benutzt. Der „800xA Simulator“
stellt ein Interface zum Ausbilderplatz bereit sowie spezifische
Funktion für das Simulatortraining, beispielsweise
das Speichern von Anfangszuständen oder von
geladenen Anfangszuständen oder das Ändern der Simulationsgeschwindigkeit.
Die Controller und Koppelbaugruppen
werden als Programme emuliert, die auf einem
Dell Poweredge-2950-Server mit 2 Dual Core 2.33 GHz
CPUs und Windows-2003-Server-Betriebssystem laufen.
Der Emulator benutzt den original Quellcode der Funktionsbausteine
und stellt so sicher, dass die Bausteine
dasselbe Verhalten wie das reale System zeigen. Jeder
Controller und jede Koppelbaugruppe läuft in einer eigenen
Windows Task. Dadurch kann das System leicht an
die Bedürfnisse angepasst und skaliert werden. Alle berechneten
Daten werden in der Datenbank Primo S abgespeichert.
Diese Datenbank ist sehr flexibel und erlaubt,
auf verschiedenen Wegen und extrem schnell auf die
Daten zuzugreifen. Einen Eindruck von der Komplexität
des Systems und den alle 250 ms zu verarbeitenden
Datenmengen vermitteln die folgenden Zahlen:
94 000 Funktionsbausteine
360 000 Inbetriebnahmeparameter
650 000 Variablen innerhalb der Controller
350 000 globale Variablen für die Kommunikation
mit dem Prozess, dem HSI und zwischen den
Controllern
Mehr als 10 000 mit dem Prozess-Simulator
ausgetauschte Prozessgrößen
Die Konfiguration der Controller und Koppelbaugruppen
erfolgt ohne manuelle Nachbearbeitung aus denselben
Daten, die auch an die realen Baugruppen gesendet werden.
Die Verbindung zum simulierten Prozess übernimmt
ein OPC-DA-Server, der alle im Emulator vorhandenen
globalen Variablen von außen zugänglich macht. Die Aktualisierung
läuft alle 250 ms entsprechend der Zykluszeit
im Emulator ab.
Während des Hochfahrens scannt der OPC-DA-Server alle
Daten in der Datenbank, liest die vom Engineering Workplace
bereitgestellten Signallisten für die Prozessvariablen
und erzeugt so die „erweiterte MSR-Liste“, die alle mit dem
Prozess-Simulator auszutauschenden Daten einschließlich
der vollständigen Signalnamen und Messbereiche enthält.
Mithilfe einiger Skripte kann der Simulator-Hersteller aus
diesen Daten vollautomatisiert die für die Ankopplung des
Prozess-Simulators notwendigen Daten generieren.
Um das ordnungsgemäße Funktionieren der Regel-Logik
zu prüfen, kann der Engineering Workplace ebenso wie
mit dem realen System auch mit dem Emulator verbunden
34
atp edition
9 / 2011
Wie bereits beschrieben besteht der Simulator aus einer
großen Anzahl von Komponenten verschiedener Hersteller
(siehe Bild 7). Es ist von größter Wichtigkeit, dass alle
diese Komponenten ohne großen Aufwand zusammenarbeiten.
Das Modul 800xA Simulator koordiniert die verschiedenen
Komponenten.
Hierzu müssen drei Aufgaben ausgeführt werden: Die
Simulator-Befehle müssen an alle Komponenten weitergereicht,
die Komponenten müssen synchronisiert und
der Datenaustausch zwischen den verschiedenen Modulen
muss ermöglicht und verwaltet werden.
Die Simulator-Befehle werden auf dem Ausbilderplatz
erzeugt und an die verschiedenen Komponenten weitergeleitet.
Jede Komponente führt die angeforderte Aktion
aus und sendet dann ein Bestätigungssignal, ob dies erfolgreich
geschehen ist. Das System fährt erst dann fort,
wenn alle Bestätigungen innerhalb einer definierten Antwortzeit
eingetroffen sind.
Dieses Vorgehen erlaubt es, alle beteiligten Komponenten
zu synchronisieren. Dadurch wird zum Beispiel sichergestellt,
dass die Anfangsbedingungen (Initial Conditions,
ICs) oder Schnappschüsse des Simulatorzustandes
konsistent sind (das heißt, dass beispielsweise der
Schnappschuss der Automatisierung mit den entsprechenden
Trend-Darstellungen zusammenpasst). Besonders
wichtig wird diese Aufgabe, wenn – wie im vorgestellten
Beispiel – nicht nur ein Emulator vorhanden ist,
sondern verschiedene Emulatoren und Prozess-Simulatoren
zusammenarbeiten.
Für die Sicherstellung des Datenaustausches wurde
das OPC DA Framework implementiert. Es handelt sich
hierbei um eine Plattform, auf der alle OPC-Daten des
Systems an einer Stelle zusammengefasst und bereitgestellt
werden. Jeder Client kann sich hier verbinden und
die notwendigen Daten austauschen.
Das System stellt ein einheitliches Interface für alle
Komponenten zur Verfügung und benutzt dazu allgemein
vorhandene Technologien wie DCOM und OPC.
Einmal implementiert ist es dann sehr einfach, Komponenten
verschiedener Hersteller zu koppeln. Dadurch ist
es möglich, unabhängig vom Anbieter, für die anstehenden
Aufgaben die Komponenten zu verwenden, die die
Anforderungen am besten erfüllen.
2. Life Cycle Support
BILD 3: D-SPICE HSI [5]
werden. So können zum Beispiel interne oder globale Variablen
angemessen und genau so im Funktionsplan dargestellt
werden, wie dies auch im realen System der Fall
ist. Deswegen braucht der Inbetriebnahme-Ingenieur kein
Spezialwissen, wenn er mit dem Emulator arbeitet.
1.4 Struktur des Simulatorsystems
Der Simulator ist darauf ausgelegt, den kompletten Lebenszyklus
eines Prozesses zu begleiten. Dabei sind folgende
Aufgaben zu erfüllen[9]:
Konzeption
Auslegung
Engineering
Inbetriebnahme
Testen der Bedienoberfläche (HSI)
Betrieb
Auf- und Umrüstungen
Während die Konzeption und die Auslegung sehr stark
mit der Hardware der Anlage verbunden sind und deswegen
nur vom Prozess-Modell und den Lieferanten der
Verfahrenstechnik unterstützt werden, ist der Simulator
sinnvoll für alle weiteren Aufgaben einzusetzen. Schon
zu einem sehr frühen Zeitpunkt ist die regelungstechnische
Applikation von höchster Wichtigkeit für den optimalen
und effizienten Betrieb der Anlage. Sie sollte frühestmöglich
auf ihre Fähigkeiten untersucht werden.
Die wichtigsten während der Engineering-Phase zu
prüfenden Bereiche sind:
Prüfen des Regelungssystems: Es muss geprüft werden,
ob die grundlegenden Funktionen ordnungsgemäß
implementiert sind und ob die Regelung alle
geforderten Funktionen bietet. Dies beginnt bei sehr
einfachen Fragestellungen wie „Arbeiten die Stellantriebe
in der richtigen Laufrichtung?“ bis zu
anspruchsvolleren Aufgaben wie zum Beispiel die
Pumpverhütungsregelung von Kompressoren (um
einen sicheren Betrieb zu gewährleisten) bis zur
korrekten Funktion einer Ablaufsteuerung (für einen
sicheren und effizienten Betrieb der Anlage).
Prüfen der Prozeduren: Die Fahrweise für das Hochfahren
und den regulären Betrieb der Anlage werden normalerweise
vom Prozesslieferanten zur Verfügung gestellt.
Wenn die Anlage neu ist oder ein Prozess sogar
zum ersten Mal zum Einsatz kommt, ist es notwendig
zu prüfen, ob die getroffenen Annahmen zutreffend
sind. Wenn der Simulator den Prozess mit hinreichender
Genauigkeit wiedergibt und dieser mit dem Emulator
des Leitsystems betrieben wird, kann der Kunde
schon Vertrauen in das korrekte Funktionieren der Anlage
bekommen. Die Ergebnisse dieser Untersuchungen
stellen zumindest eine gute Ausgangsbasis für die Inbetriebnahme
der realen Anlage bereit. In dem beschriebenen
Projekt Hammerfest wurden insgesamt 500
Punkte in diesem Bereich entdeckt und behoben [9].
atp edition
9 / 2011
35
Hauptbeitrag
BILD 6:
Angemessener
Ausgangswert
BILD 4: 800xA System Struktur
BILD 5: Funktionsbaustein
BILD 7:
Struktur des
Simulatorsystems
Prüfen der Bedienoberfläche (HSI): Der Simulator erlaubt
es, die Bedien- und Alarmierungsphilosophie
zu prüfen und gegebenenfalls zu verbessern. Dies sind
Aufgaben, die in vielen Projekten aus Zeitmangel unterbleiben,
was zu einem unbefriedigenden Ergebnis
führen kann. Mit Hilfe des Simulators ist es möglich,
das HSI so rechtzeitig zu prüfen, dass noch Optimierungsarbeiten
durchgeführt werden können.
Prüfen von Umbauten: In Zukunft soll der Simulator
dazu benutzt werden zu prüfen, ob beabsichtigte Umbauten
oder Änderungen an der Regelstrategie wirklich
Verbesserungen ergeben. Sie können ohne Gefahr
für die reale Anlage geprüft und – bei Erfolg –
umgesetzt werden.
3. uPgrade des Emulators nach Änderungen
Für alle beschriebenen Aufgaben ist es notwendig, die
bestehende regelungstechnische Applikation ändern zu
können, um gefundene Fehler zu beseitigen. Um die
Arbeit zu minimieren, ist es sehr wichtig, dass bereits
gewonnene Daten erhalten bleiben und dass nur die
Bereiche nachgezogen werden, die verändert wurden.
Folgende Änderungen sind möglich:
Änderungen in der Struktur der Automatisierung.
Dies tritt auf, wenn in der bereits umgesetzten Automatisierung
eine Fehlfunktion festgestellt wird. Hier
muss eine andere Lösung erarbeitet und im Engineering
Workplace konfiguriert werden.
Änderungen an den Parametern der Funktionsbausteine.
Diese Parameter sind fest konfiguriert und können nur
über den Engineering Workplace geändert werden.
Änderungen von Parametern über die Bedienoberfläche,
den „bedienbaren“ Parametern. Dies sind üblicherweise
Alarmgrenzen und Ähnliches.
Identifizierung der gültigen Parameter, um feststellen
zu können, ob alle Parameter wie vorgesehen geändert
wurden.
In dem beschriebenen Projekt musste zusätzlich berücksichtigt
werden, dass die Änderungen an der regelungstechnischen
Applikation beim Hersteller des DCS-Systems
durchgeführt wurden, die Integration des Emulators
mit dem Prozess-Modell aber in den Räumen des Simu-
36
atp edition
9 / 2011
latorherstellers in Sandvika in der Nähe von Oslo stattfand.
Ein Trainingssimulator wurde schon Anfang 2006
in Hammerfest installiert, der regelmäßig auf den neuesten
Stand gebracht werden musste, um belastbare Trainingskurse
durchführen zu können.
3.1 Automatisierungsstrukturen
Wenn die regelungstechnische Applikation geändert wird,
können Funktionsbausteine gelöscht, neu hinzugefügt
oder Ein- und Ausgänge anders belegt werden. Diese Prozedur
kann, wie schon erwähnt, nur im Engineering Workplace
erfolgen. Jeder Funktionsbaustein hat innerhalb des
Planes eine eindeutige Kennzeichnung (Betriebsmittelkennzeichen,
BMZ). Weiterhin benötigen die meisten Bausteine
interne (lokale) Variablen, um den Zustand des letzten
Rechenschrittes oder der letzten Rechenschritte zwischenzuspeichern.
Wenn ein Funktionsbaustein gelöscht
wird, hält der Engineering Workplace das entsprechende
BMZ und die Indizes der zugehörigen lokalen Variablen in
einer Liste. Damit wird verhindert, dass diese Größen sofort
wiederverwendet werden. Dies ist erst wieder möglich,
wenn der geänderte Plan in einen Controller geladen wurde
und dann eine erneute Änderung ansteht.
Wird ein neuer Funktionsbaustein eingefügt, dann
werden die BMZ und die Indizes an das Ende der bisher
benutzten angefügt.
Diese Regeln erlauben es, einen ausgefeilten Algorithmus
zu entwickeln, der geänderte Variablen identifiziert
und – genau wie im realen System – auf den Default-Wert
setzt (normalerweise 0).
3.2 Parameter der Funktionsbausteine
Die Parameter der Funktionsbausteine sind Bestandteil
der Konfigurationsdateien für die Controller. Nach einer
Änderung sind diese Parameter also sofort für alle Anfangzustände
wirksam.
Wenn nun im Engineering Workplace eine neue Konfigurationsdatei
erzeugt wird, nachdem ein Parameter
im Emulator geändert wurde, gehen diese Änderungen
verloren. Deswegen wurden Werkzeuge entwickelt, die
es erlauben alle Parameter im Emulator zu ex- und importieren.
Weiterhin können diese Parameter im Engineering
Workplace importiert werden. Daraus ergeben
sich zwei verschiedene Workflows:
1 | Die aus dem Emulator exportierten Parameter werden
in den Engineering Workplace importiert bevor
die neuen Konfigurationsdateien erzeugt werden.
Dann sind die neuen Parameter bereits Bestandteil
der neuen Applikation.
2 | Die exportierten Parameter werden nach der Erstellung
der neuen Applikation in den Emulator geladen
und vom Emulator in die Konfigurationsdateien
geschrieben.
Beide Vorgehensweisen waren im beschriebenen Projekt
notwendig. In der Anfangsphase wurde zunächst Workflow
2 benutzt, da das Engineering vorrangig die Struktur
der Automatisierung voranbringen wollte und nicht so
sehr auf Parameteränderungen geachtet hat. In der Endphase
ist Version 1 vorzuziehen, da hier die Parameter in
den Engineering Workplace geladen werden, der die Konfigurationsdaten
für das reale System erzeugt.
3.3 Bedienbare Parameter
Die bedienbaren Parameter können durch das Bedienpersonal
über die Bedienoberfläche geändert werden. Sie
sind Bestandteil jedes Anfangszustandes. Deswegen gibt
es ein weiteres Tool, das alle Anfangszustände automatisch
ändert. Die Parameter müssen zur späteren Anwendung
in der realen Anlage natürlich auch in den Engineering
Workplace importiert werden.
3.4 Nachführen der Anfangszustände
Schließlich müssen die Anfangszustände nachgeführt werden.
Dies ist für den Projektverlauf von höchster Wichtigkeit,
da die Ergebnisse des gesamten Integrationsprozesses
hierin gespeichert sind. Mit den beschriebenen Regeln werden
alle notwendigen Schritte automatisch ausgeführt.
3.5 Upgrade Workflow
Der Integrations- und Test-Prozess wurde dadurch erschwert,
dass die Arbeiten an drei verschiedenen Plätzen
durchgeführt wurden: dem Engineering-Bereich in Bergen,
den Büros des Simulator-Herstellers in der Nähe von
Oslo und dem Trainings-Simulator in Hammerfest.
Während das Integrations-Team das System auf Fehlfunktionen
hin prüfte, setzte das Engineering-Team seine
Arbeit fort. Bei der Integration gefundene Fehlfunktionen
wurden an das Engineering-Team zur Korrektur berichtet.
Während der Korrektur wurde die Integration aber fortgesetzt,
um Zeit zu sparen. Es ist offensichtlich, dass dieses
Vorgehen von allen Beteiligten ein hohes Maß an Disziplin
verlangte, damit keine Arbeitsergebnisse verloren gehen.
Wenn eine neue Version der Applikation vorlag, erzeugte
das Integrations-Team Anfangszustände mit dem aktuellen
Integrationsstand und eine Liste aller Parameter. Nach dem
Upgrade des Emulators auf die neue Applikation wurden
die Anfangszustände entsprechend konvertiert und die Parameter
re-importiert. Diese Schleife musste für jedes Upgrade
durchgeführt werden. In Hammerfest wurden im
Projektverlauf ungefähr 40 Iterationen vorgenommen.
In anderen aktuell bearbeiteten Projekten, wie zum
Beispiel dem Simulator für das Kohlekraftwerk Datteln,
wurde der Workflow dahingehend geändert, dass auch
dem Integrations-Team (das aus erfahrenen Inbetriebnahme-Ingenieuren
besteht) erlaubt wurde, selbst Änderungen
an der Automatisierung vorzunehmen. Dieses
Vorgehen erlaubt noch kürzere Upgrade-Intervalle.
Zusammenfassung und Ausblick
In der Öl- und Gas-Industrie in Norwegen ist es inzwischen
übliche Praxis, Simulatoren bei der Planung und
Inbetriebnahme zu benutzen. Die bisher gesammelten
Erfahrungen waren sehr positiv [10].
Derzeit wird die Umrüstung der Gas verarbeitenden Anlage
Kårstø mit dem Simulator geplant und getestet. Hier
ist zusätzlich der kombinierte Betrieb verschiedener Sor-
atp edition
9 / 2011
37
Hauptbeitrag
Referenzen
ten von Controllern zu berücksichtigen. Der Datenumfang
entspricht in etwa dem 3-fachen Volumen der beschrieben
LNG-Anlage in Hammerfest. In Kårstø benutzt Statoil insgesamt
4 Simulatoren für die Prüfung des Leitsystems. Es
musste ein altes Procontic-DCS-System mit einer Konfiguration
vergleichbar der in Hammerfest ausgetauscht werden.
Weiterhin beinhaltet die Anlage Kårstø 800MHI Controller
von ABB, sodass der Simulator auch den 800MHI
Emulator/Softcontroller enthält.
Da es sich um eine laufende Anlage handelt, war der
Fokus auf eine Reduzierung der Abschaltzeiten gerichtet.
Der Simulator ist eine wesentliche Komponente, um sicherzustellen,
dass die Automatisierung und das HSI zum
Zeitpunkt der Umschaltung 100 % korrekt arbeiten.
In Deutschland wird derzeit der Block 4 des Kraftwerkes
Datteln gebaut und virtuell in Betrieb genommen. Es
handelt sich hierbei um ein 1100-MW-Kohlekraftwerk
mit einem sehr hohen Automatisierungsgrad. Als Automatisierungssystem
kommt das 800xA-System der ABB
zum Einsatz mit mehr als 40 PM875 Controllern.
Die bisher gesammelten Erfahrungen zeigen, dass die
virtuelle Inbetriebnahme wie die Inbetriebnahme einer
realen Anlage zu behandeln ist. Das heißt zum Beispiel
auch, dass die Inbetriebnahme-Ingenieure der Verfahrensseite
bei der Integration anwesend sein müssen. Sie
werden benötigt, um die Ursachen für Probleme während
der Inbetriebnahme zu erkennen und angemessen
darauf zu reagieren.
Ein weiterer großer Vorteil ist die Möglichkeit eines
Tests mit „Versuch und Irrtum“. Es ist so möglich Regelstrategien
zu prüfen, die die reale Anlage schädigen
[1] http://www.statoil.com/statoilcom/snohvit/svg02699.nsf?OpenDatabase
&lang=en
[2] Berger, E. et al.: Das Snøhvit-Projekt. Linde Technology, 1:12–23, 2003.
(http://www.linde com/international/web/linde/like35lindede.nsf/repositorybyalias/pdf_lindetechnology_1_2003/$file/Linde_Technology_1_2003_DE.pdf)
[3] http://www.offshore-technology.com/projects /snohvit/snohvit7.html
[4] http://www.fantoft-process-technologies.com /downloads /
Simulators%20Snohvit.pdf
[5] http://www.km.kongsberg.com/ks/WEB/NOKBG0240.nsf/AllWeb/
5552FF4BD0255B25C1256A68002B4CAB?OpenDocument
[6] Krause, H.: Emulator for the digital control system Symphony. ESS'2001,
Simulation in Industry, 13th European Simulation Symposium and Exhibition,
Marseilles (France), October 18th-20th 2001, SCS-Europe Ghent
[7] Krause, H.; Niss, T.: Emulator für das Leitsystem „Melody“ der abb.
VDI-VDE-Aussprachetag „Rechnergestützter Entwurf von Regelungssystemen“,
September 13th/14th 2001, Dresden
[8] Krause, H.: Emulator für das Prozessleitsystem Symphony Melody der Firma
abb. Paper presented during GMA-Congress 2003, June 3rd/4th 2003,
Baden-Baden
[9] Skjerven, Ø., Vist, S.: Snøhvit Lifecycle Simulator from Wellhead through
Pipeline and LNG Liquefaction to Offloading. 15th International Conference &
Exhibition on Liquefied Natural Gas (LNG15), April 24th - 27th 2007, Barcelona.
[10] Fiske, T.: Use and Benefits of Dynamic Simulation for Operator Training
Systems. arC insights, Insight# 2007-38mph, August 9, 2007
könnten. Dadurch kann man zu Lösungen zu kommen,
die besser funktionieren als das, was aus Sicherheitsgründen
eingesetzt wird, da es „schon immer so gemacht“
wurde.
Manuskripteingang
16.02.2011
Autoren
Dipl.-Ing. HerbERT Krause
(geb. 1955) arbeitete seit
1982 bei Hartmann & Braun
im Bereich fortschrittlicher
Regelalgorithmen und der
Entwicklung von Simulations-
und Plant Management
Software. 2001 leitete
er bei ABB die Entwicklung
des AC 870P / Melody Emulators. Er gründete
2006 eine Firma, die hochwertige technische
Software entwickelt und vertreibt.
Secolon,
Schwarzer Weg 8, D-32423 Minden,
Tel. +49 (0) 571 386 48 72,
E-Mail: herbert.krause@secolon.de
Dr. Alexander FriCK
(geb. 1967) leitet die
Abteilung Plant Optimi
zation der ABB AG
(Power Generation).
Er ist seit zehn Jahren
bei ABB.
ABB,
Kallstadter Str. 1, D-68309 Mannheim,
Tel +49 (0) 621 381 45 39,
E-Mail: alexander.frick@de.abb.com
Torgrim SchiEFLOE
(geb. 1967) arbeitet als Area
Sales Manager für Simulator
Lösungen bei ABB Oil & Gas
Norway. Er ist seit 1990 für
ABB in verschiedenen
Automatisierungsprojekten
tätig und seit 2005 betreut er
die Simulator-Lösungen
innerhalb der ABB in Norwegen und weltweit.
ABB,
Ole Deviks vej 10, N-0666 Oslo,
Tel. +47 2287 23 83,
E-Mail: torgrim.schiefloe@no.abb.com
Im Peer-Review-Verfahren begutachtet
38
atp edition
9 / 2011
SIL
Sprechstunde
3. SIL-Sprechstunde
Funktionale Sicherheit
15. + 16.9.2011, Mannheim, Pepperl+Fuchs GmbH
www.sil-sprechstunde.de
Veranstaltungskonzept
Thema
Sie fragen – Experten antworten!
Die SIL-Sprechstunde ist eine offene Dialogveranstaltung,
bei der Sie aufgefordert sind, Fragen und Themen
einzubringen. Diese werden im Expertenkreis diskutiert
oder in interaktiver Gruppenarbeit bearbeitet.
Kleinere Unternehmen bearbeiten oft Aufträge von großen
Anwendern, die in vollem Umfang die Erfüllung der
einschlägigen Sicherheitsnormen (z.B. Functional Safety
Management) einfordern.
Die 3. SIL-Sprechstunde behandelt den Themenbereich
Funktionale Sicherheit in kleinen und mittelständischen
Unternehmen – insbesondere rund um die
Umsetzung der EN 61508/61511.
Zielgruppe & Referenten
Diese SIL-Sprechstunde richtet sich besonders an kleine
und mittelgroße Unternehmen.
Die Veranstaltung wird von profilierten Experten aus
der Praxis moderiert und begleitet, die in renommierten
Unternehmen oder Institutionen tätig sind.
Nutzen Sie Ihre Chance!
Machen Sie die 3. SIL-Sprechstunde zu Ihrer
Veranstaltung und reichen Sie schon jetzt unter
www.sil-sprechstunde.de Ihre individuellen Fragen ein.
Termin & Ort
Die SIL-Sprechstunde ist eine Zweitagesveranstaltung am:
• Donnerstag, 15.9.2011
11:30-17:00 Uhr: Fachreferate
18:30-22:00 Uhr: Abendveranstaltung
• Freitag, 16.9.2011
9:00-14:00 Uhr: Workshops
Pepperl+Fuchs GmbH
Lilienthalstr. 200
68307 Mannheim
Programmablauf
Am ersten Tag stehen Fachvorträge der Referenten auf der
Agenda, während am zweiten Tag die im Vorfeld eingereichten
Diskussionsthemen und Fragestellungen in parallel
laufenden Workshops erarbeitet werden.
Im Rahmen der Veranstaltung finden Sie ausreichend Zeit für
den Meinungs- und Erfahrungsaustausch im Kollegenkreis.
Teilnahmegebühr
Abonnenten der atp edition: € 540,-
auf Firmenempfehlung: € 590,-
reguläre Gebühr: € 690,-
Im Preis sind die Tagungsunterlagen sowie die Verpflegung
im Rahmen der Veranstaltung (Kaffeepausen, Mittagessen,
GetTogether) enthalten.
Veranstalter
Detaillierte Informationen zur Veranstaltung, das
vollständige Programm sowie die Online-
Anmeldung finden Sie im Internet unter
www.sil-sprechstunde.de
SOFORTANMELDUNG PER FAX: +49 (0) 201 / 8 20 02 40
Ja, ich melde mich verbindlich für die 3. SIL-Sprechstunde am 15.-16.9.2011 bei Pepperl+Fuchs in Mannheim an.
Ich beziehe atp edition im Abonnement
Ich beziehe atp edition nicht im Abonnement
Ich komme auf Empfehlung von der Firma: .....................................................................................................................................................................
Firma/Institution
Telefon
Telefax
Titel, Vorname, Nachname
E-Mail
Straße/Postfach
Land, PLZ, Ort
Nummer
Branche/Wirtschaftszweig
✘
Ort, Datum, Unterschrift
Nutzung personenbezogener Daten: Für die Auftragsabwicklung und zur Pflege der laufenden Kommunikation werden personenbezogene Daten erfasst und gespeichert. Mit dieser
Anmeldung erkläre ich mich damit einverstanden, dass ich vom Oldenbourg Industrieverlag oder vom Vulkan-Verlag per Post, per Telefon, per Telefax, per E-Mail, nicht
über interessante, fachspezifische Medien- und Informationsangebote informiert und beworben werde. Diese Erklärung kann ich mit Wirkung für die Zukunft jederzeit widerrufen.
hauptbeitrag
Arbeitsabläufe in der
Anlagenplanung optimieren
IT-Unterstützung für Engineering Workflows
Die Formalisierung und informationstechnische Unterstützung von Geschäftsprozessen
sind heute in größeren Unternehmen Stand der Technik. Der Beitrag zeigt, wie sich die
dort abgebildeten Prozesse grundsätzlich von denen in der Anlagenplanung unterscheiden.
Diese Unterschiede haben bisher eine informationstechnische Unterstützung von
Arbeitsabläufen in der Anlagenplanung verhindert. Die Autoren beschreiben, inwieweit
diese Art der Unterstützung durch Erweiterung und Adaption vorhandener Methoden
erreichbar ist und welche Vorteile bezüglich einer effizienteren Projektabwicklung sich
daraus ergeben.
SCHLAGWÖRTER Arbeitsablauf / Anlagenplanung / Workflow-Management-System /
Engineering Workflow Support System / EWSS
Optimization of Workflows in Plant Engineering –
IT-Support for Engineering
After an introduction to the current situation in formalization and IT support of business
processes, basic differences between business processes and engineering processes for
plant engineering will be shown. Based on these differences which prevent comparable
IT support of engineering processes up to date, it is discussed to which extent methods
available for business process can be enhanced or adapted to the needs of engineering
processes. Finally it is shown how IT support of engineering processes can contribute to
more efficient engineering.
KEYWORDS Workflow / Plant engineering / Workflow Management System /
Engineering Workflow Support System / EWSS
40
atp edition
9 / 2011
Lars Libuda, GEORG GuTERmuth, ABB Forschungszentrum Deutschland
Stefan HeiSS, Georg-Simon-Ohm-Hochschule
Profitables Wirtschaften bildet die Basis jedes
wettbewerbsorientierten Wirtschaftssystems.
Dabei haben die Erstellungskosten im Vergleich
zur Umsatzsteigerung einen größeren
Hebel als allgemein angenommen. Jeder Euro,
der bei Planung, Entwicklung, Herstellung oder Vertrieb
eines Produktes oder einer Dienstleistung eingespart
werden kann, erhöht den Gewinn überproportional:
Bei einer Gewinn-Marge von 10 % entsprechen
einem eingesparten Euro äquivalent 10 Euro mehr Umsatz!
Und je geringer die Marge, desto größer ist der
Hebel von erzielten Einsparungen. Bei 5 % Marge müssen
bereits 20 Euro Umsatz generiert werden, um den
Gegenwert zu einem intern gesparten Euro zu bilden.
Bei 1 % sind es bereits 100 Euro.
Das verdeutlicht, warum es sich lohnt, die Abläufe
in einem Unternehmen auf ihre Effizienz hin zu untersuchen
und zu optimieren. Dieses geschieht schon
in vielen Bereichen durch Optimierung von Geschäftsprozessen
und deren Umsetzung in entsprechenden
Arbeitsabläufen. Gängige Beispiele sind
Einkauf und Personalwesen, wo unter anderem Bestellungen
und Urlaubsanträge durch standardisierte
Arbeitsabläufe abgewickelt werden. Diese Arbeitsabläufe
sind dabei in einer Unternehmenssoftware
abgebildet, die ihre Einhaltung kontrolliert und unterstützt,
indem sie dafür sorgt, dass jeder Beteiligte
an einem Arbeitsablauf zeitgerecht genau die Informationen
erhält, die er für die Erfüllung seines Arbeitsschrittes
benötigt.
In der Domäne des Anlagenbaus gibt es jedoch einen
großen Bereich, in dem diese Art der informationstechnischen
Arbeitsablaufunterstützung kaum genutzt
wird, und das ist die Planung beziehungsweise das
Engineering der Prozessanlagen selbst. Es stellt sich
die Frage, warum das so ist. Denn die Anlagenplanung
ist ein komplexer, stark arbeitsteiliger Prozess mit vielen
involvierten Gewerken, sodass schnell Ineffizienz
aufkommen kann. Dieser Artikel zeigt auf, wie auch
die Anlagenplanung von einer informationstechnischen
Arbeitsablaufunterstützung profitieren kann.
1. Workflow-Management-Systeme
Seit Anfang der 90er-Jahre ist die Optimierung von Geschäftsprozessen
Gegenstand des Geschäftsprozessmanagements
oder Business Process Managements (BPM).
Dabei geht es um die Maximierung der Ausführungseffizienz
und die Ergebnisqualität von Geschäftsprozessen.
Aus diesem Umfeld stammen die folgenden Definitionen,
die in diesem Beitrag verwendet werden und zum großen
Teil aus [1] entnommen sind:
Ein Geschäftsprozess (Business Process) ist eine
zielgerichtete, zeitlich-logische Abfolge von arbeitsteilig
ausgeführten Aufgaben, Arbeitsschritten oder
Aktivitäten (Activities). Hierbei sind in der Regel
mehrere Organisationseinheiten eines Unternehmens
involviert.
Ein Arbeitsablauf (Workflow) ist ein formal beschriebener,
ganz oder teilweise automatisierter
Geschäftsprozess.
1.1 Geschäftsprozesse
Zur Implementierung von formalen Arbeitsabläufen in
informationstechnischen Systemen dienen Workflow-
Management-Systeme (WfMS).
Mit ihrer Hilfe lassen sich Arbeitsabläufe definieren,
standardisiert und teilweise automatisch ausführen und
kontrollieren. Manuelle Arbeitsschritte werden unterstützt,
indem diejenigen Personen, die an einem Arbeitsablauf
beteiligt sind, benachrichtigt werden, sobald sie
ihren Anteil leisten können und genau diejenigen Informationen
erhalten, die sie für die Erfüllung ihres Anteils
benötigen. Somit sind Entscheidungen dokumentiert, der
aktuelle Zustand ist jederzeit abrufbar und Erinnerungen
und weitere Aktionen können automatisch veranlasst
werden. Das gewährleistet eine hohe Effizienz und
Ergebnisqualität.
Workflow-Management-Systeme gehören in größeren
Unternehmen zum Stand der Technik und sind meist
atp edition
9 / 2011
41
Hauptbeitrag
modularer Bestandteil von Enterprise-Resource-Planning-Systemen
(ERP-Systeme) wie SAP. Darin werden
dann beispielsweise Arbeitsabläufe aus dem Bestell- oder
Personalwesen (zum Beispiel Urlaubsanträge) abgebildet
und anschließend von diesem System kontrolliert. Um
die Standardisierung in diesem Bereich kümmert sich
seit 1993 die Workflow Management Coalition [2].
1.2 Anlagenplanung
Gemäß der erwähnten Definition ist auch die Anlagenplanung
ein Geschäftsprozess. Ein wesentlicher Wettbewerbsfaktor
der Anlagenplanung ist eine möglichst kurze
Abwicklungszeit. Viele aktuelle Entwicklungen tragen
aber zu einer Steigerung des Planungsaufwands und damit
zu längeren Abwicklungszeiten bei. Beispiele dafür
sind: die steigende Größe und Komplexität von Anlagen,
strengere und zusätzliche einzuhaltende Vorschriften
(zum Beispiel für Umwelt und Sicherheit), aufwändigere
Technologien für das Engineering (beispielsweise Kommunikationstechnologien
wie Feldbusse) oder neue
Funktionalitäten (zum Beispiel Asset Management). Insofern
macht es Sinn, auch in der Anlagenplanung die
Effizienz und Ergebnisqualität durch den Einsatz eines
Workflow-Management-Systems zu steigern.
Vor allem für die Planung von Serienprodukten gab es
dazu bereits viele Arbeiten in den 90er-Jahren. In den EU-
Projekten JESSI Common-Frame [4] und CONSENS [3,5]
erfolgte die Weiterentwicklung einer speziell auf die Produktentwicklung
ausgerichteten Software-Plattform, welche
unter anderem ein auf die Belange von Planungsabläufen
abgestimmtes Workflow Management Modul beinhaltete.
Dazu gehört auch die Fähigkeit, komplexe, dynamische
und unter Umständen unstrukturierte Prozesse zu
planen und zu steuern [6]. Innerhalb des EU-Projekts CON-
FLOW [6,7] wurde zudem ein Konzept erarbeitet, um das
Änderungsmanagement von Planungsdaten in ein Workflow-Management-System
zu integrieren. Heute gibt es
bereits eine Vielzahl von Produkt-Daten-Management-
Systemen (PDM-Systemen) mit integrierten Workflow Management
Modulen. Der Einsatz von PDM-Systemen ist in
der Produktentwicklung heute Stand der Technik.
Vergleichbares findet sich für die Anlagenplanung
nicht. Hier werden keine Workflow-Management-Systeme
genutzt. Diese kommen erst zum Einsatz, wenn die
Anlagenplanung Ergebnisse liefert, die als Eingangsdaten
für begleitende und bereits modellierte geschäftliche
Prozesse dienen, wie zum Beispiel für die Bestellabwicklung.
Es scheinen somit Unterschiede zwischen Arbeitsabläufen
in der Anlagenplanung und den begleitenden
geschäftlichen Prozessen zu existieren. Um diese im
Folgenden zu unterscheiden, werden weitere Definitionen
eingeführt:
Ein Business Workflow ist ein Geschäftsprozess,
der bereits heute formalisiert in einem WfMS
abgebildet wird (und somit ein Arbeitsablauf
nach obiger Definition ist).
Ein Engineering Workflow ist ein Arbeitsablauf
spezifisch für die Anlagenplanung und bisher
nicht Gegenstand einer formalen Abbildung in
einem WfMS.
Die aufgeführten Beobachtungen werfen somit folgende
Fragen auf:
Was sind grundsätzliche Unterschiede zwischen
einem Engineering Workflow und einem Business
Workflow?
Wäre ein Einsatz von existierenden Workflow-
Management-Systemen in der Anlagenplanung
möglich und lohnend?
Wenn nicht, wie müsste ein Workflow-Management-System
beschaffen sein, um die Anlagenplanung
zu unterstützen?
2. Formalisierung von Engineering Workflows
Um diese Fragen beantworten zu können, ist es sinnvoll,
einen konkreten Anwendungsfall aus der Anlagenplanung
zu betrachten. Im vorliegenden Fall wurde eine Studie im
Bereich der Kraftwerksplanung innerhalb des Gewerks
Elektrotechnik durchgeführt. Ziel der Studie war, die Anforderungen
an eine formale Beschreibung von Engineering
Workflows sowie an Workflow-Management-Systeme
für die Anlagenplanung zu erfassen und letztlich die Arbeitsabläufe
im Gewerk Elektrotechnik anhand der erfassten
Anforderungen formal zu dokumentieren.
2.1. Vorgehensmodell
Dabei kam das in Bild 1 gezeigte iterative Vorgehensmodell
zum Einsatz.
Nach diesem Vorgehensmodell wurde protokolliert, welche
Aktivitäten die Anlagenplanungs-Ingenieure in welcher
Reihenfolge ausführen (Schritt 1). Gleichzeitig wurden in
Interviews ihre Ideen und Anforderungen an eine informationstechnische
Arbeitsablaufunterstützung aufgenommen.
Aus diesen Daten ließen sich im Schritt 2 die Anforderungen
an eine formale Notation für Engineering Workflows
sowie an Workflow-Management-Systeme in der Anlagenplanung
ableiten. Basierend auf den Anforderungen erfolgte
im Schritt 3 der Entwurf einer formalen Notation für
Engineering Workflows und die Dokumentation der im ersten
Schritt erfassten Arbeitsabläufe mit Hilfe dieser formalen
Notation. Schließlich wurden in Schritt 4 die erarbeiteten
Ergebnisse gemeinsam mit den Ingenieuren evaluiert.
Dort wo die Ergebnisse nicht zufriedenstellend waren, erfolgte
eine Iteration der ersten 4 Schritte. Auch Theißen [10]
erwähnt, dass Workflows dieser Komplexität in iterativen
Interviews erstellt werden müssen. Zum Schluss war es in
Schritt 5 möglich, aus den dokumentierten Arbeitsabläufen
ein Objektmodell zu generieren, welches sich informationstechnisch
nutzen lässt. Die Ergebnisse der Schritte 2 und 3
werden nachfolgend erläutert.
2.2.Anforderung an die Formalisierung
Durch die Interviews mit Ingenieuren und die Mitarbeit
in Anlagenbauprojekten (Schritt 1 des Vorgehensmodells
in Bild 1) ließen sich die wesentlichen Eigenschaften von
Engineering Workflows herausarbeiten. Werden diese den
Eigenschaften von Business Workflows gegenüber gestellt,
lassen sich grundsätzliche Unterschiede zwischen beiden
Arten von Arbeitsabläufen erkennen. Diese sind in Tabelle
1 festgehalten.
Wie Tabelle 1 in der Eigenschaft „Wertschöpfung“
zeigt, haben Engineering Workflows grundsätzlich ein
anderes Ziel als Business Workflows. Bei Business
42
atp edition
9 / 2011
Schritt 2:
Ableitung von
Anforderungen an die
formale Notation von
Engineering Workflows
Start
Schritt 1:
Mitarbeit in
Anlagenbauprojekten und
Interviews mit
Ingenieuren
Schritt 3:
Entwurf formaler Notation
und Dokumentation der
Engineering Workflows
Dokumentation
unvollständig
Schritt 4:
Evaluierung mit
Ingenieuren
Dokumentation
vollständig
Schritt 5:
Erstellung eines
Objektmodells für
Engineering Workflows
Ende
BILD 1: Eingesetztes Vorgehensmodell
für die Formalisierung
von Engineering Workflows im
Gewerk Elektrotechnik
Eigenschaft Engineering Workflow Business Workflow
Wertschöpfung
Datenvollständigkeit
Komplexität
Parallelität
Iteration
Daten -
zugriff
Systemkopplung
Das Ziel des Arbeitsablaufes ist die Erzeugung
von konsistenten Planungsdaten für
die zu projektierende Anlage und die
iterative Steigerung der Qualität dieser
Daten (Datenzentrierung).
Aktivitäten eines Arbeitsablaufes müssen
bereits gestartet werden können, auch
wenn noch nicht alle notwendigen Eingangsdaten
zur Verfügung stehen.
Der Arbeitsablauf weist viele Aktivitäten
(> 100) und komplexe Abhängigkeiten
zwischen verschiedenen involvierten
Organisationseinheiten auf.
Die parallele Ausführung von möglichst
vielen Aktivitäten ist ein Hauptprinzip in der
Anlagenplanung um eine kurze Abwicklungszeit
zu erreichen.
Durch Änderungen in den Planungsdaten
können Iterationen häufig und an jeder
Stelle im Arbeitsablauf auftreten. Die
explizite Modellierung dieser Iterationen ist
auf Grund der großen Zahl nicht möglich.
Mehrere Aktivitäten müssen gleichzeitig auf
die gleichen bzw. Kopien der gleichen Daten
zugreifen und evtl. bearbeiten.
Für die Durchführung von Aktivitäten eines
Arbeits ablaufs sind unterschiedliche
Softwarewerkzeuge notwendig, z.B.
CAD-Systeme, Office-Systeme, Simulationssysteme,
etc.
Das Ziel des Arbeitsablaufes ist die korrekte
zeitlich-logische Bearbeitung der im
Arbeitsablauf enthaltenen Aktivitäten
(Aktivitätszentrierung).
Aktivitäten arbeiten nur mit vollständigen
Daten bzw. starten erst, wenn die Eingangsdaten
vollständig sind.
Der Arbeitsablauf weist typischerweise
weniger als 20 Aktivitäten auf und nur
wenige Abhängigkeiten zwischen verschiedenen
Organisationseinheiten.
Die parallele Ausführung von Aktivitäten
ist prinzipiell möglich, wird aber in der
Praxis nur sehr sparsam eingesetzt.
Sequentielle Abfolgen von Aktivitäten
werden bevorzugt.
Iterationen treten sehr selten auf. Wenn
Iterationen vorgesehen sind, werden sie
explizit modelliert.
Zu einem bestimmten Zeitpunkt greift in der
Regel nur eine Aktivität auf einen bestimmten
Datensatz zu.
Der Arbeitsablauf wird in einem Workflow
Management System modelliert und
ausgeführt. Andere Systeme
sind nicht notwendig oder erwünscht.
TABELLE 1: Gegenüberstellung der Eigenschaften von Engineering Workflows und Business
Workflows. Die weiß hinterlegten Eigenschaften haben Auswirkungen auf die formale Notation
von Arbeitsabläufen, die grau hinterlegten Eigen schaften sind für die Implementierung einer
informationstechnischen Unterstützung von Arbeitsabläufen von Bedeutung.
atp edition
9 / 2011
43
Hauptbeitrag
Workflows steht die Abarbeitung der entsprechenden
Aktivitäten in einem exakt vordefinierten Arbeitsablauf
im Vordergrund. Nach einer Diskussion in den
1990er-Jahren [12] sind in Business Workflows heute
die entstehenden Daten von untergeordneter Bedeutung
beziehungsweise dokumentieren lediglich den
Ablauf der Aktivitäten. Bei Engineering Workflows
hingegen steht die Erhöhung der Qualität oder Detaillierung
der Planungsdaten im Vordergrund, wie, beziehungsweise
durch welche Aktivität dies geschieht
ist von untergeordneter Bedeutung.
Betrachtet man weiter die Eigenschaften „Datenvollständigkeit“
und „Iterationen“, so lässt sich erkennen,
dass ein Engineering Workflow einen kreativen Prozess
beschreibt, was die Anlagenplanung schließlich auch
ist. Dahingegen ist ein Business Workflow ein vollständig
vordefinierter administrativer Prozess.
Weitere wichtige Unterschiede finden sich in den Eigenschaften
„Komplexität“ und „Parallelität“. Engineering
Workflows sind erwartungsgemäß komplexer mit verschiedenen
Organisationseinheiten verbunden als Business
Workflows, da die Planung einer Anlage ein umfangreicher,
stark arbeitsteiliger und zeitaufwändiger Prozess ist. Zudem
wird in der Anlagenplanung Wert auf eine starke Parallelisierung
gelegt, denn somit lässt sich die Abwicklungszeit
wirksam verkürzen. Dieses Mittel wird bei Business Workflows
in der Praxis vermieden, was sich auf Grund der geringeren
Komplexität auch leicht umsetzen lässt.
Bedingt durch die Unterschiede in der Eigenschaft
„Parallelität“, existieren auch Unterschiede hinsichtlich
der Eigenschaften „Datenzugriff“ und „Systemkopplung“
zwischen Engineering und Business Workflows.
Die Modellierung und Ausführung von Business Workflows
erfolgt zentral in einem Workflow-Management-
System. Alle Daten und Funktionen werden von ihm zur
Verfügung gestellt und es kontrolliert, dass zu jedem
Zeitpunkt nur jeweils ein Benutzer für eine bestimmte
Manipulation auf die Daten zugreifen kann. Dagegen
werden für Engineering Workflows viele auf eine Aufgabe
spezialisierte Softwarewerkzeuge eingesetzt, auch
wenn in den letzten Jahren immer mehr Firmen versuchen,
auf ein zentrales Engineering Framework mit zentraler
Datenhaltung zu setzen. Außerdem müssen aufgrund
der starken Parallelisierung mehrere Benutzer
gleichzeitig auf die Daten zugreifen und sie auch möglicherweise
ändern können.
Die vorgestellten Eigenschaften lassen sich in zwei
Kategorien einteilen: Eigenschaften, die sich direkt auf
die formale Notation auswirken (in Tabelle 1 weiß hinterlegt)
und Eigenschaften, die sich auf die Implementierung
einer informationstechnischen Unterstützung
der Arbeitsabläufe auswirken (in Tabelle 1 grau hinterlegt).
Hierbei sticht die Eigenschaft „Iteration“ hervor.
Iterationen werden bei Business Workflows immer explizit
modelliert und sind somit Bestandteil der Notation.
Bei Engineering Workflows sind Iterationen nicht
Bestandteil der Notation, stattdessen sind sie in der
Implementierung zu berücksichtigen. Dieser Unterschied
ist darin begründet, dass in Engineering Workflows
Iterationen praktisch an jeder Stelle auftreten
können und es aufgrund derer Komplexität praktisch
unmöglich ist, alle Iterationen explizit zu modellieren.
Petrinetz
VKD
EPK
BPMN
BILD 2: Darstellungen sieben gebräuchlicher Notationen für Business Workflows.
VT -Ingenieure
Vorstudie
Techniker
44
atp edition
9 / 2011
Basic Engineering
Verfahrensfließbild
Aus den vier Eigenschaften, die sich auf eine formale
Notation von Engineering Workflows auswirken, lassen
sich nun Anforderungen formulieren (Schritt 2 des Vorgehensmodells
in Bild 1). Diese sind:
Eigenschaft „Wertschöpfung“: Die Notation muss
eine starke Datenzentrierung aufweisen und dabei
vor allem eine iterative Verfeinerung der Planungsdaten
berücksichtigen.
Eigenschaft „Datenvollständigkeit“: Die Notation muss
ein Element enthalten, welches es erlaubt, eine Aktivität
zu starten, auch wenn noch nicht alle Daten zu ihrer
vollständigen Bearbeitung zur Verfügung stehen.
Eigenschaft „Komplexität“: Die Notation muss für
die Domäne Engineering optimiert sein und die vorhandene
Komplexität übersichtlich darstellen.
Eigenschaft „Parallelität“: Die Notation muss eine
Parallelisierung von Teilarbeitsabläufen effektiv
unterstützen.
3.Formale Notation von Engineering Workflows
Aus den im vorhergehenden Abschnitt ermittelten Eigenschaften
von Engineering Workflows lässt sich eine formale
Notation ableiten (Schritt 3 des Vorgehensmodells
in Bild 1). Hier ist es jedoch sinnvoll, nicht gleich eine
völlig eigene Notation zu entwickeln, sondern zunächst
zu untersuchen, welche Notationen für Business Workflows
bereits existieren. Diese lassen sich möglicherweise
für die Belange von Engineering Workflows adaptieren.
Daher werden zunächst gebräuchliche Notationen vorgestellt,
um daraus anschließend eine für den in Abschnitt
2 vorgestellten Anwendungsfall „Elektrotechnik in der
Anlagenplanung“ geeignete Notation abzuleiten.
3.1. Gebräuchliche Notationen für Business Workflows
Bild 2 zeigt eine Übersicht von sieben gebräuchlichen
Notationen für Workflows: Petrinetz, Vorgangskettendiagramm
(VKD), (erweiterte) ereignisgesteuerte Prozesskette
(EPK), Business Process Modelling Notation
(BPMN), Flussdiagramm oder Programmablaufplan
(FD), UML Aktivitätsdiagramm (UML 2.0 AD) sowie
Koordination, Kooperation & Kommunikation (K3).
Nicht alle sind im engeren Sinne für Business Workflows
konzipiert, wie zum Beispiel Petrinetz für technische
Prozesse oder K3 eher für schwach strukturierte
Arbeitsprozesse [11].
Die wesentlichen Elemente jeder Notation sind Aktivitäten/Aktionen
und (oft optional) Objekte. Über gerichtete
Verbindungen zwischen diesen Elementen entsteht
letztlich ein Fluss. Aktivitäten/Aktionen stellen Tätigkeiten
dar, die entweder von einem Menschen oder einem
Rechner ausgeführt werden können. Objekte stellen
Zustände oder Eingangs- und Ausgangsdaten von Aktivitäten
dar. Tabelle 2 zeigt, inwieweit jede der sieben
Notationen die in Abschnitt 2 beschriebenen Anforderungen
erfüllen.
Keine der untersuchten Notationen für Business
Workflows in Tabelle 2 weist ausschließlich grüne Fel-
Petrinetz
VKD VKD VKD
EPK EPK EPK
BPMN BPMN
VT -Ingenieure
VT -Ingenieure
Techniker
Techniker
Vorstudie
Vorstudie
Verfahrensfließbild
Verfahrensfließbild
Basic
Basic
Engineering
Engineering
Skizze
Skizze
R&I
R&I
Prozessdaten
R&I Prozess-
festlegen
R&I
skizzieren
skizzierendaten
festlegen
Skizze
Skizze
R&I mit
R&I mit
Prozessdaten
Prozessdaten
R&I
R&I
zeichnen
zeichnen
...
...
R&I V1
R&I V1
Flussdiagramm UML UML UML 2.0 2.0 2.0
Aktivitätsdiagramm
K3
K3
atp edition
9 / 2011
45
Hauptbeitrag
der auf. Damit erfüllt auch keine Notation die Anforderungen
von Engineering Workflows in ausreichendem
Maße, was auch Killich [9] bereits für UML gezeigt hat.
Deshalb ist es erforderlich, eine eigene Notation zu entwickeln
beziehungsweise die existierenden Notationen
um die fehlenden Punkte zu erweitern. Im Rahmen
dieser Studie wurde somit eine eigenständige Notation
entwickelt, die sich aber an den untersuchten Notationen
orientiert.
3.2. Notation für Engineering Workflows
Die für Engineering Workflows entwickelte Notation
hat zum Ziel, mit möglichst wenigen Elementen alle
Anforderungen an die Modellierung zu erfüllen. Tabelle
3 enthält eine Übersicht über die verwendeten
Notationselemente, die zum großen Teil aus den im
vorhergehenden Abschnitt vorgestellten Notationen
entnommen sind. Die auf diesen Elementen basierende
Notation für Engineering Workflows wurde gemäß
dem Vorgehensmodell (Schritt 3 in Bild 1) genutzt,
um reale Engineering Workflows zu dokumentieren
und somit die Notation auf Vollständigkeit zu überprüfen.
Bild 3 zeigt exemplarisch dafür einen Auszug
aus der Dokumentation des Planungsablaufs für eine
Anlage zur unterbrechungsfreien Stromversorgung
(USV-Anlage) für ein Kraftwerk aus dem Gewerk
Elektrotechnik.
Um der Datenzentrierung von Engineering Workflows
gerecht zu werden, verlangt die Notation eine strenge
alternierende Abfolge von Objekten und Aktivitäten.
Somit stellen Objekte immer Eingangsdaten und Ergebnisse
von Aktivitäten dar. Aktivitäten werden dabei als
Rechtecke mit gerundeten Ecken dargestellt, Objekte
existieren in dreierlei Ausprägungen:
Wertschöpfung
Iterative Datenverfeinerung
Datenvollständigkeit
Komplexität
Parallelität
Datenzentrierung
Aktionsbeginn
mit unvollständigen
Daten
Für Menschen
optimierte
Darstellung
Spezialisierte
Objektmodellierung
Übersichtliche
und einfache
Darstellung
Flussdiagramm VKD UML2.0 - AD K3 EPK
Objekte (außer
Variablen)
werden nicht
modelliert
Nicht
vorgesehen
Nicht
vorgesehen
Abbildung von
auf Computern
ausführbaren
Algorithmen
Hardware fehlt
Explizite
Modellierung
von Verzweigungen
im Fluss
Fluss findet
ausschließlich in
Funktionsspalte
statt. Daten
(Dokumente)
werden jedoch
standardmäßig
mit den Funktionen
verknüpft
Kontrollfluss findet
nur zwischen
Aktionen statt.
Objektknoten sind
gebräuchlich,
sodass alternativ
auch Objektflüsse
modelliert werden
können
Der Kontrollfluss
verbindet ausschliesslich
Funktionen
miteinander.
Objekte im
Informationsfluss
sind möglich aber
optional
Streng alternierender
Fluss zwischen
Aktionen und
Zuständen - optionale
Modellierung
weiterer Objekte
(Dokument,
Datenspeicher)
Nicht vorgesehen Nicht vorgesehen Nicht vorgesehen Nicht vorgesehen
Aktionen starten
nur sequenziell
– keine Aussage
über Dokumentenzustand
System zur
Darstellung von
Geschäftsprozessen
einer
Organisation
Spalte: Daten
(jedoch nicht
spezialisiert)
Darstellung von
Parallelitäten ist
sehr unübersichtlich
Nicht vorgesehen Nicht vorgesehen Nicht vorgesehen
Graphische
Repräsentation von
Arbeitsabläufen. In
erster Linie wird
der Kontrollfluss
abgebildet
Kein spezieller
Objekttyp ist
ausgezeichnet
Modellierung über
„split“ und „join“
Elemente
Ziel ist es, den
Anwendern einen
Überblick über
komplexe
Arbeitsprozesse
zu geben.
Kein spezieller
Objekttyp ist
ausgezeichnet.
Parallelitäten
benötigen
Synchronisationsbalken
Modellierung von
Geschäftsprozessen
mit Problemen
bei Abbildung
kreativer & komplexer
Tätigkeiten
Hardware fehlt
Nur ein Eingangspfeil
zu einer Aktion.
TABELLE 2: Zu jedem der geforderten Anforderungen aus Abschnitt 2 (links) wird die Mächtigkeit gebräuchlicher
Notationen für Business Workflows (oben) analysiert. Die Farbkodierung reicht von Rot (Möglichkeiten fehlen) über
Gelb (teilweise Unterstützung) bis Grün (gute Unterstützung). Die Gründe sind als Text angegeben.
46
atp edition
9 / 2011
Dokumentsymbol: Dokumente und Dateien, die zwischen
verschiedenen Organisationseinheiten ausgetauscht
werden können.
Datenbanksymbol: Datenmodelle der Anlage oder
von zu bestellenden Ausrüstungsgegenständen, die
in Softwarewerkzeugen abgelegt sind und an denen
mehrere Organisationseinheiten gleichzeitig arbeiten
können.
Hardwaresymbol (Würfel): reale Hardware wie zum
Beispiel ein Schaltschrank oder Rechner.
Alle Typen von Objekten verfügen über eine Unterteilung
in mehrere aufeinander aufbauende Status,
die den Detaillierungsgrad der Objekte modellieren.
Die in Bild 3 eingezeichnete orange-farbige Umrandung
kennzeichnet beispielsweise das Datenmodell
einer USV („Comos DB Compact UPS“) in verschiedenen
Status beziehungsweise Detailierungsstufen
Petrinetz
Konnektoren verbinden
immer Transitionen
(Aktionen) und
Zustände - bei attributierten
PN können die
Konnektoren Objekte
transportieren
Modellierbar über
mehrere Tokens
Möglich aber nicht
übersichtlich durch die
Verwendung mehrerer
Tokens
PNs sollen auf
Computern ausführbare
Algorithmen
abbilden und sind nicht
für Menschen optimiert
Attribute von Konnektoren
sind unspezifisch
Nebenläufigkeit ist
wichtig – Verzweigungen
im Fluss
sind platzsparend
darstellbar
BPMN
„Sequence Flow“
verbindet nur
Aktivitäten. Diese
können mit Objekten
verknüpft werden,
aber nur 25 % der
Benutzer nutzen
diese Möglichkeit [8]
Nicht vorgesehen
Vorherige Aktion
muss abgeschlossen
sein
BPMN dient zur
Modellierung von
Geschäftsprozessen
und Arbeitsabläufen
gerade auch für
Menschen
Dokument, Datensatz
und physisches
Objekt
Events unterstützen
Parallelitäten
wie zum Beispiel „For Cable Sizing“. Der Statusname
ist dabei kursiv im Symbol eingetragen. Hat ein Objekt
nur einen einzigen Status, so wird dieser nicht
in der Grafik dargestellt. Status wurden eingeführt,
um eine möglichst starke Parallelisierung des Arbeitsablaufs
zu unterstützen. Die Status sind so gewählt,
dass die in jedem Status enthaltenen Informationen
ausreichen, um möglichst viele parallele Aktivitäten
starten zu können. Dies ist letztlich das
Kriterium, welches zu der in Bild 3 gezeigten Granularität
der Modellierung führt.
Aktivitäten und Objekte sind über gerichtete Kanten
miteinander verbunden. Von diesen Kanten gibt es drei
Arten, die über die Pfeilspitzen zu unterscheiden sind
und deren Bedeutung in Tabelle 4 wiedergegeben ist.
Die Arten der Kanten erlauben es der Modellierung,
die Fortsetzung des Arbeitsablaufs mit nur unvollständigen
Daten darzustellen. Ein oft auftretendes Beispiel
für diesen Fall ist die Vorabbestellung von elektrotechnischen
Ausrüstungsgegenständen, wie zum Beispiel
Transformatoren, bevor die dafür notwendige technische
Spezifikation vollständig ist. Somit wird im Falle
langer Lieferzeiten sichergestellt, dass die Ausrüstung
noch während der Projektlaufzeit angeliefert
werden kann.
Entscheidungen und Iterationen sind im Vergleich
zu den anderen Notationen aus Tabelle 2 nicht explizit
dargestellt, jedoch können letztere in jeder Aktivität
auftreten, wenn sich die Inhalte von den mit dieser
Aktivität verbundenen eingehenden Objekten ändern.
Alternative Fortsetzungen des Arbeitsablaufs, Pfade,
sind allerdings modellierbar und in Bild 3 über die
Kantendarstellung visualisiert. Der Standardpfad ist
durch durchgehende Kanten gekennzeichnet, alternative
Pfade durch gestrichelte. Die alternativen Pfade
müssen an deren ersten Kante durch Bedingungen annotiert
werden, die erfüllt sein müssen, damit dieser
Pfad gewählt werden kann. Sind diese Bedingungen
nicht erfüllt, wird der Arbeitsablauf über den Standardpfad
fortgesetzt.
Die weiteren Notationselemente wurden unverändert
aus einzelnen existierenden Notationen übernommen:
Mit Hilfe der Schwimmbahnen lassen sich, wie auch
in BPMN oder UML 2.0 Aktivitätsdiagramm, Verantwortlichkeiten
zwischen verschiedenen in den Arbeitsablauf
involvierten Organisationseinheiten trennen
(unterschiedlich gefärbte Bereiche in Bild 3). Die
Schwimmbahnen lassen sich in beliebiger Tiefe ineinander
verschachteln.
Die verbliebenen Elemente Start- und End-Knoten,
Verweise, Kommentare sowie die Möglichkeit zur hierarchischen
Strukturierung sind auch in anderen Notationen
gebräuchlich und werden wie in Bild 3 abgebildet
dargestellt.
Mit diesen wenigen Notationselementen können alle
Anforderungen an die Eigenschaften von Engineering
Workflows erfüllt werden. Allerdings erfolgt die Modellierung
von Engineering Workflows im Vergleich zu
Business Workflows auf einer anderen Abstraktionsstufe.
Der Hauptgrund dafür liegt in der Fokussierung auf
die auszutauschenden Daten und nicht auf die Aktivitäten,
Entscheidungen und Iterationen
Über die Darstellung der Notation hinaus wird aber
auch deutlich, dass Engineering Workflows einen anderen
Charakter besitzen als Business Workflows. Auf
atp edition
9 / 2011
47
Hauptbeitrag
Tabelle 3: Übersicht über die verwendeten Notationselemente. Die Erweiterungen
Tabelle gegenüber den existierenden Notationen für Business Workflows betreffen die
3:
ersten vier 3: Übersicht über
Einträge: über die
Objekt, die verwendeten
Status, Notationselemente.
Aktivität Die
und Datenfluss. Die Erweiterungen
Tabelle
gegenüber 3: Übersicht
den
den existierenden über die verwendeten
Notationen für
für Notationselemente.
Business Workflows Die Erweiterungen
betreffen die
die
Notations- Tabelle Notationselement
Notations-
Erläuterung
gegenüber
gegenüber
ersten vier
vier Einträge:
3: Übersicht den existierenden
Objekt,
über Status,
Symbol die verwendeten Notationen
Aktivität für
und
Notationselemente. und Business Verknüpfte
Datenfluss.
Workflows
Verknüpfte Die Erweiterungen
betreffen die
element
Symbol
Erläuterung
Tabelle ersten vier 3: Übersicht Einträge: den existierenden über Objekt, die Status, verwendeten Notationen
Aktivität
für Notationselemente. und Business Eigenschaft
Datenfluss.
Die Erweiterungen
Tabelle Verknüpfte
3: Übersicht über Symbol die verwendeten Notationselemente. Eigenschaft Workflows betreffen die
Die Erweiterungen
Notations-
gegenüber ersten vier Einträge: den existierenden Objekt, Erläuterung
element
Status, Notationen Aktivität für und Business Datenfluss.
Workflows betreffen die
Objekt gegenüber den existierenden Notationen für Wertschöpfung
Wertschöp-
Eigenschaft
Verknüpfte
Datenfluss. (Daten-
deren Es Instanzen gibt explizit reale Dokumente Typen / Dateien, von Objekten, Da-
Eigenschaft
Business Verknüpfte
Wertschöpfung
Workflows Es gibt betreffen explizit die verschiedene Typen von Objekten,
ersten vier Einträge: Objekt, Symbol Status, Aktivität und Datenfluss. Erläuterung
Notationselemenzentrierung),
Symbol
Wertschöpfung
Eigenschaft tenmodelle oder Hardware beschreiben. (Datenelement
ersten vier Einträge: Objekt, Status, Aktivität und Objekt
deren Instanzen reale Dokumente / Dateien,
Notationselement
Symbol
Datenmodelle oder Hardware beschreiben.
Symbol
Es Verknüpfte Erläuterung
gibt explizit verschiedene Typen von Objekten,
Notationselement
Wertschöp-
Verknüpfte
Erläuterung
Es deren gibt Instanzen explizit verschiedene reale Dokumente Typen / Dateien, von Objekten, Datenmodelle
Instanzen oder verschiedene
Objekt
Komplexität
fung zentrierung),
Eigenschaft Erläuterung
Eigenschaft Es
sind
gibt
weiß
explizit
hinterlegt.
Objekt
(Datenzentrierung),
Komplexität Es gibt explizit verschiedene Typen von Objekten,
deren Hardware reale Dokumente beschreiben. Typen / Dateien, von Objekten,
Objekte
Da-
Objekte sind weiß hinterlegt.
Wertschöp-
Wertschöpfunzentrierung),
Parallelität,
Komplexität (Daten-
deren
fung
Objekt
(Daten-
Es deren Jedes tenmodelle sind weiß
gibt Instanzen hinterlegt.
explizit oder kann Hardware
verschiedene reale zusätzlich Dokumente beschreiben. verschiedene
Typen / Dateien, Zustände
sind Jedes Instanzen (Status)
von Objekten, Datenmodelle
Status fung
Parallelität,
Jedes Objekt kann zusätzlich Objekt
(Datenzentrierung),
Komplexität
Wertschöp-
Parallelität, tenmodelle
deren Instanzen oder annehmen, Hardware reale Dokumente
reale Dokumente beschreiben. die / Detaillierungsgrad
weiß hinterlegt. wiederspiegeln oder Hardware und beschreiben. in kursiv angemerkt Objekte
Jedes stände Objekt (Status) oder
Dateien, Da-
weiß Objekt hinterlegt. kann zusätzlich verschiedene Dateien, Objekte Zu-
Objekt Status
Dazentrierung),
Wertschöpfung
Zustände (Status) annehmen, die den tenmodelle sind kann annehmen, Hardware
zusätzlich die
beschreiben. verschiedene Detaillie-
Objekte
Zuständrungsgrad
(Status) wiederspiegeln annehmen, und die in kursiv
Status
Detaillie-
Komplexität
fung
rungsgrad Komplexität sind Jedes
sind. weiß Standardmäßig
weiß Objekt
hinterlegt.
hinterlegt. kann wiederspiegeln zusätzlich
besitzt jedes
verschiedene
Objekt genau
Parallelität,
Wertschöp-
und Detaillierungsgrad
sind. Standardmäßig Objekt
angemerkt
in kursiv Zustände
angemerkt
Status
Parallelität,
Wertschöpfunständfung
Jedes
sind. Standardmäßig besitzt jedes Objekt Jedes
einen Status.
Objekt (Status) wiederspiegeln kann
kann annehmen, zusätzlich besitzt
zusätzlich und die
jedes verschiedene in
verschiedene kursiv Objekt Detaillierungsgrad
Jede sind. einen Standardmäßig Aktivität Status.
(Status)
angemerkt genau
Zu-
Zustände
genau
Status
Parallelität,
einen Status.
Parallelität,
Wertschöpfunrungsgrad
(Status) wiederspiegeln erhält annehmen, Eingangsdaten besitzt
annehmen, und die jedes
die den
den kursiv Objekt Detaillie-
und
Detaillierungsgrad
sind. Ausgangsdaten. wiederspiegeln kursiv angemerkt
angemerkt erzeugt genau
Status
Wertschöp-
Status
Wertschöpfung
(Daten-
Jede Ausgangsdaten.
einen Jede
Standardmäßig Eingangswiederspiegeln
besitzt und
und jedes Ausgangsdaten
Aktivität Status. erhält Eingangsdaten in kursiv Objekt
und erzeugt
angemerkt
genau
Aktivität
fung Wertschöpfung
sind. Jede Aktivität erhält Eingangsdaten und sind. einen werden Standardmäßig besitzt jedes Objekt genau
Aktivität
Standardmäßig Status. durch Objekte modelliert. Somit besteht
Aktivität erhält Eingangs- Eingangsdaten und
besitzt Ausgangsdaten
Wertschöpfung
(Daten-
Jede werden durch Objekte modelliert. Somit Jede Ausgangsdaten. werden der Abfolge Aktivität von erhält
jedes und erzeugt erzeugt
Objekt genau
(Daten-
einen Ausgangsdaten. einen Jede der Status.
zentrierung)
Ausgangsdaten. werden Engineering Aktivität Status. erhält Workflow Eingangsdaten Eingangs- aus einer und und alternieren-
Wertschöp-
durch Objekte Eingangs- modelliert. und Ausgangsdaten
Somit Ausgangsdaten
besteht
Aktivität
erzeugt
Aktivität erhält Eingangs- Objekten Eingangsdaten und
Eingangsdaten und Aktivitäten. Ausgangsdaten
und erzeugt Aktivitäten
der den sind
Aktivität
und erzeugt besteht der
Wertschöpfunzentrierung)
(Daten-
Engineering Abfolge von Workflow Objekten modelliert. aus und einer Aktivitäten. Somit alternieren-
besteht
fung (Daten-
Engineering durch Objekte Workflow modelliert. aus einer Somit alternierenzentrierung)
besteht
Ausgangsdaten. aus einer alternierenden
Wertschöpfung
(Daten-
werden der Ein täten durch modelliert. Somit besteht
Ausgangsdaten. werden durch
grau
Objekte
hinterlegt. Eingangs- Ausgangsdaten
Aktivität
Eingangs- und Ausgangsdaten
Wertschöpfunzentrierung)
Objekt Engineering Abfolge sind grau und von eine hinterlegt.
Workflow Objekten Aktivität aus und werden einer Aktivitäten. alternieren-
durch Aktivi-
eine
Aktivi-
werden und Aktivitäten
Aktivität
durch Objekte modelliert. Somit besteht
Aktivität
(Daten-
der sind grau hinterlegt.
zentrierung) der den gerichtete täten Ein Engineering
Engineering Abfolge Kante von Workflow
Workflow Objekten miteinander aus
aus und verbunden. einer
einer Aktivitäten. alternierenden
Abfolge von Objekten und Aktivitäten. Aktivi-
Von
alternierendetäten
gerichteten Ein Abfolge sind grau Kanten
Aktivi-
den
Objekt sind grau und eine hinterlegt. Aktivität werden durch eine
zentrierung)
Datenvollstän-
Datenfluss
Daten-
Ein Objekt
von hinterlegt. existieren drei Typen, unterschieden
Objekt durch sind grau und eine die miteinander Pfeilspitze,
Datenfluss
Objekt und eine miteinander
und
Objekten Aktivität werden verbunden.
eine Aktivität
und durch Von
Aktivitäten. eine den
werden durch
Aktividigkeit
Datenvollständigkeit
vollständigkeit gerichtete Kante miteinander verbunden. Von den
Ein Objekt und eine Aktivität werden durch eine
eine
täten sind grau hinterlegt.
täten Ein hinterlegt. Aktivität werden verbunden. deren durch Bedeutungen
gerichteten in
Von eine den
gerichteten Kanten existieren drei Typen, unterschieden
durch die Pfeilspitze, deren Bedeutun-
Datenvollständigkeit
gerichteten Kante Kanten miteinander existieren verbunden. drei Typen, Von den unter-
gerichteten Tabelle schieden gen in
durch 4
Datenfluss
Datenvollstän-
Ein Objekt Kanten
und eine miteinander existieren
Aktivität werden verbunden. drei Typen,
durch Von unter-
eine den
Datenfluss
Kante Kanten beschrieben die
miteinander existieren Pfeilspitze, sind.
verbunden. drei deren Typen, Bedeutungen
Standardpfad in
Von unterschieden
Der
Datenfluss
den
schieden durch die Pfeilspitze, deren Bedeutungen
Datenvollstän-
gerichteten Kanten existieren drei Typen, unter-
Datenfluss
Datenvollständigkeischiedegen
Kante Tabelle Der in dargestellt. durch 4 beschrieben die Ausgehend Pfeilspitze, sind. von deren einem Bedeutun-
Standigkeit
gerichteten Kanten existieren drei Typen, unter-
Datenfluss
Tabelle 4 beschrieben sind.
digkeit
schieden Tabelle durch durch 4 beschrieben die wird Pfeilspitze, immer sind.
die Pfeilspitze, mit deren durchgezogener
Bedeutun-
deren Bedeutungen
Standardpfad wird in
immer mit durchgezogener
gen Tabelle dardpfad
Alternative
Daten-
Datenvollständigkeit,
Kante dardpfad durch eine gestrichelte
Der Kante in Der Standardpfad
kann 4 beschrieben ein alternativer
wird sind. immer
Pfad
mit
abzweigen,
Standardpfad dargestellt. Ausgehend wird immer mit von durchgezogener
einem Stan-
durchgezogener
Alternative
Pfade
vollständigkeit,
Kante dargestellt. Ausgehend Tabelle
Tabelle
Der der Standardpfad beschrieben sind.
beschrieben wird immer Kante
sind. mit symbolisiert
dargestellt. kann ein Ausgehend alternativer von Pfad durchgezogener
einem abzweigen,
Datenvollständigkeit,
abzweigen, der
von einem Standardpfad
der
Standard-
Alternative Pfade
Der Standardpfad wird immer mit
Pfad durchgezogener
Der Kante wird. Jeder
Standardpfad dargestellt. alternative Ausgehend Pfad muss
wird immer mit von zu
durchgezogener
einem seinem Standardpfad
Be-
Komplexität
Datenvollstän-
durch kann eine gestrichelte ein alternativer Kante Pfad symbolisiert
Alternative Pfade
Kante
durch dargestellt.
eine gestrichelte Ausgehend
Kante von einem
symbolisiert Standardpfad
Datenvollstän-
Jeder kann
Datenvollständigkeit,
Komplexität
mit Jeder einer alternative Bedingung Pfad annotiert muss zu sein, seinem die erfüllt
Be-
der durch einer Bedingung gestrichelte
Kante
ginn mit einer
dargestellt. kann
Bedingung
ein Ausgehend alternativer
annotiert
von Pfad
sein,
einem abzweigen,
die erfüllt
der wird.
digkeit,
durch Jeder alternative gestrichelte Pfad Kante muss symbolisiert
zu seinem Beginn
Komplexität
Stan-
wird.
Alternative Pfade
alternative ein alternativer muss Pfad
zu abzweigen,
dardpfad der
sein wird. durch
muss,
kann um
gestrichelte
diesen ein alternativer Kante
zu wählen.
Pfad symbolisiert
Andernfalls
abzweigen, seinem Beginn mit
Alternative
Datenvollständigkeit,
Komplexität
muss, mit einer um Bedingung diesen Pfad annotiert zu wählen. sein, Andernfalls
die erfüllt
wird. muss, Jeder
annotiert Kante
sein, symbolisiert
Alternative Pfade
digkeit, der wird.
wird ginn sein der
durch Jeder
Standardpfad
eine alternative gestrichelte gewählt.
Kante muss symbolisiert
zu die seinem erfüllt Beginn
Trennung sein muss, mit Jeder einer
sein
Pfade
um alternative
diesen zu muss
wählen. zu seinem
Andernfalls Beginn
Pfade
Komplexität wird.
Standardpfad der um
alternative Bedingung Verantwortlichkeiten diesen Pfad gewählt.
Pfad annotiert zu wählen.
muss zu sein, zwischen Andernfalls
seinem die erfüllt verschiedenen
wird Trennung
Schwimmbahn
Parallelität
Be-
Komplexität,
wird
der mit einer
Standardpfad Bedingung
gewählt.
annotiert sein, die erfüllt
ginn sein muss, mit einer um den
Bedingung diesen Arbeitsablauf Pfad annotiert zu wählen. involvierten
sein, Andernfalls Or-
der Standardpfad der Verantwortlichkeiten gewählt. zwischen verschiedenen
der in Verantwortlichkeiten den Arbeitsablauf involvierten
die erfüllt
Schwimm-
sein muss, um diesen Pfad zu wählen. Andernfalls
sein wird ganisationseinheiten. der muss, Standardpfad Diese
um diesen Pfad gewählt. können verschieden
Komplexität,
Trennung
zu wählen. zwischen Organisationseinheiten.
Arbeitsablauf Diese können
Andernfalls
verschiedenen
hinterlegt
Schwimm- Schwimmbahn
Komplexität,
wird Trennung der Standardpfad der gewählt.
wird Trennung farbig
der Standardpfad der Verantwortlichkeiten den sein.
Parallelität
gewählt.
involvierten zwischen
verschieden
zwischen Organisationseinheiten.
farbig hinterlegt der in Verantwortlichkeiten von sein.
Arbeitsablauf Start Diese und können Ende involvierten eines verschieden Arbeits-
verschiedenen
Kennzeichnung bahnSchwimm-
bahn
Komplexität,
Parallelität schiedenen ablaufs.
/
farbig Kennzeichnung hinterlegt von sein.
Start /
Komplexität,
Trennung verschiedenen der Verantwortlichkeiten in den Arbeitsablauf zwischen involvierten
ver-
Parallelität
Trennung zwischen Or-
ver-
Schwimmbahn
/
Parallelität
ganisationseinheiten. farbig hinterlegt sein.
Diese können verschieden
bahn
Parallelität ganisationseinheiten. farbig Mit Kennzeichnung ablaufs. Hilfe hinterlegt von Verweisen von sein. Start lassen und Ende sich Verbindungen
eines Arbeits-
Start Ende
Komplexität,
schiedenen Organisationseinheiten. den Arbeitsablauf Diese involvierten können verschieden
Or-
Schwimm-
in den Start
Arbeitsablauf Diese
und können
Ende eines
involvierten verschieden
Arbeits-
Or-
Start Ende
Diese können verschieden
Verweis Start Ende /
Komplexität
Komplexität
Start / Ende farbig
Kennzeichnung hinterlegt sein.
farbig Kennzeichnung zwischen ablaufs. Mit Teilarbeitsabläufen
hinterlegt von sein. Start und herstellen, Ende eines die Arbeits-
von Start und Ende
Start /
Hilfe von Verweisen lassen sich Verbindungen
Verweis
Kennzeichnung eines Arbeitsablaufs.
von Start und Ende eines Arbeitsablaufs.
Start Ende
Kennzeichnung ablaufs. verschiedenen Mit Hilfe von Verweisen Diagrammen lassen dokumentiert sich Verbindungen sind.
Komplexität
zwischen Teilarbeitsabläufen herstellen,
von Start und die
Ende eines Arbeits-
Verweis
Ende
Komplexität
Ende
ablaufs. Mit Kommentare zwischen verschiedenen Hilfe von Teilarbeitsabläufen Verweisen zu Diagrammen einzelnen lassen Objekten dokumentiert herstellen, sich Verbindungen
oder die Aktivitäten
verschiedenen Kommentare bestehen
sind.
Verweis
Kommentar
Komplexität
zwischen
Verweis
Mit Hilfe Mit Hilfe von Verweisen von Verweisen lassen lassen sich sich Verbindungen
Komplexität Mit zwischen Hilfe von Teilarbeitsabläufen aus Diagrammen einem gelb dokumentiert
Verweisen lassen herstellen, hinterlegten
sich Verbindungen Verbindungen
die Recht-
zu einzelnen Objekten oder Aktivitä-
sind.
Kommen-
Verweis
zwischen Teilarbeitsabläufen herstellen,
herstellen, die Verweis
zwischen verschiedenen eck.
Kommentare ten bestehen zu aus
Teilarbeitsabläufen Diagrammen einzelnen einem gelb Objekten dokumentiert
hinterlegten oder Aktivitäteeck.
bestehen zu aus
herstellen, Recht-
Komplexität
die sind.
die in
Kommentar
Kommentare zu einzelnen Objekten oder Aktivitätar
verschiedenen Diagrammen dokumentiert sind.
Komplexität verschiedenen Kommentare Diagrammen einzelnen einem gelb Objekten hinterlegten
dokumentiert oder Aktivitäten
Jede eck. bestehen Aktivität
Recht-
sind. sind.
Kommen-
Kommentar Kommentare Kommentare zu aus kann
einzelnen einem prinzipiell gelb aus
zu einzelnen Objekten hinterlegten Unteraktivitäten
Objekten oder oder Aktivitäteeck.
aufgebaut Jede sein. Ebenso können beliebige Aktivitä-
Aktivität
Recht-
Hierarchie Kommentar
Komplexität
eck. ten hierarchisch zu einer übergeordneten zusam-
/
Komplexität
ten bestehen aus einem gelb hinterlegten Recht-
Kommen-
/
Komplexität bestehen kann
Aktivitäten
aus prinzipiell
bestehen
einem aus
gelb aus
hinterlegten Unteraktivitäten
Hierarchie einem gelb hinterlegten
Rechteck.
Unteraktivitar
Jede aufgebaut sein. kann Ebenso prinzipiell können aus beliebige Unteraktivitäten Aktivitä-
Hierarchie Unteraktivitätetäten
/
Jede
mengefasst aufgebaut Rechteck.
Aktivität sein. werden.
kann Ebenso prinzipiell
Dieses können wird
aus beliebige durch
Unteraktivitäten
ein Aktivitäten
hierarchisch
Hierar-
Komplexität
ten hierarchisch zu einer übergeordneten zusam-
Hierarchie Hierarchie Unteraktivitäten
Komplexität aufgebaut ten mengefasst chiesymbol hierarchisch
/ /
Komplexität
Komplexität
Jede
Jede Aktivität
Aktivität kann
kann prinzipiell
prinzipiell aus Unteraktivitäten
Jede aufgebaut
chiesymbol
Aktivität sein.
innerhalb
kann Ebenso zu einer der
prinzipiell können übergeordneten Aktivität
aus beliebige
dargestellt.
mengefasst werden. Dieses wird durch ein
Unteraktivitäten
aus Unteraktivitäten
zusam-
Aktivitä-
Hierar-
Unter-
Hierarchie /
aufgebaut
aufgebaut sein.
sein. Ebenso
Ebenso können
können beliebige
beliebige Aktivitäten
hierarchisch zu
Hierarchie Unteraktivitäten
Komplexität ten mengefasst chiesymbol innerhalb
innerhalb werden.
sein. Ebenso zu einer Dieses der können übergeordneten
Aktivität wird durch dargestellt. ein
beliebige zusam-
Hierar-
Aktivitä-
Aktivitäten
aktivitäten
Unteraktivi-
Komplexität
zu einer übergeordneten zusammengefasst
werden. Dieses wird durch ein Hierar-
Unteraktivitätemengefasschiesymbol
innerhalb werden. Dieses der Aktivität wird durch dargestellt. ein Hierar-
Hierarchiechiesymbol
innerhalb der Aktivität dargestellt.
hierarchisch werden. zu einer Dieses der Aktivität
übergeordneten wird durch dargestellt. ein zusam-
Hierar-
zusammentätechiesymbol
innerhalb der Aktivität dargestellt.
TABELLE 3: Übersicht über die verwendeten Notationselemente. Die Erweiterungen gegenüber den existierenden
Notationen für Business Workflows betreffen die ersten vier Einträge: Objekt, Status, Aktivität und Datenfluss.
48
atp edition
9 / 2011
Customer
Start
Customer
Specification
Requires
customer
approval
Working
schedule
Create component
model
For Power
Balance & SLD
COMOS DB
Compact UPS
For Power
Balance & SLD
Update SLD
visualization
COMOS DB
SLD
ABB Offer
Compare
customer
specs with offer
List of
deviations
Compact UPS
Single Line
Diagram
707.01 Single
Line Diagrams
Electrical Engineering
COMOS DB
Consumer
Basic
707.02 Load
List Handling
COMOS DB
Compact UPS
Power Balance
Calculate Load
Balance
Compact UPS
Estimate
dimensions,
weight, losses
Load Balance
Compact UPS
COMOS DB
Civil Data
Specify
Compact UPS
707.09 Civil
Input Data
Comp. ordered or
Comp. engineered
Cable List
Compact UPS
Basic
707.08 Cable
Handling
Tech. Spec .
Compact UPS
Inquiry
Tech. Spec .
Compact UPS
Change Order
With P.O.
for Design
732-1a Procurement
732-1b Procurement
732-2 Manufacturing
Create component
model
For Cable
Sizing
COMOS DB
Compact UPS
For Cable
Sizing
707.07 Cable
Sizing
COMOS DB
Compact UPS
For Detailed
Model
707.02 Load
List Handling
COMOS DB
Compact UPS
Detailed Model
7xx-3 Interface
Engineering
BILD 3: Auszug aus der Dokumentation des Arbeitsablaufs für die Planung einer USV-Anlage
mit Hilfe der neu entwickelten Notation für Engineering Workflows. Der genaue Inhalt ist im
Rahmen dieses Artikels nicht relevant. Die orange Markierung umfasst das Datenbankmodell
einer Kompakt-USV („Comos DB Compact UPS“) in 5 aufeinander aufbauenden Status.
belle 4: Bedeutung der verschiedenen Pfeilköpfe in der Notation von
belle gineering 4: Bedeutung Workflows der verschiedenen Pfeilköpfe in der Notation von
belle
gineering
4: Bedeutung
Workflows
der verschiedenen Pfeilköpfe in der Notation von
Ausgang einer Aktivität gineering sgang einer Workflows Aktivität Pfeilkopf Eingang einer Aktivität
s sgang einer Aktivität Das ausgehende Objekt
Pfeilkopf Es gibt Eingang explizit verschiedene einer Aktivität
sgang ausgehende einer Aktivität Objekt muss von Verpflichtend Pfeilkopf (gefüllter Pfeilkopf) Eingang Das eingehende einer Aktivität Objekt Typen ist von für
r Aktivität ausgehende bei jedem muss Objekt von Durchlauf muss der Aktivität von Verpflichtend (gefüllter Pfeilkopf) Objekten, Das den deren Start eingehende Instanzen der Aktivität Objekt reale erforderlich.
Start Datenmodelle der Aktivität oder erforder-
Hardware
Dokumente
/ Dateien, den
ist für
s ausgehende Objekt muss von Verpflichtend (gefüllter Pfeilkopf) Das eingehende Objekt ist für
llständig Aktivität als bei Ergebnis jedem bei jedem Durchlauf geliefert
r Aktivität bei jedem
llständig als Ergebnis vollständig Durchlauf
geliefert als Ergebnis
beschreiben. den Start der Aktivität erforderlich.
sind weiß hinterlegt.
rden.
lich.
llständig als Ergebnis
rden. geliefert geliefert werden.
Objekte
rden.
s ausgehende Objekt muss von Erforderlich (ungefüllter Pfeilkopf) Das eingehende Objekt ist für
r Aktivität ausgehende mindestens Das Objekt ausgehende einmal muss von vollndig
als Ergebnis geliefert werden.
Aktivität erforderlich, nicht je-der
r Aktivität mindestens
Objekt Erforderlich (ungefüllter Pfeilkopf) Jedes Das den Objekt erfolgreichen eingehende kann zusätzlich Objekt Abschluss verschiedene ist für der
s ausgehende Aktivität mindestens muss Objekt von muss
einmal der Aktivität von Erforderlich (ungefüllter Pfeilkopf)
vollndig
als Ergebnis mindestens einmal
Zustände Das
den (Status) eingehende
erfolgreichen annehmen, Objekt
Abschluss die den ist für
geliefert einmal vollndig
als Ergebnis vollständig geliefert als werden. Ergebnis
kursiv Aktivität
werden.
Detaillierungsgrad den erfolgreichen
Aktivität erforderlich, wiederspiegeln Abschluss
nicht und je-idoch
der
doch für den Start.
angemerkt erforderlich,
für den
sind.
Start.
Standardmäßig nicht jedoch
s ausgehende Objekt kann von Optional (Strichpfeilkopf)
geliefert werden.
besitzt
Das eingehende
jedes für Objekt den genau Start.
Objekt ist für
einen Status.
r Aktivität ausgehende als Ergebnis Objekt kann geliefert von Optional (Strichpfeilkopf)
Das die Aktivität eingehende nicht Objekt zwingend ist für
s ausgehende Aktivität als Ergebnis Das Objekt ausgehende kann von
geliefert Objekt Optional (Strichpfeilkopf) Jede Aktivität Das eingehende
die Aktivität erhält nicht Eingangsdaten Objekt ist
zwingend und für
rden.
erforderlich, muss jedoch berücksichtig
werden, wenn be-
es
r Aktivität als Ergebnis
rden. kann von geliefert der Aktivität
erzeugt die
erforderlich, Ausgangsdaten. Aktivität nicht
muss Eingangs- zwingend
jedoch und
rden. als Ergebnis geliefert
Ausgangsdaten erforderlich, werden muss durch jedoch Objekte berücksichtig
Somit besteht werden, der wenn Engineering es
rücksichtig werden, wenn es
werden.
modelliert.
vorkommt.
Workflow
vorkommt.
vorkommt. aus einer alternierenden Abfolge
von Objekten und Aktivitäten. Aktivitäten
sind grau hinterlegt.
TABELLE 4: Bedeutung der verschiedenen Pfeilköpfe in der Notation von Engineering Workflows
atp edition
9 / 2011
49
Hauptbeitrag
Grund des kreativen Charakters von Planungsprozessen
müssen auch weiterhin die Details, wie beispielsweise
bestimmte Aktivitäten durchzuführen sind, den Ingenieuren
überlassen werden.
4. Nutzen von Workflow-Management-Systemen
in der Anlagenplanung
Die im vorherigen Abschnitt vorgestellte Notation für Engineering
Workflows lässt sich in ein informationstechnisch
nutzbares Objektmodell umwandeln (Schritt 5 im
Vorgehensmodell in Bild 1), beispielsweise basierend auf
einem entsprechenden XML-Schema. Arbeitsabläufe, wie
in Bild 3 grafisch dargestellt, sind dann entsprechend in
einer dem Schema folgenden XML-Datei hinterlegt. Somit
lassen sich die Arbeitsabläufe informationstechnisch nutzen.
Doch lohnt sich diese Nutzung überhaupt?
Die Modellierung von Engineering Workflows auf einem
anderen Abstraktionsgrad im Vergleich zu Business
Workflows verhindert eine Kontrolle des Arbeitsablaufs
durch ein Workflow-Management-System, da
diese die dafür erforderlichen Details nicht bietet. Allerdings
kann ein System mit der vorgestellten Modellierung
für Engineering Workflows folgende, aufeinander
aufbauende Leistungen erbringen:
Es kann den vielen am Engineering Workflow beteiligten
Ingenieuren einen Überblick über den gesamten
Arbeitsablauf geben und jedem Einzelnen bewusst
machen, in welchem Arbeitskontext (Vorgänger,
Nachfolger) er steht.
Es kann den Engineering Workflow nachverfolgen
und den Fortschritt im Prozess visualisieren. Dieses
ermöglicht allen Beteiligten, den aktuellen Stand
zu erfahren und leichter zu entscheiden, an welcher
Stelle am günstigsten fortzufahren ist. Die Voraussetzung
für diese Fähigkeit ist die Erfüllung der
Eigenschaft „Datenzugriff“ (siehe Tabelle 1) von
Seiten des Systems.
Es kann Änderungen an den Objekten visualisieren
und entsprechend auch aufzeigen, welche nachfolgenden
Aktivitäten davon betroffen sind. Somit ist
eine Unterstützung des Änderungsmanagements
möglich. Dazu muss das System zusätzlich zur Eigenschaft
„Datenzugriff“ die Eigenschaft „Iteration“
gemäß Tabelle 1 erfüllen.
Es kann die Kommunikation des Fortschritts und
von Änderungen automatisieren, sodass Ingenieure
für nachfolgende Aktivitäten zeitnah wissen, wann
sie aktiv werden müssen.
Es kann als zentrale Benutzungsoberfläche dienen,
über die die Ingenieure über die Objekte Zugriff auf
sämtliche Planungsdaten und über die Aktivitäten
Zugriff auf die benötigten Softwarewerkzeuge bekommen.
Somit ist es möglich, dezentrale Datenhaltung
und heterogene Werkzeuglandschaften unter
einer einheitlichen Oberfläche zusammenzufassen.
Die Voraussetzung für diese Fähigkeit ist jedoch
die Implementierung der Anforderungen, die sich
aus den Eigenschaft „Systemkopplung“ gemäß
Tabelle 1 ergeben.
Die Auflistung zeigt, dass sich die Unterschiede zwischen
Engineering und Business Workflows auch auf die
Nutzungsmöglichkeiten eines WfMS auswirkt. Im Fall
von Engineering Workflows beschreiben die genannten
Nutzungsmöglichkeiten ein neues Paradigma für Workflow-Management-Systeme.
Anstatt, wie im Fall von
Business Workflows, dem Benutzer nur die Informationen
zu geben, die er in seinem Kontext benötigt und den
Workflow vollständig zu kontrollieren, muss ein WfMS
im Fall von Engineering Workflows das Gegenteil leisten:
Es muss dem Benutzer einen vollständigen Überblick
über den Arbeitsablauf geben, ihn bezüglich Fortschritt
und Änderungen in den Planungsdaten auf dem
Autoren
Dr.-Ing. LARS Libuda
(geb. 1974) ist Mitarbeiter in
der Gruppe „Automation
Engineering“ in der Abteilung
„Industrial Software and
Applications“ des ABB Forschungszentrums
Deutschland.
Sein Hauptinteresse gilt der
Entwicklung neuer Konzepte
und Methoden zur Verbesserung des Engineerings
im Bereich der Anlagenplanung mit Fokus auf
Automatisierungs- und Elektrotechnik, im
letzteren Bereich vor allem nach dem Standard
IEC 61850.
ABB AG,
Forschungszentrum Deutschland,
Wallstadter Str. 59, D-68526 Ladenburg,
Tel. +49 (0) 6203 71 61 53,
E-Mail: lars.libuda@de.abb.com
Dipl.-Phys. GEORG GuTERmuth
(geb. 1969) leitet die Gruppe
„Automation Engineering“
in der Abteilung „Industrial
Software and Applications“
des ABB Forschungszentrums
in Ladenburg. Schwerpunkte
seiner Arbeit sind Tool- und
Datenintegration, Arbeitsabläufe
und deren Unterstützung sowie neue
Methoden und Konzepte zur Effizienzsteigerung
des Engineerings im Bereich der Automatisierungstechnik.
ABB AG,
Forschungszentrum Deutschland,
Wallstadter Str. 59, D-68526 Ladenburg,
Tel. +49 (0) 6203 71 64 77,
E-Mail: georg.gutermuth@de.abb.com
50
atp edition
9 / 2011
aktuellen Stand halten und den Workflow nachverfolgen,
aber keinesfalls kontrollieren. Das System hat in
diesem Fall eine passive, informative Rolle.
Somit ist es gerechtfertigt, für ein System zur Unterstützung
von Engineering Workflows den Begriff Engineering
Workflow Support System (EWSS) einzuführen
und dieses von einem Workflow-Management-System
für Business Workflows (WfMS) abzugrenzen.
Bei konsequenter Umsetzung der Modellierung von
Engineering Workflows und deren informationstechnische
Unterstützung in einem EWSS sind die oben genannten
Nutzungsmöglichkeiten technisch realisierbar.
Dies verspricht, die Arbeitsabläufe und Kommunikation
innerhalb eines Anlagenbauprojekts effizienter zu
gestalten und dabei die notwendige Kreativität in der
Anlagenplanung zu bewahren.
Fazit
Eine Einführung von Workflow-Management-Systemen in
die Anlagenplanung verspricht eine Effizienzsteigerung
bei der Abwicklung von Anlagenbauprojekten. Workflow-
Management-Systeme müssen dafür jedoch im Vergleich
zu Geschäftsprozessen einem anderen Paradigma folgen.
Workflow-Management-Systeme für die Anlagenplanung
müssen ihren Nutzern, den Ingenieuren, einen vollständigen
Überblick über den Arbeitsablauf geben, ihn bezüglich
Fortschritt und Änderungen in den Planungsdaten
auf dem aktuellen Stand halten und den Workflow nachverfolgen.
Sie dürfen keinesfalls den Arbeitsablauf kontrollieren
und den Nutzern nur eingeschränkte Sicht auf
den Arbeitsablauf geben, wie es bei Workflow-Management-Systemen
für Geschäftsprozesse der Fall ist.
Die Gründe für diesen Paradigmenwechsel liegen in
den grundsätzlichen Unterschieden von Business Workflows
und Engineering Workflows. Erstere bilden einen
administrativen Prozess ab, letztere einen kreativen
M. Eng. Stefan HeiSS (geb. 1971)
erstellte im Rahmen seines
berufsbegleitenden Master-Studiums
an der Georg-Simon-Ohm
Hochschule seine Masterarbeit
in der Gruppe „Automation
Engineering“ in der Abteilung
„Industrial Software and
Applications“ des ABB Forschungszentrums
Deutschland. Der Fokus der
Masterarbeit liegt in der informationstechnischen
Unterstützung von Engineering Workflows. Heiß
arbeitet im Bereich Software-Qualitätsmanagement
und Funktionale Sicherheit für Embedded Systems.
Georg-Simon-Ohm-Hochschule,
Fakultät Elektrotechnik, Feinwerktechnik,
Informationstechnik,
Wassertorstraße 1, D-90489 Nürnberg,
Tel. +49 (0) 177 400 62 78, E-Mail: stefan.heiss.1@web.de
Prozess. Bedingt durch diese Unterschiede wurde in
diesem Beitrag eine Notation für Engineering Workflows
eingeführt sowie Nutzen und Anforderungen an
ein Engineering Workflow Support System für die Anlagenplanung
diskutiert.
Manuskripteingang
19.04.2011
ReferenZEn
[1] Gadatsch, A.: Grundkurs Geschäftsprozess-
Management. Vieweg, Wiesbaden 2008
[2] Workflow Management Coalition.
http://www.wfmc.org/
[3] bullinger, H.-J., und Warschat, J.: Concurrent
Simultaneous Engineering Systems. The Way to
Successful Product Development. Springer Verlag,
Berlin 1995
Im Peer-Review-Verfahren begutachtet
[4] Liebisch, D.C.; Jain, A.: JESSI common framework
design management the means to configuration and
execution of the design process. Proceedings of
European Design Automation Conference, EURO-
VHDL '92, EURO-DAC '92 (1992), S. 552 557
[5] Sum, S., Ibold, C.: Information Technology Support for
Concurrent and Simultaneous Engineering – Tool
Integration in a Meta Framework. Proceedings of
TENCON '94, IEEE Region 10's Ninth Annual International
Conference (1994) Vol. 2, S. 1068 1073
[6] Schmitt, R.: Workflow Management für die integrierte
Produktentwicklung. Mitteilungen aus dem Institut
für Maschinenwesen Nr. 21, Clausthal-Zellerfeld,
1996 (ISSN 0947 2274)
[7] goltz, M., Grigorova, K., Boór, F. und Palotai, R.: Final
Project Report, Deliverable document 5.3, Public
Document No.: CONFLOW.00.06., ConFlow, inCO
Copernicus programme (Projekt Nr. 960243), 2000
[8] zur Muehlen, M.; Recker, J.: How much language is
enough? Theoretical and practical use of the Business
Process Modeling Notation. Proceedings of the 20th
international conference on Advanced Information
Systems Engineering (2008), S. 465 479
[9] Killich, S.; Luczak, H.; Schlick, C.: Weissenbach, M.;
Wiedenmaier, S.; Ziegler, J. (1999): Task modelling for
cooperative work. Behavior & Information Technology,
Vol. 18, No. 5, 325-338
[10] theißen, M.; Hai, R.; Marquardt, W.: ProcessNet-
Fachausschuss 7. Symposium Informationstechnologien
für Entwicklung und Produktion in der Verfahrenstechnik
26. März 2010, Aachen
(online verfügbar unter:
http://www.processnet.org/processnet_media/
Elsen/Pr%C3%A4sentation+Hai.pdf)
[11] Foltz, C.; Killich, S.; Wolf, M.: K3 User Guide (Version
0.1), Institut für Arbeitswissenschaft (IAW) der RWTH
Aachen, 21.11.2000 (online verfügbar unter:
http://www.iaw.rwth-aachen.de/download/produkte/
k3_userguide_2000-11-21.pdf)
[12] zur Muehlen, M.: Workflow-based Process
Controlling, Logos Verlag, Berlin 2004
(ISBN 3-8325-0388-9), Seiten 38-39
atp edition
9 / 2011
51
hauptbeitRAG
Von Zäunen befreit
Industrieroboter mit Ultraschall absichern
Um das Risiko zu vermindern, dass Personen mit dem Roboter in Kontakt kommen und
dabei verletzt werden, arbeiten industrielle Roboter hinter starren Schutzeinrichtungen.
Das Institut für Arbeitschutz (IFA) forscht an der Zukunftstechnologie „Kollaborierender
Roboter“, um Menschen den gefahrlosen Zugang zum arbeitenden Roboter zu gewähren.
Der Beitrag beschreibt, wie im Rahmen des von der Bayerischen Forschungsstiftung geförderten
Projektes „EsIMiP“ ein Konzept entwickelt wurde, einen Roboterarm mit Ultraschallsensoren
so abzusichern, dass ein flexibles Zusammenarbeiten von Mensch und
Roboter möglich wird.
SCHLAGWÖRTER Industrieller Roboter / Ultraschallsensoren / kollaborierender Roboter /
EsIMiP / IFA / DGUV
Freed from fences –
Safeguarding industrial robots with ultrasound
Industrial robots work behind rigid safety devices in order to lower the risk that persons
come in contact with the robot and thus to harm. The IFA, an institute for research and
testing of the German Social Accident Insurance in Germany, is working on the state of
science in “collaborating robots”, to grant humans safe access to robots.
In the course of the project “EsIMiP”, promoted by the Bavarian Research Foundation, a
concept was developed at the IFA, allowing the robot’s arms to be secured by ultrasonic
sensors. This enables a flexible collaboration between human and robot.
KEYWORDS Industrial robot / ultrasonic sensors / collaborating robot / EsIMiP / IFA /
DGUV
52
atp edition
9 / 2011
Björn Ostermann, MiCHAEL HuELKE, Institut für Arbeitsschutz (IFA)
Anke Kahl, Bergische Universität Wuppertal
Der erste industrielle Roboter wurde 1954 von George
C. Devol Jr. erfunden und 1961 bei General Motors
erstmals in der industriellen Fertigung eingesetzt
[1]. Der erste tödliche Unfall geschah 1979 [2].
Ende 2009 waren weltweit bereits mehr als eine
Millionen Roboter in der Industrie im Einsatz, hiervon etwa
340 000 in Europa und mehr als 140 000 in Deutschland [3].
Durch die Anforderungen, die an die Sicherheit von
Maschinen – nicht nur im europäischen Binnenmarkt
– gestellt werden, verrichten die meisten dieser Roboter
ihren Dienst hinter starren Zäunen. Mit der Zulassung
von Laserscannern für Sicherheitsapplikationen in 1998
[4] und des Kamera Systems „SafetyEye“ in 2006 [5]
konnten einige der starren Zäune durch berührungslos
wirkende Schutzeinrichtungen ersetzt werden. Doch
auch diese unsichtbaren Zäune trennen Bediener und
Roboter entlang einer vorgegebenen starren Grenze.
Eine flexible und sichere Zusammenarbeit zwischen
Bediener und Roboter im selben Arbeitsraum ist mit heutigen
Sicherheitssystemen nicht möglich. Hierzu wird ein
neues System benötigt, dass die Bewegungsräume des Bedieners
möglichst wenig einschränkt und sicherheits- und
auch prozesstechnisch flexibel auf den Aufenthaltsort des
Bedieners reagiert. Neben der hohen Sicherheit spielen
wirtschaftliche Aspekte eine große Rolle. Ein Roboter, der
keinen Zaun benötigt und dem man sich bedenkenlos im
Betrieb nähern kann, verspricht Möglichkeiten für neuartige
Arbeitsplätze und die Umsetzung von platzsparenden
Konzepten im Rahmen der Arbeitsplatzgestaltung.
Der Forschungsbereich „Kollaborierende Roboter“ befasst
sich damit, den industriellen Roboter soweit sicher zu machen,
dass er mit Menschen auf engem Raum zusammenarbeiten
kann, ohne dabei durch eine fest stehende Schutzeinrichtung
von den Menschen getrennt zu sein. Menschen
können sich „mit Sinn und Verstand“ auf Änderungen einstellen.
Ein gewöhnlicher industrieller Roboter kann seine
Umgebung dagegen nicht wahrnehmen und hat keine Möglichkeit,
sich Veränderungen in seinen Arbeitsbedingungen
anzupassen. Er arbeitet stoisch sein Programm ab.
Das vom IFA zu entwickelnde Sicherheitssystem soll
in die Robotersteuerung eingreifen und Kollisionen verhindern,
indem die Geschwindigkeit des Roboters bei
Annäherung bis zum Stillstand reduziert wird. Als Aufgabe
ergibt sich hieraus, den Roboter mit geeigneter Sensorik
auszustatten und in seiner Steuerung gleichzeitig
Algorithmen einzubinden, die es ihm erlauben, seine
Arbeitsweise den erfassten Werten anzupassen.
Eine geeignete Sensorik muss
Daten schnell und zyklisch liefern und
relevante Daten erfassen.
Die Algorithmik muss
Daten schnell und zyklisch verarbeiten sowie
mit den gelieferten Daten auskommen.
Beide Aufgabengebiete müssen aufeinander abgestimmt
sein. Wenn die Sensorik unnötige Daten liefert, müssen
diese in der Algorithmik mühsam gefiltert werden. Wenn
die Sensorik zu wenige Daten liefert, kann die Algorithmik
keine optimale Lösung finden. Andererseits darf die Algorithmik
keine Daten erwarten, die mit Sensorik nicht erfasst
werden können. Algorithmen, die nur an vollständigen
Datensätzen aus virtuellen Computermodellen getestet
werden, scheitern in der Praxis an den unvollständigen,
fehlerbehafteten Daten, die ihnen reale Sensoren liefern.
1. Kollaborierende Roboter
2. Arbeitsaufgabe des Industrieroboters
Ein wichtiger Faktor für die Planung eines kollaborierenden
Roboters ist seine Arbeitsaufgabe. Die Wahl von Sensorik
und Algorithmik ist von folgenden Faktoren abhängig:
Typ des Industrieroboters
Kraft
Reichweite
Freiheitsgrade (Anzahl Achsen)
atp edition
9 / 2011
53
HauptbeitRAG
gewünschte Arbeitsgeschwindigkeit des
Roboters
Aufgabe des Roboters, wie Beförderung kleiner,
großer, (un‐)übersichtlicher oder komplexer Teile,
oder sonstige Aufgaben, wie Schweißen und
Lackieren
Die zu bewältigende Arbeitsaufgabe wurde im Projekt
EsIMiP festgelegt. In diesem Projekt, gefördert von der
Bayerischen Forschungsförderung (AZ‐852‐08), verfolgen
die TU München, die Universität Kassel, das IFA
sowie die Industriepartner Reis Robotics und Baumüller
das Ziel, experimentelle Ansätze aus der Forschung
mit verifizierbarer Sicherheitstechnik zu kombinieren.
Als Arbeitsmittel wurde ein Roboter RV20-16 beziehungsweise
RV30-16 der Firma Reis gewählt. Die Reichweite
dieser Roboter liegt bei zirka 2 m. Als Aufgabe
des Roboters wurde „Transport und Darreichung von
kleinen Teilen“ gewählt.
3. Absicherung des Roboters (mit Sensoren)
Zur Kollisionserkennung zwischen Roboter und Mensch
werden geeignete Sensoren benötigt. Die Wahl dieser Sensoren
hängt von verschiedenen Faktoren ab. Sie müssen
eine lückenlose Überwachung der Roboterumgebung
gewährleisten
unabhängig von der Ausrüstung des Bedieners wirken
ein sicheres Signal liefern
ein schnelles Signal liefern
störfest sein
3.1 Platzierung der Sensorik
Für die lückenlose Überwachung der Roboterumgebung
zur sicheren Kollisionsvermeidung sind drei unterschiedliche
Vorgehensweisen denkbar:
BILD 1: Arbeitsbereich, von außen überwacht mit Kameras
BILD 2: Arbeitsbereich, von innen überwacht
BILD 4: Eindringendes Objekt wirft Echos zurück,
Sensor 2 misst geringste Distanz.
BILD 5: Verkürzte Schallaufzeit für Sensor 4
54
atp edition
9 / 2011
Überwachung mittels durchdringender Sensoren
Überwachung des Arbeitsraumes mit nicht durchdringenden
Sensoren „von außen“
Überwachung der Roboterumgebung mit am
Roboter montierten Sensoren „von innen“
A | Überwachung mittels durchdringender Sensoren
Lückenlose Überwachung kann erreicht werden, wenn
Sensoren eingesetzt werden, die nur auf bestimmte Marker
reagieren und restliche Materialien durchdringen.
Ein Beispiel ist der Einsatz von RFID Tags, die vom Menschen
am Körper getragen werden. Diese Technik wurde
im IFA bereits für verschiedene Einsatzbereiche erprobt
[6]. Es können allerdings nur solche Stellen am Mensch
gefunden werden, die mit einem RFID Tag versehen sind.
Hierdurch ergibt sich, dass Bediener mit ausreichendem
Sicherheitsabstand arbeiten müssen, oder alle Körperteile
des Bedieners, welche gefährdet sind, vollständig
mit RFID Tags versehen sind.
BILD 3:
Reis-Roboter
mit Microsonic-
Sensoren
Dieser Ansatz hat für die Interaktion von Mensch und
Roboter den Nachteil, dass nur die Personen geschützt sind,
die eine entsprechende Schutzausrüstung angelegt haben.
Es muss deshalb organisatorisch sichergestellt sein, dass
sich nur so geschützte Personen im Roboterbereich aufhalten.
Organisatorische Maßnahmen sind in der Sicherheitstechnik
aber nachrangig zu technischen Maßnahmen anzuwenden,
die vorher ausgeschöpft sein müssen.
B | Überwachung des Arbeitsraumes mit nicht
durchdringenden Sensoren „von außen“
Eine lückenlose Überwachung des Arbeitsraums von außen
durch im Raum angebrachte Sensoren ist schwierig
zu realisieren. Sensoren, deren Erfassungsbereich durch
das erfasste Hindernis geblockt wird, erzeugen für den
dahinter liegenden Bereich „blinde Zonen“, für die dann
keine Daten vorliegen. Wie Bild 1 zeigt, können diese Zonen
zwar durch die Verwendung vieler Sensoren aus unterschiedlichen
Richtungen in ihrer Größe verringert
werden. Auch können bekannte, starre Hindernisse bei
der Platzierung der Sensoren berücksichtigt werden. Flexible
Hindernisse, wie zum Beispiel der Bediener, oder
auch der dynamisch ausweichende Roboter selbst, sind
in der Planung allerdings nur schwer zu berücksichtigen.
Gerade hier sind blinde Zonen besonders störend für eine
dynamische Robotersteuerung.
C | Überwachung der Roboterumgebung
mit Sensoren „von innen“
Ein weiterer Ansatz ist, die Montage der Sensoren am
Roboter, um den Raum von innen zu überwachen. Wie
Bild 2 verdeutlicht, treten auch hierbei blinde Zonen im
Erfassungsbereich auf, wenn die Sensormessung auf das
Hindernis trifft.
Die Sicherheit im Roboterarbeitsbereich wird durch
diese blinden Zonen aber nicht beeinträchtigt, da hierfür
nur der freie Bereich um den Roboter entscheidend ist.
Die Information über den gesamten freien Raum, die für
die arbeitstechnisch optimale Planung eines Roboterpfades
benötigt wird, kann hierbei nicht erfasst werden.
Daher ist das Überwachen des Raumes vom Roboter aus
nur für den Teil der Steuerung passend, der die sichere
Annäherung des Roboters an den Menschen überwachen
soll. Die Sensoren müssen so platziert werden, dass vom
Roboter gegriffene Teile und Arbeitsmittel vom Sensorfeld
vollständig umschlossen sind. Dies kann sich für
große Werkstücke problematisch gestalten.
3.2 Wahl der Sensoren
Auf Basis der beschriebenen Randbedingungen wurde im
Projekt EsIMiP die Auswahl der Sensoren zur sicheren
Hinderniserkennung auf solche beschränkt, die ohne zusätzliche
Markierungen am zu erkennenden Objekt auskommen
und sich für den Einsatz „von innen“ eignen.
Analysen der in der Literatur beschriebenen, bereits umgesetzten
Sensorkonzepte zeigen, dass
BILD 6: Unterschied der freien Räume,
mit und ohne Fehlmessung
Kraftsensoren, die erst bei Berührung auslösen,
einen Zusammenstoß erkennen aber nicht verhindern
können [7]
Kapazitive Sensoren noch nicht zur sicheren
Erfassung geeignet sind und nur einen begrenzten
Erfassungsbereich haben [8]
atp edition
9 / 2011
55
HauptbeitRAG
Kameras (2D und 3D) nur schwer sicherheitsertüchtigt
werden können und dann hohen Rechenaufwand
erfordern (Beispiel: Pilz SafetyEye)
Laserscanner für 3D-Aufnahmen eine zu geringe
Bildanzahl pro Sekunde liefern [9]
PMD-Kameras noch nicht sicherheitsgerichtet
funktionieren [10]
Nach weiteren Untersuchungen auf dem Markt verfügbarer
Sensoren kristallisierte sich als Ergebnis die Nutzung
von Ultraschallsensoren heraus. Der Vorteil dieser Sensoren
ist, neben der bereits vorhandenen Applikation in der
Sicherheitstechnik, dass sie auf jegliche Annäherung im
Erfassungsbereich reagieren, und als Messergebnis immer
die kürzeste Distanz zum erkannten Objekt zurückliefern.
Der Rechenaufwand pro Sensor ist klein, sodass eine größere
Anzahl von Sensoren eingesetzt werden kann, um
eine flächendeckende Messung zu gewährleisten.
Im Projekt wurde ein Konzept entwickelt, den Roboter
mit nach außen gerichteten Ultraschallsensoren einzukleiden.
Die Vorgehensweise ähnelt damit der Einparkhilfe
von Kraftfahrzeugen, bei der wenige Ultraschallsensoren
in der Stoßstange eingebaut sind. Die Anzahl der am Roboter
verwendeten Sensoren ist jedoch ungleich größer.
Das IFA wird hierbei durch die Firma Microsonic technologisch
unterstützt, die bereits 1996 ihren ersten Ultraschallsensor
für die Sicherheitstechnik ertüchtigt hat.
Bild 3 zeigt den Reis Roboter RV30-16 mit angebauten Ulraschall
Sensoren von Microsonic im Versatz von 10 cm.
Die Sensorwerte werden über eine Beckhoff-EtherCAT-
Schnittstelle an die Auswerteeinheit (PC) übertragen.
Nach ihrer Verarbeitung werden entsprechende Fahrbefehle
weiter an die Robotersteuerung geleitet. Zurzeit
wird davon ausgegangen, dass das Tool ebenfalls eine
umschließende Überwachung mit Ultraschall zulässt.
3.3 Messprinzip des Ultraschall‐Arrays
Ultraschallsensoren senden ein kurzes Schallsignal im
für Menschen unhörbaren Ultraschallbereich aus und
messen die Zeit, bis das von Fremdobjekten zurückgeworfene
Signal wieder vom Sensor erfasst wird. Aus dieser
Zeit, in Verbindung mit der aktuellen Lufttemperatur,
wird die Distanz bis zum Objekt berechnet. Dieses Messprinzip
ist möglich, da die Schalllaufzeit in 20 °C warmer
Luft mit etwa 343 m/s sehr gering ist. Ein Microcontroller
kann damit die Laufzeit mit der erforderlichen geringen
Toleranz messen, um einen ausreichend genauen Abstand
zum Objekt berechnen zu können. Für eine Abstandsmessung
von 50 cm benötigt Ultraschall zirka 3 ms.
Beim Anbau der Sensoren muss in der gegebenen Anwendung
darauf geachtet werden, dass sich die Schallkeulen
überschneiden, um flächendeckende Messergebnisse
in dem erforderlichen Sicherheitsabstand zu erreichen.
Dringt nun ein Objekt in den überwachten Bereich
ein, nehmen die Sensoren wie in Bild 4 gezeigt, ein zurückgeworfenes
Echo auf und können hieraus auf ihre
Entfernung zum Objekt schließen.
Der Bereich, der durch den Kegel der Sensoren in dieser
Entfernung abgedeckt wird, kann damit als „frei von
Objekten“ angenommen werden.
Um das dargestellte Bild zu erhalten, müssen die Sensoren
ihren jeweils erzeugten und zurücklaufenden Schall
voneinander unterscheiden können. Bei gleichzeitiger
Messung ist dies theoretisch durch eine Kodierung der
Frequenzen möglich. Praktisch ergeben sich aber Mehrfachreflexionen
in der Umgebung, die eine genaue Zuordnung
des Empfangssignals verhindern. Auch ist das Verwenden
verschiedener Ultraschallfrequenzen in der Praxis
kaum zu realisieren. Eine Schallkodierung der einzelnen
Sensoren lässt sich somit nicht in die Praxis umsetzen.
Theoretisch denkbar wäre es, auch sequenzielle Messungen
durchzuführen. Durch das Abklingen des Schalls
in der Umgebung sowie das zur Ruhe kommen des Sende-/Empfangsmoduls
im Sensor kann eine einzelne Messung
im Bereich bis 60 cm aber nur alle 17 bis 20 ms
durchgeführt werden. Das sequenzielle Messen führt
somit bei der hier vorgesehenen großen Anzahl von Sensoren
zu sehr großen Messzyklen.
Als Lösung für dieses Problem wird die Messung der
Ultraschallsensoren bei gleicher Kodierung der Frequenzen
gleichzeitig gestartet. Hierdurch ergibt sich jedoch ein
weiteres Problem, wie Bild 5 darstellt. Der Weg von Sensor
3 zum Objekt und zurück zu Sensor 4 ist kürzer als
von Sensor 4 selbst zum Objekt und zurück. Bei parallel
laufender Messung wird in Sensor 4 somit das Rücklaufsignal
von Sensor 3 und damit eine kürzere Distanz zum
Objekt gemessen als sie wirklich gegeben ist. Der als frei
bekannte Raum verkürzt sich damit an dieser Stelle.
Die Messung des minimalen Abstandes bleibt von dieser
Messverfälschung jedoch unberührt. Für das Beispiel ergibt
sich der in Bild 6 dargestellte Unterschied zwischen
möglicher Messung (grau) und erfolgter Messung (rot).
Da für die Umsetzung der Sicherheitsfunktion die Geschwindigkeit
des Roboters am kleinsten gemessenen
Abstand auszurichten ist, ist eine geringe Verfälschung
der restlichen Messwerte nicht von Bedeutung.
4. Algorithmen zur Messwertauswertung
Wie in Kapitel 2 beschrieben, ist es das Ziel des IFA, eine
Anpassung der Robotergeschwindigkeit an die Umgebungsbedingungen
zu erreichen.
Um die jeweils aktuell zulässige Geschwindigkeit zu
berechnen,
müssen die ermittelten Abstandswerte der
Sensoren ausgewertet und zu einer virtuellen
Karte der Umgebung verknüpft werden,
muss berechnet werden, ab welcher Geschwindigkeit
der Roboter mit den Außengrenzen der Karte
gefährlich kollidiert.
Diese Schritte sind für die Ermittlung der konkreten Geschwindigkeitsvorgabe
feiner unterteilt worden. Hierzu
beschreibt dieses Kapitel:
den Zusammenhang zwischen Messzyklus,
Abstand und Geschwindigkeit
den Datenfluss durch die einzelnen Algorithmen in
der entwickelten „Fail Safe Control“
die Bestimmung des freien Raums, angedeutet in Bild 6
die Erfassung der Karte der statischen Umgebung
und das Ziel:
die Bestimmung der aktuell zulässigen Geschwindigkeit
durch Kollisionsprüfung
56
atp edition
9 / 2011
4.1 Zusammenhang Messzyklus - Abstand -
Geschwindigkeit
Die Norm DIN EN ISO 13855 „Sicherheit von Maschinen
– Anordnung von Schutzeinrichtungen im Hinblick
auf Annäherungsgeschwindigkeiten von Körperteilen“
beinhaltet Berechnungsgrundlagen und -formeln,
die auch für das vorgestellte Sensorkonzept genutzt
werden können.
S = ( K∗T)+
C
Mindestabstand
Die DIN EN ISO 13855 gibt für die Ermittlung des Mindestabstands
„S“ die Berechnungsformel S = ( K∗T)+
C vor.
S = ( K∗T)+
C
K : Faktor für die Annäherungsgeschwindigkeit
eines S = Menschen ( K∗T)+
C 2 m s
T : Nachlaufzeit
C : Eindringungstiefe in den Gefahrenbereich
bis zur Detektion
2 m s
2 m s
Der Faktor K beträgt bei weniger als 500mm Mindestabstand
2 m s , ansonsten 16 ,
m s . Hinzu kommt die Geschwindigkeit
des Roboters selbst. Nach der erwähnten
Norm besteht die Nachlaufzeit T eines Systems aus
16 ,
m
der Zeit zwischen Auslösen des Sensorsystems s und
dem 16 ,
m s Stillstand der Maschine. Im Projekt wird für T
einen Wert von 100 ms angenommen. Da die Sensoren
Finger erkennen 16 ,
m s
können, Skann =
m
( 2C auf
s ∗100 0mm ms)+ gesetzt 0mm = werden.
Bei stillstehendem Roboter ergibt sich ein Min-
200mm
destabstand von
S =
m
( 2 s ∗100ms)+ 0mm = 200mm
S =
m
( 2 s ∗100ms)+ 0mm = 200mm
Geschwindigkeit S =
m
( 2S =
s ∗( 100 K∗ms T)+
)+ C0 mm = 200mm
Die erlaubte Geschwindigkeit des Roboters ist auf zwei
Teilstrecken linear. Eine grafische Darstellung des Zusammenhangs
bis zur maximalen Messreichweite von
600 mm zeigt Bild 7.
Danach darf sich der Roboter bei 60 cm freiem Raum
mit maximal 4,4 2 m s bewegen.
BILD 7: Zusammenhang „aktueller Abstand - maximal erlaubte
Geschwindigkeit“ für eine Reaktionszeit von 100 ms
4.2 Fail Safe Control
Um das sichere Abbremsen des Roboters vor einer Kollision
zu kontrollieren, 16 ,
m s wird im IFA die in Bild 8 dargestellte
„Fail Safe Control“ (FSC) entwickelt. Um dies zu erreichen,
werden die Sensorwerte zu einer Umgebungskarte zusammengefügt
und diese Karte mit der Roboterbewegung abgeglichen.
Diese Maßnahmen sind sicherheitsrelevant und
müssen deshalb in Echtzeit durchgeführt werden.
Die Eingaben Sin = die m
( 2 FSC
s ∗100 erfolgen ms)+ 0mm = 200mm
durch die Ultraschallsensoren, die alle 60 ms ihre
Distanzwerte liefern
durch den Roboter selbst, dessen Steuerung
alle 2 ms die eigene Position liefert
alle 10 ms die nächste anzufahrende Position liefert
durch einen weiteren Programmteil, der einmalig die
statischen Objekte der Umgebung liefert
BILD 8: Zeitlicher Ablauf der Berechnungen
BILD 9: Bahnkurvenabhängige Berechnung der
aktuell zulässigen Geschwindigkeit
Ausgegeben werden die Werte für die maximalen Geschwindigkeiten
der Achsen, die alle 10 ms bereitgestellt
werden.
atp edition
9 / 2011
57
HauptbeitRAG
4.3 Bestimmung des freien Raums
Der freie Raum (siehe Bild 6) entsteht aus den Bereichen, die
die Sensoren als frei von Objekten identifizieren. Der Abstand
des Roboters von den Außengrenzen des freien Raumes
bestimmt grundsätzlich die zulässige Geschwindigkeit
des Roboters. Es ist allerdings wichtig zu unterscheiden, ob
diese Grenzen durch statische Hindernisse beziehungsweise
durch den Arbeitsplatz selbst entstehen, oder ob dynamische
Hindernisse den freien Raum einschränken.
Die Geschwindigkeit des Roboters soll nur gegenüber
dynamischen Hindernissen, zum Beispiel Bedienern, verringert
werden, damit die maximal zulässige Geschwindigkeit
nur dort, wo es sicherheitstechnisch erforderlich
ist, eingeschränkt wird. Statische Hindernisse, beispielsweise
Arbeitstische, sind bereits heute durch andere
Funktionen der Robotersteuerung, wie Softwarenocken,
abgesichert. Auch muss gegenüber einem statischen Objekt
kein Sicherheitsabstand eingehalten werden.
Bei der Messung mit Ultraschall ist es allerdings nicht
möglich, einzelne Objekte direkt zu unterscheiden. Auch
ist die Auflösung des geplanten Sensornetzwerks zu gering,
um die Form von Objekten zu erkennen und gegebenenfalls
zuzuordnen. Wegen der angeführten Vorgabe
wird aber eine Funktion benötigt, die es dem Programm
erlaubt, zwischen statischen und dynamischen Hindernissen
zu unterscheiden. Eine solche Möglichkeit bietet
die Hintergrundausblendung. Hierbei muss die statische
Umgebung des Roboters bekannt sein und dann bei der
Auswertung der Sensorwerte ausgeblendet werden.
Karte der statischen Umgebung
Bei einem Roboter, der keine selbstständige Änderung an
seiner einprogrammierten Bahn (Trajektorie) vornimmt,
kann die geplante vorgegebene Trajektorie, die die statischen
Hindernisse bereits berücksichtigt, abgefahren
werden. Dabei können die Erwartungswerte für die Sensoren
eingelernt werden. Ein Roboter, der seine Trajektorie
an Fremdobjekte in seiner Umgebung dynamisch anpasst,
muss dagegen mit einer Karte der statischen Objekte
arbeiten, um diese von dynamischen Objekten unterscheiden
zu können. Hierbei kann benutzt werden:
ein Modell aller statischen Objekte im Raum
oder
ein Modell des freien, befahrbaren Raums
Die vorhandenen Ultraschallsensoren bieten die Konstruktion
einer Karte des freien Raums als den einfacheren Weg
an. Zu Beginn der Messung wird dazu der gesamte, von
dynamischen Objekten befreite Raum als belegt „gesetzt“.
Mit jeder Messung wird dann der Bereich, den einzelne
Sensoren als frei zurückliefern vom belegten Raum abgezogen
und der Arbeitsraum schrittweise in das Programm
eingelernt. Der Roboter wird hierfür entweder durch ein
Programm oder durch den Bediener selbst gesteuert. Wird
der Raum mit Hilfe eines Bedieners eingelernt, ist eine grafische
Darstellung von Raum, Roboter und Sensormesswerten
nötig. Zur statischen Umgebung gehört bei der dynamischen
Anpassung auch der Roboter selbst. Sensoren, die am
ersten Arm angebracht sind, erkennen ab einem bestimmten
Winkel der Gelenke den zweiten Arm, beziehungsweise
das Werkzeug des Roboters. Auch diese Werte müssen
aus der Kollisionsberechnung ausgeschlossen werden.
4.4 Kollisionstest
Der Kollisionstest erfolgt, wie auch die Sensormessung,
zyklisch. Die Dauer eines einzelnen Tests ist jedoch
geringer als die Dauer der Messung. Deshalb ist es möglich,
mehrere Kollisionsprüfungen pro Messzyklus
durchzuführen. Hieraus ergibt sich, dass die Annahmen
über den freien Raum, die vor dem ersten Kollisionstests
gemessen wurden, für den zweiten Kollisionstest
in einem Zyklus nicht mehr aktuell sind. Um jederzeit
mit sicheren Werten arbeiten zu können, müssen
die Sensorwerte deshalb an die Zeit angepasst werden,
die vergangen sein wird, wenn die errechnete Geschwindigkeitsvorgabe
angewendet wird. Damit kann
berücksichtigt werden, dass sich dynamische Objekte
in der Zwischenzeit dem Roboterarm genähert haben
können. Mit dem zeitlich angepassten Raum muss eine
Kollisionsprüfung durchgeführt werden, bei der üblicherweise
der geringste Abstand zwischen Roboter und
Umgebung bestimmt wird.
Für diesen Kollisionstest wurden zahlreiche Algorithmen
entwickelt, die aber größtenteils auf dem Hintergrund
der Pfadplanung basieren. Im Rahmen dieses Projektes
wurde eine performantere Lösung entwickelt, die
allein auf die Kollisionsüberwachung spezialisiert ist.
Abgleich freier Raum und Bewegungsvorhersage –
Berechnung der Geschwindigkeit
Eine große Herausforderung bei der dynamischen
Bewegungsplanung industrieller 6-Achsen-Roboter
ist die Kollisionsprüfung mit Hindernissen in seiner
Umgebung. Alle sechs Achsen können sich unabhängig
von einander bewegen und die Bewegung einzelner
Glieder ist von allen davorliegenden Achsen abhängig.
Auch können bestimmte Positionen des Werkzeugs
durch eine Vielzahl von Achskombinationen
erreicht werden.
Während sich die prozessorientierte Pfadplanung im
Projekt auf die Kollisionsprüfung des Roboterwerkzeugs
allein konzentrieren kann – um hierdurch den
Aufwand der Berechnungen in Grenzen zu halten –
muss die sicherheitsgerichtete Kollisionsüberwachung
stets den kompletten Roboter überwachen. Es wird im
Projekt deshalb davon ausgegangen, dass eine Überwachung
aller denkbaren Zustände, die der Roboter und
die manipulierten Werkstücke theoretisch einnehmen
können, nicht in Echtzeit erfolgen kann, weil die zu
verarbeitende Datenmenge zu groß ist.
Dieses Problem wurde in diesem Projektteil elegant
über eine „Bewegungsvorhersage“ gelöst. Die sicherheitstechnische
Überwachung greift nicht in die Pfadplanung
des Roboters selbst ein. Sie regelt nur dessen Geschwindigkeit
innerhalb des durch die Pfadplanung vorgegebenen
Pfads. Aus sicherheitstechnischer Sicht ist es ausreichend,
nur den Raum um diesen speziellen Pfad zu
überwachen. Dazu wird der Kollisionssteuerung regelmäßig
die der Pfadsteuerung bekannte aktuelle Stellung
aller Achsen sowie die nächste anzufahrende Position
des Roboters übermittelt. Der mathematische Aufwand
zur Kollisionserkennung wird damit auf ein Minimum
reduziert, und die sicherheitstechnische Steuerung des
Roboters kann in Echtzeit erfolgen.
Bild 9 zeigt den Ablauf des Algorithmus graphisch. Die
Überwachung prüft als erstes, ob im nächsten Überwa-
58
atp edition
9 / 2011
chungszyklus (geplant 10 ms bis 100 ms) eine Kollision
mit der Umgebung vorliegt, wenn der Roboter mit maximaler
Geschwindigkeit in die geplante Richtung bewegt
wird. Ist dies nicht der Fall, wird die maximale benötigte
Geschwindigkeit der Achsen erlaubt.
Falls eine Kollision droht, wird die Geschwindigkeit
aller Achsen auf 50 % der geplanten Bahngeschwindigkeit
reduziert, und eine neue Kollisionsprüfung findet
statt. Hiernach wird die Geschwindigkeit iterativ um
50 % der vorhergehenden Anpassung erhöht, beziehungsweise
vermindert, je nachdem ob eine Kollision
festgestellt wurde.
Dieser Algorithmus führt nach nur 10 Kollisionsprüfungen
zu einer Genauigkeit von 0,1 % bei der Festlegung
der maximal erlaubten Geschwindigkeit. Mit dieser Geschwindigkeitsvorgabe
kann die Robotersteuerung kollisionsfrei
fahren. Das korrekte Einhalten der Geschwindigkeitswerte
erfolgt durch die Sicherheitssteuerung.
Um die geplante Bahn nicht zu verlassen, muss diese in
der Lage sein, alle Motoren auf die errechnete Geschwindigkeit
hin zu überwachen.
Zusammenfassung
Das vorgestellte System beschreibt ein Sicherheitskonzept
für kollaborierende Roboter. Als Sensorik werden
Ultraschallsensoren eingesetzt, die ein Sicherheitsfeld
um den Roboter aufspannen. Es wird dargestellt, wie diese
Sensoren parallel messen können, ohne die Messergebnisse
zur unsicheren Seite hin zu verfälschen. Die
vorgestellten Algorithmen lassen sich in der Regel einfach
in bestehende Roboterarbeitsplätze integrieren, in
den meisten Fällen sogar ohne Änderungen an den vorhandenen
Prozesssteuerungen zu erfordern. Eine voraus-
schauende Kollisionsprüfung wird vorgestellt, die den Rechenaufwand
für Geschwindigkeitsvorgaben auf ein Minimum
reduziert. Dadurch können Kollisionsprüfungen in
sehr kurzer Zykluszeit erfolgen.
Manuskripteingang
09.09.2010
ReferenZEn
Im Peer-Review-Verfahren begutachtet
[1] United States Patent 2988237, Inventors: Devol Jr., George C.
[2] Philadelphia Inquirer - August 11, 1983 - A10 NATIONAL
[3] IFR Statistical Department, World Robotics 2010
(http://www.worldrobotics.org/downloads/2009_executive_summary.pdf)
[4] Datenbank BG-PRÜFZERT – tested products
(http://www.hvbg-service.de/pruefz.tpl/produkt.htm)
[5] Pilz SafetyEye – (http://www.pilz.de/company/press/messages/sub/
products/articles/00951)
[6] Little brother is protecting you, Der Arbeits- und Gesundheitsschutz
entdeckt die Transponder-Technologie (Teil 1), holzinfo 132 Oktober –
Dezember 2008
[7] the DLR lightweight robot: Design and control concepts for robots in
human environments, The Industrial Robot Band 34 (2007) Heft 5, Seite
376-385, A. Albu-Schäffer, S. Haddadin, C Ott, A Stemmer, T Wimböck,
G Hirzinger; Deutsches Zentrum für Luft- und Raumfahrt (DLR), Germany
[8] technische Vorraussetzungen zur Mensch-Roboter Kooperation,
P. Heiligensetzer, (http://www.bg-metall.de/fileadmin/downloads/
FA_MFS/Symposien/Praesentation__KUKA.pdf)
[9] rob@work: Robot Assistant in Industrial Environments, MORPHA,
E. Helms, R. D. Schraft and M. Hägele, 2002
[10] Industrial jointed arm robot evading dynamic objects, Master Thesis,
Björn Ostermann, (http://www.maschinenbautage.eu/fileadmin/
veroeffentlichungen/Master_Thesis_Bjoern_Ostermann.pdf)
Autoren
M.Sc. Dipl.-Ing. (FH)
Björn Ostermann
(geb. 1980) hat 2009
den „Master of Science
in Autonomous
Systems“ erworben.
Zurzeit promoviert er
zum Thema kollaborierende
Roboter an
der Bergischen Universität Wuppertal im
Fachgebiet Sicherheitstechnik / Arbeitssicherheit.
Die Arbeit wird am Institut für
Arbeitschutz (IFA) durchgeführt.
Institut für Arbeitsschutz der Deutschen
Gesetzlichen Unfallversicherung (IFA)
Fachbereich 5: Unfallverhütung /
Produktsicherheit,
Alte Heerstrasse 111, D-53757 Sankt Augustin,
Tel. +49 (0) 2241 231 26 70,
E-Mail: Bjoern.Ostermann@dguv.de
Dr. Michael HuELKE
(geb. 1959) ist
Dipl.-Ing. (TU)
Elektrotechnik. Er
leitet im Fachbereich
5 „Unfallverhütung
– Produktsicherheit“
das Referat „Neue
Technologien,
Mensch und Technik“ mit den Schwerpunkten
Funktionale Sicherheit sowie
biomechanische und kognitive Mensch-
Maschine-Schnittstellen.
Institut für Arbeitsschutz der Deutschen
Gesetzlichen Unfallversicherung (IFA)
Fachbereich 5: Unfallverhütung /
Produktsicherheit,
Alte Heerstrasse 111, D-53757 Sankt Augustin,
Tel. +49 (0) 2241 231 26 44
E-Mail: Michael.Huelke@dguv.de
Prof. Dr.-Ing.-habil.
Anke KAHL
(geb. 1969) leitet an
der Bergischen
Universität Wuppertal
im Fachbereich
D das Fachgebiet
Sicherheitstechnik/
Arbeitssicherheit.
Zu ihren Gebieten gehört Methodik der
Arbeitssicherheit, Arbeitsschutz, und
Gefahrstoffmanagement. Sie ist unter
anderem Mitglied im Ausschuss für
Gefahrstoffe (AGS) am BMAS.
Bergische Universität Wuppertal,
FB D, Fachgebiet Sicherheitstechnik/
Arbeitssicherheit,
Gaußstraße 20, D-42119 Wuppertal,
Tel. +49 (0) 202 439 20 53,
E-Mail: akahl@uni-wuppertal.de
atp edition
9 / 2011
59
praxis
Robuste Laptops unterstützen die papierfreie und
lückenlose Dokumentation in der Pharmafertigung
Produktionsdurchführung, Chargenkontrolle und Qualitätsmanagement aus einem Guss
Mobil auch in
extremen uMgebungen:
Daiichi
Sankyo setzt robuste
Acturion-Laptops im
Werk Pfaffenhofen
ein. Bild: Acturion
Komplexe Produktionsabläufe und eine lückenlose Dokumentation
müssen Medikamentenhersteller managen. Mit robusten
Laptops, einem SAP-System und Wireless-Verbindungen laufen die
Prozesse im deutschen Werk des japanischen Pharmakonzerns
Daiichi Sankyo nun erheblich schneller und papierlos ab.
Bild: Daiichi Sankyo
Der japanische Pharmakonzern Daiichi Sankyo führte
in seinem deutschen Werk in Pfaffenhofen eine
durchgängige elektronische Dokumentation ein, die besonders
den Mitarbeitern in Logistik- und Produktion
völlige Mobilität und eine kontinuierliche Verbindung
zum Netzwerk sichert. Als Bestandteile dieses Systems
sorgen robuste Mobil-Computer, ein SAP-System und
drahtlose Verbindungen dafür, dass Produktionsdurchführung,
Chargenkontrolle und Qualitätsmanagement
ohne Medienbruch miteinander verbunden sind.
VOLLSTÄNDIGER CHARGEN-STAMMBAUM NÖTIG
Wer viele Länder der Welt mit selbst entwickelten und
produzierten Arzneimitteln versorgt, kennt die inhaltlichen
und logistischen Hürden internationaler Vielfalt:
Der jährliche Ausstoß mehrerer Milliarden Arzneimittel-
Einheiten zieht Chargennummern und Herstellernachweise
nach sich, die dauerhaft archiviert werden müssen.
Größen von Tabletten, Verpackungen oder Beilagen differieren,
die Packungsbeilage enthält eine unterschiedliche
Anzahl von Sprachen. Dies führt zu wechselnden
Kampagnen und komplizierten Umrüstungen in der Herstellung
und Konfektionierung.
Ohne elektronische Unterstützung meistern Unternehmen
diese Datenflut kaum. Hinzu kommt, dass nur ein
lückenloser Herstellungsnachweis entlang der gesamten
Wertschöpfungskette vor Haftungsansprüchen schützt,
die auf Verwendung von Plagiaten fußen. Auch die lückenlose
Rückverfolgbarkeit jeder einzelnen Charge gelingt
elektronisch ungleich zuverlässiger und schneller.
Zusätzlich erleichtert sie spätere Recherchen immens.
Wer je in mehreren prallvollen Papierordnern nach einer
bestimmten Chargennummer oder einem winzigen Detail
geforscht hat, weiß, wie viele Stunden und Nerven
das kostet. Und nicht zu vergessen: Es geht um Arzneimittel.
Ein vollständiger und durchgehender Chargen-
‚Stammbaum‘ vom Rohstoff bis zum ausgelieferten Fertigarzneimittel
bescheinigt Qualität und Know-how, die
im Produkt stecken.
UNEINGESCHRÄNKTE MOBILITÄT FÜR MITARBEITER
Der Pharmakonzern Daiichi Sankyo mit Hauptsitz in Tokyo
gehört zu den 20 weltweit größten Pharmaunternehmen.
29 000 Mitarbeiter entwickeln, produzieren und
distribuieren pharmazeutische Bulk- und Fertigarzneimittel
sowie Klinikmuster mit Schwerpunkt auf kardiovaskulären
Erkrankungen, Diabetes und Stoffwechselstörungen,
Knochen- und Gelenkleiden, Infektionskrankheiten,
Krebs und Störungen des Immunsystems. Die europäische
Produktionsstätte befindet sich in bayerischen
Pfaffenhofen. 400 Mitarbeiter produzieren dort jährlich
über 25 Millionen Packungen und zwei Milliarden Tabletten,
die in 50 Länder ausgeliefert werden.
2008 entschied sich das Werk in Pfaffenhofen für die
elektronische Dokumentation, um Produktionsdurchführung,
Chargenkontrolle und Qualitätsmanagement ohne
Medienbruch miteinander zu verbinden. Im Zuge dessen
fiel die Wahl auf die Einführung eines SAP-Systems. Mit-
60
atp edition
9 / 2011
arbeiter gerade im Logistik- und Produktionsbereich sollten
überall völlige Mobilität und ständige Netzverbindung
genießen. „Jeder Beteiligte sollte von jedem Ort aus Daten
prüfen und eingeben, sich mit anderen austauschen können“,
so SAP User Support Oliver Oltmanns.
Die Frage lautete damals: Verkabelung oder Wireless?
Verkabelung bedeutet einen längeren Produktionsstillstand,
denn Wände aufzureißen raubt mehr Zeit als Antennen
zu installieren. Drahtlos gewann eindeutig und
warf die Frage nach geeigneten Terminals auf: Die verwendeten
Laptops müssen unbedingt industrietauglich
sein, denn im Produktionsalltag haben Mitarbeiter keine
Muße, ihre Arbeitshilfen mit Glacéhandschuhen anzufassen;
auch ein Sturz darf sie nicht beschädigen.
EXTREM ROBUSTER PCMCIA-SCHACHT
Ein weiteres maßgebliches Kriterium bildete die Kompatibilität
zu den zu nutzenden Funkscannern. Die zur
Verbindungsaufnahme erforderlichen Karten übertrafen
die Breite eines gewöhnlichen PCMCIA-Schacht ums
Doppelte. Doppelte Slots aber sind meist durch eine
hauchdünne Blechwand getrennt. Wichtig war also ein
doppelter PCMCIA-Schacht, der die Cards akzeptierte
– nur dann würde Daiichi-Sankyo seine IT-Lösung tatsächlich
ausschöpfen können.
Die gewünschte Stabilität, Kommunikationsfähigkeit
und den erforderlichen doppelten PCMCIA-Schacht fand
das Unternehmen beim ruggedized Computer Durios V12
des ebenfalls in Bayern beheimateten Systemhauses Acturion.
Schon seit mehr als zwei Jahren bewähren sich
die mittlerweile 56 robusten Rechner ebenso wie der
flexible Service der Hardwareexperten.
Die sowohl als Tablet-PC wie auch als Industrie-Notebook
einsetzbaren IT-Lösungen Durios V10 und V12 Ultra
trotzen widrigen Verhältnissen und weisen sehr hohe
Schutzklassen auf. Die full-ruggedized V-Serie eignet
sich daher für Einsätze in großer Kälte, bei Explosionsgefahr
sowie für Arbeiten mit Staub- oder Wasserkontakt.
Mit MIL-STD810G und MIL-STD 461F erfüllt die V-Reihe
militärische Normen: Die PCs bestanden Testszenarien
bei -51 °C. Staub und Flüssigkeiten schaden den
Komponenten der V-Serie nicht, Schutzklasse IP65 bescheinigt
Beständigkeit sogar bei Wasserstrahlen. Wer
bei seiner Tätigkeit Salzwasser ausgesetzt ist, wählt als
schützende Sonderoption die Verarbeitung von Edelstahlschrauben,
einer speziellen Oberflächenbeschichtung
sowie die Integration einer Gummitastatur.
EINSATZ IN HAZARDOUS ZONES
Die strenge europäische ATEX-Norm erlaubt eine Verwendung
dieser Acturion-Rechner in sogenannten Hazardous
Zones – Arealen mit brennbaren Gasen, Dämpfen und Stäuben,
in denen Explosionsgefahr herrscht. Sonnenlichtlesbares
Display, nutzerfreundliche Bedienung per Stift oder
Touchscreen und schockresistenter Festplattenschutz flankieren
die innen liegenden Leistungskomponenten.
Im geschlossenen Metallgehäuse arbeitet der Core-
2-Duo-Prozessor SU9400 von Intel mit 1,4 GHz Taktrate.
Die Basisvariante verfügt über 1 GB Arbeits-, 160 GB
Festplatten- und 384 MB Grafikspeicher. Für den Einsatz
im Büro steht eine externe Dockingstation zur Verfügung.
Um die speziellen Bedürfnisse des Nutzers zu erfüllen,
passt Acturion jedes der bestellten Geräte an die
Anwendungsgebiete an.
Bei Daiichi Sankyo kommen die Laptops in den Abteilungen
Herstellung, Konfektionierung und Lager/Versand
zum Einsatz. In der Feststoffherstellung und Konfektionierung
nehmen Mitarbeiter alle produkt- und
prozessspezifischen Daten elektronisch auf. Welcher
Wirkstoff ist in welche Mischung oder Granulat eingeflossen,
wann wurde welche Tablettencharge gepresst?
Welches Etikett und welche Faltschachtel wurden in der
Konfektionierung verarbeitet? Für jede dieser zahlreichen
Angaben füllen die SAP-geschulten Mitarbeiter
spezielle Eingabemasken in der elektronischen Herstellanweisung
aus.
SCHNELLERE PROZESSE UND WENIGER PAPIER
Die eingegebenen Produkt- und Prozessparameter werden
direkt online gegen die hinterlegten Grenzwerte
geprüft. Alle verwendeten Rohstoffe und Materialien
identifiziert der Funkscanner – die zugehörige Chargennummer
fließt in den Chargenverwendungsnachweis
ein, damit jeder Einsatzstoff des Gesamtprozesses nachvollziehbar
bleibt. Kritische Schritte im Prozess bestätigen
Bediener mit ihrer digitalen Signatur.
Im Bereich Lager/Versand verwalten User mithilfe
ihrer widerstandsfähigen Notebooks Warenlager sowie
Distribution und bilden den innerbetrieblichen Materialfluss
vollständig ab. „Der gesamte Prozess läuft
nicht nur viel schneller ab – ich freue mich auch sehr
darüber, dass die Unmengen an Papier endlich der Vergangenheit
angehören“, betont SAP User Support Oliver
Oltmanns, der den Mitarbeitern Umgang mit PC und
SAP nahebrachte.
Autor
Acturion Datasys GmbH,
Mühlweg 2a, D-82054 Sauerlach,
Tel. +49 (0) 8104 629 33 10,
E-Mail: o.husmann@acturion.com
Dipl.-Wirtsch.-Ing. Oliver
Husmann ist Geschäftsführer
von Acturion.
atp edition
9 / 2011
61
impressum / Vorschau
Impressum
Vorschau
Verlag:
Oldenbourg Industrieverlag GmbH
Rosenheimer Straße 145
D-81671 München
Telefon + 49 (0) 89 4 50 51-0
Telefax + 49 (0) 89 4 50 51-3 23
www.oldenbourg-industrieverlag.de
Geschäftsführer:
Carsten Augsburger
Jürgen Franke
Hans-Joachim Jauch
Herausgeber:
Dr. V. Huck
Dr. G. Kegel
Dipl.-Ing. H. Kumpfmüller
Dr. N. Kuschnerus
Beirat:
Dr.-Ing. K. D. Bettenhausen
Prof. Dr.-Ing. Ch. Diedrich
Prof. Dr.-Ing. U. Epple
Prof. Dr.-Ing. A. Fay
Prof. Dr.-Ing. M. Felleisen
Prof. Dr.-Ing. G. Frey
Prof. Dr.-Ing. P. Göhner
Dipl.-Ing. Th. Grein
Prof. Dr.-Ing. H. Haehnel
Dr.-Ing. J. Kiesbauer
Dipl.-Ing. R. Marten
Dipl.-Ing. G. Mayr
Dr. J. Nothdurft
Dr.-Ing. J. Papenfort
Dr. A. Wernsdörfer
Dipl.-Ing. D. Westerkamp
Dr. Ch. Zeidler
Organschaft:
Organ der GMA
(VDI/VDE-Gesell schaft Messund
Automatisierungs technik)
und der NAMUR
(Interessen gemeinschaft
Automatisierungs technik der
Prozessindustrie).
Redaktion:
Gerd Scholz (verantwortlich)
Telefon + 49 (0) 89 4 50 51-3 44
Telefax + 49 (0) 89 4 50 51-3 23
E-Mail: scholz@oiv.de
Anne Hütter
Telefon + 49 (0) 89 4 50 51-4 18
Telefax + 49 (0) 89 4 50 51-3 23
E-Mail: huetter@oiv.de
Einreichung von Hauptbeiträgen:
Prof. Dr.-Ing. Leon Urbas
(Chefredakteur, verantwortlich
für die Hauptbeiträge)
Technische Universität Dresden
Fakultät Elektrotechnik
und Informationstechnik
Professur für Prozessleittechnik
D-01062 Dresden
Telefon +49 (0) 351 46 33 96 14
E-Mail: urbas@oiv.de
Fachredaktion:
M. Blum
Prof. Dr. J. Jasperneite
Dr. B. Kausler
Dr. N. Kiupel
Dr. W. Morr
I. Rolle
F. Schiller
Bezugsbedingungen:
„atp edition – Automatisierungstechnische
Praxis“ erscheint
monatlich mit einer Doppelausgabe im
Januar/Februar und Juli/August.
Bezugspreise:
Abonnement (Deutschland):
€ 460,– + € 30,– Versand
Abonnement (Ausland):
€ 460,– + € 35,– Versand
Einzelheft: € 55,– + Versand
Die Preise enthalten bei Lieferung
in EU-Staaten die Mehrwertsteuer,
für alle übrigen Länder sind es
Nettopreise. Mitglieder der GMA: 30%
Ermäßigung auf den Heftbezugspreis.
Bestellungen sind jederzeit über den
Leserservice oder jede Buchhandlung
möglich.
Die Kündigungsfrist für Abonnementaufträge
beträgt 8 Wochen zum
Bezugsjahresende.
Abonnement-/
Einzelheftbestellung:
Leserservice atp
Postfach 91 61, D-97091 Würzburg
Telefon + 49 (0) 931 4170-1615
Telefax + 49 (0) 931 4170-492
E-Mail: leserservice@oiv.de
Verantwortlich für
den Anzeigenteil:
Annemarie Scharl-Send
Mediaberatung
sales & communications Medienagentur
Kirchfeldstraße 9, D-82284 Grafrath
Tel. +49 (0) 8144 9 96 95 12
Fax +49 (0) 8144 9 96 95 14
E-Mail: ass@salescomm.de
Anzeigenverwaltung:
Brigitte Krawczyk
Telefon + 49 (0) 89 4 50 51-2 26
Telefax + 49 (0) 89 4 50 51-3 00
E-Mail: krawczyk@oiv.de
Druck:
Druckerei Chmielorz GmbH
Ostring 13
D-65205 Wiesbaden-Nordenstadt
Gedruckt auf chlor- und
säurefreiem Papier.
Die atp wurde 1959 als „Regelungstechnische
Praxis – rtp“ gegründet.
© 2011 Oldenbourg Industrieverlag
GmbH München
Die Zeitschrift und alle in ihr enthaltenen
Beiträge und Abbildungen sind urheberrechtlich
geschützt. Mit Ausnahme
der gesetzlich zugelassenen Fälle ist
eine Verwertung ohne Ein willigung des
Verlages strafbar.
ISSN 2190-4111
Die Ausgabe 10 / 2011 der
erscheint am 4.10.2011
Mit folgenden Beiträgen:
Berechnung der Zuverlässigkeit
technischer Systeme
unter Feldbedingungen
Verfügbarkeitsberechnung von
Automatisierungsnetzwerken
Zuverlässigkeitsbewertung von
Automatisierungssystemen in
frühen Entwicklungsphasen
Leitfaden zur Entwicklung
von Safety-Applikationen
...und vielen weiteren Themen.
Aus aktuellem Anlass können sich die Themen
kurzfristig verändern.
LeserService
e-Mail:
leserservice@oiv.de
Telefon:
+ 49 (0) 931 4170-1615
62
atp edition
9 / 2011