atp edition Anforderungsanalyse für das integrierte Engineering (Vorschau)
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
5 / 2012<br />
54. Jahrgang B3654<br />
Oldenbourg Industrieverlag<br />
Automatisierungstechnische Praxis<br />
<strong>Anforderungsanalyse</strong> <strong>für</strong> <strong>das</strong><br />
<strong>integrierte</strong> <strong>Engineering</strong> | 28<br />
Datenkonsistenz mit<br />
AutomationML herstellen | 36<br />
Automatisiertes<br />
Kommunikationsengineering | 44<br />
Simulationsbasierte<br />
Steuerungsfunktionstests | 54
EDITORIAL<br />
Von der Softwareintegration<br />
zur Interoperabilität<br />
Das Sprichwort „ Zeit ist Geld“ trifft die derzeitige Situation der Unternehmen<br />
in der Prozessindustrie besonders gut. Denn Anlagenplaner und Anlagenbetreiber<br />
stehen heutzutage vor immensen H erausforderungen: Zunehmender<br />
internationaler Wettbewerb erfordert die Steigerung von Produktivität und<br />
Qualität. Der dadurch erhöhte Kosten- und Zeitdruck macht eine Parallelisierung<br />
der Arbeitsabläufe unabdingbar. Erschwerend kommt hinzu, <strong>das</strong>s den<br />
erweiterten und strengen gesetzlichen Vorschriften im H inblick auf Sicherheits-<br />
und Umweltschutzstandards Rechnung getragen werden muss. Zum<br />
anderen erwarten Kunden maßgeschneiderte Produkte in Top-Qualität zu attraktiven<br />
Preisen, während die Markteintrittszeiten immer kürzer werden.<br />
Ein Schlüssel zum Erfolg liegt sicherlich in der vollständigen Integration<br />
aller Prozessabläufe von Planung, Betrieb und Instandhaltung. Nur wer seine<br />
Anlage funktionsorientiert betrachtet, und nicht nach Gewerken und Fachdisziplinen,<br />
ist in der Lage, effiziente Arbeitsabläufe zu etablieren und die Produktivität<br />
langfristig zu erhöhen.<br />
Dabei ist jedoch vor allem eins nicht zu vergessen: Der Umgang mit und die<br />
Qualität von Daten. Denn die Menge digitaler Daten in heutigen Anlagenmanagement-Projekten<br />
ist beachtlich – mittlerweile ist es nicht ungewöhnlich,<br />
<strong>das</strong>s in Industrieanlagen Datenmengen im Terabyte Bereich generiert und<br />
verwaltet werden müssen. H äufig liegt die Anlagendokumentation jedoch in<br />
unübersichtlicher Papierform vor und spiegelt nicht den As-built-Zustand der<br />
Anlage wider, da Veränderungen nur unzureichend oder gar nicht dokumentiert<br />
wurden. Damit ist ein schneller und produktiver Zugriff auf notwendige<br />
Daten schlichtweg unmöglich.<br />
Anlagenplaner und -betreiber versuchen, ihre enormen Datenmengen durch<br />
den Einsatz von Software-Anwendungen zu managen. Dabei handelt es sich<br />
jedoch meist um reine Insellösungen, bei denen die eingesetzten Software-<br />
Systeme nur Teilbereiche einzelner Gewerke oder spezieller Funktionalitäten<br />
abdecken.<br />
Gerade deshalb steckt auch in dem Thema Standardisierung noch immer<br />
jede Menge Optimierungspotenzial. Nur gemeinsame Standards und frei konfigurierbare<br />
Schnittstellen schaffen die notwendig offene Architektur, welche<br />
die nahtlose Zusammenarbeit zwischen unterschiedlichen Systemen ermöglicht.<br />
So gelingt der Brückenschlag von der reinen Softwareintegration zur<br />
Interoperabilität.<br />
Festzuhalten bleibt: Integriertes Datenmanagement ist und bleibt H erausforderung<br />
und Möglichkeit zugleich!<br />
ANDREAS GEISS,<br />
Leiter Comos Industry Solutions,<br />
Siemens Industry Automation<br />
Division, Nürnberg<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
3
INHALT 5 / 2012<br />
VERBAND<br />
6 | Standardisierung von Informationsschnittstellen:<br />
Neue Namur-Empfehlungen legen Regeln fest<br />
Lohn <strong>für</strong> Strukturreform: VDI ist Verband des J ahres<br />
BRANCHE<br />
8 | Neuer GMA-Fachausschuss <strong>für</strong> Ethernet-basierte Bussysteme<br />
in der industriellen Automatisierung<br />
9 | Umsatz und Aufträge im Februar gebremst<br />
Netzwerken <strong>für</strong> <strong>das</strong> Smart Grid<br />
FORSCHUNG<br />
10 | Saarbrücker automatisieren <strong>das</strong> Fingerspitzengefühl bei Robotern<br />
Sprengstoffanalyse gelingt dank optimierter Raman-Spektroskopie<br />
nun auch aus großer Distanz<br />
11 | Tool-Entwicklung und IT-Dienst in der Praxis<br />
„ Smarter“ Tisch <strong>für</strong> neue Bedienkonzepte<br />
SCHWERPUNKT | SENSORIK<br />
12 | Satter Aufschwung: Markt <strong>für</strong> Prozess-Sensorik wächst<br />
bis 2 0 1 6 um rund sechs Prozent pro J ahr<br />
16 | Planung von Messstellen: Variable Messumformer<br />
bieten höhere Genauigkeit<br />
20 | Ausgeklügte Logistiksysteme reduzieren<br />
H andlingkosten von Verbindungselementen<br />
22 | Signalaufbereitung in der Druckmesskapsel<br />
macht Sensoren kleiner und robuster<br />
4<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
PRAXIS<br />
24 | Frühzeitige dynamische Simulationen erhöhen Sicherheit<br />
bei Inbetriebnahme und Betrieb<br />
HAUPTBEITRÄGE<br />
28 | <strong>Anforderungsanalyse</strong> <strong>für</strong> <strong>das</strong> <strong>integrierte</strong> <strong>Engineering</strong><br />
S. BIFFL, R. MORDINYI UND T. MOSER<br />
36 | Datenkonsistenz mit AutomationML herstellen<br />
R. DRATH, M. HOERNICKE UND B. SCHRÖTER<br />
44 | Automatisiertes Kommunikationsengineering<br />
F. DOHERR, M. STÖSS UND L. URBAS<br />
54 | Simulationsbasierte Steuerungsfunktionstests<br />
M. BARTH, A. FAY, J. GREIFENEDER UND P. WEBER<br />
RUBRIKEN<br />
3 | Editorial<br />
4 | Inhalt<br />
62 | Impressum, <strong>Vorschau</strong><br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
5
H<br />
VERBAND<br />
Standardisierung von Informationsschnittstellen:<br />
Neue Namur-Empfehlungen legen Regeln fest<br />
DIE NAMUR-<br />
EMPFEHLUNG 141<br />
zielt auf Systeme,<br />
die Batch-<br />
Informationen<br />
austauschen.<br />
Bild: Namur<br />
<strong>Engineering</strong>/<br />
Simulations-<br />
Werkzeuge<br />
Produktionsfeinplanungssysteme<br />
PLS/MES mit<br />
Rezeptur steuerung<br />
LIMS<br />
und ERP<br />
Batch-<br />
Informationen<br />
Online<br />
Batch-KPI-<br />
Monitore<br />
Batch-<br />
Analyse-<br />
Werkzeuge<br />
PIMS mit<br />
Batch-Historie<br />
Die Namur hat zwei neue Empfehlungen – NE 1 3 9 und<br />
1 4 1 – veröffentlicht. Die „ NE 1 4 1 Schnittstelle zwischen<br />
Batch- und MES-Systemen“ definiert Anforderungen<br />
an die Schnittstelle zwischen Batch-Systemen und MES-<br />
Lösungen (Manufacturing Execution System) und ergänzt<br />
damit wesentliche, in der Prozessindustrie bisher fehlende<br />
Aspekte der Standardisierung. Denn in vielen Vorhaben<br />
erweist sich bis heute die Einführung dieser Schnittstellen<br />
als technische H erausforderung.<br />
Die Anforderungsbeschreibung ist technologieneutral<br />
formuliert und bewusst nicht <strong>für</strong> spezifische Kommunikationstechnologien<br />
ausgelegt. Internationale Standardisierungsarbeiten<br />
wie IEC 6 1 5 1 2 (ISA S8 8 ), IEC 6 2 2 6 4 (S9 5 ) und<br />
die davon abgeleiteten Kommunikationsstandards BatchML<br />
und B2 MML wurden als Basis <strong>für</strong> die NE 1 4 1 verwendet.<br />
Der nachhaltigen Integration von Batch-Systemen und<br />
MES-Lösungen kommt dabei eine besondere Bedeutung<br />
zu. Die Integration sollte nur über standardisierte, offene<br />
und systemunabhängige Schnittstellen erfolgen. Bei Bedarf<br />
können nach dem Muster der NE 1 4 1 auch weitere<br />
Schnittstellen spezifiziert werden.<br />
Anlagenbetreibern, aber auch Systemanbietern wird mit<br />
dieser Empfehlung eine Anforderungsspezifikation zur<br />
Verfügung gestellt, welche ihnen bei der Auswahl und Entwicklung<br />
von Schnittstellen zu Batch-Systemen Unterstützung<br />
bietet. Werden die Vorgaben umgesetzt, ergeben sich<br />
aufgrund der Schnittstellen-Vereinheitlichung Kosteneinsparungen<br />
beim Aufbau und der langfristigen Pflege von<br />
Schnittstellen zwischen unterschiedlichen Systemen zum<br />
Austausch von Batch-Informationen.<br />
Die „ NE 1 3 9 Informationsschnittstellen in der Prozessautomatisierung<br />
– Betriebliche Eigenschaften“ hat einen<br />
weiter gefassten Ansatz. Denn neben der funktionalen<br />
Festlegung der einzelnen Schnittstellen ist insbesondere<br />
ein allgemeines Schema wünschenswert, <strong>das</strong> es dem Anwender<br />
erlaubt, die nichtfunktionalen Anforderungen an<br />
eine Schnittstelle, beispielsweise Anforderungen an die<br />
Informationssicherheit, die Verfügbarkeit, <strong>das</strong> Echtzeitverhalten,<br />
die Übertragungsleistung oder die Fehlersicherheit<br />
im Einzelfall einfach und einheitlich zu formulieren.<br />
Die NE 1 3 9 verfolgt zwei Ziele: Erstens formuliert sie<br />
ein allgemeines Schnittstellenkonzept, <strong>das</strong> als Grundlage<br />
<strong>für</strong> weitere Schnittstellenspezifikationen verwendet werden<br />
kann und die Arbeit anderer Namur-Arbeitskreise<br />
und Normungsgremien unterstützt und zweitens definiert<br />
sie Qualitätsmerkmale, mit denen sich die nichtfunktionalen<br />
Eigenschaften einer Schnittstelle quantitativ beschreiben<br />
lassen. Diese Qualitätsmerkmale ermöglichen<br />
es den Anwendern, in konkreten Projekten Anforderungen<br />
an die Qualität einer Schnittstelle einfach, standardisiert<br />
und eindeutig zu formulieren.<br />
NAMUR-GESCHÄFTSSTELLE,<br />
c/o Bayer Technology Services GmbH,<br />
Gebäude K 9, D-51368 Leverkusen,<br />
Tel. +49 (0) 214 307 10 34, Internet: www.namur.de<br />
Lohn <strong>für</strong> Strukturreform: VDI ist Verband des J ahres<br />
DIE AUSZEICHNUNG<br />
als Verband des Jahres<br />
„würdigt die Leistungen<br />
aller VDI-Mit arbeiter“,<br />
betont VDI-Direktor<br />
Dr.-Ing. Willi Fuchs.<br />
Bild: VDI<br />
Der VDI ist in der Kategorie „ Reform und Management“<br />
zum Verband des J ahres 2 0 1 2 gekürt worden. Die J ury<br />
der Deutschen Gesellschaft <strong>für</strong> Verbandsmanagement e.V.<br />
(DGVM) übergab diesen DGVM Innovation Award „ Verband<br />
des J ahres 2 0 1 2 “ im Rahmen des 1 3 . Deutschen Verbändekongress<br />
an VDI-Direktor Dr.-Ing. Willi Fuchs.<br />
Die DGVM würdigte damit die beispielhafte Umsetzung<br />
der Umstrukturierung des Vereins Deutscher Ingenieure<br />
von einer Linien- zu einer Matrixorganisation. Der<br />
VDI habe durch umfangreiche Re-Strukturierungsmaßnahmen<br />
eine Corporate Identity aller Beteiligten, in<br />
aupt- und Ehrenamt, geschaffen und dadurch die Leistungsfähigkeit<br />
aller Beteiligten deutlich gesteigert. Besonders<br />
überzeugt zeigte sich die J ury vom zukunftsfähigen<br />
Konzept, der hohen Veränderungsbereitschaft und der<br />
herausragenden Führungsqualität des VDI.<br />
„ Ich freue mich ganz besonders über diese Auszeichnung“<br />
, sagte Fuchs nach der Verleihung. „ Sie würdigt die<br />
Leistungen aller VDI-Mitarbeiter, denn die Umstrukturierung<br />
unserer Organisation konnte nur mit dem Engagement<br />
und der Einsatzbereitschaft aller Mitarbeiterinnen<br />
und Mitarbeiter so erfolgreich umgesetzt werden“ ,<br />
so Fuchs weiter. Diesen Innovationspreis vergibt die<br />
DGVM seit 1 9 9 7 . 2 0 1 2 wurde die Auszeichnung erstmalig<br />
in drei Kategorien verliehen.<br />
VEREIN DEUTSCHER INGENIEURE E.V.,<br />
VDI-Platz 1, D-40468 Düsseldorf,<br />
Tel. +49 (0) 211 621 40, Internet: www.vdi.de<br />
6<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
E20001-F160-M117<br />
Gewinne optimiert man nicht über<br />
Nacht. Aber Tag <strong>für</strong> Tag.<br />
Realisieren auch Sie <strong>das</strong> Potenzial energieeffizienter Lösungen<br />
Knapper werdende Ressourcen, steigende Energiekosten<br />
sowie immer strengere Umweltauflagen verschärfen den<br />
Druck auf die Industrie, effizienter als bisher mit Energie<br />
umzugehen. Und <strong>das</strong> Potenzial ist riesig. Bis zu 70 % der<br />
eingesetzten Energie in Industriebetrieben werden allein<br />
durch elektrische Antriebe und Motoren verbraucht.<br />
Ob moderne Energiesparmotoren oder innovative Software-Anwendungen<br />
– wir bieten Ihnen ein umfangreiches<br />
Portfolio an energieeffizienten Produkten und Lösungen<br />
sowie umfassendes Energy Consulting. Damit erzielen<br />
Sie auf Dauer Effizienzgewinne, die Sie immer wieder<br />
machen. Tag <strong>für</strong> Tag.<br />
siemens.de/energieeffizienz
BRANCHE<br />
Neuer GMA-Fachausschuss <strong>für</strong> Ethernet-basierte<br />
Bussysteme in der industriellen Automatisierung<br />
Mit einem neuen Fachausschuss will die VDI/VDE<br />
Gesellschaft Mess- und Automatisierungstechnik<br />
(GMA) ein gemeinsames Verständnis und ein angepasstes<br />
Vorgehensmodell von H erstellern, Systemintegratoren<br />
und Anwendern erarbeiten, <strong>das</strong> den zuverlässigen<br />
Betrieb von Ethernet-Netzwerken in der Automation sicherstellt.<br />
Der GMA-Fachausschuss „ Zuverlässiger Betrieb<br />
Ethernet-basierter Bussysteme in der industriellen<br />
Automatisierung“ soll sich vor allem diesen thematischen<br />
Schwerpunkten widmen:<br />
automatisierungsgerechtes Netzwerkmanagement,<br />
Überwachung der Betriebsbereitschaft, der Topologie,<br />
der Auslastung und der Leistung des Netzwerkes,<br />
Nutzung von Redundanzmechanismen zur Erhöhung<br />
der Ausfallsicherheit,<br />
Monitoring des Netzwerks zur Erkennung von Verhaltensdivergenzen,<br />
etwa Ermittlung von Ä nderungen<br />
gegenüber dem Normalverhalten,<br />
Diagnose und prädiktive Entscheidungsfindung,<br />
<strong>integrierte</strong>, dynamische Netzwerkdokumentation.<br />
automatisierungsgerechte Planung und Installation<br />
auf Basis existierender Vorgehensmodelle und Spezifikationen,<br />
ETHERNET-BASIERTE Kommunikationslösungen<br />
halten Einzug in die Automatisierungstechnik.<br />
Ein neuer GMA-Fachausschuss soll Regeln <strong>für</strong><br />
den zuverlässigen Betrieb erarbeiten. Bild: Audi<br />
Notwendig sei der Fachausschuss, da Ethernet-basierte<br />
Kommunikationslösungen sich als Ergänzung der Feldbussysteme<br />
verbreiten. Neben Themen wie Echtzeitfähigkeit<br />
müsse vor allem der zuverlässige Betrieb gewährleistet<br />
werden. Dies schließe Konzepte und Lösungen zu<br />
Redundanz, Diagnose, Safety und Security ein. Zunächst<br />
soll eine Übersicht und Einordnung von Anforderungen<br />
und existierenden Lösungen erarbeitet werden, auf deren<br />
Basis Best-Practice-Lösungen und H andlungsempfehlungen<br />
sowie ein Technologiekatalog erarbeitet werden. Im<br />
Bedarfsfall werden eigene Spezifikationen erstellt.<br />
Die Ergebnisse sollen als VDI/VDE-Richtlinie veröffentlicht<br />
werden. Experten von Anwendern, Betreibern, Entwicklern<br />
und H erstellern, bittet die GMA um Mitarbeit.<br />
Informationen sind in der GMA-Geschäftsstelle erhältlich<br />
(gma@ vdi.de, Betreff: „ Mitarbeit beim FA Zuverlässiger<br />
Betrieb Ethernet-basierter Bussysteme“ ).<br />
VDI/VDE-GESELLSCHAFT MESS- UND<br />
AUTOMATISIERUNGSTECHNIK (GMA)<br />
VEREIN DEUTSCHER INGENIEURE E.V.,<br />
VDI-Platz 1, D-40468 Düsseldorf,<br />
Tel. +49 (0) 211 621 40, Internet: www.vdi.de<br />
Informationsmodelle <strong>für</strong> Middleware in der Automatisierung<br />
DIE AUSGABE 11 DER ATP EDITION wird<br />
sich dem Thema Informationsmodelle<br />
<strong>für</strong> Middleware in der Automatisierungstechnik<br />
widmen. Middleware <strong>für</strong> die Automatisierungstechnik<br />
ist eine Softwareschicht<br />
zur Verbindung von Komponenten<br />
einer automatisierungstechnischen<br />
Anwendung.<br />
Generische und spezifische semantisch<br />
belegte Informationsmodelle dienen dabei<br />
der Abstraktion und Homogenisierung<br />
des Daten- und Informationsraums. Sie<br />
spielen eine wesentliche Rolle bei der Automatisierung<br />
der Automatisierung, bei<br />
Cyber-Physical Systems, und bei Systemen<br />
mit hohen Anforderungen an Adaptierbarkeit<br />
und Wandelbarkeit. Die wesentliche<br />
Herausforderung besteht darin,<br />
Informationsmodelle derart zu gestalten,<br />
<strong>das</strong>s sie den Anforderungen der industriellen<br />
Automatisierung genügen.<br />
Wir bitten Sie, bis zum 20. Juni 2012<br />
zu diesem Themenschwerpunkt einen<br />
gemäß <strong>atp</strong>-Autorenrichtlinien ausgearbeiteten<br />
Hauptbeitrag per E-Mail an<br />
urbas@oiv.de einzureichen.<br />
Ziel ihres Beitrags sollte der Brückenschlag<br />
zwischen aktuellen Erkenntnissen<br />
und Innovationen, methodischen Grundlagen<br />
und künftigen Anwendungen in der<br />
industriellen Praxis sein. Ansprechen soll<br />
Ihr Aufsatz technische Führungskräfte,<br />
Entscheider und Key Experts der Automatisierungsbranche.<br />
Alle Beiträge werden<br />
von einem Fachgremium begutachtet.<br />
Sollten Sie sich selbst aktiv an dem Begutachtungsprozess<br />
beteiligen wollen,<br />
bitten wir um kurze Rückmeldung. Für<br />
weitere Rückfragen stehen wir Ihnen<br />
selbstverständlich gerne zur Verfügung.<br />
Ihre Redaktion der <strong>atp</strong> <strong>edition</strong>:<br />
Leon Urbas, Andreas Schleinkofer,<br />
Anne Hütter<br />
CALL FOR<br />
Aufruf zur Beitragseinreichung<br />
<strong>für</strong> Ausgabe 11/2012<br />
Thema: Informationsmodelle <strong>für</strong> Middleware<br />
in der Automatisierungstechnik<br />
Kontakt: urbas@oiv.de<br />
Termin: 20. Juni 2012<br />
8<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
H<br />
Umsatz und Aufträge<br />
im Februar gebremst<br />
Ein gemischtes Bild zeichneten die Auftragseingänge<br />
der deutschen Elektroindustrie im Februar. Sie blieben<br />
um knapp zwei Prozent unter dem Wert vom Februar<br />
2 0 1 1 . Damals stand allerdings ein Plus von fast einem<br />
Fünftel zu Buche. Im aktuellen Februar sind die Bestellungen<br />
aus dem Inland um siebeneinhalb Prozent gegenüber<br />
dem Vorjahr gesunken. Die Auslandsorders haben<br />
dagegen um vier Prozent zugelegt.<br />
Von J anuar bis Februar dieses J ahres haben die Auftragseingänge<br />
ihren Vorjahresstand um dreieinhalb Prozent<br />
verfehlt. Inländische und ausländische Kunden<br />
orderten dabei sechs beziehungsweise ein Prozent weniger<br />
als im gleichen Vorjahreszeitraum. Der Umsatz der<br />
Branche legte im Februar um drei Prozent auf 1 4 Mrd.<br />
Euro zu. Im Inland wurde ein Plus von 4 ,5 Prozent auf<br />
7 ,4 Mrd. Euro erreicht, bei ausländischen Kunden war<br />
es knapp ein Prozent auf 6 ,6 Mrd. Euro.<br />
ZVEI – ZENTRALVERBAND ELEKTROTECHNIK- UND<br />
ELEKTRONIKINDUSTRIE E.V.,<br />
Lyoner Straße 9, D-60528 Frankfurt am Main,<br />
Tel. +49 (0) 69 630 20, Internet: www.zvei.org<br />
| EC12-09G |<br />
Robust und kompakt:<br />
der Embedded-PC mit<br />
Intel ® Atom .<br />
Die CX5000-Serie von Beckhoff.<br />
Netzwerken <strong>für</strong><br />
<strong>das</strong> Smart Grid<br />
Ein wichtiger Zukunftsmarkt auch <strong>für</strong> die Automatisierungstechnik<br />
können die Smart Grids in der<br />
Stromversorgung werden. Diesem Thema widmet sich<br />
der VDE-Kongress „ Smart Grid – Intelligente Energieversorgung<br />
der Zukunft“ am 5 . und 6 . November 2 0 1 2 in<br />
Stuttgart. Zum Programm gehören über 1 3 0 Vorträge in<br />
4 4 Sessions, mehr als 1 0 0 Posterpräsentationen und eine<br />
Technologie- und Innovationsausstellung. Erwartet werden<br />
2 0 0 0 Teilnehmer aus dem In- und Ausland.<br />
Ein Ziel des Kongresses ist, den Austausch zwischen<br />
allen beteiligten Akteuren zu ermöglichen. Denn den<br />
Prozess der Energieerzeugung und -verteilung optimal<br />
zu gestalten erfordert die intensive interdisziplinäre Zusammenarbeit<br />
von Ingenieuren unterschiedlicher Fachrichtungen<br />
und Branchen, die bislang oft noch wenige<br />
Schnittstellen miteinander haben. Struktuiert ist der<br />
Wissensaustausch in sechs Themenbereiche: Smart<br />
ome, Intelligentes Lastmanagement, Smart Metering<br />
und Geschäftsmodelle, Netzinfrastruktur, Smart Grid<br />
Applications/Services und Gesellschaft und Ressourcen.<br />
Auf dem e-studentday und der Karrieremesse am 5 .<br />
November haben Unternehmen die Gelegenheit, sich den<br />
potentiellen Nachwuchskräften zu präsentieren. Die Veranstalter<br />
erwarten etwa 6 0 0 Studierende und Nachwuchskräfte.<br />
Weitere Informationen zum Kongress sind<br />
zu finden auf www.vde.com/kongress2 0 1 2 .<br />
VDE VERBAND DER ELEKTROTECHNIK ELEKTRONIK<br />
INFORMATIONSTECHNIK E.V.,<br />
Stresemannallee 15, D-60596 Frankfurt am Main,<br />
Tel. +49 (0) 69 630 80, Internet: www.vde.com<br />
IPC<br />
I/O<br />
Motion<br />
Automation<br />
Halle B1, Stand 308<br />
www.beckhoff.de/CX5000<br />
Die Embedded-PC-Serie CX5000 <strong>für</strong> die Hutschienenmontage:<br />
Geeignet zum fl exiblen Einsatz als kompakter Industrie-PC oder als<br />
PC-basierte Steuerung <strong>für</strong> SPS, Motion Control und Visualisierung:<br />
Intel ® -Atom-Z530-CPU 1,1 GHz (CX5010) oder 1,6 GHz (CX5020)<br />
Robustes und kompaktes Magnesiumgehäuse<br />
Erweiterter Betriebstemperaturbereich von -25…60 °C<br />
Lüfterlos, ohne rotierende Bauteile (Compact-Flash als Speichermedium)<br />
I/O-Interface <strong>für</strong> EtherCAT-Klemmen und Busklemmen<br />
Optionsplatz <strong>für</strong> serielle oder Feldbus-Schnittstellen<br />
Integrierte 1-Sekunden-USV<br />
CX1020/CX1030<br />
Embedded-PC mit<br />
Intel ® -Pentium ® -<br />
M-CPU, 1,8 GHz<br />
oder Intel ® -<br />
Celeron ® -M-ULV-<br />
CPU, 1 GHz<br />
CX1010<br />
Embedded-PC<br />
mit Pentium ® -<br />
MMX-kompatibler<br />
CPU,<br />
500 MHz<br />
CX9000/CX9010<br />
Ethernet-<br />
Controller mit<br />
Intel ® -IXP420-<br />
XScale ® -Techno -<br />
logie, 266 MHz<br />
oder 533 MHz<br />
CX8000<br />
Feldbus Controller<br />
mit ARM9-CPU,<br />
400 MHz z.B. <strong>für</strong><br />
PROFIBUS, PROFI-<br />
NET, EtherCAT und<br />
Ethernet
H<br />
FORSCHUNG<br />
SAARBRÜCKER<br />
WISSEN-<br />
SCHAFTLER<br />
haben eine<br />
Roboterhand<br />
entwickelt, die<br />
so sensibel ist,<br />
<strong>das</strong>s sie auch<br />
ein rohes Ei<br />
greifen kann,<br />
ohne es zu<br />
zerbrechen.<br />
Foto: Markus Breig/<br />
Uni Saarland<br />
Saarbrücker automatisieren <strong>das</strong><br />
Fingerspitzengefühl bei Robotern<br />
Forschern aus Italien und Deutschland ist es gelungen,<br />
einem Roboter so viel Fingerspitzengefühl zu geben,<br />
<strong>das</strong>s er ein rohes Ei halten kann. Die neue Feinmotorik<br />
der Maschinen kann etwa bei Operationen oder industriellen<br />
Anwendungen genutzt werden. „ Wir wollten unserer<br />
Roboterhand ein breites Spektrum menschlicher<br />
Eigenschaften verleihen“ , sagt Chris Mayr, Mechatronik-<br />
Forscher am Lehrstuhl <strong>für</strong> Antriebstechnik der Universität<br />
des Saarlandes.<br />
Die nun gezeigte Roboterhand ist ein Ergebnis des europaweit<br />
geförderten Projektes Dexmart. In dessen Rahmen<br />
hatten die Saarbrücker Forscher gemeinsam mit Kollegen<br />
aus Bologna und Neapel vier J ahre lang Konzepte<br />
zum vielseitigen Einsatz zweiarmiger Roboter entwickelt.<br />
Die H erausforderung bestand darin, die komplexe<br />
Technik im menschenähnlichen Roboterarm verschwinden<br />
zu lassen. „ Dies gelang uns über Polymerschnüre,<br />
die von kleinen, schnell drehenden Elektromotoren verdrillt<br />
werden. So können wir auf kleinem Raum sehr<br />
hohe Zugkräfte erzeugen“ , erläutert Mechatronik-Forscher<br />
May <strong>das</strong> Vorgehen. Die über Sensoren geregelte<br />
and kann nun unterschiedliche Gegenstände, wie etwa<br />
eine schwere Glasflasche oder ein zerbrechliches Ei, greifen,<br />
anheben und an anderer Stelle wieder ablegen.<br />
UNIVERSITÄT DES SAARLANDES,<br />
LEHRSTUHL FÜR ANTRIEBSTECHNIK,<br />
Campus, D-66123 Saarbrücken, Tel. +49 (0) 681 30 27 16 90,<br />
Internet: www.lat.uni-saarland.de<br />
10<br />
Sprengstoffanalyse gelingt dank optimierter<br />
Raman-Spektroskopie nun auch aus großer Distanz<br />
Das Ermitteln von Chemikalien auf große Entfernung<br />
stellte bislang ein Problem dar. Forscher der TU Wien<br />
konnten nun die Raman-Spektroskopie so weiter entwickeln,<br />
<strong>das</strong>s die Identifikation der Chemikalien über eine<br />
Distanz von 1 0 0 Metern gelang.<br />
Die Raman-Spektroskopie ist eine Methode, bei der die<br />
Probe mit einem Laserstrahl beleuchtet wird. Wird <strong>das</strong><br />
Licht an den Molekülen der Probe gestreut, kann es seine<br />
Energie ändern. Damit ändert sich die Wellenlänge<br />
des Lichts und so seine Farbe. Aus der Farb-Zusammensetzung<br />
des gestreuten Lichts lässt sich ablesen, an welcher<br />
chemischen Substanz es gestreut wurde.<br />
Bislang musste man diese Methode in unmittelbarer<br />
Nähe der vermeintlich gefährlichen Substanz anwenden.<br />
„ Von hundert Millionen Photonen regen nur wenige<br />
überhaupt den gewünschten Streuprozess in der<br />
Probe an“ , erläutert Bernhard Zachhuber, Forscher an<br />
der TU Wien. Diese gestreuten Lichtteilchen verteilen<br />
sich gleichmäßig in alle Richtungen. Nur ein winziger<br />
Bruchteil gelangt von der Probe zum Lichtdetektor.<br />
Aus diesem schwachen Signal muss möglichst viel<br />
Information abgelesen werden. Ein leistungsfähiges<br />
Teleskop und hochempfindliche Lichtsensoren übernehmen<br />
dies nun.<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
Auch die Schwierigkeit des Messens innerhalb undurchsichtiger<br />
Container ist geknackt: Der Laserstrahl<br />
wird zwar am Container gebrochen, dringt teilweise<br />
aber auch in den Behälter ein. „ Es ist nicht leicht, <strong>das</strong><br />
Lichtsignal des Behälters von dem der Probe im Inneren<br />
zu unterscheiden“ , so Prof. Dr. Bernhard Lendl vom<br />
Institut <strong>für</strong> Chemische Technologien und Analytik der<br />
TU Wien.<br />
Dies gelingt nun mit einem einfachen geometrischen<br />
Trick: Der Laser trifft auf einen kleinen, fokussierten<br />
Punkt am Container, verbreitert sich dann aber im Inneren<br />
stark. Das Lichtsignal, <strong>das</strong> vom Behälter kommt, geht<br />
also von einem geometrisch eng begrenzten Bereich aus,<br />
<strong>das</strong> schwache Lichtsignal des Inhalts wird von einem<br />
größeren Bereich ausgesandt. Richtet man <strong>das</strong> Mess-Teleskop<br />
also nicht genau auf die Laser-Auftreffstelle, sondern<br />
ein Stück davon weg, misst man <strong>das</strong> charakteristische<br />
Lichtsignal des Inhalts. Die Methode kann nun in<br />
Fragen der öffentlichen Sicherheit oder in der chemischen<br />
Industrie angewandt werden.<br />
TECHNISCHE UNIVERSITÄT WIEN,<br />
Getreidemarkt 9, A-1060 Wien, Tel. +43 1 58 80 10,<br />
Internet: www.tuwien.ac.at
H<br />
Tool-Entwicklung und<br />
IT-Dienst in der Praxis<br />
Der IT-Dienstleister Cema und die H ochschule Mannheim<br />
arbeiten derzeit an einem Informatikprojekt rund<br />
um <strong>das</strong> Thema „ Cloudbasierte Dienstleistung“ . Unter der<br />
Leitung von Prof. Dr. Wolfgang Schramm widmen sich 3 0<br />
Bachelorstudenten des Informatikinstituts während des<br />
Praxissemesters diesem Projekt. Dabei geht es um die<br />
Standardisierung bei Implementierungsaufgaben im Bereich<br />
IT-Dienstleistung mit H ilfe der Cloud-Technologie.<br />
Aufgaben wie <strong>das</strong> Einrichten von Servern oder die Implementierung<br />
von Virenschutz sind meist in ihren Abläufen<br />
identisch, unterscheiden sich aber durch individuelle<br />
Kundenwünsche. Verschiedene Prozesse dieser Aufgaben<br />
werden toolgestützt oder manuell bearbeitet. Dies ist zeitaufwendig<br />
und fehleranfällig. Eine einfache Lösung verspricht<br />
die Cloud, ein digitaler Datenspeicher. Die Aufgabe<br />
der Nachwuchsinformatiker ist es nun, ein „ Self Service<br />
Portal“ einzurichten, <strong>das</strong> die Initialisierung solcher<br />
IT-Dienstleistungen wesentlich vereinfachen soll.<br />
Erste Ergebnisse liegen voraussichtlich Ende J uni vor.<br />
Die Studenten erhalten nach sorgfältiger Prüfung eine<br />
Bewertung von Cema. Die entwickelten Tools sollen<br />
dann in der Praxis zum Einsatz kommen.<br />
„ Die besondere H erausforderung dieses Projektes ergibt<br />
sich aus den vielfältigen H ard- und Softwaresystemen, die<br />
eingesetzt werden. Wir freuen uns auf <strong>das</strong> Projekt, da wir<br />
erstmals nicht ausschließlich Software entwickeln sondern<br />
uns auch mit der Konzeption von IT-Dienstleistungen auseinandersetzen“<br />
, sagt H ochschul-Projektleiter Schramm.<br />
HOCHSCHULE MANNHEIM, INSTITUT FÜR INFORMATIK,<br />
Paul-Wittsack-Straße 10, D-68163 Mannheim,<br />
Tel. +49 (0) 6212 92 61 11,<br />
Internet: www.informatik.hs-mannheim.de<br />
„ Smarter“ Tisch <strong>für</strong><br />
neue Bedienkonzepte<br />
Kognitive Belastungen und physiologische Gefahren der<br />
„ Multitouch“ -Bedienung ermitteln Forscher an der<br />
ochschule Rhein-Waal nun mithilfe eines speziellen Tisches.<br />
Seit Kurzem verfügt die dortige Fakultät <strong>für</strong> Kommunikation<br />
und Umwelt über einen „ Microsoft Surface 2 “ , ein<br />
interaktiver Tisch mit berührungsintensiver Eingabe. Neben<br />
den gewöhnlichen „ Touch“ -Funktionen sind komplexere<br />
Eingaben möglich, etwa mithilfe von Gegenständen. Außerdem<br />
können ihn beliebig viele Finger oder H ände bedienen.<br />
Auch Gegenstände, sogenannte „ Tangibles“ , erkennt <strong>das</strong><br />
Gerät. Sie dienen als Repräsentanten <strong>für</strong> digitale Information.<br />
Die Studenten der H ochschule Rhein-Waal unter der<br />
Leitung von Prof. Dr. Karsten Nebe sollen dank des „ Microsoft<br />
Surface 2 “ nun die Möglichkeit erhalten, Bedientechnologien<br />
praxisnah zu analysieren und die Entwicklung<br />
zielgerichtet und nutzerfreundlich voranzutreiben.<br />
HOCHSCHULE RHEIN-WAAL,<br />
Landwehr 4, D-47533 Kleve, Tel. +49 (0) 2821 80 67 30,<br />
Internet: www.hochschule-rhein-waal.de<br />
iTEMP<br />
iTHERM<br />
QuickSens<br />
T 90 ≥ 1,5 s<br />
Innovative<br />
Temperaturmesstechnik.<br />
iTHERM<br />
StrongSens<br />
Vibration ≥ 60 g<br />
Endress+Hauser<br />
Messtechnik GmbH+Co. KG<br />
Colmarer Straße 6<br />
79576 Weil am Rhein<br />
Telefon 0 800 EHVERTRIEB<br />
oder 0 800 348 37 87<br />
Telefax 0 800 EHFAXEN<br />
oder 0 800 343 29 36<br />
Sicherheit beginnt mit<br />
der Produktauswahl<br />
Endress+Hauser unterstützt seine Kunden<br />
mit einem umfänglichen und exzellenten<br />
Produktportfolio zur Temperaturmessung.<br />
<br />
Langzeitstabilität und Prozesssicherheit<br />
<br />
Messkette geben Planungssicherheit<br />
<br />
rantiert eine einfache und zeitsparende
SCHWERPUNKT | SENSORIK<br />
Satter Aufschwung: Markt <strong>für</strong> Prozess-Sensorik<br />
wächst bis 2 0 1 6 um rund sechs Prozent pro J ahr<br />
Studie erläutert Analysen und Prognosen <strong>für</strong> die Zukunft der Sensorik<br />
Die deutsche Sensorikindustrie zeigt sich optimistisch.<br />
Anlagenmodernisierung, neue Richtlinien<br />
und Ausbau der bestehenden Infrastruktur lassen<br />
die Umsatzzahlen wachsen. Dies ergab eine Studie<br />
des Baseler Consultingunternehmens Intechno Consulting<br />
(„ Sensors Markets 2 0 1 6 “ ). Der englischsprachige<br />
Report umfasst die Analyse und Prognose<br />
des gesamten Weltmarktes <strong>für</strong> Sensoren, wobei die<br />
Prozessindustrie einen von mehreren Schwerpunkten<br />
darstellt. In diesem Industriesektor stiegen die<br />
Sensorik-Umsätze von 8 0 7 Millionen Euro (2 0 0 6 ) auf<br />
9 7 5 Mio im J ahre 2 0 1 1 . Die Milliardenmarke wird, laut<br />
Prognose der Studie, voraussichtlich 2 0 1 6 geknackt.<br />
Auf bis zu 1 ,3 Milliarden Euro beläuft sich die Schätzung.<br />
Dies entspricht einer durchschnittlichen jährlichen<br />
Wachstumsrate von 3 ,8 % zwischen 2 0 0 6 und<br />
2 0 1 1 . Wohingegen ein Wachstum von 5 ,9 % im Zeitraum<br />
von 2 0 1 1 bis 2 0 1 6 erwartet wird. Das durch-<br />
DEUTSCHLAND:<br />
PROZESSINDUSTRIEN<br />
2006<br />
Mio. Euro<br />
2011<br />
Mio. Euro<br />
2016<br />
Mio. Euro<br />
DEUTSCHLAND:<br />
PROZESSINDUSTRIEN<br />
2006<br />
Mio. Euro<br />
2011<br />
Mio. Euro<br />
2016<br />
Mio. Euro<br />
1. Bergbau<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf – In-/Ausland<br />
26,0<br />
6,2<br />
19,9<br />
30,9<br />
6,1<br />
24,9<br />
42,2<br />
6,2<br />
36,1<br />
1. Bergbau<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf <strong>für</strong> Inland<br />
11,9<br />
6,2<br />
5,7<br />
11,6<br />
6,1<br />
5,6<br />
11,8<br />
6,2<br />
5,7<br />
2. Öl & Gas<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf – In-/Ausland<br />
24,3<br />
2,2<br />
22,1<br />
32,5<br />
2,4<br />
30,1<br />
48,5<br />
2,8<br />
45,7<br />
2. Öl & Gas<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf <strong>für</strong> Inland<br />
4,8<br />
2,2<br />
2,6<br />
5,2<br />
2,4<br />
2,8<br />
6,2<br />
2,8<br />
3,4<br />
3. Steine & Erden<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf – In-/Ausland<br />
36,9<br />
12,1<br />
24,8<br />
42,0<br />
12,7<br />
29,2<br />
51,2<br />
14,4<br />
36,8<br />
3. Steine & Erden<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf <strong>für</strong> Inland<br />
20,2<br />
12,1<br />
8,1<br />
21,2<br />
12,7<br />
8,5<br />
24,1<br />
14,4<br />
9,6<br />
4. Metallerzeugung<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf – In-/Ausland<br />
92,1<br />
15,1<br />
77,0<br />
116,3<br />
16,1<br />
100,3<br />
163,2<br />
18,3<br />
145,0<br />
4. Metallerzeugung<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf <strong>für</strong> Inland<br />
33,0<br />
15,1<br />
18,0<br />
35,3<br />
16,1<br />
19,2<br />
40,1<br />
18,3<br />
21,8<br />
5. Chemische Industrie<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf – In-/Ausland<br />
253,1<br />
93,2<br />
159,9<br />
285,6<br />
100,7<br />
184,9<br />
353,9<br />
118,4<br />
235,5<br />
5. Chemische Industrie<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf <strong>für</strong> Inland<br />
185,9<br />
93,2<br />
92,7<br />
200,8<br />
100,7<br />
100,2<br />
236,3<br />
118,4<br />
117,9<br />
6. Pharmaindustrie<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf total<br />
48,0<br />
13,5<br />
34,5<br />
63,0<br />
16,6<br />
46,5<br />
83,8<br />
20,0<br />
63,8<br />
6. Pharmaindustrie<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf <strong>für</strong> Inland<br />
38,4<br />
13,5<br />
24,9<br />
47,3<br />
16,6<br />
30,7<br />
57,1<br />
20,0<br />
37,1<br />
7. Petroindustrie<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf – In-/Ausland<br />
122,6<br />
30,5<br />
92,1<br />
153,3<br />
32,3<br />
121,0<br />
205,5<br />
36,5<br />
169,0<br />
7. Petroindustrie<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf <strong>für</strong> Inland<br />
65,1<br />
30,5<br />
34,6<br />
69,1<br />
32,3<br />
36,7<br />
77,9<br />
36,5<br />
41,4<br />
8. Papierindustrie<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf – In-/Ausland<br />
30,2<br />
10,1<br />
20,1<br />
33,2<br />
10,3<br />
22,9<br />
38,6<br />
11,0<br />
27,7<br />
8. Papierindustrie<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf <strong>für</strong> Inland<br />
20,1<br />
10,1<br />
10,0<br />
20,5<br />
10,3<br />
10,2<br />
21,8<br />
11,0<br />
10,9<br />
9. Nahrungsmittelindustrie<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf – In-/Ausland<br />
66,2<br />
14,9<br />
51,3<br />
77,1<br />
16,6<br />
60,6<br />
95,1<br />
18,8<br />
76,3<br />
9. Nahrungsmittelindustrie<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf <strong>für</strong> Inland<br />
43,1<br />
14,9<br />
28,2<br />
48,0<br />
16,6<br />
31,4<br />
54,4<br />
18,8<br />
35,6<br />
10. Kraftwerke<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf – In-/Ausland<br />
107,9<br />
23,3<br />
84,5<br />
141,5<br />
28,2<br />
113,3<br />
219,7<br />
41,5<br />
178,2<br />
10. Kraftwerke<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf <strong>für</strong> Inland<br />
50,6<br />
23,3<br />
27,3<br />
61,2<br />
28,2<br />
33,0<br />
90,1<br />
41,5<br />
48,6<br />
TOTAL<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf – In-/Ausland<br />
807,2<br />
221,0<br />
586,2<br />
975,4<br />
241,9<br />
733,5<br />
1.301,9<br />
287,9<br />
1.014,0<br />
TOTAL<br />
• Endanwender Direktbezug<br />
• OEM-Bedarf <strong>für</strong> Inland<br />
473,2<br />
221,0<br />
252,2<br />
520,3<br />
241,9<br />
278,3<br />
619,8<br />
287,9<br />
331,9<br />
TABELLE 1: Analyse und Prognose des deutschen<br />
Sensormarktes in den Prozessindustrien nach Art der<br />
Prozessindustrie: End anwender-Direktbedarf und<br />
OEM-Bedarf <strong>für</strong> In- und Ausland<br />
TABELLE 2: Analyse und Prognose des deutschen<br />
Sensormarktes in den Prozessindustrien nach Art der<br />
Prozessindustrie: Endanwender-Direktbedarf und<br />
OEM-Bedarf nur <strong>für</strong> Inland<br />
12<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
schnittliche jährliche Wachstum <strong>für</strong> den Gesamtzeitraum<br />
beträgt demnach 4 ,9 % .<br />
WELCHE BEREICHE DER<br />
PROZESSINDUSTRIE BEFRAGT WURDEN<br />
Die im Report diskutierten prozesstechnischen Industrien<br />
umfassen die verfahrenstechnisch orientierten<br />
Industrien bis zu den Kraftwerken. Dazu gehören die<br />
Sektoren Steine und Erden inklusive Glas- und Keramikindustrie,<br />
die Eisen-, Stahl- und die NE-Metallerzeugung<br />
einschließlich der Walzwerke <strong>für</strong> Stahl- und<br />
Aluminiumbleche. Ergänzt werden sie durch die chemische<br />
Industrie, die Pharma- und Petroindustrie, die<br />
Papierindustrie sowie die Nahrungsmittelindustrie.<br />
Ebenfalls abgedeckt werden der Bergbau und die Ö l-<br />
und Gasindustrie mit allen Prozessen von der Förderung<br />
über den Transport bis hin zur Aufbereitung der<br />
Mineralien.<br />
J ede dieser Branchen stellt unterschiedliche Anforderungen<br />
an die zu automatisierenden Prozesse und Einrichtungen.<br />
Auch die Trinkwasserversorgung, Kläranlagen<br />
und Müllverbrennungsanlagen deckte die Marktanalyse<br />
ab. In den Zahlen der Tabellen sind diese Industrien<br />
nicht berücksichtigt.<br />
Innerhalb der diversen Prozessindustrien gibt es wiederum<br />
vielfältige Anwendungen <strong>für</strong> die verschiedenen<br />
Arten von Sensoren. Diese Anwendungen betreffen sowohl<br />
Kern- als auch Nebenprozesse. Letztere umfassen<br />
neben Abfüllanlagen und Verpackungsmaschinen die<br />
verschiedenen Arten von Lagertechniken, Versorgungseinrichtungen<br />
sowie Umweltprozesse innerhalb der oben<br />
aufgeführten Prozessindustrien.<br />
STEIGENDE ZAHL VON GESETZEN LÄSST<br />
SENSORIK-BEDARF ANWACHSEN<br />
Tabelle 1 gibt die Zusammenfassung der deutschen Marktentwicklung<br />
bei Sensoren innerhalb der diversen Prozessindustrien.<br />
Es handelt sich um eine Ist-Analyse der J ahre<br />
2 0 0 6 und 2 0 1 1 und eine Prognose zum Stand im J ahr 2 0 1 6 .<br />
Die Tabelle beschreibt den direkten Bedarf der deutschen<br />
Endanwender, zusammen mit von deutschen Anlagenbauern<br />
<strong>für</strong> <strong>das</strong> In- und Ausland nachgefragten Sensoren.<br />
Demgegenüber ist in Tabelle 2 der Bedarf ausschließlich<br />
deutscher Endanwender an Sensoren dargestellt, die diese<br />
AUTOMATION 2012<br />
13. und 14. Juni 2012 im Kongresshaus Baden-Baden<br />
Der 13. Branchentreff der Mess- und Automatisierungstechnik<br />
Keynote Speaker:<br />
» über 70 Vorträge<br />
Prof. Dr. Siegfried Russwurm, » über 20 Poster präsentationen<br />
Mitglied des Vorstands, Siemens AG<br />
Komplexität beherrschen – Zukunft sichern<br />
www.automatisierungskongress.de<br />
Veranstaltung des VDI Wissensforums | www.automatisierungskongress.de | Telefon +49 211 6214-201 | Telefax +49 211 6214-154<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
13
SCHWERPUNKT | SENSORIK<br />
DEUTSCHLAND:<br />
SENSORARTEN<br />
2006<br />
Mio. Euro<br />
2011<br />
Mio. Euro<br />
2016<br />
Mio. Euro<br />
1. Temperatursensoren 112,2 139,2 187,8<br />
2. Wärmesensoren 4,5 5,7 7,8<br />
3. Drucksensoren 88,3 109,5 147,8<br />
4. Durchflusssensoren 208,5 257,0 340,0<br />
5. Anemometer, Windrichtung 4,0 5,5 9,1<br />
6. Füllstandssensoren 134,0 144,9 189,2<br />
7. Binäre Positionssensoren 28,0 34,6 47,0<br />
8. Positionssensoren 26,4 33,6 48,3<br />
9. Dickensensoren 1,1 1,2 1,7<br />
10. Abstandssensoren 0,7 0,9 1,4<br />
11. Bewegungssensoren 0,7 1,0 1,4<br />
12. Drehzahlsensoren 14,0 16,7 21,8<br />
13. Vibrationssensoren 16,7 20,6 28,2<br />
14. Kraftsensoren, Wägezellen 24,4 28,4 35,3<br />
15. Drehmomentsensoren 2,6 3,1 4,2<br />
16. Navigationssensoren 0,4 0,5 0,6<br />
17. Akustische Sensoren 5,8 7,3 10,0<br />
18. Photosensoren: Visible, IR, UV 4,6 5,5 6,7<br />
19. Kameras: sichtbares Spektrum 8,5 9,9 12,4<br />
20. Kameras: Infrarot-Spektrum 2,3 2,7 3,6<br />
21. Barcodescanner 0,5 0,4 0,4<br />
22. RFID-Lesegeräte 0,0 0,1 0,2<br />
23. Elektrische Stromsensoren 7,5 10,0 16,1<br />
24. Elektrische Spannungssensoren 4,5 6,0 9,8<br />
25. AMR Stromzähler 9,7 11,9 15,9<br />
26. Qualitätssensoren: Feststoffe 3,7 4,7 6,8<br />
27. Qualitätssensoren: Flüssigkeiten 4,3 5,3 7,4<br />
28. Viskositätssensoren 3,2 3,8 4,7<br />
29. Partikelsensoren 3,0 3,5 4,2<br />
30. Feuchtesensoren 16,2 18,6 22,8<br />
31. Flüssigkeits-Chemosensoren 25,1 30,1 37,7<br />
32. Gassensoren 30,7 38,7 52,0<br />
33. Biosensoren 1,6 2,0 2,6<br />
34. Rauchgasmelder 9,6 12,3 16,9<br />
TOTAL 807,2 975,4 1.301,9<br />
TABELLE 3: Analyse und Prognose des deutschen Sensormarktes<br />
in den Prozessindustrien nach Art der Sensoren: Endanwender-<br />
Direktbedarf und OEM-Bedarf <strong>für</strong> In- und Ausland<br />
direkt von den Sensorherstellern oder indirekt über die Anlagenbauer<br />
beziehen. Dieser Markt ist kleiner als der in Tabelle<br />
1 dargestellte Bedarf und wächst von 4 7 3 Millionen<br />
Euro im J ahr 2 0 0 6 auf 5 2 0 Millionen. Euro im J ahr 2 0 1 1 und<br />
auf voraussichtlich 6 2 0 Millionen Euro bis zum J ahr 2 0 1 6 .<br />
In Tabelle 3 wiederum ist der Sensorbedarf nach Sensorarten<br />
aufgeführt, welche seitens der deutschen Endanwender<br />
(Betreiberfirmen) nachgefragt werden, zusammen mit<br />
den von deutschen prozesstechnischen Anlagenbauern <strong>für</strong><br />
die inländischen und ausländischen Kunden nachgefragten<br />
Sensoren. Die Prozessindustrien im engeren Sinne<br />
(Chemieindustrie, Pharmaindustrie, Petroindustrie, Nahrungsmittelindustrie)<br />
bilden den größten Nachfragesektor,<br />
gefolgt von den Grundstoffindustrien (Steine und Erden,<br />
Metallerzeugung, Zellstoff- und Papierindustrie) und den<br />
Kraftwerken. Der Rohstoffsektor (Bergbau, Ö l- und Gasgewinnung)<br />
stellt in Deutschland <strong>das</strong> kleinste Nachfragesegment<br />
dar (Bild 1 ).<br />
Die Ursachen <strong>für</strong> den zunehmenden Einsatz von Sensoren<br />
innerhalb der Prozessindustrien liegen im steigenden Automatisierungsgrad<br />
der Anlagen. Von den Anlagen werden<br />
höhere Verfügbarkeit, stärkere Produktivität, Ressourceneffizienz<br />
und aktuelle Sicherheitsstandards erwartet. Anhand<br />
dieser Anforderungen, die gleichzeitig indirekt Wachstumsfaktoren<br />
bilden, wächst der Bedarf an Sensoren in etwa<br />
proportional zum Anstieg des Automatisierungsbedarfs.<br />
Die steigende Zahl von Gesetzen, Vorschriften und Verordnungen<br />
machen gleichzeitig einen verstärkten Einsatz<br />
von Sensoren nötig. Auch der zunehmende Bedarf an regelmäßiger<br />
und permanenter Zustandsüberwachung (Condition<br />
Monitoring) von Maschinen und Anlagen lässt die<br />
Nachfrage der Prozessindustrie nach Sensoren sprießen.<br />
Speziell in Deutschland wird die Ausbreitung der Sensorik<br />
in den Prozessindustrien durch den Modernisierungsbedarf<br />
der Anlagen bewirkt. Ebenso spielen Erweiterungsund<br />
Neuinvestitionen eine bedeutende Rolle.<br />
WAS ANLAGENBAUER WIRKLICH BENÖTIGEN<br />
Vor allem die Prozessindustrien verlangen nach Sensoren,<br />
welche unter rauen Umgebungsbedingungen funktionieren.<br />
H ierzu gehören Sensoren, die starken Vibrationen und<br />
Schocks standhalten, die gegen aggressive Flüssigkeiten<br />
immun sind, die hohen Temperaturen und Drücken standhalten<br />
sowie den modernsten H ygienevorschriften innerhalb<br />
der Pharma- und Nahrungsmittelindustrien entsprechen.<br />
Die Innovationen in diesem Bereich liegen in fortschrittlichen<br />
Gehäusetechniken und Materialien.<br />
Busfähige und drahtlos kommunizierende Sensoren<br />
gewinnen in den Prozessindustrien an Bedeutung. Beispiele<br />
sind bei räumlich weit verteilten Anlagen sowie<br />
bei der zustandsbedingten Überwachung (Condition-<br />
Based Monitoring) von rotierenden Maschinen zu finden.<br />
Solche Funksensoren benötigen eine Batterie, die sich<br />
in Zukunft allerdings zunehmend durch <strong>das</strong> Einführen<br />
von „ Energy H arvesting“ -Konzepten eliminieren lässt.<br />
Dabei gewinnt der Sensor die Energie unmittelbar aus<br />
der Umgebung (Bewegungswandler, Thermowandler,<br />
Vibrationswandler, Lichtwandler).<br />
Bei immer kürzer werdenden Produktzyklen sind Innovationen<br />
gefragt, um im Wettbewerb bestehen und Wachs-<br />
14<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
800<br />
700<br />
Mio. Euro<br />
600<br />
2011<br />
2016<br />
500<br />
400<br />
300<br />
200<br />
100<br />
0<br />
Rohstoffe Grundstoffe Prozessindustrien<br />
i.e.S.<br />
Kraftwerke<br />
UMSÄTZE:<br />
Entwicklung des<br />
deutschen Marktes <strong>für</strong><br />
Prozess sensoren bis<br />
2016 – Unterteilung<br />
nach Branchen.<br />
Quelle: Intechno Consulting<br />
tumsziele erreichen zu können. Innovative Ideen entstehen<br />
oft zufällig, doch sollte deren Management systematisch<br />
und strategisch ausgerichtet sein. „ Forschen im intelligenten<br />
Schwarm“ (Crowd Sourcing) könnte ein neuer, effizienter<br />
und zugleich kostengünstiger Ansatz sein, um Ideen<br />
systematisch zu generieren. Dies sollte aber im Rahmen<br />
eines strategischen Ansatzes geschehen. Dabei werden externe<br />
Partner in firmeninterne Prozesse eingebunden, um<br />
innovative Ideen zu generieren. Die Umsetzung dieser Ideen<br />
in marktfähige Produkte und Dienstleistungen obliegt<br />
Innovationsmanagern. Das Erstellen von Roadmaps ist ein<br />
viel versprechender Ansatz im Rahmen des strategischen<br />
Marketings. H iermit lässt sich die Markteinführung neuer<br />
Technologien gezielt und effizient gestalten.<br />
AUTOR<br />
Dr. NORBERT SCHRÖDER<br />
ist Mit-Autor der Studie<br />
und Geschäftsführer von<br />
Intechno Consulting.<br />
Intechno Consulting,<br />
Steinenbachgaesslein 49, CH-4051 Basel (Schweiz),<br />
Tel. +41 61 281 18 30,<br />
E-Mail: nschroeder@intechnoconsulting.com,<br />
Internet: www.intechnoconsulting.com<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
15
SCHWERPUNKT | SENSORIK<br />
Planung von Messstellen: Variable<br />
Messumformer bieten höhere Genauigkeit<br />
Temperaturfühler sicher, effizient und kostenoptimiert in Anlagen integrieren<br />
FLEXIBEL: Die universellen<br />
Temperaturmessumformer<br />
Macx Analog bieten sich <strong>für</strong> viele<br />
Bereiche der Prozesstechnik an<br />
Die Temperaturmessung gehört in der Prozess- und<br />
Automatisierungstechnik zu den wesentlichen physikalischen<br />
Größen. Ganz gleich ob Anlagenüberwachung<br />
oder Realisierung schwieriger Prozessabläufe:<br />
Die exakte Erfassung der Temperatur stellt <strong>für</strong> den Planer<br />
eine H erausforderung dar. Denn Prozess- und Reaktionsgeschwindigkeiten,<br />
Materialverbrauch, Ertrag<br />
sowie Produkteigenschaften und -qualität hängen von<br />
der Genauigkeit, Schnelligkeit und Zuverlässigkeit ab,<br />
mit der die Temperaturen aufgenommen werden.<br />
Die Temperatur hat einen entscheidenden Einfluss auf<br />
den Prozesswirkungsgrad, den Energieverbrauch und<br />
andere Prozessparameter. Auch die Lebensdauer von<br />
Maschinen, Anlagen und Geräten resultiert unter anderem<br />
aus den jeweiligen Temperaturbedingungen. In<br />
vielen Industriebereichen geht es vor allem darum, die<br />
Informationen aus den verlässlichen Temperaturmessungen<br />
<strong>für</strong> Steuer- und Regelfunktionen nutzen zu können.<br />
Gestiegene Anforderungen an die Messgenauigkeit<br />
und Zuverlässigkeit von industriellen Temperaturmessungen<br />
führten in der Vergangenheit dazu, <strong>das</strong>s Anlagenbetreiber<br />
die Eignung und Leistungsfähigkeit ihrer<br />
Messeinrichtungen überprüfen mussten.<br />
WEITERENTWICKELTE AUSWERTEELEKTRONIK<br />
Zur industriellen Temperaturmessung werden zumeist Widerstandsthermometer<br />
und Thermoelemente verwendet.<br />
Mit den beiden Fühlerarten lassen sich nahezu alle Messanforderungen<br />
im industriellen Alltag umsetzen. Widerstandsthermometer,<br />
in ihren Messeigenschaften genauer<br />
und stabiler, werden im Bereich von -2 0 0 ° C bis 8 5 0 ° C eingesetzt.<br />
Thermoelemente, deren Nutzungsbandbreite zwischen<br />
-2 5 0 ° C und 3 0 0 0 ° C liegt, gelten als robust und vielseitig.<br />
Beide Sensoren haben gemein, <strong>das</strong>s die elektrischen<br />
Ausgangsgrößen relativ einfach <strong>für</strong> Mess- und Regeleinrichtungen<br />
zur Verfügung gestellt werden können.<br />
Die Fühler bewährten sich aufgrund der Toleranzen<br />
in der H erstellung sowie ihres einfachen Austausches<br />
im Fehlerfall. Die Auswerteelektronik ist ebenfalls weiterentwickelt<br />
worden. Durch die Verwendung digitaler<br />
und intelligenter Messumformer bietet sie zusätzliche<br />
Möglichkeiten. Die Signalwandlung, Filterung, sichere<br />
galvanische Trennung und genaue Aufbereitung der<br />
Messwerte sind bereits in moderne Wandler integriert.<br />
Zu den anderen Neuerungen zählen die erweiterte Diagnose<br />
sowie die Erkennung von Fehlern wie Fühlerbruch<br />
oder Kurzschluss.<br />
THERMOELEMENTE VS. WIDERSTANDSTHERMOMETER<br />
Neben zahlreichen Vorteilen weisen Thermoelemente<br />
Nachteile auf. Dazu gehören unvermeidbare metallurgische<br />
Inhomogenitäten in den Thermodrähten, welche<br />
einen direkten Einfluss auf die erreichbare Genauigkeit<br />
und Langzeitstabilität der Fühler hat. Außerdem zeichnen<br />
sich Thermopaare durch nichtlineares Temperatur-/<br />
Spannungsverhältnis aus und zeigen H ysterese-Erscheinungen.<br />
Nicht zu vergessen die zusätzlichen Kosten <strong>für</strong><br />
Thermo- und Ausgleichsleitungen, die Notwendigkeit<br />
einer Vergleichsstelle sowie <strong>das</strong> relativ schwache Ausgangssignal.<br />
Im Vergleich zu Thermoelementen sind<br />
16<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
BILD 1: Eine Möglichkeit<br />
der SIL-Einstufung<br />
bietet der Risikograph.<br />
Widerstandsthermometer genauer und stabiler und erlauben<br />
eine bessere Auflösung. Die Sensoren ermöglichen<br />
derzeit die beste erreichbare Messgenauigkeit mit<br />
elektrischen Temperaturfühlern, können allerdings nur<br />
in einem begrenzten Temperaturbereich eingesetzt werden,<br />
während aus Sonderlegierungen gefertigte Thermoelemente<br />
bis zu 3 0 0 0 ° C erfassen.<br />
Die Widerstandsthermometer messen im Gegensatz<br />
zur punktförmigen Messspitze der Thermoelemente<br />
über <strong>das</strong> gesamte Volumen des Messwiderstands. Die<br />
Sensoren sind ferner weniger robust und haben ein langsameres<br />
Antwortverhalten als Thermoelemente. Für<br />
Widerstandsthermometer ist eine Stromquelle erforderlich<br />
und bei der Konstruktion und Installation muss der<br />
Selbsterwärmungseffekt berücksichtigt werden.<br />
Widerstandsthermometer sind zwei- bis dreimal so<br />
teuer wie vergleichbare Thermoelemente. J edoch verringern<br />
die modernen Dünnschichtsensoren den Leistungsunterschied<br />
zwischen den beiden Sensortypen<br />
kontinuierlich.<br />
EXPLOSIONEN VERHINDERN<br />
Temperaturmessumformer bilden die Schnittstelle zwischen<br />
dem Prozess und dem Prozessleit- oder Auswertesystem.<br />
In explosionsgefährdeten Bereichen müssen<br />
zum Schutz von Personen und Einrichtungen die Atex-<br />
Richtlinie 9 4 /9 /EG und damit die jeweiligen Bedingungen<br />
der entsprechenden Zündschutzart eingehalten<br />
werden. Ziel ist die Absicherung von Bereichen mit<br />
gefährlicher brennbarer Atmosphäre vor Zündquellen,<br />
um eine Explosion zu verhindern. Aktuell werden in<br />
den Prozessanlagen vorrangig eigensichere Geräte verbaut.<br />
Die elektrische Energie wird also limitiert, so<strong>das</strong>s<br />
kein zündfähiger Funke entstehen kann. Der Anwender<br />
muss die Sicherheitskennwerte untersuchen und überprüfen,<br />
ob eine Zusammenschaltung der einzelnen<br />
Komponenten möglich ist.<br />
Eine weitere H erausforderung bei der Auswahl des<br />
passenden Temperaturmessumformers stellen sicherheitskritische<br />
Applikationen gemäß der internationalen<br />
Norm IEC 6 1 5 0 8 /6 1 5 1 1 dar. Sicherheitskritisch bedeutet,<br />
<strong>das</strong>s bei einem technischen Versagen des Gerätes<br />
oder des gesamten Sicherheitskreises ein Störfall eintreten<br />
kann, der einen Schaden an Personen, Umwelt<br />
oder Anlagen nach sich zieht.<br />
Um dies zu unterbinden, wird mithilfe unterschiedlicher<br />
Methoden wie H AZOP (H azard and Operability),<br />
Risikograph oder LOPA (Layer of Protection Analysis)<br />
die Risikobeurteilung durchgeführt (Bild 1 ). Die<br />
Sicherheitsbetrachtung macht <strong>das</strong> Gesamtrisiko der<br />
Anlage oder des Sicherheitskreises deutlich respektive<br />
quantifizierbar und führt anschließend bei Verwendung<br />
der richtigen Komponenten zu einer hinreichenden<br />
Risikoreduzierung. SIL-Anforderungen schränken<br />
die Auswahl an potentiell nutzbaren Temperaturmessumformern<br />
ein. Für die Prozesstechnik werden ausschließlich<br />
4 -2 0 mA-Geräte nach SIL zertifiziert. Dabei<br />
beschränkt sich die SIL-Betrachtung auf <strong>das</strong> 4 -2 0 mA-<br />
Ausgangssignal, die Messwertausgabe via H art-Protokoll<br />
wird nicht beachtet.<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
17
SCHWERPUNKT | SENSORIK<br />
BILD 2: Der PFD-Wert des zu erreichenden SIL teilt<br />
sich auf die verschiedenen verwendeten Geräte auf.<br />
BILD 3: Beispielhafter Einsatz der Messumformer<br />
zur Temperaturüberwachung. Bilder: Phoenix Contact<br />
PASSENDE TEMPERATURMESSUMFORMER FINDEN<br />
Nachdem der Anlagenplaner die Risikobetrachtung abgeschlossen<br />
und eine SIL-Klassifizierung vorgenommen<br />
hat, benötigt er <strong>für</strong> den ermittelten SIL einen entsprechenden<br />
Messumformer. In diesem Zusammenhang sind folgende<br />
Fragen zu beantworten:<br />
Ist der Temperaturmessumformer <strong>für</strong> die SIL-Anwendung<br />
geeignet?<br />
Für welchen SIL kann der Messumformer maximal<br />
eingesetzt werden (SIL-Fähigkeit)?<br />
Welche H ardware-Fehlertoleranz (H FT) hat <strong>das</strong> Gerät?<br />
Ist der Aufbau redundanter Systeme möglich?<br />
Liegen die Werte <strong>für</strong> SFF (Safe Failure Fraction –<br />
Anteil an ungefährlichen Fehlern) und PFD (Probability<br />
of Failures on Demand – Wahrscheinlichkeit<br />
eines gefährlichen Fehlers bei Anforderung der<br />
Sicherheitsfunktion) vor?<br />
In welchem zeitlichen Abstand sind die wiederkehrenden<br />
Funktionsprüfungen vorzunehmen?<br />
Die komplette sicherheitstechnische Funktion (SIF – Safety<br />
Instrumented Function) umfasst den Sensor, die Logikeinheit<br />
und den Aktor. Der zugehörige PFD-Wert des<br />
zu erreichenden SIL wird aufgeteilt in 3 5 Prozent <strong>für</strong> den<br />
Sensor, 1 5 Prozent <strong>für</strong> die Logikeinheit und 5 0 Prozent<br />
<strong>für</strong> den Aktor (Bild 2 ). Erst wenn die strukturelle Eignung<br />
(H FT und SFF) der gesamten Sicherheitsfunktion erfüllt<br />
ist, wird der PFD berechnet.<br />
Aus der Addition der einzelnen PFD-Werte aller im<br />
Sicherheitskreis verwendeten Komponenten ergibt sich<br />
der Gesamt-PFD. Dieser Wert ist mit dem zuvor gewählten<br />
SIL und den Normwerten aus der IEC 6 1 5 1 1 zu vergleichen.<br />
Werden die <strong>für</strong> den SIL notwendigen Werte<br />
nicht erzielt, muss der Planer entweder zusätzliche<br />
bauliche Maßnahmen umsetzen, seine Systeme redundant<br />
auslegen oder andere geeignete Maßnahmen ergreifen,<br />
um sein Anlagenrisiko weiter zu reduzieren.<br />
Die erforderlichen Daten werden von den H erstellern<br />
in Form von Datenblättern, Zertifikaten oder einem Sicherheitshandbuch<br />
zur Verfügung gestellt.<br />
FAZIT<br />
Im Spezialmaschinenbau müssen häufig Sondersignale<br />
erfasst und verarbeitet werden, die sich nicht mit Standardsensoren<br />
wie PT1 0 0 oder Typ-J /K-Thermoelementen realisieren<br />
lassen. Ferner wird eine höhere Genauigkeit verlangt.<br />
H ier bieten sich hochfunktionale Messumformer an.<br />
Ein weiterer Einsatzbereich der Geräte findet sich in der<br />
Stahlindustrie zur Überwachung der Temperatur von Kühlmitteln<br />
durch PT1 0 0 -Sensoren. H ochofen-Temperaturen<br />
werden hingegen mit Thermoelementen aufgenommen. Dabei<br />
ist eine hochwertige galvanische Trennung notwendig,<br />
um Ausgleichsströmen sowie Messwert-Verfälschungen<br />
aufgrund von Erdschleifen vorzubeugen. Da die universellen<br />
Temperaturmessumformer <strong>für</strong> eine Vielzahl von Sensortypen<br />
genutzt werden können, vereinfacht sich die Inbetriebnahme<br />
und der Aufwand <strong>für</strong> die Ersatzteilhaltung sinkt.<br />
Ein weiteres Anwendungsgebiet liegt im Bereich der Zementindustrie,<br />
wo Thermoelemente die Brenntemperaturen<br />
erfassen. Speziell in der klassischen Prozesstechnik<br />
– also Chemie, Ö l und Gas – eröffnet die SIL-Klassifizierung<br />
und Ex-Zulassung der Geräte interessante Verwendungsmöglichkeiten<br />
(Bild 3 ).<br />
AUTOR<br />
Dipl.-Ing. WILFRIED GROTE<br />
arbeitet im Bereich Produktmarketing<br />
MCR Analog und<br />
Ex bei der Phoenix Contact<br />
Electronics GmbH in Bad<br />
Pyrmont.<br />
Phoenix Contact Electronics GmbH,<br />
Dringenauer Str. 30,<br />
D-31812 Bad Pyrmont,<br />
Tel. +49 (0) 5281 94 60,<br />
E-Mail: wgrote@phoenixcontact.com<br />
18<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
M<br />
M<br />
Automatisierung<br />
auf den Punkt<br />
FORSC HUNG<br />
BEST PRAC TIC E<br />
EVENTS<br />
Nutzen Sie <strong>das</strong> neue<br />
edienspektrum<br />
• Der Nachrichtendienst <strong>atp</strong>!info ist die konsequente<br />
Ergänzung zur Fachpublikation <strong>atp</strong> <strong>edition</strong>.<br />
Sparen Sie Zeit und nutzen Sie <strong>das</strong> umfassende<br />
Info-Angebot von <strong>atp</strong>!info gratis.<br />
TRENDS<br />
Branchennachrichten<br />
<strong>für</strong> Experten<br />
• Mit <strong>atp</strong>!info<br />
bietet Ihnen die <strong>atp</strong>-Redaktion<br />
einen schnellen, digitalen Nachrichtenservice.<br />
• Mit <strong>atp</strong>!info<br />
erfahren Sie direkt und komprimiert,<br />
was die Automatisierungsbranche bewegt.<br />
<strong>atp</strong>!info ist <strong>das</strong> moderne Info-M edium, <strong>das</strong><br />
Ihnen Nachrichten liefert und über <strong>das</strong> Sie<br />
Nachrichten recherchieren können.<br />
Rund um die Uhr<br />
erstklassig informiert<br />
TEC HNOLOGIE<br />
Neu ab<br />
21. M ai<br />
INNOVATIONEN<br />
ESSEN<br />
PRODUKTE<br />
VERFAHREN<br />
HOC HSC HULEN<br />
• Branchenrelevante Meldungen laufend<br />
aktualisiert – immer und überall.<br />
• Umfangreiche Archivfunktionen <strong>für</strong> Ihre<br />
persönlichen Recherchen.<br />
<strong>atp</strong>!info ist ideal <strong>für</strong> unterwegs und <strong>für</strong><br />
den Einsatz auf mobilen Endgeräten.<br />
ENTWIC KLUNGEN<br />
KARRIERE<br />
<strong>atp</strong>! info-Team | Oldenbourg Industrieverlag GmbH | Rosenheimer Straß e 145 | 8167 1 M<br />
ünchen
H<br />
SCHWERPUNKT | SENSORIK<br />
Ausgeklügte Logistiksysteme reduzieren<br />
H andlingkosten von Verbindungselementen<br />
Schraubenhersteller Reyher setzt <strong>für</strong> neue Logistik Sensoren von Leuze electronic ein<br />
ARBEITSPLATZ im Bereich Behälterkommissionierung<br />
KONTURENKONTROLLE im Wareneingang<br />
BARCODELESUNG<br />
mit BCL 34 und<br />
Konturenkontrolle<br />
mit Lichtschranken<br />
der Baureihe BR 46<br />
im Wareneingang<br />
THOMAS LUDWIG<br />
von U.C.S. Industrieelektronik<br />
GmbH<br />
(links) und<br />
KLAUS MUNDT,<br />
technischer Leiter<br />
bei Reyher (rechts)<br />
Am Firmensitz in H amburg bewältigt <strong>das</strong> H andelshaus<br />
Reyher täglich einen Materialumschlag von<br />
mehreren hundert Tonnen <strong>für</strong> Kunden rund um den<br />
Globus. Der H andel mit Verbindungselementen und Befestigungsteilen<br />
ist geprägt von überproportional hohen<br />
Beschaffungs- und H andlingkosten im Vergleich zum<br />
eigentlichen Warenwert. Aus diesem Grund werden bei<br />
Reyher ausgeklügelte Logistiksysteme mit sehr hohem<br />
Automatisierungsgrad eingesetzt, stetig weiterentwickelt<br />
und ausgebaut.<br />
„ Die Automatisierung macht unsere Prozesse effizienter<br />
und fehlerfreier“ , so Klaus Mundt, technischer Leiter.<br />
Er misst die Leistungsfähigkeit der Anlage in puncto<br />
Materialumschlag anhand von Geschwindigkeit, Lieferflexibilität,<br />
Lieferqualität und Fehlerfreiheit.<br />
Beim Stichwort Fehlerfreiheit im Lager- und Logistikbereich<br />
kommen die Sensoren von Leuze electronic ins<br />
Spiel: „ Täglich über 1 5 0 0 0 verschiedene Produkte auszuliefern<br />
bedeutet, über 1 5 0 0 0 Behälter, Kisten oder Paletten<br />
oft mehrmals zu bewegen. Um diese zu identifizieren,<br />
arbeiten wir mit rund 1 0 0 Barcodelesegeräten.<br />
Üblicherweise werden solche Geräte von den H erstellern<br />
mit einer recht hohen Fehlerresistenz angeboten. Aber<br />
selbst bei einer gering erscheinenden restlichen Fehlerquote<br />
von beispielsweise zwei Prozent wären täglich<br />
immer noch mehrere hundert Fehlerkisten unterwegs.<br />
Mit Barcodelesern von Leuze electronic liegt unsere<br />
Quote der Fehllesungen bei nahezu null.“<br />
Es handelt sich um stationär installierte Barcodeleser<br />
(BCL) und Barcode-Positioniersysteme (BPS). „ Letztere<br />
setzen wir neben anderen Leuze-electronic-Systemen<br />
zur exakten Positionierung von Regalbediengeräten<br />
ein“ , ergänzt Thomas Ludwig, zuständiger Projektleiter<br />
der U.C.S. Industrieelektronik GmbH . Der Anbieter<br />
<strong>für</strong> Systemsteuerung und Automatisierung aus Wedel/<br />
olstein führt bei Reyher die Lager- und Logistikautomation<br />
aus.<br />
ZUVERLÄSSIG UND EINFACH INTEGRIERT<br />
Die BPS Barcode-Positioniersysteme bestehen aus zwei<br />
wesentlichen Komponenten: dem Barcodeband BCB und<br />
dem Lesekopf. Das Codeband ist ein selbstklebendes Polyesterband,<br />
<strong>das</strong> sich entlang der Fahrstrecke eines Regalbediengeräts<br />
einfach anbringen lässt. Zusätzliche<br />
Klemmen, Klipse, Fixier- und Spanneinrichtungen sind<br />
nicht notwendig.<br />
20<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
Neben der Zuverlässigkeit der Geräte ist auch deren<br />
einfache H andhabung und Integration wichtig. Diese<br />
kommt besonders bei dem Ausbau der H alle 1 2 zum<br />
Tragen. Die H alle, mit einer Arbeitsfläche von 7 5 0 0 m 2 ,<br />
beherbergt zukünftig einen Teil des Warenausgangs, in<br />
dem kundenspezfische Kanban-Behälter bewegt und<br />
befüllt werden. In diesem Zusammenhang konnte die<br />
Sicherheitssensorik mit Muting-Funktionalität angewandt<br />
werden.<br />
OPTIMIERTE VERDICHTER-ARBEITSPLÄTZE<br />
Die Kommissionierung der Kundenaufträge basiert im<br />
gesamten Logistikzentrum auf 6 0 0 0 0 Paletten- und<br />
1 2 0 0 0 0 Behälterplätzen in drei Lagerbereichen. „ Das bedeutet,<br />
<strong>das</strong>s bei uns nicht wie oft üblich ein Behälter<br />
durch die Lagerbereiche geschickt und sukzessive gefüllt<br />
wird, sondern <strong>das</strong>s <strong>für</strong> einen Kundenauftrag gegebenenfalls<br />
mehrere Behälter aus unterschiedlichen Lagerbereichen<br />
zusammengeführt werden“ , erklärt Klaus Mundt.<br />
Dies geschieht in sogenannten Sortern. Von dort gelangen<br />
die gesammelten Behälter zu „ Verdichter-Arbeitsplätzen“ ,<br />
wo die Produkte durch manuelles Umpacken in ihre endgültige<br />
Versandverpackung gebracht werden.<br />
Der gesamte Warenfluss ist je nach Versandart im Warenausgang<br />
1 und 2 (vorwiegend herkömmlicher Palettenversand)<br />
sowie im Warenausgang 3 organisiert (Versand<br />
mittels Kanban-Behälter). Dort müssen zu jedem<br />
Kundenauftrag die richtigen Zielbehälter, nämlich die<br />
zum jeweiligen Kanban-System des Kunden passenden<br />
Kanban-Behälter, den Verdichter-Arbeitsplätzen zugeführt<br />
werden. „ Bisher hatten die Mitarbeiter die jeweiligen<br />
Behälter manuell aus den Lagerplätzen beschafft.<br />
Dazu waren sie einen großen Teil ihrer Arbeitszeit zu<br />
Fuß unterwegs“ , erzählt Klaus Mundt.<br />
Im Zuge der Kapazitätsausweitung in der H alle 1 2<br />
wird auch der Kanban-Warenausgang separiert und<br />
neu angelegt. Wesentlich ist dabei, <strong>das</strong>s die leeren<br />
Kanban-Behälter den Verdichter-Arbeitsplätzen automatisch<br />
und zum richtigen Zeitpunkt über jeweils drei<br />
Palettenstellplätze zugeführt werden. „ Dies gilt <strong>für</strong><br />
alle hochdrehenden Behälter, so<strong>das</strong>s unsere Mitarbeiter<br />
nicht mehr durch <strong>das</strong> manuelle Kanban-Leergutlager<br />
laufen müssen und sich nur noch in ganz wenigen<br />
Fällen aus einem „ Exoten-H andlager“ manuell bedienen“<br />
, ergänzt Klaus Mundt.<br />
Die vollautomatische Kanban-Behälter-Bereitstellung,<br />
die von U.C.S. Industrieelektronik mit Geräten von Leuze<br />
electronic ausgestattet wurde, verfügt über Palettenstellplätze,<br />
in denen die gesamte Varianz gängiger Kanban-Behälter<br />
untergebracht ist. H inzu kommen Kanban-<br />
Behälter von Reyher selbst, die Kunden zur Miete angeboten<br />
werden. Deren Bereitstellung aus den Regalen<br />
erfolgt mit zwei Regalbediengeräten, die auf einer 6 0<br />
Meter langen Schiene fahren – ausgerüstet mit Barcode-<br />
Positioniersystemen von Leuze electronic. Deren steuerungstechnische<br />
Anbindung seitens U.C.S. Industrieelektronik<br />
verhindert zuverlässig Kollisionen. Zur flexiblen<br />
Datenübertragung aus den bewegten Fahrzeugen<br />
werden optische H ochleistungs-Datenübertragungssysteme<br />
(DDLS) von Leuze electronic verwendet.<br />
ABGESTIMMTE SICHERHEITSKOMPONENTEN IM SET<br />
Da nun die Paletten mit den leeren Kanban-Behältern<br />
direkt den Verdichter-Arbeitsplätzen zugeführt werden<br />
und somit automatisch bewegte Teile unmittelbar in<br />
die Arbeitsbereiche gelangen, müssen diese mit entsprechenden<br />
Sicherheitseinrichtungen geschützt werden.<br />
Denn die Paletten mit den Behältern sollen aus<br />
den mit Lichtgittern geschützten Bereichen fahren<br />
können, ohne beim Durchqueren des Lichtgitter-<br />
Schutzfelds ein Abschaltsignal auszulösen. Mit der<br />
Funktion Muting ist in solchen Fällen die bestimmungsgemäße<br />
und zeitlich begrenzte Unterdrückung<br />
der Schutzfunktion möglich.<br />
Die Konstellation der Lichtgitter wird je nach Anforderung<br />
ausgelegt. Da es sich bei Reyher um unterschiedlich<br />
große Behälter handelt, wurde die Variante des<br />
Kreuz-Muting mit zwei Reflexions-Lichtschranken mit<br />
gekreuzten Strahlen gewählt. Solche Schutzeinrichtungen<br />
bestehen aus zahlreichen Komponenten, die aufeinander<br />
elektrisch und mechanisch abgestimmt sein müssen,<br />
um neben der Sicherheit auch die Verfügbarkeit zu<br />
gewährleisten. Mit den Sicherheits-Sensor-Sets CPSET<br />
bietet Leuze electronic Lösungen, die diese Anforderungen<br />
berücksichtigen. Sie beinhalten <strong>für</strong> die jeweiligen<br />
Anwendungsfälle ausgewählte und bereits vorkonfektionierte<br />
Komponenten.<br />
„ Damit haben wir neben den gesamten Sensoraufgaben<br />
in der Logistik-Automation auch Muting-Applikationen<br />
schnell, einfach und kostengünstig mit zuverlässiger<br />
Optoelektronik aus einer H and, realisiert“ , sagt U.C.S.-<br />
Projektleiter Thomas Ludwig.<br />
AUTOR<br />
Leuze electronic GmbH + Co. KG,<br />
In der Braike 1, D-73277 Owen/Teck,<br />
Tel. +49 (0) 7021 57 31 43,<br />
E-Mail: matthias.goehner@leuze.de<br />
MATTHIAS GÖHNER<br />
leitet im Produktmanagement<br />
die Gruppe Förder-Lagertechnik<br />
bei der Leuze electronic<br />
GmbH + Co. KG.<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
21
SCHWERPUNKT | SENSORIK<br />
Signalaufbereitung in der Druckmesskapsel<br />
macht Sensoren kleiner und robuster<br />
Linearisierung, Temperaturkompensation und Parametrierung finden direkt im Stahlgehäuse statt<br />
VDD<br />
+VCC<br />
R S<br />
+Vref<br />
µC<br />
Sensor<br />
SigCond<br />
+OUT<br />
GND<br />
R A<br />
R G<br />
AIN<br />
-Vref<br />
ADC<br />
10..12 Bit<br />
with internal<br />
ADC<br />
VSS<br />
SCHEMATISCHER AUFBAU EINES C-LINIE-OEM-TRANSMITTERS,<br />
direkt verbunden mit einem Mikrocontroller mit <strong>integrierte</strong>m Analog/Digital-Konverter.<br />
Wird darauf geachtet, <strong>das</strong>s die Leitungswiderstände niedrig gehalten werden, ist keine<br />
Kalibration nötig, da der ADC und der SigCond aufeinander referenziert sind.<br />
Sensor<br />
Sensor<br />
Sensor<br />
DIE EMPFINDLICHEN SENSORSIGNALE<br />
werden über ultrakurze<br />
Wire-Bond-Drähte mit dem<br />
Signalkonditionierungs-IC verbunden<br />
und als niederohmiges, aufbereitetes<br />
Signal durch die Glasdurchführungspins<br />
nach aussen geführt. Selbst der<br />
EMV- und ESD-Schutz sind integriert.<br />
Bilder: Keller Druckmesstechnik<br />
SigCond<br />
ADDR=0x02<br />
SigCond<br />
ADDR =0x01<br />
SigCond<br />
ADDR =0x00<br />
+VCC<br />
SCL<br />
SDA<br />
GND<br />
+VCC<br />
SCL<br />
SDA<br />
GND<br />
+VCC<br />
SCL<br />
SDA<br />
GND<br />
RPULLUP<br />
RPULLUP<br />
µC<br />
VDD<br />
I 2 C-Master<br />
SCL<br />
SDA<br />
VSS<br />
SCHEMATISCHER AUFBAU EINES<br />
MINI-NETZWERKES von D-Linie-OEM-<br />
Transmittern in der I2C-Version. Zwei<br />
freie digitale Tri-State-I/O-Leitungen<br />
sind die einzige Anforderung an den<br />
Mikrocontroller, der als Master <strong>das</strong><br />
Timing frei bestimmt.<br />
Mithilfe der Chip-in-Oil-Technologie (CiO) werden<br />
Sensoren sehr kompakt und besitzen hohe Widerstandsfähigkeit<br />
gegen elektrische Störfelder. Infolge kleiner<br />
Massen und kurzer Leitungswege sind sie zudem<br />
sehr vibrationsbeständig. Feuchtigkeit und hohe Temperaturen<br />
können ihnen ebenfalls wenig anhaben.<br />
Das von Keller Druckmesstechnik entwickelte Chipin-Oil-Konzept<br />
bringt die Signalaufbereitung direkt in<br />
<strong>das</strong> mit Ö l gefüllte, schützende Gehäuse der Druckmesskapsel<br />
aus Edelstahl. Dort finden die Linearisierung,<br />
Temperaturkompensation und Parametrierung statt.<br />
Die CiO-Technik bringt in einem gemeinsamen Gehäuse<br />
unmittelbar neben dem Drucksensor ein ASIC unter,<br />
der dem Anwender eine Reihe von vorteilhaften Funktionalitäten<br />
bietet. Dass trotz der Integration der Folgeelektronik<br />
die Druckmesskapsel nicht größer wird, ist<br />
zum einen der Miniaturisierung und Optimierung der<br />
Komponenten zu verdanken. Zum anderen kommt ein<br />
platzsparender Single-Chip Asic zum Einsatz.<br />
Eingesinterte, druckfeste Glasdurchführungen liefern<br />
die Transmitter-Signale nach außen. Im Innern erfolgt die<br />
Verdrahtung durch kurze, leichte Bonddrähte – alles unter<br />
Ausschluss von Luft unter Ö l. So kann beim weiteren<br />
Einbau des Druckaufnehmers auf den Anschluss filigraner<br />
Signalaufbereitungsplatinen samt vieladriger Verkabelung<br />
verzichtet werden. Zudem muss diese Folgelektronik<br />
nicht vor Feuchte und Betauung geschützt werden.<br />
Zusammen mit dem Edelstahlgehäuse wirken die Glasdurchführungen<br />
wie Durchführungskondensatoren und<br />
bilden einen Faraday’ schen Käfig. So ist die CiO-Technologie<br />
extrem robust gegen elektrische Felder. Selbst Feldstärken<br />
von 2 5 0 flV/m bei Frequenzen bis 4 flGH z können<br />
<strong>das</strong> Messsignal nicht beeinflussen. Die digitale Schnittstelle<br />
muss vom Gerätebauer selbst geschützt werden. Der<br />
22<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
ASIC ist als Mikrocontroller mit entsprechender Peripherie<br />
ausgelegt, so<strong>das</strong>s die Sensorsignale mit großer Auflösung<br />
und Dynamik erfasst werden können. Zusätzlich<br />
zum Prozessdruck wird die Temperatur des Drucksensors<br />
gemessen und bei der Signalaufbereitung zur mathematischen<br />
Temperatur-Kompensation verwendet.<br />
GERINGER AUFWAND FÜR DIE SIGNALÜBERGABE<br />
Die OEM-Transmitter bieten zwei Ausgangssignale: einen<br />
ratiometrischen analogen Spannungsausgang und eine<br />
digitale Inter-Integrated-Circuit-Schnittstelle (I2 C). Vorteil<br />
des ratiometrischen Formats des Ausgangssignals ist,<br />
<strong>das</strong>s es eigentlich kein Format hat. Denn es ist abhängig<br />
von der Versorgungsspannung. Für die Anwendung in<br />
<strong>integrierte</strong>n Systemen stellt <strong>das</strong> einen großen Vorteil dar.<br />
Wird nämlich der dem Transmitter nachfolgende Analog/<br />
Digitalwandler mit derselben Versorgungsspannung betrieben,<br />
so ist der digitale Messwert immer korrekt. Das<br />
liegt daran, <strong>das</strong>s zwar die H öhe der Digitalisierungsstufen<br />
von der Versorgungsspannung abhängt, nicht aber die<br />
Zahl der Stufen – die aber sind entscheidend.<br />
Dank ratiometrischer Signale lässt sich der Aufwand<br />
<strong>für</strong> die Signalübergabe vom Drucktransmitter an den<br />
A/D-Wandler der Folgeelektronik deutlich verringern<br />
und Kalibrierungsschritte werden überflüssig – speziell<br />
beim Anschließen an einen Mikrokontroller mit <strong>integrierte</strong>m<br />
A/D-Wandler ist er gleich Null. Trotzdem ist eine<br />
Spanne des Ausgangssignals spezifiziert, nämlich 0 ,5 ...<br />
4 ,5 V bei einer Speisespannung von 5 ,0 V. Mit einer stabilen<br />
und genauen Versorgungsspannung kann diese<br />
Spanne auch direkt als „ Normsignal“ genutzt werden.<br />
Die Abtastrate von 2 kH z bietet einen erstaunlich guten<br />
Dynamikumfang <strong>für</strong> ein Produkt, <strong>das</strong> auf dem AD/DA-<br />
Prinzip basiert. Zudem bietet die Embedded Elektronik<br />
in CiO-Technologie einen permanenten Überspannungsund<br />
Verpolungsschutz auf allen Leitungen bis ± 3 3 VDC.<br />
I2C-MASTER BESTIMMT DAS TIMING<br />
OEM-Transmitter in der Größe von Druckmesskapseln<br />
werden nie direkt an Feldbussysteme angeschlossen. Vielmehr<br />
verfügen die jeweiligen Koppelmodule über entsprechende<br />
Eingangsschnittstellen, etwa <strong>für</strong> die Inter-<br />
Integrated-Circuit- beziehungsweise die I2 C-Schnittstelle.<br />
Sie gilt seit J ahren als serieller Standard zur Überwindung<br />
kurzer Strecken in embedded Systemen. Der<br />
I2 C-Master benötigt <strong>für</strong> die seriellen Daten und den Takt<br />
<strong>für</strong> die synchrone Abfrage (Clock) zwei Leitungen. An<br />
den Master werden somit keine Anforderungen an <strong>das</strong><br />
Timing gestellt – er bestimmt es.<br />
J eder OEM-Transmitter hat eine eigene Adresse, die<br />
vom I2 C-Master angesprochen wird. Derzeit könnten<br />
von einem Master 1 2 8 unterschiedliche Adressen verwaltet<br />
werden. Die Druck- und Temperaturwerte werden<br />
durch einen Request des Masters erfasst und stehen<br />
dann an den Transmittern (Slaves) nach weniger als<br />
1 0 ms bereit um nach einem vorgegebenen Protokoll<br />
ausgetaktet zu werden. Die Werte sind über Temperatur<br />
kompensiert und normiert und müssen nur noch von<br />
1 5 Bit-Ganzzahl in einen einheitsbehafteten Druck beziehungsweise<br />
eine Temperatur skaliert werden.<br />
Im Gegensatz zur CiO-Version mit ratiometrischem Ausgang<br />
können jene mit I2 C-Ausgang auch mit nur 1 ,8 ...3 ,6<br />
VDC Versorgungsspannung arbeiten und sind damit bestens<br />
auf mobile, batteriebetriebene Anwendungen vorbereitet.<br />
Dazu gehört auch die kurze Wandlungszeit von<br />
weniger als 1 0 ms, während der lediglich 1 ,5 mA gezogen<br />
werden und der bestens optimierte Sleep-Mode – in dem<br />
die Transmitter verharren, wenn sie nicht angefragt – der<br />
mit typisch 0 ,1 µ A spezifiziert ist. Falls der Master eine<br />
angemessen schnelle Kommunikation erlaubt, können<br />
somit über 1 0 0 Samples pro Sekunde erreicht werden.<br />
KOMPAKTE LÖSUNG BRINGT AUCH KOSTENVORTEIL<br />
J e nach Format des Ausgangssignals – ratiometrisch oder<br />
digital – ändern sich typische Kenndaten. Mit dem analogen<br />
Ausgang kann der Transmitter bei Temperaturen<br />
zwischen -4 0 ° C bis + 1 5 0 ° C eingesetzt werden, während<br />
der I2 C-Ausgang die obere Grenze bei 8 0 ° C ziehen muss.<br />
Der Druckbereich der analogen Version reicht von 2 bis<br />
1 0 0 0 bar und bei der digitalen Version von 2 bar bis 2 0 0<br />
bar. Für einen erhöhten Dynamikumfang bei erhöhtem<br />
Stromverbrauch von max. 8 mA sollte die analoge Version<br />
gewählt werden. Für Low Voltage und Low Power Applikationen<br />
empfiehlt sich die digitale Version, die auch die<br />
Temperaturinformation mitliefert. Unterm Strich bietet<br />
die Chip-in-Oil-Technologie neben funktionalen Stärken<br />
auch noch einen Kostenvorteil, da eine externe<br />
Elektronik überflüssig wird und alle Funktionen mit<br />
einer Single-Chip-Lösung realisiert werden.<br />
AUTOREN<br />
Dipl. El.-Ing. (FH ) DANIEL HOFER ist<br />
Elektronik- und Software-Entwickler<br />
bei Keller Druckmesstechnik.<br />
Keller AG <strong>für</strong> Druckmesstechnik,<br />
St. Gallerstrasse 119, Postfach,<br />
CH-8404 Winterthur,<br />
Tel. +41 52 235 25 25,<br />
E-Mail: d.hofer@keller-druck.com<br />
Dipl. El.-Ing. (H TL) BERNHARD VETTERLI<br />
ist Elektronik- und Software-Entwickler<br />
bei Keller Druckmesstechnik.<br />
Keller AG <strong>für</strong> Druckmesstechnik,<br />
St. Gallerstrasse 119, Postfach,<br />
CH-8404 Winterthur,<br />
Tel. +41 52 235 25 25,<br />
E-Mail: b.vetterli@keller-druck.com<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
23
PRAXIS<br />
Frühzeitige dynamische Simulationen erhöhen<br />
Sicherheit bei Inbetriebnahme und Betrieb<br />
Ein adäquates Maschinenschutz-System in verfahrenstechnischen Anlagen verifizieren<br />
BILD 1: Prozesstopologie nach<br />
Design und Reglerstruktur.<br />
In dem Kältemittelkreislauf<br />
wird Propan aus einer<br />
Saugflasche (VV501) in<br />
drei Verdichtersektionen<br />
(KC501_I, KC501_II und<br />
KC501_III) auf den Enddruck<br />
verdichtet, anschließend<br />
in HE501 gekühlt, dabei<br />
verflüssigt und in dem<br />
Behälter VV504 gesammelt.<br />
Das flüssige Propan steht der<br />
Olefin anlage als Kältemittel<br />
auf unterschiedlichen<br />
Druckniveaus in den<br />
Verbrauchern HE316,<br />
HE326, HE401 sowie HE320,<br />
HE402, HP405 und HP601<br />
zur Verfügung.<br />
Dynamische Simulationen vertiefen <strong>das</strong> Prozessverständnis<br />
und ermöglichen einen detaillierten<br />
Einblick in <strong>das</strong> Verhalten verfahrenstechnischer Anlagen<br />
unter transienten Bedingungen. Selbst sorgfältigstes<br />
stationäres Anlagendesign deckt nicht alle Aspekte<br />
ab, welche <strong>für</strong> einen sicheren Anlagenbetrieb<br />
erforderlich sind. Da verfahrenstechnische Anlagen<br />
nicht ausschließlich in einem stationären Betriebspunkt<br />
betrieben werden, müssen bezüglich der Sicherheitsaspekte<br />
dynamische Simulationen durchgeführt<br />
werden. Diese sind zwar aufwendig, allerdings ist es<br />
nur so möglich, ein adäquates Maschinenschutzsystem<br />
zu verifizieren.<br />
Der Geschäftsbereich Linde <strong>Engineering</strong> der Linde<br />
AG plant und baut verfahrenstechnische Großanlagen<br />
zur Luftzerlegung, Erdgasverflüssigung, Gastrennung,<br />
Olefin- und Synthesegaserzeugung. In allen diesen Anlagen<br />
sind Verdichter und Turbinen ein unverzichtbarer<br />
Bestandteil der Prozessführung. Deren Betriebssicherheit<br />
ist daher nicht nur <strong>für</strong> ausgedehnte Betriebsintervalle<br />
sicherzustellen, sondern auch <strong>für</strong> einen transienten<br />
Betrieb assoziiert mit Lastregelung sowie An- und<br />
Abfahrvorgängen. Risiken bezüglich der Betriebssicherheit<br />
werden meist identifiziert, indem alle Apparate<br />
hinsichtlich ihrer Funktion geprüft werden und untersucht<br />
wird, ob diese Funktion unter anderen Randbedingungen<br />
noch gewährleistet ist.<br />
Allerdings lassen sich transiente Vorgänge nur begrenzt<br />
über derartige stationäre Betrachtungen abschätzen,<br />
hier<strong>für</strong> sind dynamische Simulationen notwendig.<br />
Die Integration einer dynamischen Simulation in den<br />
<strong>Engineering</strong>-Prozess einer Auftragsabwicklung stellt<br />
dabei eine besondere H erausforderung dar. Einerseits<br />
ist es wünschenswert, wenn grundsätzliche Erkenntnisse<br />
bereits bei der Konzeptionierung der Anlage vorliegen.<br />
Andererseits muss eine Parametrierung der Maschinen<br />
und Apparate auf der Basis von konkreten<br />
Bestellunterlagen erfolgen, welche erst sehr spät zur<br />
Verfügung stehen.<br />
Bei der Inbetriebnahme sind die vorab durchgeführten<br />
dynamischen Simulationen hilfreich, da die Reglerstruktur<br />
und H ardware bereits auf ihre Funktion<br />
überprüft wurde, somit <strong>das</strong> Anlagenverhalten als bekannt<br />
vorausgesetzt werden kann.<br />
PROPANKREISLAUF ALS TESTFALL<br />
Am Beispiel des Propankreislaufs einer petrochemischen<br />
Großanlage soll der Workflow bei Linde <strong>Engineering</strong> während<br />
der Auslegung und Überprüfung des Maschinenschutzes<br />
anschaulich erläutert werden. Das Flowsheet des<br />
Prozesses ist in Bild 1 dargestellt: In dem Kältemittelkreislauf<br />
wird Propan aus einer Saugflasche (VV5 0 1 ) in<br />
drei Verdichtersektionen (KC5 0 1 _ I, KC5 0 1 _ II und KC5 0 1 _<br />
III) auf den Enddruck verdichtet, anschließend in H E5 0 1<br />
gekühlt, dabei verflüssigt und in dem Behälter VV5 0 4<br />
gesammelt. Das flüssige Propan steht der Olefinanlage als<br />
Kältemittel auf unterschiedlichen Druckniveaus in den<br />
Verbrauchern H E3 1 6 , H E3 2 6 , H E4 0 1 sowie H E3 2 0 , H E4 0 2 ,<br />
H P4 0 5 und H P6 0 1 zur Verfügung. Es wird in diesen Wärmetauschern<br />
angewärmt und vollständig verdampft. An-<br />
24<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
BILD 2: Run-Down-Kurven<br />
und Drücke bei originaler<br />
Prozesstopologie (Normal<br />
Stop). (a)–(c) zeigen den<br />
zeitlichen Verlauf des<br />
Betriebspunkts<br />
(Betriebskennlinie) der<br />
einzelnen Verdichtersektionen<br />
(rote Linie) in ihrem<br />
zugehörigen Förderhöhen-<br />
Kennfeld. In (d) sind die<br />
wesentlichen Druckniveaus<br />
(Saugdruck, Zwischendrücke<br />
und Enddruck) geplottet.<br />
schließend wird <strong>das</strong> Propan wieder in die dem jeweiligen<br />
Druckniveau entsprechende Saugflasche eingespeist. Die<br />
Saugflaschen <strong>für</strong> die Zwischenstufen sind füllstandsgeregelt,<br />
der Saugdruck der ersten Stufe wird über die Drehzahl<br />
eingestellt. Die Temperaturen nach den Saugflaschen<br />
sind über Quenchventile geregelt.<br />
Für den Maschinenschutz ist <strong>für</strong> jede Verdichtersektion<br />
eine Bypassleitung vorgesehen, welche über die<br />
zugehörigen Ventile FV5 1 0 1 , FV5 1 0 2 und FV5 1 0 3 im<br />
Normalbetrieb abgesperrt ist. Die Bypässe binden nach<br />
den Ventilen direkt in die entsprechende Saugflasche<br />
ein. Üblicherweise werden diese Ventile vom Maschinenhersteller<br />
ausgelegt, welcher allerdings über keine<br />
Kenntnis der Prozesstopologie – insbesondere über die<br />
beteiligten Volumina – verfügt.<br />
Der selbstentwickelte gleichungsorientierte Prozesssimulator<br />
Optisim wird bei Linde <strong>Engineering</strong> zur stationären<br />
und dynamischen Simulation sowie zur stationären<br />
und dynamischen Optimierung verwendet. Die<br />
jeweiligen Apparate sind durch ihre Erhaltungsgleichungen<br />
<strong>für</strong> Energie und Menge sowie durch die physikalischen<br />
Gleichgewichte beschrieben und tauschen<br />
über Ströme, Wärmen und Signale Informationen mit<br />
den topologisch verbundenen Einheiten aus. Die Nutzer<br />
verwenden in einem Flowsheet vorgegebene Prozessunits,<br />
welche sie einer Modellbibliothek entnehmen<br />
können. Für die konkrete Anwendung müssen diese<br />
Apparate lediglich parametriert werden.<br />
Die Umwandlung eines Anlagenmodells <strong>für</strong> <strong>das</strong> Design<br />
in ein Prozessmodell <strong>für</strong> <strong>das</strong> Anlagenrating beziehungsweise<br />
<strong>für</strong> eine dynamische Simulation ist aufwendig.<br />
Meist ist es einfacher und schneller, <strong>für</strong> beide<br />
Anwendungen (Design und Rating/dynamische Simulation)<br />
getrennte Anlagenmodelle zu verwenden. Es ist<br />
empfehlenswert, <strong>für</strong> den nominalen Betriebsfall die<br />
Ergebnisse der Design- und Rating-Rechnung zu vergleichen<br />
und zu prüfen, ob die Rating-Modelle die aus<br />
dem Anlagendesign stammenden Spezifikationen wiedergeben<br />
(Designverifikation).<br />
RATINGMODELL BILDET KÄLTEKREISLAUF GUT NACH<br />
Für den hier betrachteten Propankreislauf ergeben sich<br />
Unterschiede zwischen dem Designmodell und dem Ratingmodell<br />
von maximal 1 ,5 fl% in Druck, Temperatur oder<br />
Mengen. Damit gibt <strong>das</strong> Rating-Modell den ausgelegten<br />
Kältekreislauf ausreichend genau wieder.<br />
Bei dem geplanten Maschinenstopp wird ein Verdichter<br />
mit geöffneten Bypassventilen auf die Mindestdrehzahl<br />
(hier: 2 3 5 1 rpm) gedrosselt. Erst danach wird der<br />
Antrieb abgeschaltet. Die Bilder 2 (a)– 2 (c) zeigen den<br />
zeitlichen Verlauf des Betriebspunkts (Betriebskennlinie)<br />
der einzelnen Verdichtersektionen (rote Linie) in<br />
ihrem zugehörigen Förderhöhen-Kennfeld. Dieses bildet<br />
die Förderhöhe über dem saugseitigen Volumenstrom<br />
ab. Die Isodrehzahlkurven sind als blau gestrichelte<br />
Linien dargestellt, die Pumpgrenze ist blau gepunktet.<br />
Der Betriebspunkt bei Normalbetrieb ist als roter Punkt<br />
hervorgehoben. In Bild 2 (d) sind die wesentlichen<br />
Druckniveaus (Saugdruck, Zwischendrücke und Enddruck)<br />
geplottet.<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
25
H<br />
PRAXIS<br />
BILD 3: Run-Down-Kurven und Drücke bei originaler<br />
Prozesstopologie (ESD). Die Simulation zeigt allerdings, <strong>das</strong>s <strong>für</strong><br />
einen Antriebsausfall die Konfiguration des Maschinenschutzes<br />
nicht ausreichend ist. Der Betriebspunkt in den Verdichtersektionen<br />
1 und 2 wandert nach dem Abschalten des Antriebs und trotz<br />
gleichzeitigem Öffnen der Bypassventile über die Pumpgrenze aus<br />
dem Kennfeld heraus.<br />
BILD 4: Run-Down-Kurven und Drücke bei modifizierter<br />
Prozess topologie (Normal Stop). Die Simulationen zeigt, <strong>das</strong>s<br />
die umfangreichen Modifikationen <strong>für</strong> den ESD bei einem<br />
normalen Maschinenstopp kaum Auswirkungen haben.<br />
Auf den Bildern 2 (a)– (c) ist zu sehen, <strong>das</strong>s der Betriebspunkt<br />
durch <strong>das</strong> Ö ffnen der Bypassventile zunächst<br />
weit nach rechts wandert. Durch die anschließende<br />
Verringerung der Drehzahl bis zur Mindestdrehzahl<br />
des Verdichters bewegt sich der Betriebspunkt im<br />
Kennfeld anschließend in Richtung Pumpgrenze. Dann<br />
erfolgt <strong>das</strong> H erunterfahren auf die untere Leerlaufdrehzahl.<br />
Ein Verdichter ist dann ausreichend vor Pumpen<br />
geschützt, wenn die Betriebskennlinie die Pumpgrenze<br />
innerhalb des Kennfeldes nicht schneidet. Damit pumpt<br />
bei diesem Fahrfall keine der drei Maschinensektionen,<br />
und auch der Warmstart von der unteren Leerlaufdrehzahl<br />
aus erfolgt problemlos.<br />
Beim Warmstart wird die Maschine mit einer vom<br />
ersteller vorgegebenen Ramprate durch den biege- und<br />
torsionskritischen Drehzahlbereich von der unteren<br />
Leerlaufdrehzahl auf die Mindestdrehzahl beschleunigt.<br />
Anschließend werden die Anti-Surge-Regler in Betrieb<br />
genommen. Dadurch erfolgt bei Mindestdrehzahl ein<br />
Androsseln bis hin zur Pumpgrenze. Danach wird auf<br />
die Nenndrehzahl beschleunigt, wodurch der Taupunkt<br />
im Kondensator VV5 0 4 erreicht wird. Dies führt dazu,<br />
<strong>das</strong>s die Anti-Surge-Regler in ihre Sättigung laufen und<br />
die Bypassventile schließen. Zuletzt werden die übrigen<br />
Regler wieder in Betrieb genommen und der alte Ausgangszustand<br />
ist erreicht.<br />
ANTRIEBSLEISTUNG BRICHT PLÖTZLICH EIN<br />
Nun stellt ein geplanter Maschinenstopp hinsichtlich des<br />
Maschinenschutzes lediglich ein notwendiges, aber kein<br />
hinreichendes Kriterium dar. Das Nichtvorhandensein<br />
vom Pumpen in den drei Verdichtersektionen zeigt, <strong>das</strong>s<br />
zumindest ein notwendiges Kriterium erfüllt ist.<br />
Ein hinreichendes Kriterium ist <strong>das</strong> Nicht-Pumpen bei<br />
einem Antriebsausfall. Dabei bricht instantan die Antriebsleistung<br />
ein. Erst mit der Detektion dieses Ereignisses<br />
erhalten die Bypassventile <strong>das</strong> Signal zum Ö ffnen,<br />
was zur Druckentlastung der Maschine führen sollte. Die<br />
Simulation zeigt allerdings (Bild 3 ), <strong>das</strong>s <strong>für</strong> einen Antriebsausfall<br />
die Konfiguration des Maschinenschutzes<br />
nicht ausreichend ist. Der Betriebspunkt in den Verdichtersektionen<br />
1 und 2 wandert nach dem Abschalten des<br />
Antriebs und trotz gleichzeitigem Ö ffnen der Bypassventile<br />
über die Pumpgrenze aus dem Kennfeld heraus.<br />
BYPÄSSE NICHT AUSREICHEND AUSGELEGT<br />
Da in den bisherigen Simulationen die vom Maschinenhersteller<br />
vorgegebenen Bypassventile verwendet wurden,<br />
zeigt dieses Ergebnis, <strong>das</strong>s ein Maschinenhersteller<br />
die ausreichende Auslegung der Bypässe nicht gewährleisten<br />
kann, da er nicht über alle notwendigen Informationen<br />
vom Gesamtprozess verfügt.<br />
Ist der Maschinenschutz nicht gewährleistet, so wird<br />
zunächst versucht, eine Lösung mit der bereits ausgelegten<br />
Prozesstopologie zu finden, <strong>das</strong> heißt, die Bypassventile<br />
zu vergrößern. Führt auch <strong>das</strong> zu keinem<br />
zufriedenstellenden Ergebnis, so muss die Topologie<br />
selbst hinterfragt werden. In dem betrachteten Beispiel<br />
mussten sowohl die Topologie als auch die Dimension<br />
der Bypassventile modifiziert werden. Weitere Simulationen<br />
zeigen, <strong>das</strong>s mit diesen Ä nderungen eine Notab-<br />
26<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
Mit Sicherheit<br />
kompetent<br />
schaltung aus unterschiedlichsten Lastfällen problemlos<br />
durchgeführt werden kann. Diese Modifikationen<br />
haben aber nur einen Einfluss auf die direkt<br />
nach einem Abschalten zu beobachtende kurzfristige<br />
Dynamik. Das Verhalten der Verdichter bei einem geplanten<br />
Stopp wird dadurch nur unwesentlich beeinflusst,<br />
da hierbei der Antrieb bei bereits geöffneten<br />
Bypassventilen abgeschaltet wird (Bild 4 ).<br />
Wie <strong>das</strong> Beispiel der Auslegung von Maschinenschutzsystemen<br />
zeigt, müssen bezüglich der Sicherheitsaspekte<br />
dynamische Simulationen durchgeführt<br />
werden. Ein weiterer Schritt zur Erleichterung einer<br />
Inbetriebnahme ist die Einbindung eines Emulators,<br />
beispielsweise der Performance- und Anti-Surge-<br />
Regelung in die Prozesssimulation über eine geeignete<br />
Schnittstelle. Derartige Emulatoren werden von<br />
einigen H erstellern von Maschinenregelsystemen<br />
angeboten. Auf diese Weise ist es möglich, bereits<br />
vorab die Reglerparameter zu bestimmen und <strong>das</strong><br />
DCS (Distributed Control System) mit diesen Werten<br />
zu parametrieren.<br />
Besuchen Sie uns auf der<br />
ACHEMA 2012<br />
Halle 11.1, Stand C75<br />
AUTOREN<br />
Dr.-Ing. MARTIN HÄFELE<br />
ist <strong>für</strong> die Entwicklung<br />
des Prozesssimulators<br />
Optisim verantwortlich<br />
und übernimmt Projektleitungsaufgaben<br />
bei der<br />
dynamischen Simulation.<br />
Linde AG, <strong>Engineering</strong> Division,<br />
Dr.-Carl-von-Linde-Str. 6-14, D-82049 Pullach,<br />
Tel. +49 (0) 89 74 45 28 90,<br />
E-Mail: martin.haefele@linde-le.com<br />
Dipl.-Ing. MARTIN KAMANN<br />
ist als Projekt-Ingenieur<br />
<strong>für</strong> die Abwicklung und<br />
Durchführung dynamischer<br />
Simulationen zur Verifikation<br />
von Maschinen schutzund<br />
Regelsystemen verantwortlich.<br />
SIL<br />
SIL SIL<br />
Mit den Stellventilen Typ 3241 von<br />
SAMSON sind Sie immer auf der<br />
sicheren Seite. Dank ihrer hohen<br />
MTBF brauchen Sie sich um einen<br />
Ausfall nicht zu sorgen.<br />
Noch mehr Sicherheit garantieren die<br />
Stellungsregler der Bauarten 3730<br />
und 3731. Mit ihrem zertifizierten<br />
Magnetventil und dem induktiven<br />
Grenzkontakt führen sie die Sprungantworttests<br />
automatisch durch und<br />
dokumentieren die Ergebnisse.<br />
Gehen Sie auf Nummer sicher mit<br />
SAMSON.<br />
Linde AG, <strong>Engineering</strong> Division,<br />
Dr.-Carl-von-Linde-Str. 6-14, D-82049 Pullach,<br />
Tel. +49 (0) 89 74 45 27 57,<br />
E-Mail: martin.kamann@linde-le.com<br />
A01039DE<br />
SAMSON AG · MESS- UND REGELTECHNIK<br />
Weismüllerstraße 3 · 60314 Frankfurt am Main<br />
Telefon: 069 4009-0 · Telefax: 069 4009-1507<br />
E-Mail: samson@samson.de · www.samson.de<br />
SAMSON GROUP · www.samsongroup.net
HAUPTBEITRAG<br />
<strong>Anforderungsanalyse</strong> <strong>für</strong><br />
<strong>das</strong> <strong>integrierte</strong> <strong>Engineering</strong><br />
Mechanismen und Bedarfe aus der Praxis<br />
Anhand von Anwendungsfällen aus der Praxis diskutiert dieser Beitrag den Bedarf an<br />
besserer Integration von Daten und Funktionen aus Software-Werkzeugen, um Abläufe<br />
im <strong>Engineering</strong> von industriellen Anlagen auf Projektebene zu automatisieren. Stärken<br />
und Beschränkungen von drei Ansätzen <strong>für</strong> Integrationsmechanismen in Software-Werkzeugen<br />
werden untersucht. Es werden Anforderungen <strong>für</strong> ein System zur Integration<br />
heterogener Werkzeuge identifiziert. Die darauf aufbauende Softwarelösung, Automation<br />
Service Bus, wird in einem Folgebeitrag vorgestellt.<br />
SCHLAGWÖRTER Paralleles <strong>Engineering</strong> / Software-Werkzeug-Integration /<br />
Datenaustausch / Werkzeug unterstützte Arbeitsabläufe / Automation<br />
Service Bus<br />
Requirement analysis for integrated engineering –<br />
Mechanisms and and practical demands<br />
On the basis of practical industrial applications, this contribution considers the need for<br />
improved integration of data and functions from software tools for the automation of<br />
processes in the engineering of industrial plants. Strengths and limitations of three approaches<br />
for integration mechanisms in software tools are investigated, and requirements<br />
for the integration of heterogeneous tools are identified. A derived software solution – the<br />
Automation Service Bus – will be presented in a future contribution.<br />
KEYWORDS parallel engineering / software tool integration / data exchange /<br />
tool-supported workflows / Automation Service Bus<br />
28<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
H<br />
H<br />
STEFAN BIFFL, RICHARD MORDINYI UND THOMAS MOSER, Technische Universität Wien<br />
Das parallele <strong>Engineering</strong> industrieller Anlagen<br />
erfordert die effektive und effiziente Zusammenarbeit<br />
von Experten mehrerer Fachbereiche<br />
– wie mechanisches, elektrisches und<br />
Software-<strong>Engineering</strong> – und deren spezialisierter<br />
Software-Werkzeuge zum Editieren von Sichten<br />
auf <strong>das</strong> gemeinsame mechatronische Modell der Anlage,<br />
etwa Fließbildschemata, elektrische Pläne und Software-<br />
Code <strong>für</strong> die Kontrolle von Geräten und Prozessabläufen.<br />
Es gibt Bestrebungen, definierte Mengen von Software-<br />
Werkzeugen vorzugeben, die gut miteinander nutzbar<br />
sind. Allerdings ist die Realität in den meisten Projekten<br />
eine Sammlung der <strong>für</strong> den jeweiligen Fachbereich bestgeeigneten<br />
Software-Werkzeuge, die aber nicht <strong>für</strong> eine<br />
lückenlose Zusammenarbeit entworfen wurden.<br />
Ein Beispiel, <strong>das</strong> zeigt, wie die effiziente Zusammenarbeit<br />
von Werkzeugen Risiken und Aufwände reduziert,<br />
sind Ä nderungskaskaden. So kann eine durch den<br />
Maschinenbauer vorgenommene Typänderung eines<br />
Füllstandsensors weitere Ä nderungen bei der Verkabelung<br />
durch den Elektriker und bei der Kontrolllogik<br />
durch den Experten <strong>für</strong> die Automatisierungs-Software<br />
notwendig machen. Falls derartige Ä nderungen nicht<br />
korrekt und rechtzeitig an die richtigen Personen kommuniziert<br />
werden, ergeben sich daraus kostspielige<br />
Nacharbeiten. Die funktionierende Integration der Daten<br />
und Funktionen der beteiligten Software-Werkzeuge<br />
erlaubt es, Ä nderungen in einer Modellsicht automatisch<br />
in den korrespondierenden Sichten nachzuziehen<br />
oder zumindest den zuständigen Kollegen über die Ä n-<br />
derung zu informieren.<br />
In der Praxis ist eine Art „ <strong>Engineering</strong> Polynesien“<br />
aus Software-Werkzeuginseln beobachtbar, mit<br />
Schnittstellen, die nicht nahtlos passen; und zugleich<br />
ein „ <strong>Engineering</strong> Babylon” , in dem Fachexperten gemeinsame<br />
Konzepte auf Projektebene verwenden, welche<br />
in den Software-Werkzeugen auf unterschiedliche<br />
Weise repräsentiert sind. Daher müssen Fachexperten<br />
zusammenarbeiten, um sich wiederholende Aufgaben<br />
durchzuführen, die eigentlich durch kooperierende<br />
Werkzeuge erledigt werden sollten, etwa Ä nderungskaskaden<br />
oder die grundlegende Qualitätssicherung<br />
zwischen Modellsichten.<br />
Bild 1 zeigt auf der linken Seite die Fachexperten und<br />
deren spezifische Software-Werkzeuge und Daten, auf der<br />
rechten Seite Projektpartner, die Arbeitsabläufe unter<br />
Verwendung der Daten aus mehreren Software-Werkzeugen<br />
effizient durchführen wollen. In der Mitte gibt es die<br />
Lücke zwischen beiden Seiten, da unklar ist, wie die Integration<br />
auf den Ebenen der (1 ) technischen Systeme und<br />
Funktionen, (2 ) der Datenmodelle und (3 ) der Beschreibung<br />
der Arbeitsabläufe systematisch zu adressieren ist.<br />
Im Bereich der Integration von Daten und Funktionen<br />
aus Software-Werkzeugen können generell mehrere Ansätze<br />
beobachtet werden:<br />
erstellerspezifische (proprietäre) Ansätze, um die<br />
Werkzeuge in der Suite eines H erstellers besser zu<br />
integrieren<br />
Behelfslösungen lokaler Experten, die Lücken zwischen<br />
Werkzeugen und Datenbeständen überbrücken,<br />
um spezifische Abläufe im <strong>Engineering</strong>-Projekt<br />
(teilweise) zu automatisieren<br />
erstellerneutrale Ansätze, um alle heterogenen<br />
Software-Werkzeuge und Datenmodelle in einem<br />
<strong>Engineering</strong>-Projekt zu integrieren als Basis <strong>für</strong> wiederkehrende<br />
Abläufe, Berichte und Evaluierungen<br />
Dieser Beitrag untersucht die Stärken und Beschränkungen<br />
dieser drei Ansätze in Bezug auf die zuvor identifizierten<br />
Bedarfe an Integration. Die Vision der Forschung des<br />
Christian-Doppler-Forschungslabors „ Software <strong>Engineering</strong><br />
Integration <strong>für</strong> flexible Automatisierungssysteme“<br />
(CDL-Flex), <strong>das</strong> von Logi.cals Automation Solutions & Services<br />
an der Technischen Universität Wien betrieben wird,<br />
ist ein Ansatz zur offenen Integration von Daten und Funktionen<br />
aus Software-Werkzeugen, um Abläufe in <strong>Engineering</strong>-Projekten<br />
systematisch zu automatisieren. Im Bereich<br />
herstellerneutraler Ansätze existiert keine offene Integrationsplattform<br />
zur Integration von Daten und Funktionen<br />
aus Software-Werkzeugen zur Unterstützung von Abläufen<br />
auf Projektebene.<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
29
HAUPTBEITRAG<br />
1. BEDARF AN INTEGRATION VON<br />
SOFTWARE-WERKZEUGEN<br />
Dieser Abschnitt diskutiert den Bedarf an besserer Integration<br />
zwischen Software-Werkzeugen und deren Datenmodellen<br />
in der industriellen Praxis. Die Anwendungsfälle<br />
wurden bei Industriepartnern aus dem Bereich<br />
Anlagenplanung und -bau (wie Wasserkraftwerke,<br />
Stahlwalzwerke, chemische Prozesse) erhoben.<br />
1.1 Änderungsmanagement im Anlagen-<strong>Engineering</strong><br />
Im verteilten und parallelen <strong>Engineering</strong> industrieller<br />
Anlagen wirken sich Planänderungen in einem Fachbereich<br />
oft auf Pläne in anderen Bereichen aus, die<br />
speziellen Software-Werkzeuge arbeiten aber nicht<br />
nahtlos zusammen. Etwa kann die Ä nderung des Typs<br />
eines Sensors es nötig machen, <strong>das</strong>s die Kabelführung<br />
im Elektroplan und die Skalierung im kontrollierenden<br />
Software-Programm angepasst werden müssen [ 1 ] . In<br />
der Anbindung von heterogenen Software-Werkzeugen<br />
an Abläufe in <strong>Engineering</strong>-Projekten bestehen technische<br />
und begriffliche Lücken, die durch Behelfsimplementierungen<br />
und informell organisierten Datenaustausch<br />
nur aufwendig und nicht ausreichend zuverlässig<br />
geschlossen werden.<br />
Tabelle 1 zeigt die Matrix der beschriebenen exemplarischen<br />
Anwendungsfälle und der daraus abgeleiteten<br />
Bedarfe (B1 bis B1 2 ) an die Integration heterogener Software-Werkzeuge.<br />
Für diesen Anwendungsfall lassen<br />
sich die folgenden Integrationsbedarfe ableiten: Das Erkennen<br />
und Verteilen von Planungsänderungen im<br />
Anlagen-<strong>Engineering</strong> soll effektiv, effizient und robust<br />
sein, um Fehler und Risiken in der Gesamtplanung zu<br />
minimieren (B1 , B2 , B7 ). Die Fachexperten sollen weiterhin<br />
die gewohnten Software-Werkzeuge verwenden<br />
können (B1 1 ). Auch vor Ort (etwa bei Inbetriebnahme<br />
der Anlage) vorgenommene Ä nderungen müssen erfasst<br />
werden können (B1 2 ).<br />
Ing. Prozess<br />
Ing. Elektrik<br />
Ing. Software<br />
Werkzeugdomäne X<br />
Anwender<br />
<strong>Engineering</strong><br />
Werkzeuge &Systeme<br />
R&ISchema<br />
Wkzg. Daten<br />
Elektroplan<br />
Wkzg. Daten<br />
Software-Entw.<br />
Umgebung<br />
Wkzg. Daten<br />
Werkzeugdomäne<br />
X<br />
Wkzg. Daten<br />
1<br />
?<br />
2<br />
3<br />
Prozesse &Anwendungen<br />
auf Projektebene<br />
Nach<br />
Meilenstein B<br />
Ja<br />
Ändern &<br />
Informieren<br />
Ticket<br />
ausstellen<br />
Start<br />
Entwurf<br />
Signale<br />
Genehmigt?<br />
Genehmigen<br />
Customer Rep. Kundenvertreter<br />
Ende<br />
Projekt- Project<br />
Manager Manager<br />
Nein Projekt<br />
Teilnehmer<br />
Ändern<br />
BILD 1: Unterstützung von Geschäftsprozessen in <strong>Engineering</strong>-<br />
Projekten durch heterogene Software-Werkzeuge.<br />
BILD 2: Effiziente Navigation zwischen<br />
<strong>Engineering</strong> Objekten.<br />
S1<br />
S2<br />
S3<br />
S4<br />
S5<br />
Sensor<br />
System<br />
Schnittstelle<br />
Software Software<br />
Schnittstelle „Verhalten“<br />
V_A<br />
V_B<br />
V_C<br />
V_D<br />
Verdrahtung Konfiguration Verwendung derDaten<br />
Ing. Elektrik Ing. Konfiguration Ing. Software<br />
BILD 3: Automatisierte Qualitätssicherung über<br />
Werkzeug- und Fachbereiche hinweg.<br />
BILD 4: Projektweite Auswertungen<br />
über Werkzeuggrenzen hinweg.<br />
BILD 5: Effiziente<br />
Qualitätssicherung<br />
der Beiträge externer<br />
Projektpartner.<br />
30<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
H<br />
1.2 Effiziente Navigation zwischen <strong>Engineering</strong>-Objekten<br />
Bei der Qualitätssicherung im <strong>Engineering</strong> und <strong>für</strong> die<br />
Inbetriebnahme einer Anlage müssen Fachexperten<br />
zwischen gemeinsamen <strong>Engineering</strong>-Objekten, etwa<br />
Signalen oder Geräten, in Plänen aus unterschiedlichen<br />
Bereichen navigieren, um die Plausibilität und<br />
Konsistenz abzusichern. Etwa: „ Zeige im Elektroplan<br />
die Stelle an, an der <strong>das</strong> zu dieser Variable gehörende<br />
Signal verwendet wird“ (siehe Bild 2 ). Die Software-<br />
Werkzeuge der Fachbereiche vernetzen die <strong>Engineering</strong>-Objekte<br />
nicht vollständig und effizient, so<strong>das</strong>s die<br />
Experten diese <strong>Engineering</strong>-Objekte in den Plänen<br />
unterschiedlicher Fachbereiche relativ aufwendig suchen<br />
müssen. Daraus lassen sich folgende Bedarfe ableiten:<br />
Die Vernetzung aller relevanten <strong>Engineering</strong>-<br />
Objekte mit ihren Repräsentationen in den im Projekt<br />
verwendeten Software-Werkzeugen soll vollständig,<br />
richtig und <strong>für</strong> die Navigation benutzerfreundlich verwendbar<br />
sein (B6 , B8 , B9 ).<br />
1.3 Automatisierte Qualitätssicherung<br />
eterogene Werkzeuglandschaften ermöglichen individuelle<br />
qualitätssichernde Maßnahmen in den jeweiligen<br />
(abgeschlossenen) Disziplinen, ohne jedoch Werkzeuge<br />
aus anderen Fachbereichen zu berücksichtigen. Übergreifende<br />
Maßnahmen (zum Beispiel Integrationstests) werden<br />
meist im Rahmen der Anlagenkommissionierung<br />
durchgeführt und sind kaum automatisiert (siehe Bild 3 :<br />
Automatisierter Test der durchgängigen Verbindung zwischen<br />
H ardware-Sensor und Software-Variable). Die manuelle<br />
Durchführung der Integrationstests erfordert einen<br />
hohen Aufwand durch Experten, die durch Automatisierung<br />
unterstützt werden sollen. Daraus lassen sich folgende<br />
Bedarfe ableiten: Erkennen von Fehlern, etwa fehlerhafte<br />
Pfade zwischen Sensoren/Aktoren und Software-<br />
Variablen, in Entwicklungsphasen und der Kommissionierung<br />
(B8 , B1 0 ), Ermöglichen und Verbessern von<br />
automatisierten Tests über Werkzeug- und Fachbereichsgrenzen<br />
(B5 , B7 ).<br />
B1 – Propagieren von Änderungen<br />
zwischen Werkzeugen<br />
B2 – Versioniertes Abspeichern<br />
von Werkzeugdaten<br />
B3 – Auswertungsmöglichkeiten<br />
zu durchgeführten Änderungen<br />
B4 – Abbildung von Projektverantwortlichkeiten<br />
und Stati<br />
verteilter <strong>Engineering</strong> Teams<br />
B5 – Durchgängige Sichtbarkeit<br />
<strong>für</strong> Projektmanagement<br />
B6 – Projektweit gemeinsame<br />
Konzepte trotz unterschiedlicher<br />
Repräsentation in Werkzeugen<br />
Änderungs<br />
management<br />
im Anlagen-<br />
<strong>Engineering</strong><br />
Effiziente<br />
Navigation<br />
zwischen<br />
<strong>Engineering</strong>-<br />
Objekten<br />
Automatisierte<br />
Qualitätssicherung<br />
über<br />
Werkzeugund<br />
Domänengrenzen<br />
Projektweite<br />
Auswertungen<br />
über<br />
Werkzeuggrenzen<br />
hinweg<br />
Effiziente<br />
Qualitätssicherung<br />
der<br />
Beiträge externer<br />
Projektpartner<br />
B7 – Notifikation relevanter Rollen<br />
B8 – Identifizierung korrespondierender<br />
Daten elemente in unterschiedlichen<br />
Werkzeugen<br />
B9 – Ansteuerung von Werkzeugen<br />
entsprechend der Navigationsanforderung<br />
B10 – Einschränkungen und Regeln<br />
<strong>für</strong> gemeinsame Konzepte über<br />
mehrere Sichten hinweg<br />
B11 – Fachexperten sollen gewohnte<br />
Werkzeuge verwenden können<br />
B12 – Erfassung von vor Ort vorgenommenen<br />
Änderungen<br />
TABELLE 1: Exemplarische Anwendungsfälle und abgeleitete Bedarfe.<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
31
Ä<br />
H<br />
H<br />
HAUPTBEITRAG<br />
1.4 Projektweite Auswertungen<br />
Im Anlagen-<strong>Engineering</strong> werden die Planungsdaten verteilter<br />
Bereiche parallel entwickelt, oft ohne Überblick zum<br />
aktuellen und realen Projektfortschritt (siehe auch Bild 4 :<br />
Gewerkspezifische Projektstatusinformationen bis auf Signalebene<br />
herab [ 2 ] ). Projektmanager und Gruppenleiter sehen<br />
den realen Fortschritt und etwaige Risiken typischerweise<br />
erst spät, etwa kurz vor Projektmeilensteinen. Insbesondere<br />
Planungsänderungen, die spät im Projekt erforderlich<br />
werden, sind oft nur unzureichend sichtbar und <strong>für</strong><br />
Verbesserungen analysierbar. Daraus lassen sich folgende<br />
Bedarfe ableiten: Projektmanager benötigen auch zwischen<br />
Projektmeilensteinen einen Überblick zum Projektfortschritt<br />
auf Basis von aktuellen und systematisch <strong>integrierte</strong>n<br />
Daten (B3 , B5 ). Die Daten aus allen relevanten Software-<br />
Werkzeugen und Systemen müssen erfasst werden (B6 ). Die<br />
Erfassung des Status von <strong>Engineering</strong>-Objekten muss effizient<br />
möglich sein (B4 ).<br />
1.5 Beiträge externer Projektpartner<br />
In Anlagen-<strong>Engineering</strong>-Projekten gibt es externe Projektpartner<br />
wie Kunden oder Berater, die außerhalb der<br />
<strong>Engineering</strong>-Umgebung des Projekts immer wieder Ä n-<br />
derungen an Planungsdaten durchführen. Das Einpflegen<br />
externer Ä nderungen in die Projektdatenhaltung ist<br />
aufwendig und anfällig <strong>für</strong> Fehler (siehe Bild 5 : Externe<br />
Bearbeitung von Signaldaten in Microsoft Excel), da die<br />
momentan vorhandenen Software-Werkzeuge im Anlagen-<strong>Engineering</strong><br />
diesen Vorgang oft nur wenig beziehungsweise<br />
nur teilweise unterstützen. Durch die lange<br />
Dauer des Analysierens und Einpflegens externer Ä nderungen<br />
verändert sich oftmals inzwischen die Datenbasis<br />
des Projekts und erhöht weiter Aufwand und Risiken.<br />
Daraus lassen sich folgende Bedarfe ableiten: Das Erkennen<br />
der Ä nderungen externer Projektpartner muss extern<br />
möglich sein, so<strong>das</strong>s nur gewollte Ä nderungen ins<br />
Projekt Eingang finden (B1 0 , B1 1 ). Konflikte zwischen<br />
nderungen externer Projektpartner und zwischenzeitlichen<br />
Ä nderungen der Projektdatenbasis müssen effizient<br />
erkannt und den relevanten Personen <strong>für</strong> die benutzerfreundliche<br />
Auflösung zugeordnet werden (B4 , B1 2 ).<br />
2. A B DECKUNG DER BEDARFE DURCH<br />
INTEGRATIONSANSÄTZE<br />
Wie bereits erwähnt, können im Bereich der Integration<br />
von Software-Werkzeugen generell die folgenden Ansätze<br />
beobachtet werden:<br />
erstellerspezifische (proprietäre) Ansätze, um die<br />
Werkzeuge in der Suite eines H erstellers besser zu<br />
integrieren [ 3 ]<br />
Behelfslösungen lokaler Experten, die Lücken in der<br />
Anbindung von Werkzeugfunktionen und Datenbeständen<br />
zu Abläufen im <strong>Engineering</strong>-Projekt überbrücken,<br />
um diese Abläufe (teilweise) zu automatisieren<br />
erstellerneutrale Ansätze, um alle heterogenen<br />
Software-Werkzeuge [ 4 ] und Datenmodelle in einem<br />
<strong>Engineering</strong>-Projekt zu integrieren [ 5 -7 ] als Basis <strong>für</strong><br />
wiederkehrende Abläufe, Berichte und Evaluierungen<br />
in einem <strong>Engineering</strong>-Projekt [ 1 , 8 ] .<br />
Im Bereich der herstellerspezifischen Ansätze geht der<br />
Trend in Richtung einer vereinheitlichten Bedienoberfläche<br />
und einer gemeinsamen einheitlichen Datenbasis<br />
über alle Software-Werkzeuge in einer definierten Werkzeug-Suite<br />
hinweg, um dem Maschinen- und Anlagenbauer<br />
<strong>das</strong> Leben zu erleichtern. Beispiele <strong>für</strong> diese Ansätze<br />
sind <strong>das</strong> Siemens TIA (Totally-Integrated-Automation)<br />
Portal, EPlan-<strong>Engineering</strong>-Center (EEC), Comos von<br />
Siemens; zu erwähnen sind auch <strong>das</strong> B&R Automation<br />
Studio, die Multiprog-Suite von KW Software oder die<br />
CoDeSys-Suite von 3 S. Klarer Vorteil dieses Ansatzes ist<br />
die erwünschte nahtlose Integration der ausgewählten<br />
Werkzeuge auf den Ebenen der Daten und der Werkzeugfunktionen.<br />
Dieser Vorteil wird allerdings durch die<br />
Einschränkung der verfügbaren Werkzeuge und die weiterhin<br />
holprige Integration von Werkzeugen und Daten<br />
außerhalb der Werkzeug-Suite erkauft. Allerdings haben<br />
die H ersteller derartiger Werkzeug-Suiten typischerweise<br />
beträchtlichen Aufwand in die Konzipierung des verwendeten<br />
Datenmodells beziehungsweise in Entwurf<br />
und Umsetzung der Integrationsplattform investiert.<br />
Einen nicht zu unterschätzenden Anteil an den in der<br />
Praxis verwendeten Ansätzen stellen Behelfslösungen lokaler<br />
Experten dar, die zum Beispiel mithilfe von gemeinsamen<br />
Datenbanken oder skriptbasierten Daten- und Funktionstransformationsmechanismen<br />
Integrationsprobleme<br />
adressieren. Im Bereich des Datenaustausches, zum Beispiel<br />
via E-Mail, hat sich auch <strong>das</strong> Verwenden von Excel-Arbeitsmappen<br />
etabliert, da Microsoft Excel so gut wie überall<br />
verfügbar und auch vergleichsweise einfach bedienbar ist,<br />
allerdings Ä nderungen auch fehleranfällig und nicht lückenlos<br />
nachvollziehbar sind. Im Bereich der herstellerneutralen<br />
Ansätze unterscheidet man Ansätze zur Vereinheitlichung<br />
beziehungsweise Integration der Datenaustauschformate<br />
sowie Ansätze zur funktionalen Integration von<br />
Software-Werkzeugen. Bekannte Vertreter der ersten Gruppe<br />
sind etwa die AutomationML-Initative, die PlantX ML-<br />
Initiative oder die NEfl1 0 0 . AutomationML [ 9 ] ist ein neutrales,<br />
X ML-basiertes Datenformat <strong>für</strong> die Speicherung und<br />
zum Austausch von Anlagenplanungsdaten, <strong>das</strong> als offener<br />
Standard zur Verfügung steht. Ziel der AutomationML ist<br />
der Austausch von <strong>Engineering</strong>-Daten in einer heterogenen<br />
Werkzeuglandschaft <strong>für</strong> verschiedene Disziplinen, wie zum<br />
Beispiel mechanisches Design, elektrisches Design, oder<br />
SPS-Programmierung. PlantX ML [ 1 0 ] von Evonik Degussa<br />
ist ebenfalls ein neutrales, X ML-basiertes Datenformat <strong>für</strong><br />
die Datenkonsolidierung im Bereich der Prozess- und Verfahrenstechnik.<br />
Die Verwendung von X ML als Basis der<br />
Modellierung erlaubt es, die vorhandenen Schnittstellen<br />
auch bei Ä nderungen einzelner Datenmodelle weiter zu<br />
verwenden. PlantX ML stellt daher eine gute Basis <strong>für</strong> die<br />
Datenkonsolidierung dar, hat jedoch seine Grenzen bei der<br />
externen Kommunikation, da die verwendeten Modelle typischerweise<br />
nur firmeninterne Gültigkeit besitzen.<br />
Ein Weg zur Bereitstellung dieser Kommunikationsmöglichkeit<br />
ist die ISOfl1 5 9 2 6 [ 1 1 ] , welche den Anspruch stellt,<br />
den Informationsaustausch zwischen allen Beteiligten<br />
(Planer, Kontraktor, Lieferant, Betreiber, Standortbetreiber)<br />
in allen Phasen einer prozess- oder verfahrenstechnischen<br />
Anlage zu ermöglichen. Durch diesen Anspruch ist die<br />
ISOfl1 5 9 2 6 eine Chance zur standardisierten Kommunikation<br />
<strong>für</strong> die Prozessindustrie, jedoch ist diese Norm komplex<br />
und aufwendig in der H andhabung und einzelne<br />
Teile sind auch noch in der Entwicklung beziehungsweise<br />
im Reifungsprozess. Die Merkmalleisten der NEfl1 0 0 [ 1 2 ]<br />
versetzen Anwender und H ersteller von Prozessleittechnik<br />
32<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
B1 – Propagieren von<br />
Änderungen zwischen<br />
Werkzeugen<br />
B2 – Versioniertes<br />
Abspeichern von Werkzeugdaten<br />
B3 – Auswertungsmöglichkeiten<br />
zu durchgeführten<br />
Änderungen<br />
B4 – Abbildung von<br />
Projektverantwortlichkeiten<br />
und Stati verteilter<br />
<strong>Engineering</strong> Teams<br />
B5 – Durchgängige<br />
Sichtbarkeit <strong>für</strong><br />
Projekt management<br />
B6 – Projektweit gemeinsame<br />
Konzepte trotz<br />
unterschiedlicher<br />
Repräsentation in Werkzeugen<br />
B7 - Notifikation<br />
relevanter Rollen<br />
B8 – Identifizierung<br />
korrespondierender<br />
Daten elemente in unterschiedlichen<br />
Werkzeugen<br />
B9 – Ansteuerung von<br />
Werkzeugen entsprechend<br />
der Navigationsanforderung<br />
B10 – Einschränkungen und<br />
Regeln <strong>für</strong> gemein same<br />
Konzepte über mehrere<br />
Sichten hinweg<br />
B11 – Fachexperten sollen<br />
gewohnte Werkzeuge<br />
verwenden können<br />
B12 – Erfassung von<br />
vor Ort vorgenommenen<br />
Änderungen<br />
herstellerspezifische<br />
Ansätze<br />
Nur <strong>für</strong> Werkzeuge der Werkzeug-<br />
Suite möglich (dadurch Einschränkung<br />
auf vom Hersteller vorgegebene<br />
Werkzeuge)<br />
Nur bei Unterstützung durch<br />
Werkzeug-Suite möglich<br />
(Werkzeug-Suite externe<br />
Versionierung wird aufgrund<br />
geschlossener Daten formate<br />
nur selten unterstützt.)<br />
Nur <strong>für</strong> in der Werkzeuge-Suite<br />
enthaltene Werkzeuge möglich<br />
Nur bei Unterstützung durch<br />
Werkzeug-Suite möglich<br />
(oder falls direkter Zugriff auf<br />
Daten, zum Beispiel über eine API,<br />
ermöglicht wird)<br />
Nur <strong>für</strong> in der Werkzeuge-Suite<br />
enthaltene Werkzeuge möglich<br />
Nur bei Unterstützung durch<br />
Werkzeug-Suite möglich<br />
(Das zu verwendende Datenmodell<br />
ist aber vom Hersteller<br />
fix vorgegeben.)<br />
Nur bei Unterstützung durch<br />
Werkzeug-Suite möglich<br />
Nur <strong>für</strong> Werkzeuge der Werkzeug-<br />
Suite möglich (dadurch Einschränkung<br />
auf vom Hersteller<br />
vorgegebene Werkzeuge)<br />
Nur bei Unterstützung durch<br />
Werkzeug-Suite möglich oder<br />
falls direkter Zugriff auf Daten,<br />
zum Beispiel über eine API,<br />
ermöglicht wird.<br />
Nur bei Unterstützung durch<br />
Werkzeug-Suite und nur <strong>für</strong><br />
Werkzeuge der Werkzeug-Suite<br />
möglich<br />
Einschränkung auf vom Hersteller<br />
vorgegebene Werkzeuge<br />
Nur bei Unterstützung durch<br />
Werkzeug-Suite möglich (Das zu<br />
verwendende Daten modell ist aber<br />
vom Hersteller fix vorgegeben.)<br />
Behelfslösungen<br />
lokaler Experten<br />
Nur <strong>für</strong> ursprüngliche berücksichtigte<br />
Anwendungsfälle<br />
möglich (etwaige Änderungen<br />
müssen aufwendig durchgeführt<br />
werden, dadurch erhöhte<br />
Fehleranfälligkeit)<br />
Möglich, aber meistens sehr<br />
aufwendig<br />
(Bei Änderungen der Behelfslösungen<br />
ist hoher Aufwand<br />
nötig, um vorhandene Daten<br />
zu aktualisieren.)<br />
Möglich, aber meistens nicht<br />
vorhanden. da hoher Zusatzaufwand<br />
<strong>für</strong> Implementierung<br />
nötig ist.<br />
Möglich, aber meistens nicht<br />
vorhanden, da hoher Zusatzaufwand<br />
<strong>für</strong> Implementierung<br />
nötig ist.<br />
Möglich, aber meistens nicht<br />
vorhanden. da hoher Zusatzaufwand<br />
<strong>für</strong> Implementierung<br />
nötig ist.<br />
Typischerweise direkte Transformation<br />
zwischen einzelnen<br />
verwendeten Werkzeugen<br />
(kein oder sehr einfaches<br />
gemein sames Datenmodell)<br />
Möglich, aber meistens<br />
sehr aufwändig<br />
(fehleranfällig bei Änderungen<br />
der Behelfslösungen)<br />
Möglich, aber meistens sehr<br />
aufwendig<br />
(fehleranfällig bei Änderungen<br />
der Behelfslösungen)<br />
Meistens reine<br />
Datenintegrations lösungen<br />
(keine Funktionsintegration)<br />
Nur manuell möglich<br />
(Meistens wird direkte Transformation<br />
verwendet, und<br />
daher sind keine projektweiten<br />
Konzepte definiert.)<br />
Nur <strong>für</strong> ursprünglich berücksichtigte<br />
Anwendungsfälle<br />
möglich (Etwaige Änderungen<br />
müssen aufwendig durchgeführt<br />
werden, dadurch erhöhte<br />
Fehleranfälligkeit.)<br />
Möglich, aber meistens sehr<br />
aufwendig<br />
(fehleranfällig bei Änderungen<br />
der Behelfslösungen)<br />
herstellerneutrale<br />
Ansätze<br />
Verwendete Werkzeuge können<br />
frei gewählt werden (erhöhter<br />
Grundaufwand <strong>für</strong> Einbindung<br />
der Werkzeuge; zusätzlich<br />
limitiert durch Offenheit der<br />
verwendeten Werkzeuge)<br />
Datenaustauschformate<br />
können unabhängig von einer<br />
möglichen Unterstützung der<br />
Werkzeuge versioniert<br />
abgespeichert werden.<br />
Für beliebige Werkzeuge<br />
verfügbar, oft aber hoher<br />
Aufwand nötig, um von<br />
Werkzeug-Suites bekannte<br />
Möglichkeiten zu bieten.<br />
Zusatzinformation kann<br />
abgebildet werden und<br />
ist dann, zum Beispiel in<br />
Abfragen, verwendbar<br />
Für beliebige Werkzeuge<br />
verfügbar, oft aber hoher<br />
Aufwand nötig, um von<br />
Werkzeug-Suites bekannte<br />
Möglichkeiten zu bieten.<br />
Das verwendete Datenmodell<br />
kann beliebig (zum Beispiel<br />
abhängig vom Anwendungsfall)<br />
definiert werden.<br />
Notifikation kann einfach und<br />
individuell konfiguriert werden.<br />
Verwendete Werkzeuge<br />
können frei gewählt werden.<br />
Bei Unterstützung des verwendeten<br />
Werkzeugs möglich<br />
Verwendete Werkzeuge<br />
können frei gewählt werden<br />
(Verwendetes Datenmodell<br />
kann beliebig definiert<br />
werden.)<br />
Verwendete Werkzeuge<br />
können frei gewählt werden.<br />
Verwendete Werkzeuge können<br />
frei gewählt werden (Verwendetes<br />
Datenmodell kann<br />
beliebig definiert werden.)<br />
TABELLE 2: Generelle Integra tionsansätze und adressierte<br />
Bedarfe <strong>für</strong> Integrationsmechanismen von Werkzeugen.<br />
= Bedarf wird nicht oder nur gering abgedeckt<br />
= Bedarf wird teilweise bzw. unter bestimmten<br />
einschränkenden Annahmen abgedeckt<br />
= Bedarf wird gut abgedeckt<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
33
H<br />
HAUPTBEITRAG<br />
Projektmanager<br />
<strong>Engineering</strong><br />
Cockpit<br />
Ing. Prozess<br />
Ing. Elektrik<br />
R&ISchema<br />
Wkzg. Daten<br />
Elektroplan<br />
Wkzg. Daten<br />
C<br />
C<br />
Konzepte auf<br />
Projektebene<br />
Automation<br />
Service Bus<br />
C<br />
Laufzeitdatenquellen<br />
Wkzg. Daten<br />
C<br />
<strong>Engineering</strong><br />
Object Editor<br />
Wkzg. Daten<br />
Software-Entw.<br />
Umgebung<br />
Wkzg. Daten<br />
Ing. Kommissionierung<br />
Kundenvertreter<br />
Ing. Software<br />
BILD 6: Der Automation<br />
Service Bus als<br />
herstellerneutrale Brücke<br />
zwischen heterogenen<br />
Software-Werk zeugen und<br />
Basis <strong>für</strong> die Automatisierung<br />
von <strong>Engineering</strong>-Prozessen.<br />
(Geräten aus dem Bereich Elektro-, Automatisierungstechnik<br />
und Mess-, Steuerungs- und Regelungstechnik) in die<br />
Lage, nicht nur den Datenaustausch innerhalb sondern<br />
auch zwischen Unternehmen zu optimieren.<br />
Der in einem Folgebeitrag vorgestellte Automation-<br />
Service-Bus (ASB) ist ebenfalls ein herstellerneutraler<br />
Ansatz [ 4 , 8 ] und bietet Methoden und Techniken sowohl<br />
<strong>für</strong> Datenintegration als auch <strong>für</strong> funktionale Integration<br />
von Software-Werkzeugen an. Der ASB ist eine Weiterentwicklung<br />
des in der Business IT erfolgreichen Enterprise<br />
Service Bus (ESB) [ 1 3 ] <strong>für</strong> den <strong>Engineering</strong>-Bereich.<br />
In der Business IT hat der ESB in weiten Teilen die technische<br />
Integration von Systemen übernommen, die auf<br />
unterschiedlichen Plattformen laufen, da die Komplexität<br />
durch Behelfslösungen nicht mehr nachhaltig beherrschbar<br />
war. Ein ähnlicher Anstieg der Komplexität<br />
in der IT in <strong>Engineering</strong>-Unternehmen ist absehbar und<br />
kann mit dem ASB adressiert werden. Tabelle 2 veranschaulicht<br />
die Stärken und Beschränkungen dieser drei<br />
generellen Ansätze in Bezug auf die zuvor identifizierten<br />
Bedarfe an Integrationsmechanismen. Dem Vergleich in<br />
Tabelle 2 ist vorauszuschicken, <strong>das</strong>s auch in allen Umfeldern,<br />
die gut <strong>integrierte</strong> Werkzeug-Suiten verwenden,<br />
in den <strong>Engineering</strong>-Projekten weitere Werkzeuge eingesetzt<br />
werden, die nicht direkt in die Werkzeug-Suite integriert<br />
sind. Daher sind alle bisher von uns beobachteten<br />
<strong>Engineering</strong>-Umgebungen als mehr oder weniger<br />
heterogen einzuschätzen.<br />
ZUSAMMENFASSUNG UND AUSBLICK<br />
In <strong>Engineering</strong>-Projekten <strong>für</strong> den industriellen Anlagenbau<br />
sind mehrere Software-Werkzeuge im Einsatz, die<br />
Fachexperten helfen, ihre Aufgaben gut zu erledigen, aber<br />
nicht nahtlos mit Abläufen im <strong>Engineering</strong>-Team auf Projektebene<br />
zusammenarbeiten. Gute Integration von Daten<br />
und Funktionen verringert <strong>das</strong> Risiko, wichtige Ä nderungen<br />
nicht ausreichend zu adressieren und reduziert<br />
auch die Kosten <strong>für</strong> Ä nderungsmanagement und Qualitätssicherung<br />
im Projektteam, da sich derartige Arbeitsabläufe<br />
in wesentlichen Teilen effizienter gestalten lassen.<br />
erstellerspezifische Werkzeug-Suiten können zwar den<br />
Großteil der vorgestellten Anwendungsfälle abdecken, allerdings<br />
ist die Auswahlmöglichkeit der verwendbaren<br />
Werkzeuge extrem eingeschränkt beziehungsweise ein zu<br />
verwendendes Datenmodell fix vorgeben. Im Gegensatz<br />
dazu ermöglichen Behelfslösungen lokaler Fachexperten<br />
zwar auf proprietäre Art und Weise die Datenintegration<br />
zwischen Werkzeugen, sind allerdings oftmals fragil und<br />
fehleranfällig im H inblick auf Ä nderungen. H erstellerneutrale<br />
Ansätze schränken die Auswahl der verwendbaren<br />
REFERENZEN<br />
[1] Waltersdorfer, F., Moser, T. Zoitl, A. et al.: Version<br />
Management and Conflict Detection Across Heterogeneous<br />
<strong>Engineering</strong> Data Model. In: 8th IEEE International<br />
Conference on Industrial Informatics (INDIN 2010),<br />
S. 928 - 935, IEEE, 2010,<br />
[2] T. Moser, R. Mordinyi, D. Winkler et al., “<strong>Engineering</strong> Project<br />
Management Using The <strong>Engineering</strong> Cockpit,” in IEEE 9th<br />
International Conference on. Industrial Informatics<br />
(INDIN'2011), Caparica, Lisbon, Portugal, 2011, pp. 579 - 584.<br />
[3] H appacher, M.: Benchmark <strong>für</strong> <strong>das</strong> <strong>Engineering</strong>!<br />
(Editorial), computer & automation 11, S. 3, 2011.<br />
[4] Biffl, S.; Schatten, A.: A Platform for Service-Oriented<br />
Integration of Software <strong>Engineering</strong> Environments.In:<br />
8th Conference on New Trends in Software Methodologies,<br />
Tools and Techniques (SoMeT 09), S. 75 - 92, 2009.<br />
[5] Drath, R.; Fay, A.: Erfahrungen bei der Nutzung einer neutralen<br />
XML-Beschreibungsform verfahrenstechnischer Anlagen <strong>für</strong><br />
den Datenaustausch zwischen dem Process <strong>Engineering</strong> und<br />
dem Control System <strong>Engineering</strong>. In GMA-Fachtagung<br />
„<strong>Engineering</strong> in der Prozessindustrie", S. 145-155, 2002.<br />
[6] Drath, R.; Fedai, M.: CAEX – ein neutrales Datenaustauschformat<br />
<strong>für</strong> Anlagendaten. Teil 1. <strong>atp</strong> – Automatisierungstechnische<br />
Praxis 46(2), S. 52-56, 2004.<br />
[7] Mayr, G.; Drath, R.: IEC PAS 62424 – Grafische Darstellung<br />
PLT-Aufgaben und Datenaustausch zu <strong>Engineering</strong>-Systemen,<br />
<strong>atp</strong> – Automatisierungstechnische Praxis 49(5), S. 22-29, 2007.<br />
[8] Biffl, S.; Schatten, A.; Zoitl, A.: Integration of Heterogeneous<br />
<strong>Engineering</strong> Environments for the Automation Systems<br />
Life cycle. In: 7th IEEE International Conference on Industrial<br />
Informatics (INDIN 2009), S. 576 - 581, 2009.<br />
34<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
Werkzeuge und zu verwendenden Datenmodelle in keiner<br />
Weise ein und stellen dadurch den aus Fachexpertensicht<br />
nützlichsten Ansatz dar; allerdings erfordern diese Ansätze<br />
oft einen erhöhten Grundaufwand <strong>für</strong> die Einbindung der<br />
Werkzeuge, da es keine offene Integrationsplattform zur Integration<br />
von Daten und Funktionen aus Software-Werkzeugen<br />
zur Unterstützung von Abläufen auf Projektebene gibt.<br />
Aus der Evaluierung ergibt sich Entwicklungsbedarf,<br />
um <strong>für</strong> die Praxis eine ausreichende Unterstützung von<br />
typischen Anwendungsfällen in der Projektpraxis auch in<br />
einer heterogenen Software-Landschaft zu ermöglichen.<br />
Die Integration von Daten und Funktionen aus Software-<br />
Werkzeugen <strong>für</strong> Arbeitsabläufe auf Projektebene wird in<br />
Forschung und Praxis zunehmend adressiert. Allerdings<br />
ist der detaillierte systematische Vergleich schwierig, da<br />
die relevanten Informationen nicht leicht verfügbar sind.<br />
In diesem Bereich wäre die Definition von Benchmarks<br />
sinnvoll, die einen objektiven Vergleich ermöglichen.<br />
Der zweite Teil des Beitrags stellt einen neuen herstellerneutralen<br />
Ansatz zur Integration von Software-Werkzeugen<br />
vor, den Automation Service Bus (ASB), Basierend<br />
auf dem in der Wirtschaftsinformatik erfolgreichen<br />
Ansatz des Enterprise Service Bus [ 4 ] wurden da<strong>für</strong> die<br />
<strong>für</strong> <strong>das</strong> <strong>Engineering</strong>-Umfeld erforderlichen Verbesserungen<br />
vorgenommen, um <strong>das</strong> „ <strong>Engineering</strong> Polynesien“<br />
systematisch zu integrieren (siehe Bild 6 ). Das „ <strong>Engineering</strong><br />
Babylon” wird dadurch adressiert, <strong>das</strong>s genau die,<br />
von den Fachexperten <strong>für</strong> die Kooperation benutzten,<br />
gemeinsamen Konzepte modelliert, auf die lokalen Repräsentationen<br />
der Software-Werkzeuge abgebildet und<br />
so <strong>für</strong> Maschinen verständlich gemacht werden.<br />
Der ASB hat <strong>das</strong> Potenzial, wesentliche Lücken bisheriger<br />
herstellerneutraler Ansätze zu schließen, um Vorteile,<br />
die bisher nur mit herstellerspezifischer Integration erreicht<br />
werden konnten, auch <strong>für</strong> die Integration heterogener<br />
Werkzeuge zu ermöglichen. Durch die Integration von Daten<br />
und Funktionen werden neue Funktionen auf Projektebene<br />
ermöglicht, etwa die Navigation zwischen Sichten<br />
auf ein mechatronisches Objekt in den unterschiedlichen<br />
Werkzeugen; oder Datenauswertungen auf Projektebene<br />
über heterogene Datenmodelle in den Werkzeugen hinweg.<br />
MANUSKRIPTEINGANG<br />
10.02.2012<br />
Im Peer-Review-Verfahren begutachtet<br />
[9] Drath, R.: Datenaustausch in der Anlagenplanung<br />
mit AutomationML: Integration von CAEX, PLCopen<br />
XML und COLLADA S. 326, Springer-Verlag Berlin<br />
Heidelberg, 2010.<br />
[10] Anhäuser, F. ; Richert, H.; Temmen, H.: Degussa PlantXML<br />
– Integrierter Planungsprozess mit flexiblen Bausteinen,<br />
<strong>atp</strong> - Automatisierungstechnische Praxis 46(10), 2004.<br />
[11] ISO 15926: Industrial automation systems and integration<br />
- Integration of life-cycle data for process plants including<br />
oil and gas production facilities, Part 1: Overview and<br />
fundamental principles, 2004.<br />
[12] NE 100: Nutzung von Merkmalleisten im PLT-<strong>Engineering</strong>-<br />
Workflow, Namur, 2010.<br />
[13] Chappell, D.: Enterprise Service Bus - Theory in Practice.<br />
O’Reilly Media, 2004.<br />
AUTOREN<br />
Ao. Univ.Prof. DI Mag.<br />
Dr.techn. STEFAN BIFFL<br />
(geb. 1 9 6 7 ) ist Leiter des<br />
Christian Doppler Forschungslabors<br />
„ Software<br />
<strong>Engineering</strong> Integration <strong>für</strong><br />
flexible Automatisierungssysteme“<br />
(CDL-Flex) an der<br />
Fakultät <strong>für</strong> Informatik der<br />
Technischen Universität Wien. Seine Forschungsinteressen<br />
liegen im Bereich der<br />
Produkt- und Prozessverbesserung <strong>für</strong> Software-intensive<br />
Systeme sowie der empirischen<br />
Evaluierung im industriellen Umfeld.<br />
Technische Universität Wien,<br />
Favoritenstr. 9-11/188, A-1040 Wien,<br />
Tel. +43 1 58 80 11 88 10,<br />
E-Mail: stefan.biffl@tuwien.ac.at<br />
DI Mag. Dr.techn. RICHARD<br />
MORDINYI (geb. 1 9 7 9 ) ist<br />
Postdoc im Christian<br />
Doppler Forschungslabor<br />
„ Software <strong>Engineering</strong><br />
Integration <strong>für</strong> flexible<br />
Automatisierungssysteme"<br />
(CDL-Flex) an der Fakultät<br />
<strong>für</strong> Informatik der Technischen<br />
Universität Wien. Seine Forschungsinteressen<br />
liegen im Bereich der Modell-getriebenen<br />
Konfiguration von Integrationsplattformen,<br />
Agilen Software-Architekturen und<br />
sicheren Koordinationsstrategien in komplexen<br />
verteilten Systemen.<br />
Technische Universität Wien,<br />
Favoritenstr. 9-11/188, A-1040 Wien,<br />
Tel. +43 1 588 01 18 80 51,<br />
E-Mail: richard.mordinyi@tuwien.ac.at<br />
Mag. Dr.rer.soc.oec.<br />
THOMAS MOSER (geb. 1 9 8 1 )<br />
ist Postdoc im Christian<br />
Doppler Forschungslabor<br />
„ Software <strong>Engineering</strong><br />
Integration <strong>für</strong> flexible<br />
Automatisierungssysteme“<br />
(CDL-Flex) an der Fakultät<br />
<strong>für</strong> Informatik der Technischen<br />
Universität Wien. Seine Forschungsinteressen<br />
liegen im Bereich der Datenmodellierung<br />
und Datenintegration <strong>für</strong> Software-intensive<br />
Systeme sowie im Bereich Semantic Web.<br />
Institut <strong>für</strong> Softwaretechnik und interaktive Systeme,<br />
Technische Universität Wien,<br />
Favoritenstr. 9-11/188, A-1040 Wien,<br />
Tel. +43 1 588 01 18 80 51,<br />
E-Mail: thomas.moser@tuwien.ac.at<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
35
HAUPTBEITRAG<br />
Datenkonsistenz mit<br />
AutomationML herstellen<br />
Konzept <strong>für</strong> heterogene <strong>Engineering</strong>-Werkzeug-Landschaften<br />
Dieser Beitrag stellt ein neuartiges Konzept vor, in einer heterogenen Landschaft von<br />
<strong>Engineering</strong>-Werkzeugen Konsistenz zwischen Planungsdaten herzustellen, ohne die betreffenden<br />
<strong>Engineering</strong>-Werkzeuge tief miteinander zu integrieren. Dazu wird eine vermittelnde<br />
Kollaborationssoftware eingeführt. Diese muss keine Kenntnis von den beteiligten<br />
Werkzeugen besitzen, sondern stellt, basierend auf einem neutralen Datenaustauschformat,<br />
generische Kollaborationsfunktionen zur Verfügung.<br />
SCHLAGWÖRTER Datenkonsistenz / AutomationML / <strong>Engineering</strong> / heterogene Werkzeuglandschaft<br />
Achieving data consistency with AutomationML –<br />
A concept for heterogeneous engineering tools<br />
This contribution proposes a novel concept to achieve data consistency across engineering<br />
tools in a heterogeneous tool landscape without the need for deep tool integration. We<br />
propose introducing a middleware solution which provides generic collaboration functionality<br />
on top of a neutral intermediate file.<br />
KEYWORDS data consistency / AutomationML / engineering / heterogeneous tool<br />
landscape<br />
36<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
RAINER DRATH, MARIO HOERNICKE, BEN SCHRÖTER, ABB Forschungszentrum<br />
Die Planung fertigungs- und verfahrenstechnischer<br />
Anlagen erfordert ein orchestrier -<br />
tes Zusammenarbeiten von Ingenieuren unterschiedlicher<br />
Disziplinen mit ihren individuellen<br />
<strong>Engineering</strong>-Werkzeugen. Selbst in<br />
kleinen Anlagen werden dabei einzelne domänenspezifische<br />
Teilbereiche zerlegt, wie zum Beispiel die Elektroplanung,<br />
Schaltschrankplanung sowie die Programmierung<br />
von SPSen, Antrieben, Sicherheitssteuerungen<br />
und Robotern.<br />
Das <strong>Engineering</strong> innerhalb dieser Gewerke erfolgt in<br />
der Praxis – wie in Bild 1 als Netzwerk von Aktivitäten<br />
dargestellt – parallel und verzahnt. Dabei werden eine<br />
Vielzahl effizienter und leistungsfähiger <strong>Engineering</strong>-<br />
Werkzeuge eingesetzt [ 1 ] , [ 2 ] . J e nach Art und Umfang<br />
der Projekte sind Abteilungen, Firmen, Dienstleister<br />
und Zulieferer aus unterschiedlichen Regionen, Ländern,<br />
Kontinenten und Kulturkreisen beteiligt: Es handelt<br />
sich dabei um eine heterogene Werkzeuglandschaft<br />
in Kombination mit einem räumlich und zeitlich verteilten<br />
Personenkreis. Dies gilt <strong>für</strong> fertigungstechnische<br />
und prozesstechnische Anlagen [ 3 ] . Welche Antworten<br />
geben Werkzeughersteller, um diese H erausforderungen<br />
zu bewältigen?<br />
J eder SPS-, Roboter- oder Antriebshersteller liefert <strong>für</strong><br />
<strong>das</strong> <strong>Engineering</strong> seiner Geräte ein eigenes individuelles<br />
Konfigurationswerkzeug. Die Konfiguration der Geräte<br />
erfolgt in der Regel ohne eine übergeordnete Koordinations-<br />
oder Kooperationssoftware. Nach Fertigstellung<br />
der Programmier- und Konfigurationsarbeit wird <strong>das</strong><br />
Zusammenspiel der unterschiedlichen Komponenten bei<br />
der Inbetriebnahme systemweit getestet. Die Anlage<br />
funktioniert aber nur im Idealfall auf Anhieb. In der<br />
Praxis verzögert sich häufig die Fertigstellung, weil Fehler<br />
aus der vorausgegangenen Planung auftreten: Vereinbarungen<br />
wurden nicht von allen Beteiligten korrekt<br />
verstanden beziehungsweise konsequent umgesetzt,<br />
Konventionen <strong>für</strong> Signalnamen und -belegungen wurden<br />
verändert, Stromlaufpläne sind aufgrund später Ä nderungen<br />
nicht mehr aktuell, die Kommunikation zwischen<br />
Steuerungen funktioniert nicht.<br />
Viele der genannten Fehler ließen sich vermeiden,<br />
wenn die Planungsdaten zuvor werkzeugübergreifend<br />
auf Konsistenz geprüft oder die Konsistenz bereits während<br />
des <strong>Engineering</strong>s überwacht worden wäre. So definiert<br />
beispielsweise ein SPS-Programmierer binäre Ausgangssignale,<br />
die dem Roboterprogrammierer als Zustands-<br />
oder H andshakesignale dienen. Oder ein Schaltschrankplaner<br />
verwendet diese Signale, um deren<br />
Verkabelung und Anschlussplanung im Schaltschrank<br />
durchzuführen. Diese Beispiele verdeutlichen, wie stark<br />
die tägliche Arbeit der Planungsingenieure innerhalb<br />
ihrer unabhängigen Planungswerkzeuge miteinander<br />
verwoben ist. Doch die verwendeten <strong>Engineering</strong>-Werkzeuge<br />
unterschiedlicher H ersteller sind nicht da<strong>für</strong> konzipiert<br />
– sie wurden unabhängig voneinander entwickelt<br />
und kennen sich nicht. Allerdings müssen diejenigen<br />
Planungsdaten, die die Interaktion zwischen den Automatisierungskomponenten<br />
beschreiben, über alle betroffenen<br />
<strong>Engineering</strong>-Werkzeuge konsistent gehalten werden<br />
(siehe Bild 2 ). Die dazugehörigen Datenobjekte werden<br />
im Folgenden als Kollaborationsobjekte bezeichnet.<br />
1. METHODISCHE GRUNDLAGEN<br />
Die Fähigkeit zur Interaktion zwischen <strong>Engineering</strong>-<br />
Werkzeugen (vergleiche [ 4 ] ) wird mit dem Begriff der Interoperabilität<br />
zusammengefasst.<br />
„ Interoperabilität zwischen <strong>Engineering</strong>werkzeugen<br />
verfolgt <strong>das</strong> Ziel, Konsistenz zwischen den Daten einer<br />
Werkzeugkette computergestützt, systematisch und wiederholt<br />
herstellen zu können.“ [ 5 ] .<br />
Als Voraussetzung <strong>für</strong> Interoperabilität gelten die<br />
durch den GMA-Fachausschuss 6 .1 2 („ Durchgängiges<br />
<strong>Engineering</strong> von Leitsystemen“ ) hinsichtlich des Informationsaustausches<br />
definierten Attribute durchgängig,<br />
vernetzt und offen. Die Vernetzung der Werkzeuge<br />
über offene Schnittstellen offeriert die Möglichkeit<br />
eines durchgängigen <strong>Engineering</strong>s entlang des<br />
<strong>Engineering</strong>-Workflows, gewerke- und unternehmensübergreifend<br />
[ 6 ] .<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
37
HAUPTBEITRAG<br />
act Gesamt-<strong>Engineering</strong>-Prozess<br />
Teile-Design<br />
BILD 1: Typischer <strong>Engineering</strong>-Workflow<br />
im Fertigungsumfeld<br />
Standard-Anlagenplanung<br />
Planung der realen Anlage<br />
Construction /<br />
Manufacturing<br />
act Funktionales <strong>Engineering</strong><br />
Standard-Anlagenplanung<br />
Anlagenplanung<br />
Mechanische Planung<br />
Abstrakter Materialflußsimulation<br />
Angebot<br />
verfeinerte Materialflußsimulation<br />
Steuerungsplanung<br />
Roboter-<br />
Simulation<br />
Elektroplanung<br />
HMI<br />
<strong>Engineering</strong><br />
Roboter Offlineprogrammierung<br />
Virtuelle Inbetriebnahme<br />
Commissioning / Production<br />
Vor-Inbetriebnahme-<br />
Inbetriebnahme<br />
Betrieb<br />
BILD 2: Zwischen <strong>Engineering</strong>-Werkzeugen<br />
verteilte Kollaborationsobjekte<br />
In der Praxis haben sich zwei methodische Ansätze<br />
zur Erstellung interoperabler <strong>Engineering</strong>-Werkzeuge<br />
etabliert:<br />
a | eine tiefe Integration der Werkzeuge basierend auf<br />
einer gemeinsamen Datenbank<br />
b | eine lose Kopplung und Interaktion über einen Dateiaustausch,<br />
in der Regel jedoch ohne die Möglichkeit,<br />
die Daten automatisch zu übernehmen<br />
Unter [ 5 ] findet sich ein vergleichender Überblick über<br />
beide Varianten. Die tiefe Integration ist im Allgemeinen<br />
nur <strong>für</strong> solche Werkzeuge möglich, die sich im Besitz<br />
eines Softwareherstellers befinden. Allerdings verwenden<br />
Ingenieure in der Praxis gerne die <strong>für</strong> ihre Einsatzzwecke<br />
am besten geeigneten Werkzeuge – und die meisten<br />
am Markt befindlichen Werkzeuge stammen von<br />
unterschiedlichen H erstellern. Das vorgestellte Konzept<br />
verfolgt daher Variante b).<br />
1.1 Anforderungen<br />
Der Kern des Konzeptes besteht darin, <strong>für</strong> die Interoperabilität<br />
zwischen Werkzeugen ein vermittelndes Kollaborationswerkzeug<br />
einzuführen. Dazu müssen folgende<br />
Anforderungen erfüllt sein:<br />
1 | Das Werkzeug muss keine Kenntnisse über die Datenmodelle<br />
der beteiligten Werkzeuge benötigen<br />
und die Unabhängigkeit der Werkzeuge untereinander<br />
bewahren.<br />
2 | Das Werkzeug muss Kollaborationsfunktionen zur<br />
Verfügung stellen, die beim klassischen dateibasierten<br />
Datenaustausch fehlen, zum Beispiel die<br />
Ermittlung von Inkonsistenzen, Ä nderungsmanagement<br />
oder Benachrichtigungsfunktionen.<br />
Grundlage <strong>für</strong> diese Funktionen ist ein gemeinsames<br />
Datenformat.<br />
3 | Das Werkzeug muss konzeptionell unabhängig von<br />
den verwendeten Werkzeugen oder dem Workflow<br />
arbeiten – und sich somit in vorhandene Werkzeuglandschaften<br />
und Workflows einführen lassen.<br />
4 | Mit den zum Datenaustausch verwendeten Kollaborationsobjekten<br />
muss ein Großteil der Schnittstellendaten<br />
abgedeckt werden. Sie sollen jedoch<br />
werkzeugspezifisch erweiterbar sein, um auch über<br />
Standarddaten hinausgehende Informationen zur<br />
Verfügung stellen zu können.<br />
5 | Das Werkzeug muss dem Eigentümer der Daten<br />
Rückmeldung über die Verwendung der Kollaborationsobjekte<br />
geben. Mögliche Ausprägungen sind<br />
„ nicht verwendet“ , „ verwendet und konsistent“<br />
oder „ verwendet, aber nicht konsistent“ .<br />
6 | Der Datenaustausch muss auf etablierten Standardtechnologien<br />
basieren.<br />
2. GRUNDIDEE UND KONZEPT<br />
Das Grundkonzept lässt sich mit einem interaktiven Vorgang<br />
des Verleihens von Daten vergleichen. Anstelle einer<br />
tatsächlichen Datenübergabe im Sinne eines Kopierens<br />
leiht ein Ingenieur dem anderen lediglich seine<br />
38<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
Ä<br />
<strong>Engineering</strong>-Daten. Er gewährt damit einen reduzierten<br />
Einblick auf die <strong>für</strong> den anderen relevanten Daten. Der<br />
benötigte Leihgegenstand, beispielsweise ein Signal,<br />
wird von beiden Ingenieuren im Kollaborationswerkzeug<br />
durch Auswahl der entsprechenden Kollaborationsobjekte<br />
interaktiv festgelegt – aber er verbleibt nach dem<br />
Vorgang des Leihens im Besitz des verleihenden Ingenieurs.<br />
Der andere Ingenieur kann <strong>das</strong> geliehene Kollaborationsobjekt<br />
sehen und verwenden, aber er kann es<br />
weder ändern noch löschen.<br />
Wesentlicher Bestandteil der Kollaborationsobjekte ist<br />
die Referenz zu den jeweiligen Ursprungsdaten. Mithilfe<br />
dieser Referenz erhält der leihende Ingenieur jederzeit<br />
die Möglichkeit zu prüfen, ob <strong>das</strong> von ihm verwendete<br />
Artefakt noch aktuell ist, wohingegen der Eigentümer<br />
jederzeit prüfen kann, wem er welche Daten verliehen<br />
hat und ob diese Daten tatsächlich verwendet werden.<br />
ndert der Eigentümer ein verliehenes Kollaborationsobjekt,<br />
wird der Leihende darüber informiert.<br />
2.1 Das Eigentumskonzept<br />
Das Konzept verlangt einen gerichteten Datenfluss vom<br />
Erzeuger der Daten zu einem Konsumenten. Der Erzeuger<br />
ist dabei der Eigentümer der Daten, er ist <strong>für</strong> die Freigabe,<br />
<strong>für</strong> die Korrektheit und <strong>für</strong> die Ä nderungen verantwortlich.<br />
Mit dem Datenaustausch wird diese Verantwortung<br />
im Gegensatz zum klassischen Dateiaustausch<br />
nicht aufgegeben, sondern durch <strong>das</strong> Verleihkonzept<br />
bewahrt. Nur der Eigentümer darf Daten ändern. Der<br />
Empfänger hingegen darf die geliehenen Daten zwar verwenden,<br />
jedoch nicht ändern.<br />
2.2 Kollaborationsobjekte<br />
Das Ideal des Datenaustausches wäre ein weltweit vereinbartes<br />
und akzeptiertes Weltmodell des <strong>Engineering</strong>. Bekanntermaßen<br />
sind jedoch in den hier betrachteten Domänen<br />
alle Bemühungen und Ansätze in dieser Richtung<br />
an der Komplexität, an der Vielzahl von Werksnormen,<br />
Standards und Gewerken gescheitert. Ohne Vereinbarungen<br />
lässt sich ein elektronischer Datenaustausch jedoch<br />
nicht wirtschaftlich realisieren.<br />
Das Konzept der Kollaborationsobjekte verfolgt die<br />
Idee, nur die tatsächlich benötigte Schnittmenge der Daten<br />
zu standardisieren, beispielsweise ein H andshake-<br />
Signal. Solche Mikro-Datenmodelle sind insbesondere<br />
im Fertigungsumfeld einfach genug, um Konsens über<br />
ein zugehöriges Datenmodell zu erlangen.<br />
Ein Kollaborationsobjekt ist ein <strong>Engineering</strong>-Objekt<br />
einer Anlage (mit zugehörigen Attributen), welches von<br />
mehreren domänenspezifischen Projektingenieuren in<br />
verschiedenen <strong>Engineering</strong>-Werkzeugen instanziiert,<br />
konfiguriert und zugleich im <strong>Engineering</strong>prozess über<br />
alle beteiligten Werkzeuge hinweg konsistent gehalten<br />
werden muss [ 5 ] .<br />
Auf diese Weise wird der Datenaustausch innerhalb<br />
einer heterogenen Werkzeuglandschaft signifikant vereinfacht<br />
– Kollaborationsobjekte bieten ein effizientes<br />
Verhältnis zwischen Standardisierungsaufwand und<br />
praktischer Anwendbarkeit. Kollaborationsobjekte<br />
sind an keinen internationalen Standard gebunden.<br />
Im Gegenteil, sie können kleine, lokale Projektstandards<br />
umsetzen oder auch existierende Ergebnisse<br />
ontologiebasierter Forschungsarbeiten aufgreifen, zum<br />
Beispiel [ 9 ] , oder Standards wie [ 1 0 ] , [ 1 1 ] oder [ 1 2 ] nutzen.<br />
Das vorgestellte Konzept schreibt kein Datenmodell<br />
vor, sondern ist konzeptionell auf künftige Standards<br />
vorbereitet.<br />
2.3 Rückführungsauswertung<br />
Das Konzept der Rückführung stellt einen Rückbezug<br />
zwischen geliehenen Daten und ihren Originalen her.<br />
Dabei werden drei Auswertungen durchgeführt:<br />
Rückführung 1 :<br />
Die Information, welche Daten vom Empfänger tatsächlich<br />
verwendet werden, wird dem Eigentümer<br />
zurückgesendet.<br />
Rückführung 2 :<br />
Ein automatischer Vergleich zwischen verliehenen<br />
Daten mit ihrem Original ermöglicht die automatische<br />
Erkennung relevanter Ä nderungen.<br />
Rückführung 3 :<br />
Die Information, welche Ä nderungen vom Empfänger<br />
bestätigt und somit verarbeitet sind, wird dem<br />
Dateneigentümer zurückgesendet.<br />
Diese drei Rückführungen ermöglichen der Kollaborationssoftware,<br />
die Konsistenz zwischen relevanten Daten<br />
automatisch zu prüfen. So wird verhindert, <strong>das</strong>s Datenstände<br />
unerkannt auseinanderdriften.<br />
2.4 Vorgehensmodell<br />
Das Konzept des Datenaustausches sieht technisch folgende<br />
Schritte vor (siehe auch Bild 3 ):<br />
1 | Eine Exportersoftware exportiert relevante Daten<br />
aus dem Quellwerkzeug. Diese ist auf <strong>das</strong> Quellwerkzeug<br />
zugeschnitten und kennt dessen Datenmodell.<br />
Beim Export transformiert sie (ausschließlich)<br />
die interessierenden Datenobjekte in individuell<br />
vereinbarte oder standardisierte Kollaborationsobjekte.<br />
2 | Die Daten werden im genannten Kollaborationswerkzeug<br />
verwaltet und visualisiert. H ier erhält<br />
der Datenbesitzer die Möglichkeit, Datenempfänger<br />
zu definieren und aus dem Pool der verfügbaren<br />
Kollaborationsobjekte diejenigen auszuwählen,<br />
die <strong>für</strong> den Datenempfänger relevant sind.<br />
Dies entspricht einem Freigabeprozess. Weiterhin<br />
wird ein gemeinsamer Ort auf einem beliebigen<br />
Filesharingsystem vereinbart, der <strong>für</strong> den Datenaustausch<br />
verwendet wird.<br />
3 | Die aktuelle Implementierung der ausgewählten<br />
Kollaborationsobjekte kann zum gewünschten<br />
Zeitpunkt vom Dateneigentümer mit H ilfe des Kollaborationswerkzeugs<br />
in eine Übergabedatei kopiert<br />
werden. Neben den Kollaborationsobjekten<br />
enthält diese Datei Verweise auf die Originalobjekte<br />
im Software-Werkzeug des Dateneigentümers.<br />
Diese Datei wird im definierten Ordner abgelegt.<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
39
HAUPTBEITRAG<br />
4 | Der Empfänger nimmt diese Datei entgegen und<br />
kann sie mithilfe eines Importers in sein Werkzeug<br />
überführen. Der Importer kennt die vereinbarten<br />
Kollaborationsobjekte sowie <strong>das</strong> Datenmodell des<br />
Zielwerkzeuges. Der tatsächliche Import einzelner<br />
Daten in <strong>das</strong> Zielwerkzeug wird hierbei explizit<br />
quittiert beziehungsweise abgelehnt. An jedes einzelne<br />
Kollaborationsobjekt wird dabei die Information<br />
angehängt, in welcher Ausprägung es verwendet<br />
wird (siehe Abschnitt 1 .1 Anforderung 5 ). Diese<br />
Information wird dem Kollaborationswerkzeug<br />
übermittelt und steht damit dem Dateneigentümer<br />
zur Verfügung.<br />
5 | Erfolgen während des <strong>Engineering</strong>s im Quellwerkzeug<br />
Ä nderungen an freigegebenen und verwendeten<br />
Daten, entstehen Inkonsistenzen. Daher ermittelt <strong>das</strong><br />
Kollaborationswerkzeug anhand der vom Empfänger<br />
tatsächlich verwendeten Daten diejenigen Ä nderungen,<br />
die <strong>für</strong> jeden Empfänger individuell relevant<br />
sind. Der Dateneigentümer kann daraufhin entscheiden,<br />
ob er die Ä nderungen in seinem <strong>Engineering</strong>-<br />
Werkzeug aufgrund von zu hohen Ä nderungsaufwänden<br />
in den Zielwerkzeugen noch einmal überarbeitet<br />
oder die Ä nderungen an die Datenempfänger<br />
freigibt. Ö ffnet der Empfänger die freigegebenen<br />
Daten, dann wird er vom Kollaborationswerkzeug<br />
sowohl über Ä nderungen gegenüber der letzten Version<br />
als auch über Inkonsistenzen zur Implementierung<br />
in seinem Zielwerkzeug hingewiesen. Inkonsistenzen<br />
werden somit <strong>für</strong> alle Beteiligten transparent.<br />
Die Übernahme der geänderten Kollaborationsobjekte<br />
erfolgt analog zu Schritt 4 .<br />
Die Grundlage von Kollaborationsfunktionen wie Ä nderungsberechnungen<br />
oder Benachrichtigungssysteme ist<br />
ein gemeinsames Datenformat. H ier<strong>für</strong> wird Automation-<br />
ML [ 7 ] verwendet. Die Nutzung der X ML-Syntax eignet<br />
sich besonders <strong>für</strong> den Datenaustausch zwischen <strong>Engineering</strong>-Werkzeugen<br />
[ 8 ] .<br />
Dadurch ensteht ein Wirkmechanismus, der die Kollaborationsobjekte<br />
auf Basis einfacher Konfigurationsdateien<br />
konsistent halten kann. Die einzige Anforderung<br />
an die IT-Infrastruktur ist ein gemeinsam genutzter<br />
Datei server. Auf die Einrichtung von Datenbanken oder<br />
Webservices kann verzichtet werden.<br />
2.5 Beispiel<br />
Im Folgenden wird <strong>das</strong> Vorgehensmodel anhand eines<br />
Beispiels erläutert. Exemplarisch wird dazu der Austausch<br />
eines einzelnen Signals zwischen einem SPS-<br />
Programmierer und einem Roboterprogrammierer betrachtet.<br />
Der Dateneigentümer ist der SPS-Programmierer,<br />
der Roboterprogrammierer ist der Datenempfänger. Gemäß<br />
dem unter 2 .4 vorgestellten Vorgehensmodell werden<br />
folgende Phasen durchschritten:<br />
Schritt 1 – Export der Daten aus dem SPS-<strong>Engineering</strong>-<br />
Werkzeug: Als erstes wird aus dem SPS-<strong>Engineering</strong>-Werkzeug<br />
ein Export in AutomationML durchgeführt. Dieser<br />
Export enthält alle Daten, inklusive der Elternobjekte, die<br />
auch <strong>für</strong> andere Planungsphasen oder -werkzeuge interessant<br />
sein können. In diesem Beispiel sind dies vier Signale<br />
– zwei digitale Eingänge und zwei digitale Ausgänge.<br />
Bild 4 illustriert <strong>das</strong> beschriebene Vorgehen. Nachdem<br />
der Export ausgelöst wurde, werden die Daten aus dem<br />
SPS-<strong>Engineering</strong>-Werkzeug (links) exportiert (1 ) und im<br />
Kollaborationswerkzeug (rechts) dargestellt (2 ).<br />
Schritt 2 – Verleihen des Signals: „ Digital Input 1 “ soll<br />
an den Roboterprogrammierer verliehen werden. Der<br />
SPS-Programmierer benutzt <strong>das</strong> Kollaborationswerkzeug<br />
zur Freigabe und definiert zunächst die Empfänger<br />
(Bild 5 ). Die Beispieldaten sollen an zwei Empfänger<br />
verliehen werden, den Roboterprogrammierer und einen<br />
anderen Empfänger.<br />
Für den Roboterprogrammierer wird „ Digital Input 1 “<br />
durch Setzen eines H äkchens in der entsprechenden<br />
Zelle freigegeben (Bild 5 ). Die Daten sind damit zum Verleihen<br />
vorbereitet.<br />
Schritt 3 – Versand des verliehenen Signals zum Roboterprogrammierer:<br />
Die zum Verleih freigegebenen Daten,<br />
im Beispiel „ Digital Input 1 “ , werden anschließend<br />
vom Kollaborationswerkzeug in eine Übergabendatei<br />
extrahiert und an einem zuvor vereinbarten Ort abgelegt.<br />
Der Roboterprogrammierer nutzt <strong>das</strong> Kollaborationswerkzeug,<br />
um die ihm geliehenen Daten anzuzeigen und<br />
in <strong>das</strong> Roboter-<strong>Engineering</strong>-Werkzeug zu importieren (1 ).<br />
In Bild 6 werden die Daten, die im Kollaborationswerkzeug<br />
auf SPS Seite freigegeben wurden (links), mit der<br />
Ansicht der Daten im Kollaborationswerkzeug auf Roboterseite<br />
(rechts) dargestellt. Der Roboterprogrammierer<br />
sieht nur noch „ Digital Input 1 “ und die darüber liegende<br />
Struktur, also nur die <strong>für</strong> ihn relevanten Daten.<br />
Schritt 4 – Importieren des Signals ins Roboter-<strong>Engineering</strong>-Werkzeug:<br />
Das geliehene Signal „ Digital Input<br />
1 “ wird abschließend in <strong>das</strong> Roboter-<strong>Engineering</strong>-Werkzeug<br />
importiert. Der Roboterprogrammierer benutzt hierzu<br />
ebenfalls <strong>das</strong> Kollaborationswerkzeug.<br />
Wie in Bild 7 dargestellt wird zunächst der Import<br />
ausgelöst, welcher <strong>das</strong> freigegebene Signal in <strong>das</strong> Zielwerkzeug<br />
(rechts) überführt. Wenn die Daten erfolgreich<br />
importiert wurden, wird dies im Kollaborationswerkzeug<br />
(links) bekannt gegeben und entsprechend quittiert.<br />
Schritt 5 – Anzeige und Quittieren des geänderten<br />
Default-Wertes: Nachdem der Roboterprogrammierer <strong>das</strong><br />
Signal in sein Werkzeug importiert hat, findet im Laufe<br />
des <strong>Engineering</strong> eine Ä nderung auf der SPS-Seite statt.<br />
Der Dateneigentümer hat den Default-Wert des Signals<br />
verändert und damit eine Inkonsistenz zwischen<br />
dem SPS-<strong>Engineering</strong>-Werkzeug und dem Roboter-<br />
<strong>Engineering</strong>-Werkzeug verursacht. Diese wird auf Dateneigentümerseite<br />
(Bild 8 , links) und auf Empfängerseite<br />
(Bild 8 , rechts) farblich am Objekt und auch am<br />
geänderten Attribut markiert. Wenn der Empfänger<br />
diese Ä nderung verarbeitet hat, kann dieser die Ä nderung<br />
quittieren und damit die Inkonsistenz auf beiden<br />
Seiten aufheben.<br />
2.6 U nterschiede zum klassischen<br />
dateibasierten Datenaustausch<br />
Der skizzierte Ansatz unterscheidet sich konzeptionell<br />
erheblich von klassischen dateibasierten Ansätzen. Im<br />
Vergleich zum traditionellen Dateiaustausch werden die<br />
Konzepte der Kollaborationsobjekte, der Eigentümerschaft<br />
sowie der Rückmeldung der Verwendung eingeführt.<br />
H ierbei werden folgende Aspekte umgesetzt:<br />
40<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
Fokussierung auf Kollaborationsobjekte: Nur diejenigen<br />
Objekte werden ausgetauscht, die tatsächlich gemeinsam<br />
verwendet werden. Eine Ö ffnung der <strong>Engineering</strong>-Werkzeuge<br />
ist somit nur sehr eingeschränkt erforderlich und stellt<br />
keine Gefahr <strong>für</strong> deren H ersteller dar. Eine herstellerübergreifende<br />
und flexible Mikro-Standardisierung von Datenmodellen<br />
<strong>für</strong> derartige Kollaborationsobjekte ist greifbar.<br />
Bereitstellung von Kollaborationsfunktionen: Das<br />
Kollaborationswerkzeug verfügt über generische Kollaborationsfunktionen<br />
wie Ä nderungsmanagement<br />
und Benachrichtigungssysteme. Diese funktionieren<br />
unabhängig vom Datenmodell der beteiligten Werkzeuge<br />
und den tatsächlich verwendeten Kollaborationsobjekten.<br />
Transparente Eigentumsverhältnisse: Das explizit vorgesehene<br />
Konzept der Dateneigentümerschaft löst <strong>das</strong><br />
bekannte Problem der bidirektionalen Datensynchronisation<br />
durch eine unidirektionale Verbindung. Verant-<br />
Werkzeug 1<br />
Werkzeug 2<br />
Exporter 2<br />
Werkzeug 3<br />
Export aller<br />
Kollaborationsobjekte<br />
Exporter 1<br />
Exporter 3<br />
Werkzeug<br />
<strong>für</strong> Dateneigentümer<br />
Auswahl der<br />
Empfänger und<br />
Zuordnung der<br />
Kollaborationsobjekte<br />
Kollaborationswerkzeug<br />
Rückmeldung<br />
zur<br />
Verwendung<br />
Änderungsmanagement<br />
Versionierung<br />
Schreibgeschützte Kopie<br />
der geliehenen Daten<br />
Mitteilungen<br />
. . .<br />
Import der<br />
Kollaborationsobjekte<br />
Importer A<br />
Werkzeug A<br />
Importer B<br />
Werkzeug B<br />
Importer C<br />
Werkzeug C<br />
BILD 3: Konzept des Datenaustausches<br />
zwischen zwei <strong>Engineering</strong>-Werkzeugen<br />
BILD 6: Eigentümer- und Empfängeransicht<br />
des Kollaborationswerkzeuges<br />
BILD 4: Export interessanter Daten<br />
aus dem SPS-<strong>Engineering</strong>werkzeug<br />
BILD 7: Import von Daten in <strong>das</strong> Zielwerkzeug<br />
BILD 5:<br />
Freigabe des Signals und<br />
seiner Elternobjekte in der<br />
Kollaborations software<br />
als Vorbereitung zum<br />
Verleih an den<br />
Roboter programmierer<br />
BILD 8: Zwei Sichten des Deltamanagements<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
41
HAUPTBEITRAG<br />
wortlichkeiten und Zugehörigkeiten sind Teil des Konzeptes<br />
und dadurch klar definiert. Ein kontrollierter<br />
bidirektionaler Datenaustausch ist durch Einführung<br />
des umgekehrten Leih-Weges möglich.<br />
Rückmeldung der Verwendung: Dem Eigentümer wird<br />
zurückgemeldet, welche Kollaborationsobjekte verwendet<br />
werden. Dies ist die Basis <strong>für</strong> ein Ä nderungsmanagement.<br />
Wahrung der Unabhängigkeit der <strong>Engineering</strong>-Werkzeuge:<br />
Die <strong>Engineering</strong>-Werkzeuge müssen nicht verändert<br />
werden, eine Abstimmung zwischen den H erstellern<br />
der Werkzeuge ist nicht erforderlich. Ä nderungen an den<br />
Werkzeugen können den Komfort des Konzeptes erhöhen,<br />
sind aber nicht zwingend erforderlich.<br />
AUTOREN<br />
ZUSAMMENFASSUNG<br />
Dieser Beitrag stellt ein neuartiges Konzept vor, die Konsistenz<br />
von verteilten <strong>Engineering</strong>daten ohne tiefe Integration<br />
der beteiligten Planungswerkzeuge zu erreichen.<br />
Dazu wurden grundlegende Möglichkeiten der Interoperabilität<br />
diskutiert und Anforderungen an ein praxistaugliches<br />
Kollaborationswerkzeug formuliert. Abschließend<br />
wurden die benötigten Konzepte sowie <strong>das</strong> zugrundeliegende<br />
Vorgehensmodell erläutert und anhand eines Beispiels<br />
demonstriert.<br />
MANUSKRIPTEINGANG<br />
08.12.2011<br />
REFERENZEN<br />
Im Peer-Review-Verfahren begutachtet<br />
Dr.-Ing. RAINER DRATH (geb. 1 9 7 0 ) ist<br />
Senior Principal Scientist im ABB<br />
Forschungszentrum Deutschland in<br />
Ladenburg. Er beschäftigt sich mit der<br />
Entwicklung neuer Konzepte und<br />
Methoden zur Verbesserung des <strong>Engineering</strong><br />
von Automatisierungssystemen.<br />
ABB Forschungszentrum Ladenburg,<br />
Wallstadter Str. 59, D-68526 Ladenburg,<br />
Tel. +49 (0) 6203 71 64 71, E-Mail: rainer.drath@de.abb.com<br />
Dipl.-Ing. (FH ) MARIO HOERNICKE<br />
(geb. 1 9 8 4 ) ist wissenschaftlicher Mitarbeiter<br />
des ABB Forschungszentrums Deutschland.<br />
Sein H auptinteresse gilt der Entwicklung<br />
neuer und innovativer <strong>Engineering</strong>-<br />
Konzepte, unter anderem im Bereich<br />
Emulation von Leitsystemfunktionen und<br />
Subsystemen, sowie der Automation des<br />
<strong>Engineering</strong>s.<br />
ABB AG Forschungszentrum Ladenburg,<br />
Wallstadter Str. 59, D-68526 Ladenburg,<br />
Tel. +49 (0) 6203 71 62 66, E-Mail: mario.hoernicke@de.abb.com<br />
Dr.-Ing. BEN SCHRÖTER (geb. 1 9 7 7 ) ist<br />
wissenschaftlicher Mitarbeiter der<br />
Abteilung „ Industrial Software and<br />
Applications“ des ABB Forschungszentrums<br />
Deutschland. Sein Arbeitsschwerpunkt<br />
ist die Entwicklung von Methoden<br />
zur Verbesserung des <strong>Engineering</strong>s von<br />
automatisierten Systemen in der diskreten<br />
Fertigung.<br />
ABB Forschungszentrum Ladenburg,<br />
Wallstadter Str. 59, D-68526 Ladenburg,<br />
Tel. +49 (0) 6203 71 62 76, E-Mail: ben.schroeter@de.abb.com<br />
[1] Weidemann, D.; Drath, R.: Übersicht von Softwarewerkzeugen<br />
im <strong>Engineering</strong>. In: Drath, R. (Hrsg.):<br />
Datenaustausch in der Anlagenplanung mit AutomationML,<br />
S. 5. Springer Verlag Berlin Heidelberg, 2010.<br />
[2] Drath, R.; Fay, A.; Schmidberger, T.: Computer-aided<br />
design and implementation of interlock control code.<br />
In: Tagungsband “IEEE Conference on Computer Aided<br />
Control Systems Design” , S. 2652-2658. IEEE, 2006.<br />
[3] Drath, R.: Die Zukunft des <strong>Engineering</strong>. Herausforderungen<br />
an <strong>das</strong> <strong>Engineering</strong> von fertigungs- und<br />
verfahrenstechnischen Anlagen. In: Tagungsband<br />
Karlsruher leittechnisches Kolloquium 2008, S. 33-40,<br />
Fraunhofer IRB Verlag, Karlsruhe, 2008<br />
[4] Tauchnitz, T.; Maier, U.: Prozessleitsysteme (PLS). In:<br />
K. F. Früh, U. Maier, D. Schaudel (Hrsg.): Handbuch der<br />
Prozessautomatisierung – Prozessleittechnik <strong>für</strong><br />
verfahrenstechnische Anlagen. , S. 191, 4. Auflage,<br />
Oldenbourg Industrieverlag München, 2009.<br />
[5] Drath, R.; Fay A.; Barth, M.: Interoperabilität von<br />
<strong>Engineering</strong>-Werkzeugen. at – Automatisierungstechnik<br />
59(9), S. 598-607, 2011<br />
[6] Fay, A.: <strong>Engineering</strong> in vernetzten, offenen, durchgängigen<br />
Systemen. In: at – Automatisierungstechnik 53<br />
(4-5), S. 205-210, 2005<br />
[7] Drath, R (Hrsg.): Datenaustausch in der Anlagenplanung<br />
mit AutomationML. Springer Verlag, Berlin, 2009<br />
[8] Epple, U.: Austausch von Anlagenplanungsdaten auf<br />
der Grundlage von Metamodellen. Atp - Automatisierungstechnische<br />
Praxis 45 (7), S. 61-70, 2003<br />
[9] Wiesner, A.; Wiedau, M.; Marquardt, W.; Temmen, H.;<br />
Richert, H.; Anhäuser, F.: Wissensbasierte Integration<br />
und Konsolidierung von heterogenen Anlagenplanungsdaten.<br />
<strong>atp</strong> <strong>edition</strong> - Automatisierungstechnische<br />
Praxis 52(4), S. 48-58, 2010.<br />
[10] I SO 15926. Industrial automation systems and<br />
integration of life-cycle data for process plants<br />
including oil and gas production facilities<br />
[11] I SO10303: Automation systems and integration<br />
— Product data representation and exchange, formerly<br />
known as STEP, Standard for the Exchange of Product<br />
model data<br />
[12] N E 100: Merkmalleisten zur Erstellung von PLT-Gerätespezifikationen.<br />
Namur, 2003<br />
42<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
Abo plus<br />
<strong>atp</strong> <strong>edition</strong><br />
als Heft<br />
+ als ePaper<br />
Die Referenzklasse fü r die<br />
Automatisierungstechnik<br />
Erfahren Sie auf höchstem inhaltlichen Niveau, was die<br />
Automatisierungsbranche bewegt. Alle Hauptbeiträge<br />
werden in einem Peer-Review-Verfahren begutachtet,<br />
um Ihnen maximale inhaltliche Qualität zu garantieren.<br />
Sichern Sie sich jetzt dieses erstklassige Lektü reerlebnis.<br />
Als exklusiv ausgestattetes Heft oder als praktisches<br />
ePaper – ideal fü r unterwegs, auf mobilen Endgeräten<br />
oder zum Archivieren.<br />
Gratis <strong>für</strong> Sie: Der Tagungsband AALE 2011 als ePaper<br />
Das Kompendium bietet eine Zusammenstellung der Fachreferate des 8. Fachkolloquiums fü r<br />
angewandte Automatisierungstechnik in Lehre und Entwicklung an Fachhochschulen.<br />
Die Veranstaltung versteht sich als Forum fü r Fachleute der Automatisierungstechnik aus Hochschulen<br />
und Wirtschaft. Sie wird von der Fakultät Mechatronik und Elektrotechnik der Hochschule Esslingen mit<br />
Unterstü tzung des VFAALE und dem Kompetenzzentrum Mechatronik BW e.V. organisiert und ausgerichtet.<br />
1. Aufl age 2012, 350 Seiten<br />
<strong>atp</strong> <strong>edition</strong> erscheint in der Oldenbourg Industrieverlag GmbH, Rosenheimerstr. 145, 81671 Mü nchen<br />
Oldenbourg-Industrieverlag<br />
www.<strong>atp</strong>-online.de<br />
Vorteilsanforderung per Fax: +49 (0) 931 / 4170 - 492 oder im Fensterumschlag einsenden<br />
Ja, ich möchte <strong>atp</strong> <strong>edition</strong> im Abo-plus-Paket lesen.<br />
Bitte schicken Sie mir die Fachpublikation fü r zunächst ein Jahr (12 Ausgaben) als gedrucktes Heft<br />
+ digital als ePaper (PDF-Datei als Einzellizenz) fü r € 638,40 (Deutschland) / € 643,40 (Ausland).<br />
Als Dankeschön erhalte ich den Tagungsband AALE 2011 gratis als eBook.<br />
Nur wenn ich nicht bis von 8 Wochen vor Bezugsjahresende kü ndige, verlängert sich der Bezug um<br />
ein Jahr.<br />
Die sichere, pü nktliche und bequeme Bezahlung per Bankabbuchung wird mit einer Gutschrift von<br />
€ 20,- auf die erste Jahresrechung belohnt<br />
Antwort<br />
Leserservice <strong>atp</strong><br />
Postfach 91 61<br />
97091 Würzburg<br />
Firma/Institution<br />
Vorname/Name des Empfängers<br />
Straße/Postfach, Nr.<br />
Land, PLZ, Ort<br />
Telefon<br />
Telefax<br />
E-Mail<br />
Branche/Wirtschaftszweig<br />
Bevorzugte Zahlungsweise □ Bankabbuchung □ Rechnung<br />
Bank, Ort<br />
✘<br />
Bankleitzahl<br />
Kontonummer<br />
Widerrufsrecht: Sie können Ihre Vertragserklärung innerhalb von 14 Tagen ohne Angabe von Gründen in Textform (Brief, Fax, E-Mail) oder durch<br />
Rücksendung der Sache widerrufen. Die Frist beginnt nach Erhalt dieser Belehrung in Textform. Zur Wahrung der Widerrufsfrist genügt die rechtzeitige Datum, Unterschrift<br />
PAATPE0212<br />
Absendung des Widerrufs oder der Sache an den Leserservice <strong>atp</strong>, Franz-Horn-Str. 2, 97082 Wü rzburg<br />
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, <strong>das</strong>s ich vom<br />
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 <strong>für</strong> die Zukunft jederzeit widerrufen.
HAUPTBEITRAG<br />
Automatisiertes<br />
Kommunikationsengineering<br />
Kommunikationsstrukturen aus Planungsdaten erzeugen<br />
Dieser Beitrag präsentiert ein Planungsassistenzsystem <strong>für</strong> die <strong>integrierte</strong> Kommunikationsplanung<br />
einer prozesstechnischen Anlage. Ziel des Ansatzes ist es, die Ingenieure<br />
dabei zu unterstützen, die Anforderungen der Prozessführung bei der Gestaltung der<br />
industriellen Kommunikation optimal zu berücksichtigen – ausgehend von bestehenden<br />
Basisplanungsdaten der Elektro-, Mess-, Steuer- und Regelungstechnik (EMSR), der Verfahrenstechnik,<br />
der Sicherheitstechnik und der Aufstellungsplanung. Das System hilft<br />
bei der Auswahl der optimalen Kommunikationstechnologie, entwirft Strukturen <strong>für</strong> <strong>das</strong><br />
EMSR-Mengengerüst (Signale von Sensoren beziehungsweise zu Aktoren) und generiert<br />
ein detailliertes Mengengerüst <strong>für</strong> die industrielle Kommunikation. Damit wird erstmals<br />
der Feldbusplanungsprozess nach NAfl1 1 4 mit H ilfe einer technologieunabhängigen Werkzeugkette<br />
durchgängig unterstützt.<br />
SCHLAGWÖRTER Feldbus / Integriertes <strong>Engineering</strong> / Automatisierung der<br />
Auto matisierung / Entscheidungsunterstützung<br />
Automated communications engineering –<br />
Generating structures supported by integrated basic engineering data<br />
This paper presents a support system for integrated communication planning for a process<br />
plant. The goal is to meet the process communication requirements of the engineer on the<br />
basis of the basic engineering data from the various departments relating to control engineering,<br />
process design, safety, and construction. The system helps with the selection of<br />
the optimum communication technology, and automatically calculates the structure and<br />
material take off (MTO) of required communication equipment. For the first time, the<br />
fieldbus planning process according NA 1 1 4 is supported by an integrated and technology-independent<br />
tool chain.<br />
KEYWORDS fieldbus / integrated engineering /automation of automation /<br />
decision support<br />
44<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
FALK DOHERR, MARKUS STÖSS, LEON URBAS, Technische Universität Dresden<br />
Beim <strong>Engineering</strong> technischer Anlagen müssen<br />
vielfältige H erausforderungen bewältigt werden<br />
[ 1 ] . Neue Technologien können sich nur<br />
durchsetzen, wenn sie bereits im <strong>Engineering</strong><br />
beherrschbar sind. Somit ist <strong>Engineering</strong> eine<br />
Schlüsselkomponente zur Verbreitung neuer Technologien<br />
und gewährleistet die Investitionssicherheit <strong>für</strong><br />
zukünftige Entwicklungen. Die digitale Signalübertragung<br />
bis zu den Feldgeräten (Feldbus) ist solch eine Technologie,<br />
die viele Vorteile besitzt, aber speziell in der<br />
Prozessindustrie nur langsam Einzug hält. Eine Ursache<br />
liegt im <strong>Engineering</strong> der Feldbussysteme; effiziente und<br />
phasenübergreifende Planungsunterstützungssysteme<br />
sind derzeit nicht verfügbar. Dieser Beitrag zeigt einen<br />
innovativen Forschungsansatz zur Entscheidungs- und<br />
Planungsunterstützung <strong>für</strong> die feldnahe Kommunikation<br />
in der Prozessindustrie. Das System NetGen: X integriert<br />
alle <strong>für</strong> <strong>das</strong> Kommunikationsengineering notwendigen<br />
Daten der unterschiedlichen Gewerke. Dies reicht<br />
von den funktionalen Anforderungen der Prozessführung<br />
an Instrumentierung und Automatisierung, über<br />
die Aufstellungsplanung bis hin zu elektrischen und<br />
logischen Eigenschaften und Randbedingungen konkreter<br />
Feldbustechnologien.<br />
1. KOMMUNIKATION IN DER PROZESSAUTOMATISIERUNG<br />
Kommunikationseinrichtungen sind Kernkomponenten<br />
der Anlagenautomatisierung, die im Idealfall aus Sicht<br />
der Prozessführung vollkommen transparent arbeiten.<br />
Um dies effizient und effektiv zu gewährleisten, ist eine<br />
Strukturierung des industriellen Kommunikationsnetzwerkes<br />
sinnvoll.<br />
1.1 Arten der Signalanbindung<br />
Im Normalbetrieb wird unidirektional und kontinuierlich<br />
ein Datum pro Feldgerät übertragen. Im Inbetriebnahme-,<br />
Wartungs- oder Fehlerfall müssen hingegen<br />
viele Diagnose- und Parameterinformationen bidirektional<br />
übertragen werden. Kiupel [ 2 ] bezeichnet diese<br />
als Zusatzinformation. Bild 1 zeigt schematisch die in<br />
der Prozessindustrie verwendeten Ankopplungsarten<br />
von Signalen der Feldgeräte an die prozessnahen Komponenten<br />
(PNK) des Leitsystems.<br />
Bei der konventionellen Verdrahtung werden <strong>für</strong> jedes<br />
binäre und analoge Feldsignal zwei bis vier Leitungen<br />
<strong>für</strong> die Signalübertragung zwischen Feldgerät und<br />
zentralem Schaltraum gezogen. Dabei werden die in<br />
NEfl6 [ 3 ] und DINflIECfl6 0 3 8 1 [ 4 ] definierten Strom- und<br />
Spannungssignale verwendet und diese mittels Feldverteilern<br />
(J unction Box), Stammkabel und Rangierverteilern<br />
an die Eingangs-/Ausgangsbaugruppen der PNK<br />
angeschlossen.<br />
Remote I/O (RIO) ist eine Signalanbindungsart, die die<br />
konventionelle Verdrahtung im Feld beibehält. Die<br />
Klemmkästen im Feld werden durch RIO-Einheiten ersetzt,<br />
die mit einem digitalen Bussystem an den<br />
Schaltraum angebunden sind. Dadurch verringert sich<br />
der Verdrahtungsaufwand und Platzbedarf in den Schalträumen<br />
deutlich. Nachteilig ist, <strong>das</strong>s der Platzbedarf im<br />
Feld steigt und die funktionalen Beschränkungen der<br />
konventionellen Verdrahtung bestehen bleiben.<br />
Bei der direkten Anbindung der Feldgeräte an die PNK<br />
über digitale Feldbussysteme werden die im Feldgerät<br />
digitalisierten und normierten Signale zu den PNK übertragen.<br />
J e nach Anwendungsfall kommen unterschiedliche<br />
Bussysteme zum Einsatz. Die Unterschiede äußern<br />
sich beispielsweise in der Topologie, den Datenübertragungsraten<br />
oder der maximal möglichen Kabellänge und<br />
der Anzahl der Teilnehmer pro Segment. Für den praktischen<br />
Einsatz von Feldbussystemen in verfahrenstechnischen<br />
Anlagen stellt NE 7 4 [ 5 ] Anforderungen und gibt<br />
eine Empfehlung <strong>für</strong> den hierarchischen Aufbau der<br />
Feldbussysteme (Bild 2 ): „ Ein schneller H 2 -Feldbus, der<br />
optional auch redundant sein kann, verbindet die prozessnahen<br />
Komponenten (PNK) mit H 1 -Bussegmenten.<br />
An diese sind Feldgeräte angeschlossen, welche bei Installation<br />
im Ex-Bereich zusammen mit dem H 1 -Bus explosionsgeschützt<br />
ausgeführt sind. Da die Datenübertra-<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
45
HAUPTBEITRAG<br />
gungsgeschwindigkeit eines H 1 -Busses deutlich niedriger<br />
ist (3 1 ,2 5 kbits) als die des H 2 -Busses, können je H 2 -<br />
Linie mehrere H 1 -Busse bearbeitet werden." [ 5 , S.7 ] .<br />
Typische Vertreter der H 1 -Ebene sind Profibus PA, Foundation<br />
Fieldbus H 1 , AS-Interface, DeviceNet und Profinet<br />
I/O. Vertreter der H 2 -Ebene sind Profibus DP, Foundation<br />
Fieldbus H SE und Profinet.<br />
Mit allen drei Signalanbindungsarten lässt sich Zusatzinformation<br />
übertragen. Die bidirektionale Übertragung<br />
zum Feldgerät erfolgt bei konventioneller Verdrahtung<br />
und Remote I/O mittels H ART (H ighway-Adressable-Remote-Transducer).<br />
Dies ist allerdings mit<br />
zusätzlichem Aufwand (H ART-Multiplexer oder H ARTfähige<br />
Ein/Ausgangsbaugruppen) verbunden. Die erreichbare<br />
Übertragungsgeschwindigkeit ist technologiebedingt<br />
gering – in einer Sekunde werden zwei bis<br />
drei Werte übertragen. Die digitalen Feldbusse hingegen<br />
können zyklisch mehrere Prozesssignale pro Feldgerät<br />
sowie azyklisch Zusatzinformation mit der prinzipiell<br />
gleichen Geschwindigkeit übertragen. Sie bieten darüber<br />
hinaus eine Reihe von Vorteilen gegenüber der konventionellen<br />
Verdrahtung:<br />
flexible Strukturierbarkeit<br />
schnelle und einfache Parametrierung und Diagnose<br />
Reduktion des Verkabelungsaufwands<br />
weniger Schaltschrankbedarf<br />
keine aufwendige Signalrangierung<br />
nur eine A/D-Wandlung (direkt im Feldgerät)<br />
weniger Aufwände im Leitsystem (beispielsweise<br />
keine Signalnormierung)<br />
prädiktive Instandhaltung<br />
In allen Phasen des <strong>Engineering</strong>s der Prozessleittechnik<br />
sind die Kommunikationseinrichtungen zu betrachten:<br />
beginnend bei der Erarbeitung der Konzepte, über Festlegung<br />
der zu realisierenden Technologie, Spezifikation<br />
des Leitsystems, Erstellung der EMSR-Stellen- und<br />
Montagepläne, Errichtung, Inbetriebnahme bis hin zum<br />
Betrieb der Anlage [ 6 ] .<br />
Die Abschätzung in frühen Planungsphasen und die<br />
Ausführungsplanung (Detailengineering) der konventionellen<br />
Verdrahtung sind vergleichsweise einfach. Es<br />
gibt nur wenige zu berücksichtigende Randbedingungen,<br />
wie die Beschränkung der Kabellängen durch den<br />
maximal tolerierbaren Spannungsabfall oder die Trennung<br />
von Spannungsebenen in Stammkabeln und Trassen.<br />
Die Massenbearbeitung ist durch CAE-Werkzeuge<br />
der EMSR-Technik zudem sehr gut unterstützt und<br />
kennzahlorientierte Kostenschätzungsverfahren liefern<br />
gute Ergebnisse.<br />
Bei Feldbussystemen ist die Komplexität beim <strong>Engineering</strong><br />
und im Betrieb deutlich höher, da eine Reihe<br />
von verknüpften Zwangs- und Randbedingungen, wie<br />
beispielsweise Teilnehmeranzahl pro Segment, Kabellängen<br />
und Übertragungsgeschwindigkeit, zu berücksichtigen<br />
sind. Eine Kostenschätzung in frühen <strong>Engineering</strong>phasen<br />
ist schwierig. Ferner wachsen die Erfahrungen<br />
der Ingenieure mit den existierenden Technologien<br />
nur langsam, was auch auf die Diversität der<br />
verfügbaren Systeme zurückzuführen ist [ 7 ] . H inzu<br />
kommt, <strong>das</strong>s gerade in frühen Planungsphasen keine<br />
adäquaten Unterstützungswerkzeuge <strong>für</strong> <strong>das</strong> <strong>Engineering</strong><br />
existieren. Kommerziell verfügbare Konfigurationswerkzeuge<br />
<strong>für</strong> Feldbusse, wie H W-Config [ 8 ] , <strong>das</strong><br />
ABB Layout-Werkzeug (Profibus, Foundation Fieldbus)<br />
[ 9 ] , den Pepperl+ Fuchs SegmentChecker [ 1 0 ] oder DesignMATE<br />
[ 1 1 ] , unterstützen lediglich <strong>das</strong> Zeichnen,<br />
Parametrieren und Prüfen von Feldbussen und deren<br />
Komponenten. Somit sind diese Werkzeuge erst <strong>für</strong> die<br />
Ausführung der Detailplanung verwendbar; <strong>für</strong> die<br />
Technologieauswahl, Kostenschätzung und Basisplanung<br />
eignen sie sich nicht. Der Betrachtungshorizont<br />
beschränkt sich zudem meist auf ein einziges Feldbussegment.<br />
Das bedeutet <strong>für</strong> die Massenbearbeitung einen<br />
erheblichen manuellen Zusatzaufwand. Besondere<br />
Nachteile ergeben sich jedoch aus dem engen Fokus auf<br />
die elektrischen und logischen Eigenschaften der Feldbusse.<br />
Die Werkzeuge berücksichtigen weder die funktionale<br />
und topologische Struktur einer Anlage, noch<br />
deren hierarchischen Aufbau. Eine einfache Datenintegration<br />
in die CAE-Werkzeuge der EMSR und Verfahrenstechnik<br />
wird nicht unterstützt. Zusammenfassend<br />
lässt sich sagen, <strong>das</strong>s die verfügbaren Systeme den Planer<br />
bei der technologiespezifischen Detailplanung eines<br />
kleinen Teilbereichs ausreichend unterstützen, aber bei<br />
daten<strong>integrierte</strong>n Massenbearbeitungen oder einer<br />
technologieunabhängigen Entscheidungsunterstützung<br />
unter Berücksichtigung von allgemeinen Anforderungen<br />
und Kosten nicht verwendet werden können.<br />
1.2 <strong>Engineering</strong><br />
2. NETGEN:X-ANSATZ<br />
Die wirtschaftlichen und technologischen Vorteile von<br />
Bussystemen gegenüber der konventionellen Verdrahtungstechnik<br />
hat bereits die FuRIOS-Studie verifiziert<br />
[ 1 2 ] [ 1 3 ] . Auch die Anwenderseite bestätigt entscheidende<br />
Vorteile beim Einsatz von Buslösungen [ 1 4 ] . „ H eute<br />
[ ist] die ,Beweislast‘ <strong>für</strong> die Legitimation eines Feldbusses<br />
andersherum zu definieren, <strong>das</strong> heißt es ist darzulegen,<br />
warum man keinen Feldbus einsetzen soll“ [ 2 ,<br />
S. 2 7 ] . Dennoch findet eine Verdrängung der konventionellen<br />
Verdrahtung, auch in neuen Großprojekten, nur<br />
langsam statt. Als größtes H emmnis wurde die fehlende<br />
Unterstützung im <strong>Engineering</strong>, speziell in den frühen<br />
Planungsphasen, herausgestellt. In [ 1 5 ] wird ein<br />
erster Ansatz beschrieben, der auf Basis eines Mengengerüsts<br />
der EMSR-Technik, der topologischen Vorgaben<br />
der Anlage und der Randbedingungen von Feldbustechnologien<br />
ein Mengengerüst der Kommunikationseinrichtungen<br />
erzeugt. NetGen: X erweitert diesen Ansatz<br />
zu einem interaktiven System mit Entscheidungs- und<br />
Planungsunterstützung <strong>für</strong> industrielle Kommunikationsnetzwerke<br />
in prozesstechnischen Anlagen.<br />
Die automatische Erzeugung und Analyse von Kommunikationsnetzen<br />
und die Anwendung graphenbasierter<br />
Lösungsmuster wird in der Wissenschaft bereits<br />
über 2 0 J ahre behandelt [ 1 6 ] [ 1 7 ] . NetGen: X überführt<br />
46<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
die theoretischen H erangehensweisen in einen <strong>integrierte</strong>n<br />
<strong>Engineering</strong>systemansatz, der sich <strong>für</strong> Technologieauswahl,<br />
Kostenschätzung und Basisplanung<br />
einsetzen lässt.<br />
2.1 Allgemeiner Systemaufbau<br />
Der Systemaufbau von NetGen: X (Bild 3 ) orientiert<br />
sich an dem in NAfl1 1 4 [ 1 8 ] beschriebenen Vorgehensmodell<br />
zur Planung von Feldbussystemen. Die darin<br />
erläuterten Arbeitsschritte lassen sich wie folgt auf die<br />
Komponenten und Schnittstellen der Softwarearchitektur<br />
abbilden:<br />
Ermittlung des EMSR-Mengengerüsts – Extraktion<br />
des Mengengerüsts der Instrumentierung aus den<br />
CAE-Systemen und Import in die NetGen: X -Umgebung<br />
Extraktion der feldbusrelevanten Geräte – Filterung<br />
und Strukturierung der Eingangsdaten nach Anforderung<br />
des Nutzers<br />
Festlegung der Bustechnologie und Festlegung der<br />
Segmentanbindung – Vorschlag durch ein Entscheidungsunterstützungssystem<br />
anhand funktionaler und<br />
nicht-funktionaler Anforderungen an die Kommunikation<br />
beziehungsweise Vorgabe von konkreten Kommunikationstechnologien<br />
<strong>für</strong> die Ebenen H 1 und H 2 .<br />
Ermittlung der Anbindungskomponenten – Erzeugung<br />
und Optimierung der Kommunikationsstrukturen<br />
auf den Ebenen H 1 und H 2 im Network-Layout-<br />
Designer<br />
Entwicklung des elektrischen Layouts – Export des<br />
Mengengerüsts der Kommunikationseinrichtungen<br />
und der Verbindungsinformationen<br />
Aus dem Mengengerüst der Instrumentierung wird zunächst<br />
durch die Anforderungen des Nutzers und die<br />
Process Communication Fact Base (PCFB) ein angereichertes<br />
und strukturiertes EMSR-Mengengerüst erzeugt,<br />
<strong>das</strong>s in einer Instrumentation-Data-Base abgelegt<br />
wird. Die darin abgelegte Information wird über <strong>das</strong><br />
Instrumentation Data Base Interface (IDBI) von dem<br />
Network Layout Designer ausgelesen. Dieser erzeugt<br />
eine mathematische, graphen-theoretische Abstraktion<br />
der angeforderten Kommunikationsbeziehungen und<br />
entwirft eine Netzwerktopologie, die die in der PCFB<br />
<strong>für</strong> die Zieltechnologie abgelegten Randbedingungen<br />
erfüllt. Ergebnisse dieses Entwurfsschritts sind derzeit<br />
vor allem quantitative Daten wie Mengengerüst, Kosten<br />
und Verbindungsinformation, aber auch qualitative<br />
Aussagen wie Reserven oder Robustheit.<br />
2.2 Verwendete Planungsdaten<br />
NetGen: X setzt voraus, <strong>das</strong>s <strong>das</strong> EMSR-Mengengerüst<br />
bereits bekannt ist. Der Import erfolgt über eine X ML-<br />
Datei, die aus der Datenbasis des CAE-Werkzeugs <strong>für</strong><br />
die Instrumentierung erzeugt wird. Die prozesstechnischen<br />
Anforderungen an Feldgeräte müssen dabei<br />
in eine technologische H ierarchie nach DINflENfl6 1 5 1 2 -<br />
1 [ 1 9 ] eingeordnet und den Einzelsteuereinheiten zugeordnet<br />
sein (Bild 4 ). Um bereits frühe Planungsphasen<br />
zu unterstützen, ist der Umfang der beschreibenden<br />
Information pro Gerät bewusst klein gehalten:<br />
Benötigt werden die Art der Signalanbindung (Analog/<br />
Digital, Eingang/Ausgang), der Instrumententyp (Temperaturtransmitter,<br />
Regelventil), die Art der PNK und<br />
räumliche Information. Da letztere in frühen Planungsphasen<br />
noch nicht genau definiert ist, kann <strong>das</strong><br />
System je nach Planungsfortschritt unterschiedliche<br />
Detailierungsgrade verarbeiten:<br />
Typ 1 (Vorplanung) – Feldgeräte sind einem Baufeld<br />
zugeordnet,<br />
Typ 2 (Basisplanung) – Feldgeräte sind einen Planquadrat<br />
und einer H öhenebene zugeordnet<br />
Typ 3 (Ausführungsplanung) – Feldgeräte besitzen<br />
konkrete Koordinaten (X ,Y ,Z)<br />
Schaltraum PNK<br />
E/ABaugruppe<br />
Feld<br />
ABK<br />
Rangierverteiler<br />
Feldverteiler<br />
Feldgerät<br />
PNK<br />
Klassisch Remote I/O Feldbus<br />
Kanal<br />
1 2 3 4<br />
Buskarte<br />
Feldbuskarte<br />
1 2 3 4<br />
1 2 3 4 1 2 3 4 1 2 3 4<br />
BILD 1: Anbindungsarten von Feldsignalen an<br />
prozessnahe Komponente Prozess- beziehungsweise<br />
Sicherheitssystem [2, S.27]<br />
HE HE HE<br />
K<br />
K<br />
FG<br />
FG<br />
FG<br />
FG<br />
FG<br />
FG =Feldgeräterät<br />
ABK =Anzeige- und Bedienkomponente<br />
PNK =Proz<br />
essnahe Komponente<br />
FG<br />
FG<br />
FG<br />
PLS Bus<br />
H2 Bus optional<br />
redundant<br />
H1 Bus<br />
Segmente<br />
PLS =Proz<br />
essleitsystem<br />
H1 =Feldbus im EX-Berei<br />
ch<br />
H2 =Feldbus schnell<br />
K<br />
FG<br />
FG<br />
IK<br />
FG<br />
FG<br />
PNK<br />
IK =Ingenieurkonsole<br />
HE =Hilfsenergiergi<br />
e<br />
K = Segmentkoppler<br />
BILD 2: Hierarchischer Aufbau eines Feldbussystems H1- und<br />
H2-Bus (leicht veränderte Darstellung aus [5, S. 13])<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
47
HAUPTBEITRAG<br />
Für Typ 1 und 2 werden <strong>für</strong> die späteren Berechnungen<br />
konkrete Koordinaten auf Basis von Verteilungsfunktionen<br />
errechnet. Für ein spezifisches Feldgerät wird eine<br />
definierte Koordinate bestimmt, die dem späteren tatsächlichen<br />
Einbauort nicht entspricht. Für <strong>das</strong> einzelne<br />
Feldgerät führt dies bei Kabellängen und Kosten zu erheblichen<br />
Fehlern. Da die Fehler jedoch nicht gerichtet<br />
sind, ist davon auszugehen, <strong>das</strong>s diese sich bei einer<br />
großen Menge an Feldgeräten gegenseitig aufheben.<br />
Die PCFB ist ein strukturierter Fakten- und Regelspeicher,<br />
der Aussagen zu den Eigenschaften von Kommunikationsstrukturarten<br />
enthält. Er ist erweiterbar<br />
ausgelegt und eingeteilt in Technologie der Ebenen H 1<br />
und H 2 . Er enthält wesentliche Strukturinformationen,<br />
die <strong>für</strong> eine Auswahl, eine Entscheidungsunterstützung<br />
und den Network-Layout-Designer relevant<br />
sind, wie mögliche Topologien, maximale Teilnehmeranzahl,<br />
Segmentlängen oder Buszugriffsverfahren.<br />
BILD 3:<br />
Allgemeiner Systemaufbau<br />
von NetGen:X<br />
Input<br />
Integration der automatisch erzeugten<br />
Kommunikationsstrukturen<br />
Output<br />
CAE – System<br />
Datenbank<br />
¢ Mengengerüst M e n g e n g e der d e r<br />
Instrumentierung<br />
I n m e n tie n g<br />
¢ 3D 3 D Layout y o u t I nformationenn a n e n<br />
Filter und<br />
Strukturierung<br />
¢ Entscheid ungsunterstützung<br />
¢ Festlegung von<br />
Verdrahtungsspezifikationen<br />
NetGen:X Umgeb ung<br />
Instrumentation<br />
Data Base<br />
Interface (IDBI):<br />
angereichertes<br />
und strukturiertes<br />
Mengengerüst der<br />
Instrumentierung<br />
Netw ork<br />
Layout<br />
Designer<br />
¢ Erzeugung und<br />
Optimierung der<br />
Kommunikationsstrukturen<br />
Quantity<br />
¢ Mengengerüst des<br />
Kommunikationsequipments<br />
¢ Verbind ungsinformationen<br />
¢ Kosteninformationen<br />
Enterprise<br />
Proce ss<br />
Communication<br />
Fact Base (PCFB)<br />
¢ generisch g e n e strukturierter<br />
k tu rie rter<br />
Speicher e e r der d e r Eigenschaften e n a von v o n<br />
Kommunikationsstrukturen<br />
m m u n a n k tu re n<br />
¢ Kla ssifikation a n in System- - und u n d<br />
Feldkommunikation<br />
k o m m u n a n<br />
Fact Base I nterface (FBI ): Schnittstelle zur<br />
Bereitstellung der Strukturinformationen der<br />
Kommunikationstechnologien (Eigenschaften,<br />
Randbedingungen, ...)<br />
Quality<br />
¢ Zuverlä ssigkeitsaussagen<br />
¢ Füllgrade und<br />
Auslastung<br />
Site<br />
Area<br />
CommunicationBlock<br />
1 1<br />
CentralPoint<br />
1<br />
Process Cell<br />
1..*<br />
SystemBlock<br />
+Paren<br />
t:CommunicationBlock<br />
1<br />
Unit<br />
1..*<br />
FieldBlock<br />
+Paren<br />
t:SystemBlock<br />
BILD 5: Aufbau des<br />
Instrumentation Data Base<br />
Interface [20, Bild 3]<br />
1<br />
Equipment<br />
Modul<br />
Control<br />
Modul<br />
BILD 4: Physikalisches<br />
Modell einer Prozessanlage<br />
nach DIN EN 61512 [19, S. 8]<br />
1..*<br />
FieldDeviceList<br />
+Paren<br />
t:FieldBlock<br />
1<br />
1..*<br />
FieldDevice<br />
+ID<br />
+Position<br />
+SignalType<br />
+Name<br />
+FunctionID<br />
+...<br />
48<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
H<br />
2.3 NetGen:X-Umgebung<br />
Filterung und Strukturierung<br />
Die erste der beiden Kernkomponenten der NetGen: X -<br />
Umgebung dient der Anpassung und Anreicherung des<br />
importierten EMSR-Mengengerüsts zur optimalen Initialisierung<br />
der Netzwerk-Layout-Design-Komponente,<br />
Sie ermöglicht es dem Nutzer, Anforderungen an die<br />
Kommunikationsstruktur einfließen zu lassen. Diese<br />
Filterungs- und Strukturierungskomponente bietet unter<br />
anderem folgende Möglichkeiten:<br />
Filterung und Gruppierung der Eingangsdaten auf<br />
allen Ebenen der technologischen H ierarchie nach<br />
DIN EN 6 1 5 1 2 -1 [ 1 9 ]<br />
Festlegung ebenenspezifischer und ebenenübergreifender<br />
Kriterien beziehungsweise Zwangsbedingungen<br />
<strong>für</strong> die Verdrahtungsstruktur (zum<br />
Beispiel getrennte Verdrahtung aller Signale unterschiedlicher<br />
Teilanlagen, Trennung von digitalen<br />
und analogen Signalen, Trennung redundanter<br />
Signale, Anzahl der Stichleitungen pro Verteilerkomponente)<br />
Definition einzuhaltender Reserven<br />
Integration von Kostenmodellen <strong>für</strong> Kabel und Kommunikationskomponenten<br />
Weiterhin ist vom Nutzer zu spezifizieren, wie welche<br />
Art von Instrumenten beziehungsweise Gruppe von<br />
Instrumenten jeweils auf H 1 - und H 2 -Ebene angebunden<br />
werden (zum Beispiel konventionell, Profibus DP/<br />
PA, Foundation Fieldbus). Die Festlegung kann manuell<br />
erfolgen. Dies würde dem Szenario entsprechen, <strong>das</strong>s<br />
der Nutzer bereits eine spezifische Kommunikationstechnologie<br />
vorgeben möchte, weil diese Technologie<br />
vorgegeben ist oder verschiedene Technologien gezielt<br />
verglichen werden sollen.<br />
Eine weitere Möglichkeit stellt die Verwendung des<br />
Entscheidungsunterstützungssystems dar. Dabei kann<br />
der Nutzer seine Anforderungen an die Kommunikation<br />
in Dialogform formulieren und erhält vom Unterstützungssystem,<br />
<strong>das</strong> dabei auf die PCFB zurückgreift, Vorschläge,<br />
welche Kommunikationsstrukturarten sich <strong>für</strong><br />
seine Anforderungen und <strong>das</strong> vorliegende Mengengerüst<br />
der Instrumentierung am besten eignen. Dies würde dem<br />
Szenario entsprechen, <strong>das</strong>s der Nutzer keine Vorgabe <strong>für</strong><br />
eine spezifische Kommunikationslösung machen möchte<br />
beziehungsweise kann, aber dennoch eine automatisch<br />
erzeugte Kommunikationsstruktur <strong>für</strong> die optimal<br />
geeignete Technologie erhalten möchte.<br />
Aufbauend auf den Festlegungen in dieser Komponente<br />
wird <strong>das</strong> IDBI erzeugt, welches <strong>das</strong> angereicherte und<br />
strukturierte EMSR-Mengengerüst darstellt. Bild 5 zeigt<br />
den hierarchischen Aufbau des IDBI, <strong>das</strong> in [ 2 0 ] detaillierter<br />
beschrieben wird.<br />
Network-Layout-Designer<br />
Die zweite Kernkomponente erzeugt auf Basis des IDBI<br />
ein Kommunikationsnetzwerk, welches den Anforderungen<br />
des Planers und den Restriktionen der verschiedenen<br />
Kommunikationssysteme genügt. Die H auptaufgabe ist<br />
dabei die Ermittlung von Anbindungskomponenten<br />
(NAfl1 1 4 [ 1 8 ] ). Der Network Layout Designer verfolgt bei<br />
dieser Ermittlung vier Grundkonzepte [ 2 0 ] :<br />
H 1 H 2<br />
4 [ 5 ]<br />
H 1 H 2 1 2<br />
H 1<br />
1 | Unterteilung der Netzwerkplanung in - und -<br />
Ebene gemäß NE7<br />
2 | Definition der zentralen Anschlussmöglichkeiten<br />
der Kommunikationstechnik an die PNK<br />
3 | Segmentkoppler stellen die Verbindung zwischen<br />
den -Bussegmenten und dem -Bus (H -H -<br />
Gateways) dar<br />
4 | Auf -Ebene werden Feldbarrieren als Signalverteiler<br />
genutzt<br />
Der Designer kalkuliert Ergebnisse mithilfe eines abstrakten<br />
Datenmodells, welches <strong>das</strong> Kommunikationsnetzwerk<br />
als Graph aus Knoten und Kanten beschreibt;<br />
Knoten repräsentieren Geräte und Kanten Verbindungen<br />
der Signalübertragung. Auf Basis dieser Abstraktion<br />
können Algorithmen verwendet werden, die aus der<br />
Graphentheorie allgemein bekannt und erprobt sind.<br />
Unter anderem werden Clustering-Verfahren [ 2 1 ] und<br />
Algorithmen <strong>für</strong> <strong>das</strong> Problem des H andlungsreisenden<br />
(Traveling-Salesman-Problem, TSP) eingesetzt. Letztere<br />
lassen sich bei kleinen Netzwerken durch Brute-Force-<br />
Methoden [ 2 2 ] lösen, bei größeren Netzwerken werden<br />
genetische Algorithmen [ 2 3 ] zur Suche nach einer approximierten<br />
Lösung genutzt. Der Algorithmus arbeitet<br />
Bottom-Up von H 1 - zu H 2 -Ebene eine feste Sequenz von<br />
Schritten ab, die im Folgenden am Beispiel Profibus PA/<br />
DP illustriert ist.<br />
H1-Layout:<br />
Begonnen wird mit einem Clustering-Verfahren, <strong>das</strong> Feldgeräte<br />
zu Feldbarrieren zuordnet, welche <strong>für</strong> Profibus-PA-<br />
Netzwerke bevorzugt zu verwenden sind [ 2 4 ] . Anschließend<br />
werden die einzelnen Feldbarrieren an die H 1 -Bussegmente<br />
angeschlossen. Dies erfolgt durch die Lösung<br />
des TSP und eine anschließende Segmentierung. Dabei<br />
werden die Restriktionen des Bussystems berücksichtigt.<br />
Im Anschluss werden <strong>für</strong> die entstandenen Segmente<br />
Segmentkoppler erzeugt, welche nahe der zentralen<br />
Punkte zu installieren sind, um die H 2 -Bus-Verkabelung<br />
zu reduzieren.<br />
H2-Layout:<br />
Aufgabe des H 2 -Busses ist es, die einzelnen Segmente einzusammeln.<br />
Dies geschieht durch <strong>das</strong> Lösen des TSP zwischen<br />
dem Segmentkoppler und gegebenenfalls weiteren<br />
2 -Geräten im selben Systemblock. Anschließend erfolgt<br />
eine Segmentierung auf H 2 -Ebene, welche ebenfalls die<br />
Kriterien <strong>für</strong> <strong>das</strong> H 2 -Bussystem erfüllen muss. Eine Anbindung<br />
der H 2 -Busse an die Kommunikations-Ports der<br />
PNKs erfolgt direkt, wenn es die Restriktionen zulassen,<br />
oder unter Verwendung von Signalauffrischern (Repeater).<br />
2.4 Ergebnisse<br />
Die erzeugten Strukturen und Ergebnisse lassen sich<br />
innerhalb der NetGen: X -Umgebung betrachten, wie<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
49
HAUPTBEITRAG<br />
beispielhaft in Bild 6 zu sehen. Um den integrativen<br />
Charakter des Werkzeugs auch auf der Ergebnisseite<br />
zu gewährleisten, sind diese in verschiedene Formate<br />
exportierbar. Die Ergebnisse lassen sich in einen quantitativen<br />
und einen qualitativen Bereich diskutieren.<br />
Quantität<br />
Es werden Mengengerüste <strong>für</strong> die benötigten Netzwerkkomponenten<br />
und Kabel erzeugt, mit denen es möglich<br />
ist, ein erstes MTO (Material Take-Off) und eine erste<br />
Kostenaufstellung zu bilden. Weiterhin werden die<br />
Segmentinformationen der entstehenden Bussegmente,<br />
wie Teilnehmeranzahl, Stichleitungslänge, Segmentausdehnung<br />
erzeugt. Diese Verbindungsinformationen<br />
lassen sich auslesen und zur Rückführung von Verdrahtungsinformationen<br />
in die CAE-Werkzeuge der<br />
Instrumentierung nutzen. Ein Export der Verbindungsinformationen<br />
in <strong>das</strong> GML-Format ist realisiert und<br />
ermöglicht die Darstellung der automatisch generierten<br />
Verbindung in Grapheneditoren (GML – Geography-<br />
Markup-Language: X ML-Dialekt <strong>für</strong> Geodaten). Bild 7<br />
präsentiert <strong>das</strong> Beispiel aus Bild 6 im Grapheneditor<br />
yEd [ 2 5 ] . Die räumlichen Informationen rücken bei der<br />
Anpassung der Darstellung im Editor in den H intergrund,<br />
da<strong>für</strong> wird eine übersichtliche Darstellung der<br />
automatisch erzeugten Kommunikationsstruktur leicht<br />
ersichtlich.<br />
Qualität<br />
Neben quantitativen Informationen muss ein solches<br />
Unterstützungs- und Planungssystem zur automatischen<br />
Generierung von Strukturen auch Auskunft über die erzeugte<br />
Qualität liefern. Durch diese Qualitätsinformationen<br />
können Rückschlüsse auf die Funktionsfähigkeit<br />
des Systems per se und auf die getroffenen Angaben und<br />
Annahmen in der Komponente „ Filterung und Strukturierung“<br />
getroffen werden. Neben Füll- beziehungsweise<br />
Nutzungsgrad der Netzwerkkomponenten soll <strong>das</strong> System<br />
in Zukunft auch Zuverlässigkeitsaussagen über die<br />
Netzwerkstruktur herausgeben, um Schwachstellen oder<br />
Engpässe zu detektieren und Informationen über Buszykluszeiten<br />
liefern.<br />
BILD 6: Screenshot der NetGen:X-Realisierung – Beispielanlage<br />
mit festgelegten Koordinaten (Detail: Network-Layout-Designer)<br />
BILD 8: Screenshot der NetGen:X-Realisierung - Beispielanlage<br />
mit zufälligen Koordinaten (Detail: Network-Layout-Designer)<br />
BILD 7: Darstellung des GML-Exports der<br />
Beispielanlage von Bild 6 mittels des Grapheneditors<br />
„yEd“ (reduzierte Darstellung)<br />
BILD 9: Darstellung des GML-Exports der<br />
Beispielanlage von Bild 8 mittels des<br />
Grapheneditors „yEd“ (reduzierte Darstellung)<br />
50<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
3. VERIFIKATION<br />
Zur Überprüfung der Machbarkeit und Plausibilität der<br />
gesamten Umgebung wurden Testfälle mit künstlich<br />
erzeugten Anlagenmengengerüsten und Topologien erzeugt.<br />
Die Bilder 6 bis 9 zeigen zwei Testfälle mit jeweils<br />
2 0 0 Feldgeräten und unterschiedlicher Signalanbindungsart,<br />
die alle zu einem zentralen Punkt<br />
(Schaltraum) verbunden werden. Die beiden Testfälle<br />
unterscheiden sich lediglich in der topologischen Anordnung<br />
der Feldgeräte.<br />
Testfall 1 (Bild 6 ) dient vor allem der übersichtlichen<br />
Darstellung der Ergebnisse. Die Feldgeräte befinden sich<br />
in acht Baufeldern an fest definierten Koordinaten. Der<br />
Ausdehnungsbereich der Anlage beträgt etwa 5 0 0 m²<br />
und alle Elemente sind auf der gleichen Anlagenebene<br />
installiert. Diese einfache und überschaubare räumliche<br />
Anordnung der Geräte erlaubt den Vergleich von<br />
manuellen und automatischen Netzwerklayouts,<br />
Testfall 2 (Bild 8 ) liegt eine zufällige Verteilung der<br />
gleichen Anzahl und Art von Feldgeräten auf der<br />
gleichen Fläche wie in Testfall 1 zugrunde. Die<br />
kleinen Rechtecke auf den Bildern stellen die Feldgeräte<br />
dar und deren Farbe die Art der Kommunikationsanbindung<br />
(blau – Profibus PA; schwarz – konventionelle<br />
Verdrahtung). Die größeren Rechtecke<br />
stehen <strong>für</strong> Kommunikationsstrukturelemente, wie<br />
Feldbarrieren (hellblau), Segmentkoppler (magenta)<br />
und konventionelle Anschlusskästen (grau). Auf<br />
der linken Seite des Network-Layout-Designers werden<br />
<strong>das</strong> benötigte Kommunikationsequipment sowie<br />
Kabel angezeigt.<br />
Die erfolgreiche Bearbeitung der Testfälle ergab, <strong>das</strong>s<br />
die NetGen: X -Umgebung <strong>für</strong> ein vorgegebenes strukturiertes<br />
Mengengerüst der Instrumentierung automatisch<br />
eine Kommunikationsstruktur unter Berücksichtigung<br />
der Randbedingungen der Kommunikationstechnologien<br />
und unter Berücksichtigung der Spezifikationen<br />
des Nutzers erzeugt. Zur Verdeutlichung der<br />
Ergebnisse sei auf Bild 7 und Bild 9 hingewiesen, die<br />
den GML-Export beider Testfälle im Grapheneditor yEd<br />
[ 2 5 ] zeigen.<br />
REFERENZEN<br />
[1] H ollender, M.: Collaborative Process Automation Systems.<br />
ISA, 2009<br />
[2] Kiupel, N.: Planung, Montage, Inbetriebnahme und Betrieb von<br />
Foundation Fieldbus-Installationen. <strong>atp</strong> - Automatisierungstechnische<br />
Praxis 50(5), S. 26-33, 2008<br />
[3] NE06 - Elektrische Einheitssignale und Fragen der Gerätetechnik.<br />
Namur.<br />
[4] DIN IEC 60381: Analoge Signale <strong>für</strong> Regel- und Steueranlagen.<br />
Namur.<br />
[5] NE74 - NAMUR-Anforderungen an einen Feldbus. Namur.<br />
[6] NA35 - Abwicklung von PLT-Projekten. Namur.<br />
[7] H MS Industrial Networks, (Feb. 2012), Variantenvielfalt bei<br />
Kommunikationssystemen [Online]<br />
- http://www.feldbusse.de/Trends/trends.shtml<br />
[8] Siemens, (Feb. 2012), HW Config SIMATIC S7 [Online]<br />
- http://www.automation.siemens.com/mcms/industrial-controls/de/industrielle-kommunikation/as-interface_alt/diagnose/<br />
hw-konfig/Seiten/default.aspx<br />
[9] ABB, (Feb. 2012), DTE100 und DTD100 [Online]<br />
- www.abb.com/product/ge/9AAC100304.aspx<br />
[10] P epperl + Fuchs, (Feb. 2012), SegmentChecker [Online]<br />
- http://www.segmentchecker.com<br />
[11] Fieldbus Foundation, (Feb. 2012), DesignMATE [Online]<br />
- http://www.fieldbus.org/index.php?option=com_content&task=<br />
view&id=866&Itemid=281<br />
[12] Schmieder, W., Tauchitz, T., Seintsch, S.: FuRIOS: Feldbus<br />
und Remote I/O – ein Systemvergleich. <strong>atp</strong> - Automatisierungstechnische<br />
Praxis 44(12), S. 61-70, 2002<br />
[13] Kasten, T.: Die Anwendbarkeit der FuRIOS Studie. <strong>atp</strong> -<br />
Automatisierungstechnische Praxis 45(3), S. 51-54, 2003<br />
[14] O‘Brien, L.: Best Practices for Fieldbus & HART Project<br />
Implementation & Lifecycle Benefits Realization,<br />
ARC Forum 2008, Presentation [Online]<br />
- http://www.arcweb.com/events/arcforum-presentations/<br />
orlando-forum-2008-presentations/ARC%20Speaker%20<br />
Presentations/LOBrien-ARC.pdf<br />
[15] Doherr, F., Schmidt, T., Urbas, L.: Fieldbus material take-off<br />
estimation: Towards an automated cost estimation of fieldbus<br />
installations. In: Proceedings 2010 IEEE International Workshop<br />
on Factory Communication Systems, S. 165–168. IEEE, 2010<br />
[16] Tanaka, Y, Akiyama, M., Wallström, B.: A systematic design<br />
method of highly reliable communication networks by the use of<br />
graph theory. In: Proceedings of the 12th International Teletraffic<br />
Congress (ITC 12), S. 4.2B.5.1 - 4.2B.5.7, 1988<br />
[17] Dengiz, B., Altiparmak, F., Belgin, O.: Design of reliable communication<br />
networks: A hybrid ant colony optimization algorithm, IIE<br />
Transactions 42 (4), S.273-287, 2010<br />
[18] NA114 - Best Practice Feldbusanwendungen Auswahl, Planung,<br />
Montage, Inbetriebnahme und Betrieb von Feldbussen<br />
[19] DIN EN 61512-1 - Chargenorientierte Fahrweise Teil 1: Modelle<br />
und Terminologie<br />
[20] Stöß, M., Doherr, F., Urbas, L.: Automated network layout for the<br />
industrial communication engineering system NetGen:X. In:<br />
Tagungsband IEEE WFCS2012, angenommen, 2012.<br />
[21] B ackhaus, K., Erichson, B., Plinke, W., Weiber, R.: Multivariate<br />
Analysemethoden: Eine anwendungsorientierte Einführung,<br />
Springer:Berlin, 2011<br />
[22] Cormen, Th.H., Leiserson, Ch.E., Rivest, R., Stein, C.:<br />
Algorithmen - eine Einführung, Oldenbourg, München, 2010<br />
[23] P etz, J.: Softcomputing in der Bioinformatik, Springer:<br />
Berlin, 2006<br />
[24] Diedrich, C., Bangemann, T.: Profibus PA – Instrumentierungstechnologie<br />
<strong>für</strong> die Verfahrenstechnik. Oldenbourg:<br />
München, 2006<br />
[25] yWorks GmbH [Online] - http://www.yworks.com<br />
[26] Niemann, K.-H.: Verfügbarkeitsberechnung von Automatisierungsnetzwerken.<br />
Teil 2: Topologien und Designempfehlungen. <strong>atp</strong><br />
<strong>edition</strong> - Automatisierungstechnische Praxis 53 (11), S. 58-65, 2011.<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
51
H<br />
HAUPTBEITRAG<br />
FAZIT<br />
Mit NetGen: X wurde ein Forschungsansatz und eine erste<br />
Realisierung eines <strong>integrierte</strong>n und interaktiven <strong>Engineering</strong>systems<br />
vorgestellt, <strong>das</strong> <strong>für</strong> ein gegebenes EMSR-<br />
Mengengerüst eine Kommunikationsstruktur mit den<br />
dazu benötigten Geräten und Verbindungen automatisch<br />
erzeugen kann. Dazu integriert es die Daten unterschiedlicher<br />
Gewerke. Ein Planer kann seine Strukturierungsvorgaben<br />
gezielt einfließen lassen, die Massenbearbeitung<br />
und die Einhaltung der komplexen Spezifikationen der<br />
Kommunikationstechnologien erledigt der Rechner.<br />
NetGen: X unterstützt sowohl bei der ersten Auslegung<br />
der Kommunikation, die in den meisten Fällen auf eine<br />
erste Kostenschätzung zielt, aber auch bei einem möglichen<br />
Entscheidungsfindungsprozess. In der vorgestellten<br />
Entwicklungsstufe kann konventionelle Verdrahtung mit<br />
Profibus DP auf der H 2 -Ebene und Profibus PA auf der<br />
H 1 -Ebene verglichen werden.<br />
An zwei Testfällen wurden die prinzipielle Machbarkeit,<br />
die Bedienbarkeit des Systems, die Passung zu bestehenden<br />
<strong>Engineering</strong>workflows und der praktische Nutzen<br />
AUTOREN<br />
überprüft. Die Diskussion der Ergebnisse mit erfahrenen<br />
Anwendern zeigt, <strong>das</strong>s <strong>für</strong> den Übergang von einem Forschungsdemonstrator<br />
in ein praxistaugliches Werkzeug<br />
noch einige Weiterentwicklungen notwendig sind:<br />
Berücksichtigung weiterer Kommunikationstechnologien<br />
in der Faktenbasis<br />
Validierung der Entwurfsqualität mit realen Anlagen<br />
Berücksichtigung einer vorhandenen Trassenplanung<br />
beziehungsweise Vorschlag <strong>für</strong> Trassenverläufe<br />
Erweiterung der 2 D-Darstellung des Network-Layout-<br />
Designers zu einer interaktiven 3 D-Visualisierung<br />
Re-Import der Verbindungsinformationen in die<br />
CAE-Systeme der Instrumentierung<br />
Intensiver Forschungsbedarf besteht bei der Berücksichtigung<br />
von Aspekten der funktionalen Sicherheit <strong>für</strong> den<br />
Entwurf von Netzwerkstrukturen. Eine mögliche Erweiterung<br />
wäre die Integration der von Niemann [ 2 6 ] vorgestellten<br />
Berechnungsverfahren und Designempfehlungen.<br />
MANUSKRIPTEINGANG<br />
10.02.2012<br />
Im Peer-Review-Verfahren begutachtet<br />
Dipl.-Ing. FALK DOHERR (geb. 1 9 8 1 ) ist<br />
wissenschaftlicher Mitarbeiter und Leiter<br />
der Arbeitsgruppe Funktions- und Informationsintegration<br />
an der Professur <strong>für</strong><br />
Prozessleittechnik an der Technischen<br />
Universität Dresden und Projektingenieur<br />
bei der Linde <strong>Engineering</strong> Dresden GmbH .<br />
Sein wissenschaftliches H auptarbeitsgebiet<br />
ist <strong>das</strong> <strong>integrierte</strong> prozessleittechnische<br />
<strong>Engineering</strong> mit Fokus feldnaher Kommunikationssysteme.<br />
TU Dresden,<br />
Fak. Elektrotechnik und Informationstechnik,<br />
Georg-Schumann-Str. 11, D-01187 Dresden,<br />
Tel. +49 (0) 351 46 33 21 62,<br />
E-Mail: falk.doherr@tu-dresden.de<br />
Dipl.-Ing. MARKUS STÖSS (geb. 1 9 8 3 ) ist<br />
wissenschaftlicher Mitarbeiter an der<br />
Professur <strong>für</strong> Prozessleittechnik. Seine<br />
auptarbeitsgebiete sind die formale<br />
Modellierung und Unterstützungssysteme<br />
<strong>für</strong> <strong>das</strong> H MI-<strong>Engineering</strong> und Operator-<br />
Training-Systeme.<br />
Prof. Dr.-Ing.<br />
LEON URBAS<br />
(geb. 1 9 6 5 ) ist Inhaber<br />
der Professur <strong>für</strong><br />
Prozessleittechnik<br />
an der Technischen<br />
Universität Dresden.<br />
Seine H auptarbeitsgebiete<br />
umfassen<br />
<strong>Engineering</strong> verteilter sicherheitskritischer<br />
Systeme, insbesondere Funktionsintegration,<br />
modellgetriebenes<br />
<strong>Engineering</strong>, Modularisierung, Informationmodelle<br />
der Prozessindustrie,<br />
Prozessinformations- und Managementsysteme<br />
und Middleware in der<br />
Automatisierungstechnik. Gebrauchstauglichkeit<br />
von multimodalen und<br />
mobilen Nahtstellen in Automatisierungssystemen,<br />
Analyse, Gestaltung<br />
und Bewertung von Alarmierungs- und<br />
Unterstützungssysteme sowie Methoden<br />
der Benutzermodellierung zur<br />
prospektiven Gestaltung von Mensch-<br />
Technik-Interaktion.<br />
TU Dresden,<br />
Fak. Elektrotechnik und Informationstechnik,<br />
Georg-Schumann-Str. 11, D-01187 Dresden,<br />
Tel. +49 (0) 351 46 33 52 21,<br />
E-Mail: markus.stoess@tu-dresden.de<br />
TU Dresden,<br />
Fak. Elektrotechnik und Informationstechnik,<br />
Georg-Schumann-Str. 11, D-01187 Dresden,<br />
Tel. +49 (0) 351 46 33 96 14,<br />
E-Mail: leon.urbas@tu-dresden.de<br />
52<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
Jetzt<br />
doppelt sparen:<br />
Edition<br />
15% Rabatt<br />
gwf Praxiswissen<br />
im Fortsetzungsbezug<br />
20% Rabatt<br />
<strong>für</strong> gwf-Abonnenten<br />
Diese Buchreihe präsentiert kompakt aufbereitete Fokusthemen aus der Wasserbranche und Fachberichte<br />
von anerkannten Experten zum aktuellen Stand der Technik. Zahlreiche Praxisbeispiele zeigen individuelle<br />
Lösungen und vermitteln praktisches Know-how <strong>für</strong> ökologisch und wirtschaftlich sinnvolle Konzepte.<br />
Band I – Regenwasserbewirtschaftung<br />
Ausführliche Informationen <strong>für</strong> die Planung und Ausführung von Anlagen zur Regenwasserbwirtschaftung<br />
mit gesetzlichen Rahmenbedingungen sowie Anwendungsbeispielen aus der Praxis.<br />
Hrsg. C. Ziegler, 1. Auflage 2011, 184 Seiten, Broschur<br />
Buch + Bonusmaterial <strong>für</strong> € 54,90 € 46,70<br />
Buch + Bonusmaterial + eBook auf DVD <strong>für</strong> € 69,90 € 59,40<br />
Band II – Messen • Steuern • Regeln<br />
Grundlageninformationen über Automatisierungstechnologien, die dabei helfen, Wasser effizienter<br />
zu nutzen, Abwasser nachhaltiger zu behandeln und Sicherheitsrisiken besser zu kontrollieren.<br />
Hrsg. C. Ziegler, 1. Auflage 2011, ca. 150 Seiten, Broschur<br />
Buch + Bonusmaterial <strong>für</strong> € 54,90 € 46,70<br />
Buch + Bonusmaterial + eBook auf DVD <strong>für</strong> € 69,90 € 59,40<br />
Band III – Energie aus Abwasser<br />
Abwärme aus dem Kanal und Strom aus der Kläranlage: Wie aus großen Energieverbrauchern<br />
Energieerzeuger werden. Methoden und Technologien zur nachhaltigen Abwasserbehandlung.<br />
Hrsg. C. Ziegler, 1. Auflage 2011, ca. 150 Seiten, Broschur<br />
Buch + Bonusmaterial <strong>für</strong> € 54,90 € 46,70<br />
Buch + Bonusmaterial + eBook auf DVD <strong>für</strong> € 69,90 € 59,40<br />
Band IV – Trinkwasserbehälter<br />
Grundlagen zu Planung, Bauausführung, Instandhaltung und Reinigung sowie Sanierung von<br />
Trinkwasserbehältern. Materialien, Beschichtungssysteme und technische Ausrüstung.<br />
Hrsg. C. Ziegler, 1. Auflage 2011, ca. 150 Seiten, Broschur<br />
Buch + Bonusmaterial <strong>für</strong> € 54,90 € 46,70<br />
Buch + Bonusmaterial + eBook auf DVD <strong>für</strong> € 69,90 € 59,40<br />
Oldenbourg Industrieverlag München<br />
www.gwf-wasser-abwasser.de<br />
VORTEILSANFORDERUNG PER FAX: +49 (0)201 / 82002-34 oder per Brief einsenden<br />
Ja, ich bestelle die Fachbuchreihe gwf Praxiswissen im günstigen Fortsetzungsbezug,<br />
verpasse keinen Band und spare 15%. Ich wünsche die<br />
Lieferung beginnend ab Band<br />
als Buch + Bonusmaterial <strong>für</strong> € 46,70 (gwf-Abonnenten: € 37,30)<br />
als Buch + Bonusmaterial + eBook auf DVD <strong>für</strong> € 59,40<br />
(gwf-Abonnenten: € 47,50)<br />
Wir beziehen gwf im Abonnement nicht im Abonnement<br />
Jeder aktuelle Band wird zum Erscheinungstermin ausgeliefert und<br />
separat berechnet. Die Anforderung gilt bis zum schriftlichen Widerruf.<br />
Die pünktliche, bequeme und sichere Bezahlung per Bankabbuchung<br />
wird mit einer Gutschrift von € 3,- auf die erste Rechnung belohnt.<br />
Firma/Institution<br />
Vorname, Name des Empfängers<br />
Straße/Postfach, Nr.<br />
PLZ, Ort<br />
Telefon<br />
E-Mail<br />
Telefax<br />
Antwort<br />
Vulkan Verlag GmbH<br />
Versandbuchhandlung<br />
Postfach 10 39 62<br />
45039 Essen<br />
Branche/Wirtschaftszweig<br />
Bevorzugte Zahlungsweise Bankabbuchung Rechnung<br />
Bank, Ort<br />
Bankleitzahl<br />
✘<br />
Datum, Unterschrift<br />
Kontonummer<br />
PAGWFP2011<br />
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<br />
die rechtzeitige Absendung des Widerrufs oder der Sache an die Vulkan-Verlag GmbH, Versandbuchhandlung, Huyssenallee 52-56, 45128 Essen.<br />
Nutzung personenbezogener Daten: Für die Auftragsabwicklung und zur Pflege der laufenden Kommunikation werden personenbezogene Daten erfasst und gespeichert. Mit dieser Anforderung erkläre ich mich damit einverstanden, <strong>das</strong>s ich vom Oldenbourg Industrieverlag oder vom<br />
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 <strong>für</strong> die Zukunft jederzeit widerrufen.
HAUPTBEITRAG<br />
Simulationsbasierte<br />
Steuerungsfunktionstests<br />
Generierung von Anlagenmodellen aus CAE-Planungsdaten<br />
Sicherzustellen, <strong>das</strong>s Steuerungsprogramme in Prozessleitsystemen (PLS) entsprechend<br />
der Kundenanforderungen implementiert wurden, ist eine wesentliche Aufgabe im <strong>Engineering</strong><br />
von Automatisierungssystemen. Da diese Anforderungen nicht formalisiert vorliegen,<br />
werden dazu umfangreiche Tests durchgeführt. Dieser Beitrag stellt eine Methode<br />
vor, mit der <strong>das</strong> Test-<strong>Engineering</strong> durch den Einsatz von automatisch generierten Simulationsmodellen<br />
unterstützt und verkürzt wird. Mit dem generierten Anlagenmodell wird<br />
es möglich, rein virtuelle Steuerungstests und H ardware-in-the-Loop (H IL)-Prüfungen<br />
durchzuführen. So lassen sich Funktionsblöcke, Verriegelungen und Schrittketten sowie<br />
die <strong>für</strong> die Werksabnahme des Leitsystems (Factory Acceptance Test, FAT) notwendigen<br />
Kommunikationsparameter (zum Beispiel Feldbusadressen) testen.<br />
SCHLAGWÖRTER Factory Acceptance Test / automatische Modellgenerierung / Simulation /<br />
Modelica / CAEX / Objektorientierung / PLS-Test-<strong>Engineering</strong><br />
Simulation based control logic tests –<br />
Automated generation of simulation models based on CAE data<br />
To validate that control functions have been implemented correctly (according to specification)<br />
in process control systems is a crucial task in the engineering of automation<br />
systems. Because these specifications are usually only given informally, numerous test<br />
runs are carried out to detect possible design or implementation faults in the control<br />
software. Within this paper, a method is presented which supports the tests by means of<br />
automatically generated simulation models. Starting point is the hypothesis that it should<br />
be feasible to derive a simulation model from the CAE planning data of the process plant,<br />
and that this simulation model should be detailed and accurate enough to generate valid<br />
test results. This approach has been developed and implemented, which allows to run<br />
both purely virtual system simulations and H ardware-in-the-loop (H IL) tests. Thus, control<br />
function blocks, interlocks, sequences and communication parameters (such as field<br />
bus addresses) relevant for Factory Acceptance Test can be carried out with significantly<br />
reduced time and costs.<br />
KEYWORDS Factory Acceptance Test / automated model generation / simulation /<br />
Modelica / CAEX / object orientation<br />
54<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
MIKE BARTH, ABB Forschungszentrum<br />
ALEXANDER FAY, Helmut-Schmidt-Universität,<br />
JÜRGEN GREIFENEDER, PETER WEBER, ABB Forschungszentrum<br />
Das <strong>Engineering</strong> von Prozessleitsystemen (PLS)<br />
stellt zunehmende H erausforderungen an Ingenieure.<br />
Zum einen haben sich Prozessleitsysteme<br />
zu einem Produkt mit hoher Funktionsintegration<br />
entwickelt, welche der Steuerung/<br />
Regelung immer komplexerer Anlagen dienen. Andererseits<br />
sinkt die zur Verfügung stehende Projektdauer (seit<br />
1 9 7 0 um 2 5 % ). Beide Entwicklungen erschweren es, eine<br />
konstant hohe Qualität der Automatisierungslösung beizubehalten.<br />
Verfahrenstechnische Anlagen operieren<br />
mit hohen Druck- und Temperaturniveaus und beinhalten<br />
teilweise gefährliche Medien. Aus diesem Grund<br />
können Fehler im Steuerungscode nicht ausschließlich<br />
<strong>für</strong> die Anlage gefährlich werden, sondern auch <strong>für</strong><br />
Mensch und Umwelt schädlich sein.<br />
Die Konfiguration der Steuerungs- und Regelalgorithmen<br />
<strong>für</strong> Prozessleitsysteme zeichnet sich als eine der<br />
Aktivitäten aus, welche in mehrfacher H insicht als fehleranfällig<br />
kategorisiert werden muss. In NAfl3 5 wird<br />
diese als „ Software Konfiguration“ bezeichnete Aktivität<br />
dadurch gekennzeichnet, <strong>das</strong>s „ vielfältige Fehlermöglichkeiten“<br />
bestehen. Die Fehler werden meist erst in<br />
späteren Phasen, <strong>das</strong> heißt während der Inbetriebnahme<br />
auf der Baustelle erkannt, wodurch die Folgen monetärer<br />
und zeitlicher Natur sind [ 1 ] . Vor diesem H intergrund<br />
kommt dem Testen der Steuerungskonfiguration eine<br />
entscheidende Rolle zu.<br />
In Teil 1 dieses Beitrages [ 2 ] wurde eine Methode zur<br />
semi-automatischen Überführung von Leitsystem-Typicals<br />
in Simulationsmodellobjekte vorgestellt. Der Fokus<br />
dieser Methode liegt auf der Generierung von Einzelelementinstanzen,<br />
welche sich <strong>für</strong> simulationsbasierte<br />
Tests von Funktionsbausteinen einsetzen lassen. Um<br />
jedoch Ablaufsteuerungen, Verriegelungen und Grenzwerte<br />
<strong>für</strong> größere Anlagenabschnitte testen zu können,<br />
muss es möglich sein, ein Simulationsmodell mit entsprechend<br />
instanziierten und verschalteten Modellobjekten<br />
des gesamten Anlagenabschnittes zu generieren.<br />
In diesem Beitrag werden dahingehend folgende Punkte<br />
als Bestandteil einer Generierung von Simulationsmodellen<br />
betrachtet [ 3 ] :<br />
a | Instanziierung aller Modellobjekte (zum Beispiel<br />
Tanks, Ventile, Pumpen, Rohrleitungen)<br />
b | Parametrierung aller Modellobjekte (wie Zuweisung<br />
von Durchmesser und H öhe eines Behälters)<br />
c | Verschaltung aller Modellobjekte (Materialfluss,<br />
Energiefluss)<br />
d | Generierung einer visuellen Repräsentation des<br />
Simulationsmodells<br />
e | Definition der Kommunikation zwischen Simulationswerkzeug<br />
und Steuerung<br />
Die in Teil 1 dieses Beitrages erläuterte Generierung von<br />
Simulationsmodellen auf Basis des PLS-<strong>Engineering</strong>-Systems<br />
ermöglichte die Instanziierung (a) der Modellobjekte<br />
sowie die Ableitung der Kommunikationseinstellungen (e).<br />
Um eine vollständig automatische Modellgenerierung erreichen<br />
zu können, wird an dieser Stelle eine weitere, dem<br />
PLS-<strong>Engineering</strong> vorliegende Datenquelle <strong>für</strong> die automatische<br />
Modellgenerierung herangezogen: <strong>das</strong> CAE-System.<br />
1. DATENQUELLE FÜR DIE MODELLGENERIERUNG<br />
Die Nutzung von Planungsdokumenten, um Simulationsmodelle<br />
zu generieren, hängt von der dem Planungswerkzeug<br />
hinterlegten Datenmodellierung ab. Als Beispiel<br />
wird in [ 4 ] die Generierung von Verhaltensmodellen<br />
von Werkzeugmaschinen aus Stromlaufplänen beschrieben.<br />
Voraussetzung ist, <strong>das</strong>s die stromführenden<br />
Leiter im Stromlaufplan nicht ausschließlich als Linien<br />
„ gezeichnet“ , sondern als Leiterobjekte mit entsprechend<br />
instanziierten Verbindungen angelegt werden.<br />
Im Gegensatz zu konventionellen CAE-Systemen vermeiden<br />
objektorientierte CAE-Systeme die getrennte<br />
Datenhaltung von Grafikdateien, abgelegt in einem Dateisystem,<br />
und alphanumerischen Daten. Grafische und<br />
alphanumerische Informationen werden zusammen in<br />
einem Datenbankobjekt gespeichert. Die grafischen Editoren<br />
arbeiten unmittelbar auf den Datenbanken und<br />
nicht wie bei den konventionellen Systemen in Grafikdateien.<br />
Die Bezeichnung objektorientiert bezieht sich<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
55
HAUPTBEITRAG<br />
nicht auf die eingesetzte Datenbank, da diese in den<br />
meisten Werkzeugen eine relationale Standarddatenbank<br />
ist. Objektorientiert bedeutet, „ <strong>das</strong>s <strong>für</strong> jedes Objekt im<br />
PLT-<strong>Engineering</strong>-Zyklus alle Daten nur einmal eingegeben<br />
werden müssen und in allen anderen unterstützten<br />
<strong>Engineering</strong>-Phasen inklusive ihrer syntaktischen Zusammenhänge<br />
zur Verfügung stehen“ [ 5 ] . Derartige CAE-<br />
Systeme werden zunehmend eingesetzt. Vertreter sind<br />
Comos PT, PLANEDS und SmartPlant P&ID. Der H auptvorteil<br />
ist, <strong>das</strong>s ein real vorhandenes Objekt, beispielsweise<br />
ein Elektromotor, als zentraler dokumentenübergreifender<br />
Träger von Planungsinformationen betrachtet<br />
wird. Einem solchen Objekt werden Attribute zugeordnet,<br />
die sich beispielsweise <strong>für</strong> die Generierung und Parametrierung<br />
eines Simulationsmodells nutzen lassen.<br />
Dies wurde bereits im Projekt Aubios (Automatisierung<br />
umwelt- und bioverfahrenstechnischer Prozesse und<br />
Systeme) erfolgreich genutzt, indem Bibliothekselemente<br />
des CAE-Systems Comos PT um Simulationsaspekte<br />
aus der Verfahrenstechnik erweitert wurden [ 6 ] .<br />
Die Auswirkungen der Objektorientierung auf eines<br />
der wichtigsten Planungsdokumente der PLT-Planung,<br />
<strong>das</strong> Rohrleitungs- und Instrumentenfließbild, werden im<br />
folgenden Abschnitt erläutert.<br />
1.1 Rohrleitungs- und Instrumentenfließbild<br />
Auf dem Grund- und Verfahrensfließbild aufbauend gibt<br />
<strong>das</strong> Rohrleitungs- und Instrumentenfließbild (R&I-Fließbild)<br />
einen Überblick der leittechnischen Planung in Form<br />
von Elektro-, Mess-, Steuerungs- und Regelungstechnik-<br />
Funktionen (EMSR). In [ 7 ] wird es als Schlüsseldokument<br />
<strong>für</strong> ein angestrebtes durchgängiges <strong>Engineering</strong> definiert.<br />
Die datentechnisch dahinterliegenden Objektstrukturen<br />
bilden bereits heute die Grundlage <strong>für</strong> eine Vielzahl von<br />
Automatismen. Beispielhaft kann die Generierung von<br />
PLT-Stellenverzeichnissen genannt werden [ 5 ] . In einem<br />
objektorientierten CAE-System werden bei der Erstellung<br />
des R&I-Fließbildes vorhandene Bibliotheksobjekte oder<br />
Module instanziiert und, sofern möglich, spezifiziert.<br />
Bild 1 zeigt ein Beispiel, in dem die Geometriedaten (zum<br />
Beispiel H öhe, Innendurchmesser, Volumen) eines Behälters<br />
über eine Parametermaske eingegeben werden.<br />
Die Bedeutung des R&I-Fließbildes <strong>für</strong> <strong>das</strong> PLT-<strong>Engineering</strong><br />
wird in [ 8 ] bestärkt, in dem <strong>das</strong> R&I-Fließbild als<br />
Ausgangspunkt <strong>für</strong> die Automatisierung von <strong>Engineering</strong>-Tätigkeiten<br />
benannt wird. Vor dem H intergrund der<br />
im R&I-Fließbild enthaltenen Planungsobjekte, deren<br />
mögliche Parametrierung sowie deren Verbindung wird<br />
dieses CAE-Dokument als Datenquelle <strong>für</strong> die im Folgenden<br />
erläuterte Modellgenerierung benutzt.<br />
1.2 Überführung in ein neutrales Datenaustauschformat<br />
Für eine automatische Generierung der Simulationsmodelle<br />
werden die Daten des R&I-Fließbildes in einem rechnergestützt<br />
auswertbaren Format benötigt. Die damit verbundene<br />
Thematik eines rechnergestützten Austausches von<br />
<strong>Engineering</strong>-Daten ist seit den frühen Einsätzen von CAE-<br />
Werkzeugen bekannt. H eute gilt die durch den Einsatz<br />
offener Datenaustauschformate ermöglichte Interoperabilität,<br />
welche die Fähigkeit zur Zusammenarbeit von Software-Systemen<br />
umschreibt, als wichtige Voraussetzung<br />
<strong>für</strong> effizientes <strong>Engineering</strong>: „ Die Vernetzung der Werkzeuge<br />
über offene Schnittstellen offeriert die Möglichkeit eines<br />
durchgängigen <strong>Engineering</strong>s entlang des <strong>Engineering</strong>-<br />
Workflows, gewerke- und unternehmensübergreifend“ [ 9 ] .<br />
Als Sprache <strong>für</strong> Datenaustauschformate hat sich die<br />
eX tensible Markup Language (X ML) durchgesetzt [ 1 0 ] .<br />
Beispiele <strong>für</strong> Formate, die in der Prozessautomatisierung<br />
eingesetzt werden, sind:<br />
BatchML (IEC 6 1 5 1 2 : Batch Control Part 1 : Models<br />
and Terminology)<br />
CAEX (DIN EN ISO 6 2 4 2 4 : Darstellung von Aufgaben<br />
der Prozessleittechnik – Fließbilder und Datenaustausch<br />
zwischen EDV-Werkzeugen zur Fließbilderstellung<br />
und CAE-Systemen)<br />
Degussa PlantX ML [ 1 1 ]<br />
PandIX (PandIX Spezifikation V. 4 .0 )<br />
PLCopen X ML (PLCopen X ML – TC6 )<br />
NE 1 0 0 (Merkmalleisten zur Erstellung von PLT-<br />
Gerätespezifikationen)<br />
X MpLant (ISO 1 5 9 2 6 : Industrial Automation Systems<br />
and Integration – Oil and Gas – Part 1 : Overview and<br />
Fundamental Principles, 2 0 0 3 /Part 2 : Data model)<br />
BILD 1: R&I-Darstellung eines<br />
Tanks mit korrespondierender<br />
Parametermaske<br />
56<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
H<br />
Darüber hinaus existieren weitere X ML-basierte Formate,<br />
die im PLT-<strong>Engineering</strong> eingesetzt werden. H ierzu zählen<br />
zum Beispiel GSDML oder EDDL [ 1 2 ] , die, ähnlich wie FDT<br />
X ML, <strong>für</strong> den spezifischen Austausch von Gerätekonfigurationsdaten<br />
verwendet werden. Von den genannten Formaten<br />
eignen sich ausschließlich CAEX , X MpLant und<br />
PandIX <strong>für</strong> die Modellierung der in der PLT-Planung im<br />
R&I-Fließbild projektierten Daten. Insbesondere CAEX<br />
diente in den vergangenen J ahren immer wieder als Ausgangspunkt<br />
<strong>für</strong> unterschiedliche Ansätze im Rahmen der<br />
„ Automatisierung der Automatisierung“ . Beispiele sind die<br />
automatische Generierung von Asset Management Funktionen<br />
[ 1 3 ] und die automatische Generierung von Verriegelungen<br />
[ 1 4 ] . Alle anderen Formate sind entweder durch<br />
ihren Modellierungsansatz nicht geeignet (zum Beispiel<br />
NE 1 0 0 keine Modellierung von Aggregationen oder Assoziationen)<br />
oder erweisen sich als proprietäres Format.<br />
Das Format PandIX befindet sich derzeit noch im Status<br />
einer hochschulinternen Empfehlung. Weil es sich jedoch<br />
um einen CAEX -Dialekt handelt, lassen sich die Aussagen<br />
zur Anwendbarkeit mit denen von CAEX gleichsetzen.<br />
Für die Übertragung aller Planungsaspekte müssen die <strong>für</strong><br />
die CAE-basierte Modellgenerierung identifizierten Datenaustauschformate<br />
eine objektorientierte Modellierung ermöglichen.<br />
Dies erfordert die Referenz einer Instanz auf <strong>das</strong> entsprechende<br />
Bibliotheksobjekt und die Zuordnung von Attributen<br />
zu deren Objekten. Um der ebenfalls aus der objektorientierten<br />
Programmierung stammenden Forderung nach<br />
eindeutigen Identifikationen aller Elemente nachzukommen,<br />
wird jeder Instanz ein Schlüssel zugewiesen. H ier<strong>für</strong> wird<br />
oft auf den von Programmierumgebungen erzeugten 1 2 8 Bit<br />
(1 6 Bytes) Globally Unique Identifier (GUID) zurückgegriffen.<br />
Die Interpretation des Anlagenaufbaus erfolgt durch die<br />
Kombination der Assoziationen und Aggregationen.<br />
2. MODELLGENERIERUNG<br />
In der Modellierung technischer Systeme haben sich<br />
zwei Ansätze durchgesetzt [ 1 5 ] :<br />
die signalflussbasierte (kausale, explizite) Modellierung<br />
und<br />
die objektorientierte (a-kausale, implizite) Modellierung<br />
Bei der signalflussbasierten Modellierung wird <strong>das</strong> System<br />
in Form eines Blockschaltbildes modelliert. Dabei werden<br />
Blöcke, in denen eine Verarbeitung der eingehenden Signalwerte<br />
erfolgt, mittels in ihrer Übertragungsrichtung<br />
festgelegten Wirklinien verbunden. Dies bedeutet, <strong>das</strong>s<br />
eine Signalschnittstelle explizit als Signalausgang oder<br />
-eingang definiert ist. Ein Block ist gekennzeichnet durch<br />
die Ermittlung eines (Single Output – SO) oder mehrerer<br />
(Multiple Output – MO) Ausgangssignale in Abhängigkeit<br />
eines (Single Input – SI) oder mehrerer (Multiple Input –<br />
MI) Eingangssignale. Aufgrund der gerichteten Wirklinien<br />
besteht ein eindeutiger Ursache-Wirkungs-Zusammenhang<br />
(kausal). Die Vorteile dieses Modellierungsansatzes<br />
liegen in der Darstellung von kausalen Systemen – zum<br />
Beispiel Regelkreisen. Dementgegen stehen die Nachteile<br />
der bei größeren Modellen schnell unübersichtlich werdenden<br />
Strukturen. Nachträgliche Ä nderungen erfordern<br />
eine genaue Kenntnis aller mathematischen Zusammenhänge<br />
sowie den Zugang zu den realisierten Subsystemen.<br />
Die aufgrund ihrer Fokussierung auf physikalische Objekte<br />
auch als physikalische Modellierung bezeichnete<br />
objektorientierte Modellierung kennzeichnet sich durch<br />
ihre a-kausale Schnittstellendefinition. H ierbei wird nicht<br />
zwischen Ein- und Ausgang unterschieden. Im Gegensatz<br />
zum signalflussbasierten Ansatz kommt den Schnittstellen<br />
eine multiple physikalische Bedeutung zu. So entspricht<br />
eine Verbindung am Beispiel verfahrenstechnischer Anlagen<br />
etwa einem Stutzen (Materialfluss), einer Kabelklemme<br />
(Signalfluss) oder einer beheizten Fläche (Energiefluss).<br />
Die übertragenen Variablen lassen sich aufteilen in:<br />
Flussgrößen, die unter Beachtung ihres Vorzeichens<br />
addiert werden:<br />
Am Beispiel verfahrenstechnischer Anlagen können<br />
so der Massen- und/oder Wärmestrom (falls modelliert)<br />
in Rohrsegmenten benannt werden.<br />
Potenzialgrößen, die an den Verbindungspunkten<br />
gleichgesetzt werden:<br />
Am Beispiel verfahrenstechnischer Anlagen, insbesondere<br />
Druck und Temperatur.<br />
Energieflüsse entstehen durch Potenzialunterschiede –<br />
zum Beispiel stellt sich der Wärmefluss von einem im<br />
Rohr fließenden Medium durch die Rohrwandung nur bei<br />
geringerer Umgebungstemperatur ein. Des Weiteren beinhaltet<br />
die objektorientierte Modellierung wichtige<br />
Merkmale der objektorientierten Programmierung. So<br />
wird die Klassenbibliothek in Form einer Modellbibliothek<br />
umgesetzt. Durch die Instanziierung, Parametrierung<br />
und Verbindung der in ihr beinhalteten Modelle<br />
entsteht ein Gesamtmodell.<br />
Die Datenquelle CAE-System stellt in Verbindung mit<br />
einem offenen Datenaustauschformat eine Möglichkeit<br />
<strong>für</strong> ein durchgehend objektorientiertes Konzept dar. Den<br />
Anlagenelementen sind geometrische (beispielsweise<br />
öhe, Durchmesser) und physikalische (zum Beispiel<br />
KV-Wert) Parameter zugewiesen. Von den erläuterten<br />
Modellierungsansätzen kann aufgrund der bestehenden<br />
Merkmalsüberschneidungen die objektorientierte Modellierung<br />
eingesetzt werden.<br />
2.1 Modellierungssprache und Zielsystem<br />
Um die geforderte objektorientierte Struktur zu gewährleisten,<br />
wird die Modellierungssprache Modelica angewendet.<br />
Modelica wurde 1 9 9 6 als Weiterführung der gleichungsbasierten<br />
Sprachen ObjectMath und Mathematica<br />
entwickelt. Die deklarative gleichungsbasierte Sprache<br />
eignet sich <strong>für</strong> die gleichzeitige Modellierung mehrerer<br />
physikalischer Effekte [ 1 6 ] , wie sie in verfahrenstechnischen<br />
Anlagen auftreten (wie Drücke, Temperaturen, Materialfluss).<br />
Als Simulationsumgebung wird stellvertretend<br />
die Umsetzung mit dem am häufigsten eingesetzten Werkzeug<br />
Dymola erläutert. Modelica bietet die Möglichkeit<br />
einer Modellierung in Form von gewöhnlichen Differenzialgleichungen<br />
(ODE), differenzial algebraischen Gleichungen<br />
(DAE) sowie Bedingungs-Operatoren (zum Beispiel<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
57
H<br />
H<br />
HAUPTBEITRAG<br />
„ Wenn-Dann“ ) <strong>für</strong> die hybride Modellierung. Weitere <strong>für</strong><br />
die Umsetzung relevante Aspekte von Modelica sind:<br />
Direkte Integration von externen Funktionen<br />
Der Zugriff auf außerhalb von Modelica implementierte<br />
Funktionen ermöglicht die Kommunikation<br />
mit beispielsweise OPC-Servern oder Feldbuskarten.<br />
Geringer Abstraktionsgrad bei der Modellierung und<br />
Parametrierung<br />
Die Übernahme von Parametern aus der Datenquelle<br />
CAE-System (zum Beispiel Tankdurchmesser)<br />
wird damit unmittelbar möglich.<br />
Die textbasierte Modellierung gestattet die externe<br />
Manipulation.<br />
Der Modellgeneratoralgorithmus kann ASCII-<br />
Zeichenfolgen ausgeben.<br />
Der Aufbau eines Modelica-Modells gliedert sich in diese<br />
Bereiche:<br />
Objektinstanziierung (Bildung von Instanzen der<br />
Bibliotheksobjekte – zum Beispiel Tank)<br />
Gleichungen/Schnittstellen (Verbindung der Instanzen<br />
untereinander – beispielsweise Tank mit Rohrleitung<br />
verbinden)<br />
Funktions- beziehungsweise Algorithmen-Implementierung<br />
(Aufruf von externen Funktionen – zum<br />
Beispiel Initialisierung der OPC-Übertragung)<br />
Die Anwendung dieser drei Bereiche wird im Folgenden<br />
erläutert.<br />
2.2 Automatische Modellgenerierung<br />
Bild 2 stellt in schematischer Form die Arbeitsweise des<br />
implementierten Modellgenerators dar. Zunächst werden<br />
die Daten aus dem CAE-System in ein Datenaustauschformat<br />
(hier: CAEX ) überführt und <strong>für</strong> die Generierung des<br />
Simulationsmodells in Modelica-Syntax verwendet. H ier<strong>für</strong><br />
werden, ähnlich der objektorientierten Programmierung,<br />
Bibliotheksmodelle (zum Beispiel OpenTank) instanziiert.<br />
Der Instanz werden anschließend der Name sowie die Parameter<br />
des korrespondierenden CAE-Planungsobjektes<br />
übergeben. Die <strong>für</strong> die Generierung des Simulationsmodells<br />
verwendeten Bibliotheksmodelle entstammen der Modelica-Fluid-Bibliothek<br />
[ 1 7 ] . Diese wurde 2 0 1 0 als ergänzendes<br />
Modul in die Standard-Modellbibliothek der Modelica Association<br />
(www.modelica.org) übernommen und steht als<br />
Open-Source-Komponente zur Verfügung. Eine detailliertere<br />
Beschreibung der in der Modelica-Fluid-Bibliothek<br />
umgesetzten Modellierungstiefe findet sich unter [ 1 8 ] .<br />
Eine vollständige Generierung des Simulationsmodells<br />
erfordert zusätzlich die Definition der Verbindungen<br />
zwischen den Simulationsmodellen. Dies ist in<br />
Bild 3 beispielhaft <strong>für</strong> <strong>das</strong> Ventil Y 2 0 4 dargestellt, welches<br />
an den Behälter B9 9 0 angeschlossen wird.<br />
2.3 Visualisierung und Kommunikation<br />
Die eingangs als Anforderung (d) definierte Visualisierung<br />
der Simulationsmodelle in Form eines Simulations-<br />
Fließbildes wird vom Modellgenerator durch die Ergänzung<br />
der Modelica-Syntax um „ Modelica annotation<br />
tags“ umgesetzt. Dies erlaubt die Positionierung von<br />
TML-Elementen <strong>für</strong> die instanziierten Elemente mit<br />
X Y -Koordinaten und einer an die Fließbilddarstellung<br />
angepassten Skalierung, zum Beispiel:<br />
annotation(Documentation<br />
(info= “ < H TML> < IMG… /> < /H TML> “ ),<br />
Placement(Transformation<br />
(x= 8 0 , y= 2 0 , scale= 0 .1 )).<br />
Bild 4 zeigt hierzu ein automatisch generiertes Simulationsmodell,<br />
nachdem es in Dymola eingeladen wurde. Alle<br />
Objekte wurden dabei automatisch, entsprechend der Anordnung<br />
im R&I-Fließbild, platziert. Letzteres lässt sich<br />
optional durch den Modellgenerator als H intergrundbild<br />
einbinden. H ierdurch ist es möglich, <strong>das</strong> generierte Simulationsmodell<br />
mit den Planungsdaten zu vergleichen. Weiterer<br />
Vorteil: Das Vertrauen der Ingenieure in die Korrektheit<br />
des generierten Modells steigt damit. Ein ebenfalls<br />
wichtiger Aspekt, welcher aus der Generierung der Visualisierung<br />
hervorgeht, ist die Interaktionsmöglichkeit<br />
während des Testens. So ist es dem Ingenieur möglich, auf<br />
Basis der dargestellten Objekte (zum Beispiel Pumpe), online<br />
Werte zu setzen, beziehungsweise zu fixieren. H ierdurch<br />
können Fehler in der Aktorik (zum Beispiel Verklemmen<br />
eines Ventils, Abriss einer Signalleitung, Ausfall<br />
einer Pumpe) oder Sensordefekte vorgetäuscht und die<br />
Reaktion der Steuerung überprüft werden. Derartige Testszenarien<br />
sind insbesondere <strong>für</strong> Verriegelungen wichtig.<br />
Um die automatische Simulationsmodellgenerierung im<br />
Sinne der genannten Kriterien zu vervollständigen, bildet<br />
die Definition der Kommunikationsperipherie ein zusätzliches<br />
Merkmal. Ziel des vorgestellten Ansatzes ist es, den<br />
Steuerungscode in kompilierter Form zu testen, wodurch<br />
entweder eine Soft-SPS (emuliert Steuerung in Verbindung<br />
mit einem OPC-Server) oder die reale Steuerung eingesetzt<br />
werden muss. Bei Verwendung einer Soft-SPS wird eine<br />
rein virtuelle Testumgebung geschaffen, welche auch als<br />
Systemsimulation definiert ist. In Bezug auf die Implementierung<br />
von OPC <strong>für</strong> <strong>das</strong> Simulationssystem Dymola wurden<br />
die <strong>für</strong> Modelica standardmäßig existierenden Kommunikationstechniken<br />
DDE und Named Pipes um einen<br />
OPC-Client erweitert, welcher mit den Server-Applikationen<br />
gängiger Soft-Steuerungen kommuniziert [ 1 9 ] . Mithilfe<br />
der Einbindung externer Funktionen in Modelica ließ<br />
sich die in Bild 5 links dargestellte OPC-Bibliothek entwickeln,<br />
deren Modelle auf den in Bild 5 rechts als C# -Klasse<br />
dargestellten OPC-Client zugreifen.<br />
Durch den Einsatz des CAE-Systems als Datenquelle <strong>für</strong><br />
die automatische Modellgenerierung können die definierten<br />
Kriterien (a) bis (d) bereits erfüllt werden. Dies beinhaltet<br />
die Instanziierung, Parametrierung und Verschaltung<br />
der Simulationsobjekte sowie die Generierung einer<br />
visuellen Repräsentation des Modells. Darüber hinaus<br />
kann die Initialisierung des OPC-Clients durch <strong>das</strong> Einlesen<br />
von PLCopen X ML Dateien automatisiert werden.<br />
ier<strong>für</strong> muss die CAE-basierte Generierung des Simulationsmodells<br />
um Daten aus der <strong>Engineering</strong>-Umgebung<br />
des Leitsystems angereichert werden. Dies ist im Prototyp<br />
bereits umgesetzt, wodurch <strong>das</strong> bis dahin noch unerfüllte<br />
Kriterium (e) durch automatische Kommunikationsinstanziierung<br />
erfüllt wird.<br />
58<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
H<br />
BILD 3: Generierung von Verbindungen in Modelica<br />
BILD 2: Modellinstanziierung und Parameterübergabe<br />
vom CAE-System zu Modelica<br />
BILD 5: OPC-Bibliothek <strong>für</strong> Modelica [20]<br />
BILD 4: Automatisch generiertes Simulationsmodell<br />
Neben dem Test des Steuerungscodes beinhaltet der<br />
FAT zusätzliche Prüfungen der Feldbusadressen sowie<br />
weiterer, <strong>für</strong> die Initialisierung der Kommunikation notwendiger<br />
Busparameter (Feldbustyp, Konfigurationsdatei,<br />
FB-Knotentyp, FB-Knotenversion, FB-Baudrate, FB-<br />
Knoten, FB-Knotenadresse). Diese Testart erfordert eine<br />
ardware-in-the-Loop-Simulation und dadurch die Einbeziehung<br />
der realen Steuerung in Kombination mit Teilen<br />
der realen Peripherie. Dabei werden die prozessnahen<br />
Komponenten (Feldgeräte und Remote IO) weiterhin im<br />
Simulationsmodell modelliert. Dies bedeutet, <strong>das</strong>s der<br />
Simulationsrechner eine oder mehrere Remote-IO-<br />
Komponente(n) gegenüber der Steuerung emuliert. Dazu<br />
wird der Simulationsrechner mit einer Profibus-PCI-Karte<br />
ausgerüstet, welche über eine RS4 8 2 -Verkabelung mit<br />
der Steuerung verbunden wird.<br />
Bild 6 stellt die <strong>für</strong> diese Arbeit realisierte H IL-Testkonfiguration<br />
in Kombination mit der Simulationsumgebung<br />
Dymola dar. Als Steuerung wurde eine reale SPS mit einer<br />
Profibus-DP-Schnittstelle eingesetzt. Diese ist mit einer realen<br />
Remote-IO-Baugruppe und mit dem Simulationsrechner<br />
verbunden. Im <strong>Engineering</strong>-System der SPS wird der<br />
Simulationsrechner als „ normale“ Remote-IO-Komponente<br />
mit H ilfe einer Gerätespezifikationsdatei (* .gsd) eingebunden.<br />
In den Funktionsmustern wird die H IL-Variante durchgehend<br />
als Remote-IO-Konfiguration umgesetzt. Dies bedeutet,<br />
<strong>das</strong>s alle im Simulationssystem instanziierten Sensoren<br />
und Aktoren zunächst mit einer modellierten Remote-IO<br />
kommunizieren, welche alle Werte über Feldbus an die reale<br />
Steuerung überträgt beziehungsweise von ihr empfängt.<br />
Im Gegensatz zur Systemsimulation mit OPC erfordert<br />
die H IL-Simulation deutlich mehr Parameter <strong>für</strong> die In-<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
59
H<br />
H<br />
H<br />
HAUPTBEITRAG<br />
itialisierung der Kommunikation. H ierzu zählen Feldbusadressen<br />
oder Baudraten. Aus diesem Grund ist die<br />
IL-Variante in Kombination mit den generierten Simulationsmodellen<br />
möglich, jedoch nicht im gleichen Maße<br />
automatisiert wie die OPC-Variante.<br />
ZUSAMMENFASSUNG UND AUSBLICK<br />
In diesem Beitrag wurde eine Methode zur automatischen<br />
Generierung von Simulationsmodellen auf Basis<br />
von CAE-Planungsdaten vorgestellt. H ierzu wurden<br />
Rohrleitungs- und Instrumentenfließbilder in <strong>das</strong> neutrale<br />
Datenaustauschformat CAEX überführt. Als Modellierungssprache<br />
wurde die objektorientierte gleichungsbasierte<br />
Modelica-Syntax angewendet. Zusätzlich<br />
zur Generierung des physikalischen Modells ließ sich<br />
die Parametrierung der Simulationsobjekte sowie die<br />
Generierung eines Simulations-H MI erreichen. Sowohl<br />
ardware-in-the-Loop- als auch Systemsimulation mittels<br />
OPC-Kommunikation sind möglich.<br />
Erste Einsätze wiesen die Tauglichkeit der generierten<br />
Simulationsmodelle <strong>für</strong> folgende Bereiche nach:<br />
Tests von Verriegelungen,<br />
Tests von Ablaufsteuerungen,<br />
Tests der Wirkrichtung von Reglern,<br />
Tests von Grenzwerten <strong>für</strong> Alarme und Meldungen.<br />
Dieser Auflistung folgend, werden die generierten Simulationsmodelle<br />
im Wesentlichen <strong>für</strong> funktionale Tests<br />
des Steuerungscodes eingesetzt. Dadurch lassen sich<br />
frühzeitig Fehler, wie beispielsweise eine falsch gesetzte<br />
Übergangsbedingung in einer Ablaufsteuerung beziehungsweise<br />
damit verbundene falsch gesetzte Grenzwerte,<br />
identifizieren und beheben. Die Anwendung der Simulation<br />
bedeutet gleichzeitig eine natürliche Grenze<br />
der Testmöglichkeiten: Da die reale H ardware simuliert<br />
wird, können Fehler in der Konfiguration der realen<br />
ardware, wie zum Beispiel <strong>das</strong> falsche Setzen von IP-<br />
Adressen, Baud-Raten, Timeouts oder <strong>das</strong> Vertauschen<br />
von Anschlussklemmen am Schaltschrank, nur bedingt<br />
oder nicht gefunden werden. Diese Einschränkung wurde<br />
in der Zielstellung dieser Arbeit berücksichtigt, indem<br />
auf eine Unterstützung der vor und während des<br />
FAT stattfindenden funktionalen Tests fokussiert wurde.<br />
Einen Site Acceptance Test (SAT) kann <strong>das</strong> vorgestellte<br />
Konzept nicht ersetzen, wohl aber verkürzen.<br />
Weitere Entwicklungsstufen sehen die zusätzliche Generierung<br />
von Simulationsskripten <strong>für</strong> die automatische<br />
Konfiguration des Simulationslaufes sowie <strong>für</strong> die Vorabauswahl<br />
von Simulationsvariablen <strong>für</strong> die Testdokumentation<br />
vor. H ierbei werden die PLT-Stellen des R&I-Fließbildes<br />
ausgewertet, um dem Modellgenerator ausschließlich<br />
die <strong>für</strong> die Prozessleittechnik relevanten Prozessinformationen<br />
über von Sensoren erfasste Drücke, Füllstände,<br />
Durchflüsse oder Temperaturen zu übergeben. Darauf basierend<br />
kann eine Vorabdefinition der entsprechenden Simulationsvariablen<br />
erfolgen.<br />
MANUSKRIPTEINGANG<br />
06.11.2011<br />
Im Peer-Review-Verfahren begutachtet<br />
REFERENZEN<br />
BILD 6: Hardware-in-the-Loop-<br />
Testkonfiguration <strong>für</strong> Modelica<br />
[1] Krause, K.; Frick, A.; Schiefloe, T.: Life Cycle Support mit<br />
Simulator. <strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische<br />
Praxis 53(9), S. 32-38, 2011.<br />
[2] G reifeneder, J.; Weber, P.; Barth, M.; Fay, A.: Generierung<br />
von Simulationsmodellen auf Basis von PLS-<strong>Engineering</strong>-<br />
Systemen. <strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische<br />
Praxis 54(4), S. 34-41, 2012<br />
[3] B arth, M.: Automatisch generierte Simulationsmodelle<br />
verfahrenstechnischer Anlagen <strong>für</strong> den Steuerungstest.<br />
Dissertation an der Helmut-Schmidt-Universität /<br />
Universität der Bundeswehr Hamburg, Institut <strong>für</strong><br />
Automatisierungstechnik, Fortschritt-Berichte VDI,<br />
Reihe 20, 2011<br />
[4] Kufner, A.; Dreiss, P.; Klemm, P.: Fortschritt bei Simulation<br />
von Montagemaschinen. <strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische<br />
Praxis 53(9), S. 24-31, 2011.<br />
[5] R auprich, G.; Haus, C.; Ahrens, W.: PLT-CAE – Integration<br />
in Gewerke-übergreifendes <strong>Engineering</strong> und Plant-Maintenance.<br />
<strong>atp</strong> - Automatisierungstechnische Praxis 44(2),<br />
S. 50-62, 2002.<br />
[6] H oyer, M.: Catalogue based computer aided engineering<br />
(CAE) of process models. Dissertation an der University<br />
of Glamorgan, erarbeitet an der University of Applied<br />
Sciences and Arts Hannover, Faculty of Advanced<br />
Technology, 2007<br />
60<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
AUTOREN<br />
Dr.-Ing. MIKE BARTH (geb. 1 9 8 1 ) war von 2 0 0 8 bis<br />
2 0 1 1 wissenschaftlicher Mitarbeiter von Prof. Fay an<br />
der H elmut-Schmidt-Universität/Universität der<br />
Bundeswehr H amburg. Seit März 2 0 1 1 ist er Mitarbeiter<br />
am ABB AG Forschungszentrum. Seine<br />
Arbeitsgebiete umfassen <strong>das</strong> <strong>Engineering</strong> und die<br />
Kollaboration von Automatisierungssystemen.<br />
ABB AG Forschungszentrum,<br />
Wallstadter Straße 59,<br />
D-68526 Ladenburg,<br />
Tel. +49 (0) 6203 71 64 61,<br />
E-Mail: mike.barth@de.abb.com<br />
Prof. Dr.-Ing. ALEXANDER FAY (geb. 1 9 7 0 ) ist Professor<br />
<strong>für</strong> Automatisierungstechnik an der Fakultät <strong>für</strong><br />
Maschinenbau der H elmut-Schmidt-Universität/<br />
Universität der Bundeswehr H amburg. Sein Forschungsschwerpunkt<br />
sind Beschreibungmittel,<br />
Methoden und Werkzeuge <strong>für</strong> einen effizienten<br />
Entwurf von Automatisierungssystemen.<br />
Institut <strong>für</strong> Automatisierungstechnik,<br />
Helmut-Schmidt-Universität/<br />
Universität der Bundeswehr Hamburg,<br />
Holstenhofweg 85, D-22043 Hamburg,<br />
Tel. +49 (0) 40 65 41 27 19, E-mail: alexander.fay@hsu-hh.de<br />
Dr.-Ing. JÜRGEN GREIFENEDER (geb. 1 9 7 5 ) ist seit<br />
2 0 0 8 Wissenschaftler am ABB Forschungszentrum.<br />
Er studierte Technische Kybernetik in Stuttgart<br />
und promovierte über formale Antwortzeitanalyse<br />
netzbasierter Automatisierungssysteme in Kaiserslautern.<br />
Seine wissenschaftlichen Schwerpunkte liegen<br />
auf Systemmodellierung und effizientem <strong>Engineering</strong>.<br />
ABB Forschungszentrum Deutschland,<br />
Wallstadter Str 59, D-68526 Ladenburg,<br />
Tel. +49 (0) 6203 71 62 22,<br />
E-Mail: juergen.greifeneder@de.abb.com<br />
Dipl.-Phys. PETER WEBER (geb. 1 9 5 6 ) ist<br />
Principal Scientist am ABB Forschungszentrum.<br />
Seine Forschungsschwerpunkte liegen im<br />
Bereich Virtuelle Inbetriebnahme und Advanced<br />
<strong>Engineering</strong> Methods.<br />
ABB Foschungszentrum Deutschland,<br />
Wallstadter Str. 59, D-68526 Ladenburg,<br />
Tel. +49 (0) 6203 71 62 74,<br />
E-Mail: peter.weber@de.abb.com<br />
[7] R odies, H.-J.: Planungswerkzeuge aus Sicht des Anlagenbaus.<br />
<strong>atp</strong> - Automatisierungstechnische Praxis 44(1), S.<br />
40-44, 2002<br />
[8] Schlütter, M.; Schmitz, S.: Automatische Datenübernahme<br />
aus dem R&I-Fließbild in CAE-Werkzeuge. Chemie Technik<br />
37(11), S. 18-20, 2008.<br />
[9] Fay, A.: <strong>Engineering</strong> in vernetzten, offenen, durchgängigen<br />
Systemen. at – Automatisierungstechnik 53(4-5), S. 205-210,<br />
2005.<br />
[10] Epple, U.: Austausch von Anlagenplanungsdaten auf der<br />
Grundlage von Metamodellen. <strong>atp</strong> - Automatisierungstechnische<br />
Praxis 45(7), S. 61-70, 2003<br />
[11] Anhäuser, F.; Richert, H.; Temmen, H.: Degussa PlantXML<br />
– <strong>integrierte</strong>r Planungsprozess mit flexiblen Bausteinen. <strong>atp</strong><br />
- Automatisierungstechnische Praxis 46(10), S. 61-71, 2004.<br />
[12] Weidemann, D.; Drath, R.: Einleitung in AutomationML. In:<br />
Drath (Hrsg.) Datenaustausch in der Anlagenplanung mit<br />
AutomationML – Integration von CAEX, PLCopen XML, und<br />
COLLADA. S. 26, Springer-Verlag Berlin Heidelberg, 2009.<br />
[13] Schmidberger, T.; Fay, A.; Drath, R.; Horch, A.: Von Anlagenstrukturinformationen<br />
automatisch zum Asset-Management.<br />
<strong>atp</strong> – Automatisierungstechnische Praxis 48(6), S.<br />
54-61, 2006<br />
[14] Schmidberger, T.; Fay, A.; Drath, R.: Automatisiertes<br />
<strong>Engineering</strong> von Prozessleitsystem-Funktionen. <strong>atp</strong> – Automatisierungstechnische<br />
Praxis 47(2), S. 46-51, 2005.<br />
[15] Breitenecker, F.; Popper, N.: Classification and evaluation of<br />
features in advanced simulators. In: Tagungsband MATHMOD<br />
2009 - 6th Vienna International Conference on Mathematical<br />
Modeling, S. 1445-1467. Wien:ARGESIM-Reports 35,,2009.<br />
[16] Elmqvist, H.; Mattsson, S.E.; Otter, M.: Modelica – A<br />
Language for Physical System Modeling, Visualization and<br />
Interaction. In: Tagungsband IEEE Symposium on Computer-<br />
Aided Control System Design. S. 630-639, 1999<br />
[17] Casella, F.; Otter, M.; Proelss, K.; Richter, C.; Tummescheit,<br />
H.: The Modelica Fluid and Media library for modeling of<br />
incompressible and compressible thermo-fluid pipe<br />
networks. In: Proceedings of the 5th Modelica Conference, S.<br />
631-639, 2006.<br />
[18] B arth, M.; Fay, A.: Erfahrungen im Umgang mit der<br />
Modelica-Fluid-Bibliothek auf dem Gebiet der Prozessautomatisierung.<br />
In: Tagungsband "ASIM-Treffen 2010 - Simulation<br />
technischer Systeme - Grundlagen und Methoden in<br />
Modellbildung und Simulation, S. 60-67, 2010<br />
[19] Wagner, F.; Frey, G.: Hardware-in-the-Loop-Simulation bei<br />
kurzfristig zu langsamen Simulations-Modellen. Automation<br />
im gesamten Lebenszyklus. In Tagungsband: GMA-Kongress<br />
2007, , S. 151-161, VDI-Berichte, 2007.<br />
[20] B arth, M.; Fay, A; Wagner F.; Frey, G.: Effizienter Einsatz<br />
Simuations-basierter Tests in der Entwicklung automatisierungstechnischer<br />
Systeme. In: Tagungsband "Automation<br />
2010", S. 47-50, VDI-Berichte, 2010.<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012<br />
61
IMPRESSUM / VORSCHAU<br />
IMPRESSUM<br />
VORSCHAU<br />
Verlag:<br />
Oldenbourg Industrieverlag GmbH<br />
Rosenheimer Straße 145<br />
D-81671 München<br />
Telefon + 49 (0) 89 4 50 51-0<br />
Telefax + 49 (0) 89 4 50 51-3 23<br />
www.oldenbourg-industrieverlag.de<br />
Geschäftsführer:<br />
Carsten Augsburger, Jürgen Franke<br />
Spartenleiter:<br />
Andreas Schleinkofer<br />
Herausgeber:<br />
Dr. T. Albers<br />
Dr. G. Kegel<br />
Dipl.-Ing. G. Kumpfmüller<br />
Dr. N. Kuschnerus<br />
Beirat:<br />
Dr.-Ing. K. D. Bettenhausen<br />
Prof. Dr.-Ing. Ch. Diedrich<br />
Prof. Dr.-Ing. U. Epple<br />
Prof. Dr.-Ing. A. Fay<br />
Prof. Dr.-Ing. M. Felleisen<br />
Prof. Dr.-Ing. G. Frey<br />
Prof. Dr.-Ing. P. Göhner<br />
Dipl.-Ing. Th. Grein<br />
Prof. Dr.-Ing. H. Haehnel<br />
Dr.-Ing. J. Kiesbauer<br />
Dipl.-Ing. R. Marten<br />
Dipl.-Ing. G. Mayr<br />
Dr. J. Nothdurft<br />
Dr.-Ing. J. Papenfort<br />
Dr. A. Wernsdörfer<br />
Dipl.-Ing. D. Westerkamp<br />
Dr. Ch. Zeidler<br />
Organschaft:<br />
Organ der GMA<br />
(VDI/VDE-Gesell schaft Messund<br />
Automatisierungs technik)<br />
und der NAMUR<br />
(Interessen gemeinschaft<br />
Automatisierungs technik der<br />
Prozessindustrie).<br />
Redaktion:<br />
Andreas Schleinkofer (verantwortlich)<br />
Telefon + 49 (0) 89 4 50 51-2 36<br />
Telefax + 49 (0) 89 4 50 51-2 07<br />
E-Mail: schleinkofer@oiv.de<br />
Anne Hütter<br />
Telefon + 49 (0) 89 4 50 51-4 18<br />
Telefax + 49 (0) 89 4 50 51-2 07<br />
E-Mail: huetter@oiv.de<br />
Gerd Scholz<br />
Einreichung von Hauptbeiträgen:<br />
Prof. Dr.-Ing. Leon Urbas<br />
(Chefredakteur, verantwortlich<br />
<strong>für</strong> die Hauptbeiträge)<br />
Technische Universität Dresden<br />
Fakultät Elektrotechnik<br />
und Informationstechnik<br />
Professur <strong>für</strong> Prozessleittechnik<br />
D-01062 Dresden<br />
Telefon +49 (0) 351 46 33 96 14<br />
E-Mail: urbas@oiv.de<br />
Fachredaktion:<br />
Dr.-Ing. M. Blum<br />
Prof. Dr-Ing. J. Jasperneite<br />
Dr.-Ing. B. Kausler<br />
Dr.-Ing. N. Kiupel<br />
Dr. rer. nat. W. Morr<br />
Dipl.-Ing. I. Rolle<br />
Dr.-Ing. S. Runde<br />
Prof. Dr.-Ing. F. Schiller<br />
Bezugsbedingungen:<br />
„<strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische<br />
Praxis“ erscheint<br />
monatlich mit Doppelausgaben im<br />
Januar/Februar und Juli/August.<br />
Bezugspreise:<br />
Abonnement jährlich: € 468,– + € 30,–/<br />
€ 35,- Versand (Deutschland/Ausland);<br />
Heft-Abbonnement + Online-Archiv:<br />
€ 638,40; ePaper (PDF): € 468,-;<br />
ePaper + Online-Archiv: € 608,40;<br />
Einzelheft: € 55,– + Versand;<br />
Die Preise enthalten bei Lieferung<br />
in EU-Staaten die Mehrwertsteuer,<br />
<strong>für</strong> alle übrigen Länder sind es<br />
Nettopreise. Mitglieder der GMA: 30%<br />
Ermäßigung auf den Heftbezugspreis.<br />
Bestellungen sind jederzeit über den<br />
Leserservice oder jede Buchhandlung<br />
möglich.<br />
Die Kündigungsfrist <strong>für</strong> Abonnementaufträge<br />
beträgt 8 Wochen zum Bezugsjahresende.<br />
Abonnement-/<br />
Einzelheftbestellung:<br />
Leserservice <strong>atp</strong><br />
Postfach 91 61, D-97091 Würzburg<br />
Telefon + 49 (0) 931 4170-1615<br />
Telefax + 49 (0) 931 4170-492<br />
E-Mail: leserservice@oiv.de<br />
Verantwortlich <strong>für</strong><br />
den Anzeigenteil:<br />
Annemarie Scharl-Send<br />
Mediaberatung<br />
sales & communications Medienagentur<br />
Kirchfeldstraße 9, D-82284 Grafrath<br />
Tel. +49 (0) 8144 9 96 95 12<br />
Fax +49 (0) 8144 9 96 95 14<br />
E-Mail: ass@salescomm.de<br />
Es gelten die Preise der Mediadaten 2012<br />
Anzeigenverwaltung:<br />
Brigitte Krawczyk<br />
Telefon + 49 (0) 89 4 50 51-2 26<br />
Telefax + 49 (0) 89 4 50 51-3 00<br />
E-Mail: krawczyk@oiv.de<br />
Art Director / Grafik:<br />
Deivis Aronaitis | dad |<br />
Druck:<br />
Druckerei Chmielorz GmbH<br />
Ostring 13,<br />
D-65205 Wiesbaden-Nordenstadt<br />
Gedruckt auf chlor- und<br />
säurefreiem Papier.<br />
Die <strong>atp</strong> wurde 1959 als „Regelungstechnische<br />
Praxis – rtp“ gegründet.<br />
© 2012 Oldenbourg Industrieverlag<br />
GmbH München<br />
Die Zeitschrift und alle in ihr enthaltenen<br />
Beiträge und Abbildungen sind urheberrechtlich<br />
geschützt. Mit Ausnahme der<br />
gesetzlich zugelassenen Fälle ist eine<br />
Verwertung ohne Ein willigung des Verlages<br />
strafbar.<br />
Gemäß unserer Verpflichtung nach § 8<br />
Abs. 3 PresseG i. V. m. Art. 2 Abs. 1c DVO<br />
zum BayPresseG geben wir die Inhaber<br />
und Beteiligungsverhältnisse am Verlag<br />
wie folgt an:<br />
Oldenbourg Industrieverlag GmbH,<br />
Rosenheimer Straße 145, 81671 München.<br />
Alleiniger Gesellschafter des Verlages<br />
ist die ACM-Unternehmensgruppe,<br />
Ostring 13,<br />
65205 Wiesbaden-Nordenstadt.<br />
ISSN 2190-4111<br />
DIE AUSGABE 6 / 2012 DER<br />
ERSCHEINT AM 04.06.2012<br />
MIT FOLGENDEN BEITRÄGEN:<br />
PFD-Berechnung bei nicht<br />
konstanten Ausfallraten<br />
Automatische Generierung<br />
sicherer diversitärer Software<br />
Architekturen <strong>für</strong><br />
diagnosefähige Aktorik in<br />
sicherheitsgerichteten Kreisen<br />
Operational Access to<br />
SIS Components<br />
...und vielen weiteren Themen.<br />
Aus aktuellem Anlass können sich die Themen<br />
kurzfristig verändern.<br />
LESERSERVICE<br />
E-MAIL:<br />
leserservice@oiv.de<br />
TELEFON:<br />
+ 49 (0) 931 4170-1615<br />
62<br />
<strong>atp</strong> <strong>edition</strong><br />
5 / 2012
Erreichen Sie die Top-Entscheider<br />
der Automatisierungstechnik.<br />
Sprechen Sie uns an wegen Anzeigenbuchungen<br />
und Fragen zu Ihrer Planung.<br />
Annemarie Scharl-Send: Tel. +49 (0) 8144 9 96 95 12<br />
E-Mail: ass@salescomm.de
<strong>atp</strong> kompakt<br />
Methoden Verfahren Konzepte<br />
Sonderpreise<br />
<strong>für</strong><br />
Abonnenten<br />
der <strong>atp</strong> <strong>edition</strong><br />
Die Automatisierungstechnik wird durch neue Forschungen und Entwicklungen bestimmt. Damit Ingenieure<br />
fit <strong>für</strong> ihren Job sind und die entscheidenden Trends in der Automatisierungstechnik schnell zur Hand haben,<br />
legt die Fachpublikation <strong>atp</strong> <strong>edition</strong> die Buchreihe <strong>atp</strong> kompakt auf. Alle darin enthaltenen Beiträge haben<br />
ein wissenschaftliches Gutachterverfahren durchlaufen.<br />
Herausgeber Prof. Dr.-Ing. Frank Schiller leitet am Lehrstuhl <strong>für</strong> Informationstechnik im Maschinenwesen der<br />
TU München <strong>das</strong> Fachgebiet Automatisierungstechnik.<br />
<strong>atp</strong> kompakt Band 1<br />
Erfolgreiches <strong>Engineering</strong> – Die wichtigsten Methoden<br />
Diese Ausgabe befasst sich mit den Methoden, Verfahren und Standards, die Sie in den nächsten Jahren im <strong>Engineering</strong> beschäftigen<br />
werden. Wichtige Kriterien sind die einfache Wiederverwendbarkeit von Komponenten, die Unterstützung durch geeignete Werkzeuge,<br />
die Erhöhung der Flexibilität von Anlagen sowie geeignete Modellierungs- und Gerätebeschreibungssprachen.<br />
1. Auflage 2010, 138 Seiten mit CD-ROM, Broschur, € 79,- • ISBN: 978-3-8356-3210-3<br />
Für Abonnenten<br />
€ 74,-<br />
<strong>atp</strong> kompakt Band 2<br />
Effiziente Kommunikation – Die bedeutendsten Verfahren<br />
Sie bekommen Einblick in die wachsende Bedeutung der industriellen Kommunikation und dem Wandel in der Gerätekommunikation.<br />
Einen Schwerpunkt bildet die Kommunikationstechnik in der Prozessautomatisierung mit deren besonderen Rahmenbedingungen wie<br />
dem Explosionsschutz. Die bedeutendsten Verfahren und Methoden der modernen Kommunikation werden praxisnah veranschaulicht.<br />
1. Auflage 2010, 72 Seiten mit CD-ROM, Broschur, € 59,- • ISBN: 978-3-8356-3212-7<br />
Für Abonnenten<br />
€ 54,-<br />
<strong>atp</strong> kompakt Band 3<br />
Praktische Messtechnik – Die besten Konzepte<br />
Dieser Band vermittelt wertvolles Know-how zu allen Aspekten der praktischen Messtechnik und fokussiert besonders die Prozessmesstechnik.<br />
Lernen Sie die Fortschritte in der Sensortechnik entlang der Technologie-Roadmap kennen und profitieren Sie von erstklassigen<br />
Konzepten zu kostengünstigen und effizienten Lösungen.<br />
1. Auflage 2010, 72 Seiten mit CD-ROM, Broschur, € 59,- • ISBN: 978-3-8356-3213-4<br />
Für Abonnenten<br />
€ 54,-<br />
<strong>atp</strong> kompakt Kollektion (Bände 1-3)<br />
Erfolgreiches <strong>Engineering</strong> Effiziente Kommunikation Praktische Messtechnik<br />
Mit dieser dreibändigen Kollektion zu den Themen <strong>Engineering</strong>, Kommunikation und Messtechnik erhalten Sie ein nützliches,<br />
kompakt und praxisnah aufbereitetes Kompendium zu den Kernthemen der Automatisierungstechnik. Die wertvolle Grundlage<br />
<strong>für</strong> Ihre tägliche und zukünftige Arbeit.<br />
1. Auflage 2010, ca. 282 Seiten mit CD-ROM, Broschur • € 179,- • ISBN: 978-3-8356-3221-9<br />
Für Abonnenten<br />
€ 169,-<br />
Sofortanforderung im Online-Shop www.oldenbourg-industrieverlag.de<br />
oder telefonisch +49 (0)201 / 82002-14<br />
OldenbOurg IndustrIeverlag gmbH<br />
vulkan-verlag gmbH<br />
www.oldenbourg-industrieverlag.de • www.vulkan-verlag.de