atp edition Konfigurationsmanagement im Anlagenlebenszyklus (Vorschau)
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
10 / 2013<br />
55. Jahrgang B3654<br />
DIV Deutscher Industrieverlag GmbH<br />
Automatisierungstechnische Praxis<br />
<strong>Konfigurationsmanagement</strong><br />
<strong>im</strong> <strong>Anlagenlebenszyklus</strong> | 30<br />
Geräteintegration und<br />
-management | 38<br />
Geräteintegration in<br />
AT-Systeme | 46<br />
Selbsterklärende Geräte | 56
<strong>atp</strong> <strong>edition</strong> – die Referenzklasse<br />
der Automatisierungstechnik
EDITORIAL<br />
Wirtschaftliche Geräteintegration<br />
erfordert einheitliche Lösung<br />
Die Namur hat in der jüngeren Vergangenheit <strong>im</strong>mer wieder deutlich gemacht,<br />
dass eine einheitliche, herstellerübergreifende Technologie zur Geräteintegration<br />
notwendige Voraussetzung für die breite Anwendung der digitalen Kommunikation<br />
in der Feldebene ist. Mit anderen Worten: Endanwender ziehen bisher<br />
nur bedingt wirtschaftlichen Nutzen aus den von intelligenten Geräten zusätzlich<br />
bereitgestellten Informationen und Funktionen, weil unterschiedliche<br />
Hersteller verschiedene inkompatible Integrationstechniken unterstützen.<br />
Unbedingt erforderlich ist dafür ein Standard, der von möglichst vielen Herstellern<br />
der Prozessautomatisierung unterstützt wird. Eine Gerätebeschreibung<br />
soll unabhängig vom jeweiligen Hersteller in allen Systemen und Asset Management<br />
Tools funktionieren. Die Geräteintegration soll keine unerwünschten Rückwirkungen<br />
auf die Kernfunktionen des Leitsystems haben. Sie soll weitgehend<br />
unabhängig von der schnelllebigen IT-Welt sein und gleichzeitig erlauben, Informationen<br />
für die Business-Systeme bereitzustellen. Außerdem ist die Kompatibilität<br />
mit der installierten Basis sicherzustellen.<br />
Unmöglich, das alles unter einen Hut zu bringen? Mit der FDI-Initiative (Field<br />
Device Integration) scheint es gelungen zu sein. Maßgebliche Automatisierungshersteller<br />
wie ABB, Emerson, Endress+Hauser, Honeywell, Invensys, Siemens und<br />
Yokogawa unterstützen die Verbände FDT Group, Fieldbus Foundation, Hart Communication<br />
Foundation, Profibus-Nutzerorganisation und OPC Foundation bei ihrem<br />
gemeinsamen Vorhaben, die einheitliche Geräteintegrationslösung zu entwickeln.<br />
Das Projekt hat gute Fortschritte gemacht. Die FDI-Spezifikation (IEC 62769) liegt<br />
als CDV (Committee Draft for Vote) vor. Die zugrundeliegende Electronic Device<br />
Desription Language, EDDL (IEC 61804), wurde verbessert und protokollübergreifend<br />
harmonisiert. Zusätzlich zu den technischen Spezifikationen wurde ein<br />
Usability Style Guide entwickelt, der den Herstellern hilft, anwenderfreundliche<br />
und konsistente Bedienoberflächen für Feldgeräte zu erstellen. Die FDI-Architektur<br />
sieht optional die Ankopplung an Business-Systeme über eine OPCUA-Schnittstelle<br />
vor. Eine Entwicklungsumgebung für Gerätehersteller und einheitliche<br />
Kernkomponenten für System- und Toolhersteller stellen Interoperabilität sicher.<br />
Möglich ist dies nur, weil Hersteller erkannt haben, dass proprietäre Lösungen<br />
oder zu viele konkurrierende Standards unwirtschaftlich sind, wenn sie <strong>im</strong><br />
Markt nur bedingt Akzeptanz finden.<br />
Ich freue mich darauf, dass FDI bald Ergebnisse präsentiert, und die Technologie<br />
für die Produktentwicklung genutzt werden kann. Dann wird sich zeigen,<br />
ob die umfangreichen Anforderungen und hohen Erwartungen erfüllt wurden.<br />
Auf den folgenden Seiten finden Sie interessante Beiträge zu unterschiedlichen<br />
Aspekten der Geräteintegration. Ich wünsche Ihnen be<strong>im</strong> Lesen viel Spaß und<br />
gute Anregungen.<br />
Signum<br />
ACHIM LAUBENSTEIN,<br />
ABB Automation<br />
Executive Director der<br />
FDI Cooperation<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
3
INHALT 10 / 2013<br />
FORSCHUNG<br />
6 | Tiger-Chip: Ein Rechner auf 15 mal 15 Mill<strong>im</strong>eter<br />
Produkte testen in der virtuellen Realität<br />
Call for <strong>atp</strong> experts: Big Data in der Automation<br />
7 | Innovationspreis für junge Ingenieure<br />
BRANCHE<br />
8 | 5. SIL-Sprechstunde: Experten finden Normen-Interpretationen<br />
für individuelle Anwendungen<br />
9 | Automation 2014: Call for smart Papers<br />
Broschüre erklärt IO-Link-Technologie<br />
VERBAND<br />
10 | Namur-Hauptsitzung: Integrated Engineering<br />
über den gesamten Lebenszyklus <strong>im</strong> Fokus<br />
NE 151 unterstützt Koexistenz von Funkanwendungen<br />
11 | Nach Mitgliederbefragung: Sensorverband AMA erweitert<br />
Ausrichtung auf Messtechnik<br />
INTERVIEW<br />
12 | „Aufgabe der Automatisierer ist es, den Visionen rund um<br />
‚Industrie 4.0‘ Bodenhaftung zu geben“<br />
<strong>atp</strong>-CHEFREDAKTEUR LEON URBAS FORDERT STEFAN KOWALEWSKI ZUR STANDORTBESTIMMUNG<br />
DER AUTOMATISIERER IN DER DEBATTE UM CYBER-PHYSISCHE SYSTEME AUF<br />
4<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
PRAXIS<br />
16 | Steuerungstechnik ermöglicht effiziente Kühlung<br />
<strong>im</strong> Frankfurter Rechenzentrum von BT Germany<br />
20 | Neue Mess- und Steuerungstechnik sichert die<br />
Hochspannungsversuchsfelder der TU München<br />
22 | Safe Human-Robot Collaboration Combines<br />
Expertise and Precision in Manufacturing<br />
26 | Industrial WLAN erlaubt auch zuverlässige<br />
Kommunikation mit Echtzeitanforderungen<br />
Produkte,<br />
Systeme<br />
und Service<br />
für die<br />
Prozessindustrie?<br />
Natürlich.<br />
HAUPTBEITRÄGE<br />
30 | <strong>Konfigurationsmanagement</strong><br />
<strong>im</strong> <strong>Anlagenlebenszyklus</strong><br />
G. GREDY, J. HÄHNICHE UND M. BRCIC<br />
38 | Geräteintegration und -management<br />
H. RACHUT, H. RICHTER, S. RUNDE, R. LANGE,<br />
A. JUSTUS, J. FICKER UND K. SCHNEIDER<br />
46 | Geräteintegration in AT-Systeme<br />
C. DIEDRICH UND T. HADLICH<br />
56 | Selbsterklärende Geräte<br />
RUBRIKEN<br />
D. JOHN, B. DANZER, M. RIEDL UND H. ZIPPER<br />
3 | Editorial<br />
62 | Impressum, <strong>Vorschau</strong><br />
Der PostionMaster EDP300<br />
überzeugt durch hohe Luftleistung<br />
(50 kg/h bei 10 bar), Diagnosefähigkeit<br />
nach Namur und<br />
Überdruckfestigkeit in fast allen<br />
Umgebungsbedingungen. Mit den<br />
Zulassungen für den Betrieb in<br />
Ex-Zone 1 und SIL2 ermöglicht<br />
der EDP300 eine hohe Anlagensicherheit.<br />
Durch die mechanische<br />
Stellungsanzeige ist die Erfassung<br />
der Ventilstellung auch ohne Stromversorgung<br />
möglich. Zuverlässiges<br />
Regelverhalten, Flexibilität und<br />
seine kompakte Bauform zeichnen<br />
den EDP300 aus.<br />
www.abb.de/aktorik<br />
Wussten Sie, dass Ihnen ABB<br />
neben dem umfassenden Portfolio<br />
für die Instrumentierung ebenso<br />
herausragende Produkte und<br />
Lösungen für die Analysentechnik,<br />
maßgeschneiderte Leitsysteme<br />
sowie erstklassigen Service bietet?<br />
Lesen Sie mehr unter:<br />
www.abb.de/<br />
prozessautomatisierung<br />
ABB Automation Products GmbH<br />
Tel.: 0800 111 44 11<br />
Fax: 0800 111 44 22<br />
vertrieb.messtechnik-produkte@de.abb.com
FORSCHUNG<br />
Tiger-Chip: Ein Rechner auf 15 mal 15 Mill<strong>im</strong>eter<br />
Die NRW-Kampagne „Germany at its best“ hat den Tiger-Chip<br />
als Speicherchip mit der höchsten Performance<br />
ausgezeichnet. Aus über 2000 Bewerbungen wählte<br />
die Expertenjury den Mikroprozessor aus.<br />
Der Tiger-Chip ermöglicht erstmals eine Profinet-Integration<br />
in einfache Feldgeräte. Dadurch werden Informationstechnologien<br />
durchgehend in der Feldebene nutzbar.<br />
DER MIKRO-<br />
PROZESSOR<br />
ermöglicht eine<br />
Profinet-Integration<br />
in einfache Feldgeräte.<br />
Bild: Centrum<br />
Industrial IT (CIIT)<br />
Große Datenmengen können mit Übertragungszeiten von<br />
unter 100 Mikrosekunden übermittelt werden.<br />
Unter dem Dach des Centrum Industrial IT (CIIT) entwickelten<br />
das Lemgoer Fraunhofer-Anwendungszentrum<br />
Industrial Automation (IOSB-INA) und das Institut für<br />
industrielle Informationstechnik (Init) der Hochschule<br />
OWL die erste Single-Chip-Lösung für das Echtzeit-Ethernetsystem<br />
Profinet. „Er misst gerade einmal 15 mal 15 Mill<strong>im</strong>eter,<br />
enthält jedoch mit 30 Millionen Transistoren praktisch<br />
einen kompletten Rechner auf einem winzigen Stück<br />
Silizium“, sagt Professor Jürgen Jasperneite, Leiter beider<br />
Forschungsinstitute. Auftraggeber für das sechs Millionen<br />
Euro teure Projekt war Phoenix Contact. Außerdem beteiligte<br />
sich die Nürnberger Siemens AG an der Entwicklung.<br />
Die Kampagne „Germany at its best: Nordrhein-Westfalen“<br />
ehrt Bestleistungen aus Wirtschaft, Wissenschaft,<br />
Kultur und Sport. (aha)<br />
CENTRUM INDUSTRIAL IT (CIIT),<br />
Langenbruch 6, D-32657 Lemgo,<br />
Tel. +49 (0) 5261 702 59 97, Internet: www.ciit-owl.de<br />
Produkte testen in der virtuellen Realität<br />
Um exakte Voraussagen über die Zuverlässigkeit neuer<br />
Produkte machen zu können, haben Forscher aus<br />
Magdeburg und Kaiserslautern digitale Engineering-<br />
Konzepte entwickelt. Im Forschungsprojekt „Virtuelle<br />
und Erweiterte Realität für höchste Sicherheit und Zuverlässigkeit<br />
von Eingebetteten Systemen“ erstellen die<br />
Wissenschaftler digitale, funktionale Modelle der geplanten<br />
Produkte und s<strong>im</strong>ulieren das Verhalten der<br />
Steuerungssoftware. Schließlich verknüpfen sie beides<br />
miteinander und visualisieren das Ergebnis. An dem<br />
virtuellen Testmodell können die Forscher verschiedene<br />
kritische Systemzustände s<strong>im</strong>ulieren und darstellen.<br />
Bei der FuelCon AG kommen die Entwicklungen<br />
bereits zum Einsatz: Das Unternehmen verfügt nun über<br />
ein Fahrzeugs<strong>im</strong>ulationsmodell zum Testen von Batterielastzuständen.<br />
(aha)<br />
FRAUNHOFER-INSTITUT FÜR FABRIKBETRIEB UND<br />
-AUTOMATISIERUNG IFF MAGDEBURG,<br />
D-39106 Magdeburg,<br />
Tel. +49 (0) 391 409 04 46,<br />
Internet: www.iff.fraunhofer.de<br />
Call for <strong>atp</strong> experts: Big Data in der Automation<br />
DIE AUSGABE 56(4) DER ATP EDITION <strong>im</strong><br />
April 2014 ist dem Thema Big Data gewidmet.<br />
Die Generierung von Information aus<br />
den in automatisierten, technischen Systemen<br />
vielfältig anfallenden Daten hat mit<br />
Industrie 4.0 und cyber-physikalischen<br />
Systemen neue Aktualität erfahren; die<br />
Einsatzbereiche von Big Data reichen von<br />
Ressourcenopt<strong>im</strong>ierung über Prozessdiagnose<br />
und Asset Management bis hin zur<br />
Entscheidungsunterstützung bei Entwurf,<br />
Analyse und Betrieb automatisierter Anlagen.<br />
Ihre Beiträge beschreiben spezielle<br />
Herausforderungen und Anforderungen<br />
von Automation und Prozessführung, stellen<br />
neuartige Methoden und Potentiale<br />
aktueller Lösungsansätze vor oder diskutieren<br />
innovative Geschäftsmodelle auf<br />
der Basis von Big Data. Wir bitten Sie bis<br />
zum 31.10.2013 zu diesem Thema einen<br />
gemäß Autorenrichtlinien der <strong>atp</strong> <strong>edition</strong><br />
ausgearbeiteten Hauptbeitrag per E-Mail<br />
an urbas@di-verlag.de einzureichen.<br />
Die <strong>atp</strong> <strong>edition</strong> ist die hochwertige Monatspublikation<br />
für Fach- und Führungskräfte der<br />
Automatisierungsbranche. In den Hauptbeiträgen<br />
werden die Themen mit hohem wissenschaftlichem<br />
und technischem Anspruch<br />
und vergleichsweise abstrakt dargestellt.<br />
Im Journalteil stellen die Autoren praxisnahe<br />
Erfahrungen von Anwendern mit neuen Technologien,<br />
Prozessen oder Produkten dar.<br />
Alle wissenschaftlichen Hauptbeiträge werden<br />
von einem Fachgremium begutachtet.<br />
Sollten Sie sich selbst aktiv an dem Begutachtungsprozess<br />
beteiligen wollen, bitten<br />
wir um kurze Rückmeldung.<br />
Für weitere Rückfragen stehen wir Ihnen<br />
selbstverständlich gerne zur Verfügung.<br />
Redaktion <strong>atp</strong> <strong>edition</strong><br />
Leon Urbas, Anne Purschwitz,<br />
Aljona Hartstock<br />
CALL FOR<br />
Aufruf zur Beitragseinreichung<br />
Thema: Big Data in der Automation<br />
Kontakt: urbas@di-verlag.de<br />
Termin: 31. Oktober 2013<br />
6<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
DER KONGRESS SPS IPC DRIVES bietet an<br />
drei Tagen 48 Vorträge. Neben dem gewohnten<br />
Messeprogramm wird erstmals der<br />
Inno vationspreis der Automatisierungs industrie<br />
verliehen. Bild: Mesago Messe Frankfurt<br />
Innovationspreis für<br />
junge Ingenieure<br />
Auf der diesjährigen SPS IPC Drives in Nürnberg<br />
wird erstmals der Innovationspreis der Automatisierung<br />
verliehen. Der Preis will herausragende Leistungen<br />
junger Ingenieure unter 35 Jahren fördern. Die<br />
Preisverleihung findet am 27. November 2013 <strong>im</strong> Rahmen<br />
des Kongresses statt.<br />
Eine Jury, bestehend aus dem Kongresskomitee,<br />
wählt auf Basis der eingereichten Abstracts die Nominierten<br />
des Innovationspreises der Automatisierungsindustrie<br />
aus. Kriterien für die Auswahl sind Aktualität<br />
des Themas und Neuigkeitsgehalt des Inhalts. Es<br />
werden nur Erstveröffentlichungen akzeptiert. Aus<br />
den fertigen Manuskripten wählen die Komiteevorsitzenden<br />
Prof. Georg Frey, Prof. Alexander Verl und<br />
Prof. Walter Schumacher anschließend die Preisträger<br />
aus. Die drei Prämierten erhalten Preisgelder von<br />
3000, 2000 und 1000 Euro.<br />
Der Kongress der SPS IPC Drives 2013 wird an drei<br />
Tagen, vom 26. bis 28. November 2013, veranstaltet. Das<br />
Programm bietet unter anderem die beiden für alle Besucher<br />
kostenlos zugänglichen Keynotes „Industrie 4.0<br />
– Basis für die stetige Verbesserung in der Produktion“<br />
und „Sensorik 4.0 – wie granular werden CPPS?“ sowie<br />
die kostenlose Trendsession „Security“. Weitere Themen<br />
der Veranstaltung sind Automation und Cloud,<br />
Energieeffizienz und Systemarchitekturen, die einen<br />
Überblick über die Trends der elektrischen Automatisierung<br />
geben. Außerdem präsentieren zwei Tutorials<br />
praxisbezogenes Wissen in den Bereichen Automation<br />
und Drives. (aha)<br />
MESAGO MESSEMANAGEMENT GMBH,<br />
Rotebühlstraße 83-85, D-70178 Stuttgart,<br />
Tel. +49 (0) 711 61 94 60,<br />
Internet: www.mesago.de/sps
BRANCHE<br />
5. SIL-Sprechstunde: Experten finden Normen-<br />
Interpretationen für individuelle Anwendungen<br />
EXPERTENTREFF: Dr. Thomas Karte (links) referierte<br />
vor Teilnehmern der 5. SIL-Sprechstunde über das Thema<br />
„Diagnose durch automatisches Testen“.<br />
INDIVIDUELLE LÖSUNGEN: In Workshops<br />
diskutierten die Besucher ihre vorab eingereichten<br />
Fragen. Der zweite Tag gehört traditionell dem<br />
Austausch mit den Fachleuten. Bilder: ahü<br />
Sie fragen, Experten antworten: Unter diesem Motto<br />
stand die mittlerweile 5. SIL-Sprechstunde, die die<br />
<strong>atp</strong> <strong>edition</strong> mit der Firma Pepperl+Fuchs am 17. und 18.<br />
September 2013 veranstaltete. Die insgesamt 24 Teilnehmer<br />
stellten vorab unter www.sil-sprechstunde.de ihre<br />
Fragen an die Veranstalter. Die Referenten Thomas Gabriel<br />
(Bayer Technology Services), Dirk Hablawetz (BASF),<br />
Martin Herrmann (Evonik Degussa), Udo Hug (BlmSchG<br />
§ 29a Sachverständiger), Dr. Thomas Karte (Samson), Dr.<br />
Gerold Klotz-Engmann (Endress+Hauser Messtechnik)<br />
Josef Kuboth (Landesamt für Natur, Umwelt und Verbraucherschutz<br />
Nordrhein Westfalen), Dr. Bernd Schrörs (Bayer<br />
Technology Services), Heiko Schween (H<strong>im</strong>a), Peter<br />
Sieber (Bilfinger alpha msr) und Johann Ströbl (Tüv Süd<br />
Industrie Service) beantworteten die Fragen und stellten<br />
sich der Diskussion.<br />
Rund 20 Fragen hatten die Teilnehmer vorab eingereicht.<br />
Die Themen variierten stark, so dass sich das Thema<br />
„Funktionale Sicherheit nicht nach Schema F“ als gut gewählt<br />
herausstellte. Bereits der erste Vortrag am Mittwoch<br />
von Joseph Kuboth bot Anlass zur Diskussion. Kuboth<br />
sprach über die Namur-Empfehlung 138 und die Richtlinie<br />
2180 Bl. 6 vom VDI/VDE. Peter Sieber übernahm dann und<br />
stellte SIL von elektronischen Komponenten nach Namur-<br />
Empfehlung 142 vor. Im Anschluss referierte Dr. Thomas<br />
Karte über die Diagnose durch automatisches Testen.<br />
Nach der Pause fuhr Heiko Schween fort und informierte<br />
über Funktionale Sicherheit bei Nieder- und Mittelspannungsschalanlagen,<br />
gefolgt von Johann Ströbl,<br />
der die sichheitstechnische Bewertung ohne Probabilistik<br />
(50156) vornahm. Da die Sprechstunde straff organisiert<br />
ist und es bereits zahlreiche interessierte Nachfragen<br />
und Diskussionen seitens der Teilnehmer gegeben<br />
hatte, blieben Dr. Andreas Hildebrandt nur noch zehn<br />
Minuten Zeit, um über die PFD-Berechnung bei nichtkonstanten<br />
Ausfallraten zu sprechen. An das umfangreiche<br />
Vortragsprogramm schließt sich am ersten Tag<br />
traditionell die Abendveranstaltung an. Dieses Jahr besichtigten<br />
die SIL-Teilnehmer das Automuseum Dr. Carl<br />
Benz in Ladenburg. Im Anschluss genossen sie ein Catering.<br />
Die SIL-Sprechstunde fand am folgenden Morgen<br />
ihre Fortsetzung. Um den individuellen Charakter der<br />
Sprechstunde zu bewahren, teilte Tagungsleiter Andreas<br />
Hildebrandt die Teilnehmer in zwei Gruppen ein.<br />
Ausgehend von den eingereichten Fragen hatten sich<br />
zwei große Themenkomplexe um SIL ergeben: Die Fragen<br />
nach den rechtlichen Rahmenbedingungen, wie etwa:<br />
„In welchem Umfang bestehen für den Profibus PA Einschränkungen<br />
hinsichtlich der Funktionalen Sicherheit?“<br />
oder „Ist ein eigenes Sicherheits-Managementsystem<br />
erforderlich, wenn eine Firma als Dienstleister<br />
Schutzeinrichtungen für einen Kunden bearbeitet?“<br />
beantworteten die Experten in einem Tagungsraum mit<br />
etwa zwölf Teilnehmern.<br />
Der andere Komplex stand unter eher technischen Gesichtspunkten<br />
wie beispielsweise: „Reicht bei einem Liquiphant<br />
(FTL71 mit FEL 58) die Betätigung des Testtasters als<br />
‚Erstmalige Prüfung vor Inbetriebnahme‘ aus oder muss die<br />
Schaltung zwingend mit Produkt ausgelöst werden?“ oder<br />
„Kann ich mit drei SIL2-Transmittern (in 2v3 Verschaltung)<br />
in Summe SIL3 erreichen? Der PFDavg für SIL3 wird erreicht.“<br />
sowie „Kann ich mit zwei SIL2-Ventilen (in1v2 Verschaltung)<br />
in Summe SIL3 erreichen?“ Der PFDavg für SIL3<br />
wird erreicht wurde von einer zweiten Gruppe von Teilnehmern<br />
untersucht. <strong>atp</strong> <strong>edition</strong> und Pepperl+Fuchs organisieren<br />
in diesem Jahr eine weitere Sprechstunde zum Thema<br />
Explosionsschutz am 18. und 19. November 2013 in Mannhe<strong>im</strong>.<br />
Noch sind Plätze frei. <br />
(ahü)<br />
SIL-SPPRECHSTUNDE,<br />
Ansprechpartnerin: Anne Purschwitz, Redaktion <strong>atp</strong>,<br />
Arnulfstraße 124, D-80636 München,<br />
Tel. +49 (0) 89 203 53 66 58, E-Mail: purschwitz@di-verlag.de,<br />
Internet: www.sil-sprechstunde.de<br />
8<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
Automation 2014:<br />
Call for smart Papers<br />
Unter dem Motto „Smart X – Powered by Automation“<br />
startet am 1. Juli 2014 der zweitägige Kongress<br />
Automation. Der 15. Branchentreff der Messund<br />
Automatisierungstechnik beschäftigt sich mit<br />
der Frage, in welchem Ausmaß die Automation<br />
Grundlage und Antrieb ist für smarte Technik und<br />
smarte Lösungen in Wirtschaft und Gesellschaft. Dabei<br />
gilt es, die Anforderungen der industriellen Automation<br />
auf andere Branchen und Lebensbereiche<br />
zu übertragen. Eingeschlossen sind wirtschaftliche<br />
Aspekte ebenso wie die Interaktion des Menschen mit<br />
den smarten Systemen.<br />
Bis zum 11. November 2013 können Experten Kurzfassungen<br />
von Vorträgen zu smarten Methoden, Technologien<br />
und Anwendungen unter www.automatisierungskongress.de<br />
einreichen. Sie sollten einen Umfang<br />
von einer DIN-A4-Seite haben und unter anderem<br />
eine Inhaltsangabe sowie eine Aussage zum Innovationsgrad<br />
des Beitrags enthalten. Die Abgabe der Manuskripte<br />
soll dann bis zum 16. Mai 2014 erfolgen.<br />
Bei den Anwendungen stehen die Prozessautomation,<br />
die Fertigungsautomation, die Medizintechnik,<br />
die Gebäudeausrüstung und andere technische und<br />
nicht-technische Anwendungsfelder <strong>im</strong> Vordergrund.<br />
Als zusätzliches Gliederungselement für die Tagung<br />
wurde der Lebenszyklus gewählt – vom Geräte- und<br />
Systementwurf über den Betrieb automatisierter Anlagen<br />
bis zu Aspekten der Wartung und Diagnose. Den<br />
offiziellen Call for Papers finden Interessenten unter<br />
vdi-wissensforum.de.(aha)<br />
Unser<br />
Know-how<br />
für Sie<br />
Besuchen Sie uns:<br />
MEORGA<br />
30.10.2013<br />
Volkswagen Halle<br />
Braunschweig<br />
Stand Q2<br />
VDI WISSENSFORUM GMBH,<br />
D-40002 Düsseldorf, Tel. +49 (0) 211 621 42 01,<br />
Internet: www.wissensforum.de<br />
Broschüre erklärt<br />
IO-Link-Technologie<br />
Eine von der IO-Link-Firmengemeinschaft veröffentlichte<br />
Systembeschreibung ist nun online. Sie bietet<br />
einen Überblick über die I/O-Technologie IO-Link.<br />
Die Broschüre zeigt das Zusammenspiel der verschiedenen<br />
Komponenten eines IO-Link-Systems und hilft<br />
Nutzern, die Technologie besser zu verstehen.<br />
IO-Link ist eine weltweit standardisierte I/O-Technologie<br />
(IEC 61131-9), die die Kommunikation mit Sensoren<br />
und Aktoren ermöglicht. Die IO-Link-Firmengemeinschaft<br />
entwickelt und vermarktet die Technologie.<br />
Die Systembeschreibung kann unter www.profibus.<br />
com/download/ <strong>im</strong> Bereich „Technichal Descriptions<br />
& Books“ heruntergeladen werden.<br />
(aha)<br />
Mit über 50 weitgehend selbstständigen<br />
Tochtergesellschaften<br />
und über 220 Ingenieur- und Verkaufsbüros<br />
ist SAMSON auf allen<br />
Kontinenten kundennah vertreten.<br />
Um Ihnen die gesamte Regeltechnik<br />
in höchster Qualität zu<br />
bieten, hat SAMSON mit hochspezialisierten<br />
Unternehmen die<br />
SAMSON GROUP gebildet.<br />
IO-LINK-FIRMENGEMEINSCHAFT<br />
C/O PROFIBUS NUTZERORGANISATION E. V. (PNO),<br />
Haid-und-Neu-Str. 7, D-76131 Karlsruhe,<br />
Tel. +49 (0) 721 965 85 90,<br />
Internet: www.io-link.com<br />
A01120DE<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
VERBAND<br />
Namur-Hauptsitzung: Integrated Engineering<br />
über den gesamten Lebenszyklus <strong>im</strong> Fokus<br />
Die fortschreitende Digitalisierung und Vernetzung<br />
industrieller Wertschöpfungsprozesse bewirkt einen<br />
grundlegenden Wandel in der Industrie und ermöglicht<br />
neue Produktivitätshebel. Moderne Industrieanlagen<br />
sind durch eine extrem hohe Komplexität gekennzeichnet.<br />
Große Datenmengen müssen nicht nur gemanagt,<br />
sondern auch durchgängig von der<br />
Planungsphase bis zum Betrieb verfügbar<br />
und aktuell sein. Leistungsfähige<br />
und „intelligente“ Tools für Integration<br />
von Planung, Betrieb und<br />
Instandhaltung sind entscheidend<br />
für ein ganzheitliches Engineering<br />
über den gesamten Produkt- und<br />
Anlagen-Lebenszyklus.<br />
Die Namur hat daher das Thema<br />
Integrated Engineering zum Schwerpunkt<br />
ihrer 76. Hauptsitzung am<br />
7. und 8. November 2013 in Bad<br />
Neue nahr gewählt. Als Partner für<br />
die Hauptsitzung wurde die Siemens<br />
AG gewonnen, die mit ihrem breiten<br />
Produktportfolio innovative Lösungskonzepte<br />
für den gesamten Lebenszyklus<br />
einer Anlage anbietet.<br />
Mit industrieller IT und Industriesoftware<br />
können die einzelnen Prozessschritte intelligent<br />
miteinander vernetzt und so der gesamte Produktionsprozess<br />
opt<strong>im</strong>iert werden.<br />
Welche Möglichkeiten Integrated Engineering schon<br />
heute bietet und wie durchgängige Kommunikation zukünftig<br />
aussehen wird, werden Eckard Eberle, CEO Industrial<br />
Automation Systems bei Siemens, und Hans-<br />
Georg Kumpfmüller, CEO Sensors and Communication<br />
bei Siemens, in ihrem Plenarvortrag aufzeigen. Integrated<br />
Engineering ist das Zusammenspiel aller notwendigen<br />
Werkzeuge wie Anlagenmanagement, Prozessleitsystem<br />
und Geräteplanung/-Konfiguration.<br />
Der Vortrag wird anhand einzelner Phasen <strong>im</strong> Anlagen-Lebenszyklus<br />
zeigen, wie Informationsflüsse, basierend<br />
auf einem gemeinsamen, objektorientierten Datenmodell,<br />
enger zusammenwachsen – über Schnittstellen<br />
für den Informationsaustausch zwischen dem Computer<br />
ECKARD EBERLE UND HANS-GEORG<br />
KUMPFMÜLLER (v.l.) werden in ihrem<br />
Plenarvortrag bei der Namur-Hauptsitzung<br />
darstellen, welche Möglichkeiten<br />
Integrated Engineering schon<br />
heute bietet und wie durchgängige<br />
Kommunikation zukünftig aussehen<br />
wird. Bilder: Siemens<br />
Aided Engineering-Tool (CAE), dem Prozessleitsystem<br />
(PLS) und der Wartungsplanung bis hin zu einem lückenlosen<br />
elektronischen Workflow.<br />
Die Integration opt<strong>im</strong>iert das Prozessengineering und<br />
führt so zu kürzeren Projektlaufzeiten. Durch automatisierten<br />
Datenabgleich existiert stets eine aktuelle Anlagendokumentation.<br />
Bei der Instandhaltung<br />
kann auf die aktuellen und engineerten<br />
Daten zurückgegriffen werden.<br />
Viele der manuell zu verarbeitenden<br />
Prozessdaten werden teilweise schon<br />
heute vollständig automatisch in unterschiedliche<br />
Systeme übertragen.<br />
Gerätedaten, die bisher nur über Messstellenblätter<br />
ausgetauscht wurden,<br />
können durch webbasierte Tools mit<br />
entsprechenden Schnittstellen nicht<br />
nur in der Verfahrensplanung und <strong>im</strong><br />
Basic Engineering, sondern auch <strong>im</strong><br />
Einkauf für die Beschaffung genutzt<br />
werden. Dadurch werden manuelle<br />
Eingaben vermieden, Zeit und Datenkonsistenz<br />
erhöht.<br />
Den Siemens-Hauptvortrag <strong>im</strong> Eröffnungsplenum<br />
ergänzen drei Beiträge<br />
der Namur, die Aspekte des Vortrags<br />
aufgreifen und die Sicht der Anwender darstellen werden.<br />
Dabei werden wichtige Fragen zum Datenaustausch, zu<br />
einheitlichen Schnittstellen und Vorteile eines aktuellen<br />
Datenmodells während der Betriebsphase behandelt.<br />
Eine Vielzahl von Workshop-Beiträgen aus den Arbeitsfeldern<br />
der Namur, von internationalen Kooperationspartnern<br />
sowie weitere Vorträge des diesjährigen Partners<br />
der Hauptsitzung zum Schwerpunktthema laden die<br />
Zuhörer zum Besuch ein. Zudem erwarten die Teilnehmer<br />
weitere Vorträge zu aktuellen Problemen. Auch das<br />
übergeordnete Thema Industrie 4.0 wird die Namur zur<br />
Diskussion stellen. <br />
(gz)<br />
NAMUR-GESCHÄFTSSTELLE,<br />
c/o Bayer Technology Services GmbH,<br />
Gebäude K 9, D-51368 Leverkusen,<br />
Tel. +49 (0) 214 307 10 34, Internet: www.namur.de<br />
NE 151 unterstützt Koexistenz von Funkanwendungen<br />
Mit dem Thema Frequenzmanagement beschäftigt sich<br />
die neu erschienene Namur-Empfehlung NE 151. Im<br />
Mittelpunkt der Empfehlung stehen die systematische<br />
Erfassung und Verwaltung aller Funkanwendungen sowie<br />
die Definition von Rollen und Verantwortlichkeiten.<br />
Die NE 151 soll dabei helfen, die Koexistenz von Funkanwendungen<br />
sicherzustellen, das heißt einen wirtschaftlichen<br />
und störungsfreien Betrieb ermöglichen und Planungssicherheit<br />
bei der Einführung von industriellen<br />
Funkanwendungen bieten.<br />
Funkfrequenzen sind eine begrenzte Ressource, die in<br />
unterschiedlichen Nutzungsfeldern (etwa industrielle<br />
Anwendungen, Consumer-Anwendungen) zum Einsatz<br />
kommt. Um den gleichzeitigen störungsfreien Betrieb<br />
mehrerer Funkanwendungen (Koexistenz) zu ermöglichen,<br />
kommt der Regulierung der Frequenznutzung derzeit<br />
eine große Bedeutung zu. <br />
(aha)<br />
NAMUR-GESCHÄFTSSTELLE<br />
c/o Bayer Technology Services GmbH,<br />
Gebäude K9, D-51368 Leverkusen,<br />
Tel. +49 (0) 214 307 10 34,<br />
Internet: www.namur.de<br />
10<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
Nach Mitgliederbefragung: Sensorverband AMA<br />
erweitert Ausrichtung auf Messtechnik<br />
Die Mitgliederversammlung des AMA Fachverband<br />
für Sensorik hat beschlossen, seinen Namen und die<br />
Ausrichtung zum AMA Fachverband für Sensorik und<br />
Messtechnik zu ändern. Der Verband hatte seine rund<br />
480 Mitglieder befragt, um seine Positionierung und das<br />
eigene Profil zu überprüfen. Nach Angaben des AMA<br />
zeigten die Ergebnisse, dass sich der Verband für Sensorik<br />
längst zu einem Verband für Sensorik und Messtechnik<br />
entwickelt hat.<br />
„Nach der Ausrichtung der eigenen Unternehmen befragt,<br />
zeigte sich, dass bereits heute mehr als die Hälfte<br />
aller AMA-Mitglieder sowohl in der Sensorik als auch<br />
in der Messtechnik behe<strong>im</strong>atet sind. Die Neuausrichtung<br />
des Verbandes vernetzt und vereint die Innovatoren<br />
der gesamten Messkette vom Sensorelement bis<br />
zum Messergebnis“, sagte Vorstandsvorsitzender Wolfgang<br />
Wiedemann.<br />
Der AMA Verband für Sensorik und Messtechnik startet<br />
parallel zur Umbenennung einen neuen Webauftritt<br />
unter www.ama-sensorik.de. <br />
(aha)<br />
AMA VERBAND FÜR SENSORIK UND MESSTECHNIK E.V.,<br />
Sophie-Charlotten-Str. 15, D-14059 Berlin,<br />
Tel. +49 (0) 30 221 90 36 20,<br />
Internet: www.ama-sensorik.de<br />
VORSTAND DES AMA 2013: Schatzmeister<br />
Johannes Steinebach, AMA-Geschäftsführer<br />
Dr. Thomas S<strong>im</strong>mons, stellv. Vorsitzender Peter<br />
Krause, Schriftführer Peter Scholz, Vorsitzender<br />
Wolfgang Wiedemann, Vorsitzender des<br />
Wissenschaftsrats Andreas Schütze (v.l.n.r.).<br />
Bild: AMA Verband für Sensorik und Messtechnik<br />
Feldbusunabhängig<br />
in den Ex-Bereich!<br />
Ausgelegt für den Ex-Bereich:<br />
• Zugelassen für den Einsatz in Zone 2/22<br />
• Ex i I/O-Module zum Anschluss eigensicherer Sensorik/Aktorik<br />
• Zertifiziert gemäß ATEX, IECEx, UL ANSI/ISA 12.12.01, UL508,<br />
Schiffbau, GOST-R, etc.<br />
Safety meets Ex i:<br />
• Vereint in einem Modul: Funktionale Sicherheit und Explosionsschutz<br />
Kompakt, Flexibel & Modular:<br />
• Kleinste, feldbusunabhängige Steuerung (SPS)<br />
• Programmierbar gemäß IEC 61131-3<br />
• Über 400 verschiedene I/O-Module<br />
• Standard-I/O- und Ex i-Module kombinierbar<br />
• Einspeisungen verschiedener Potentiale in einem Knoten<br />
• Unterstützung der Fernwirkprotokolle IEC 60870 und IEC 61850<br />
CAGE CLAMP ® -Technologie:<br />
• Gasdichte Federklemmverbindung<br />
• Vibrationsfest und wartungsfrei<br />
• Hohe Anlagenverfügbarkeit und -zuverlässigkeit<br />
www.wago.com/ex
INTERVIEW<br />
„Aufgabe der Automatisierer ist es,<br />
den Visionen rund um ‚Industrie 4.0‘<br />
Bodenhaftung zu geben“<br />
<strong>atp</strong>-Chefredakteur Leon Urbas fordert Stefan Kowalewski<br />
zur Standortbest<strong>im</strong>mung der Automatisierer in der Debatte<br />
um cyber-physische Systeme auf<br />
Prof. Dr.-Ing. Stefan Kowalewski ist Inhaber des Lehrstuhls Informatik 11 Software für eingebettete Systeme an der<br />
RWTH Aachen und Leiter des GMA-Fachausschusses 7.20 Cyber Physical Systems (CPS). Im Gespräch mit dem<br />
Chefredakteur der <strong>atp</strong>-<strong>edition</strong>, Prof. Dr.-Ing. Leon Urbas, informiert er über den Unterschied zwischen cyber-physischen<br />
Systemen und dem gehypten Begriff „Industrie 4.0“. Als roter Faden zieht sich seine Forderung nach Kooperation<br />
zwischen Informatikern und Automatisierern durch das Gespräch. Im Interview nennt er erfolgreiche Forschungsprojekte,<br />
die bereits über große Distanzen vernetzt miteinander arbeiten.<br />
<strong>atp</strong> <strong>edition</strong>: Auf der Diskussionsrunde während des GMA-<br />
Kongresses Automation haben Sie cyber-physische Systeme<br />
als eine Evolution eingebetteter Systeme bezeichnet. Welchen<br />
Druck auf die Entwicklung nehmen Sie dort wahr? Kann<br />
man daraus heute schon Entwicklungspfade erkunden?<br />
STEFAN KOWALEWSKI: Cyber-physische Systeme als Weiterentwicklung<br />
der eingebetteten Systeme zu betrachten,<br />
ist, flapsig gesagt, hinsichtlich der Forschungsförderung<br />
richtig. Inhaltlich sind wir tatsächlich aber auch schon weit.<br />
Wir sind jetzt in der Lage komplexe eingebettete Systeme<br />
so zu entwickeln, dass sie den Qualitätsanforderungen<br />
entsprechen. Wir können die Systeme stärker vernetzen<br />
als bisher, nicht nur lokal. Wir können öffentlich verfügbare<br />
Netze anwählen, um eingebettete Systeme zu verbinden.<br />
Dadurch realisieren wir Anwendungen, die vorher nicht<br />
möglich waren. Die Optionen sind da und wollen genutzt<br />
werden. Wir müssen nun flexibler auf Kundenaufträge und<br />
Betreiber reagieren. So entsteht der Druck auf die Weiterentwicklung<br />
der cyber-physischen Systeme.<br />
<strong>atp</strong> <strong>edition</strong>: Edward Lee aus Berkeley forderte 2008 „To<br />
realize the full potential of CPS, we will have to rebuild<br />
computing and networking abstractions. These abstractions<br />
will have to embrace physical dynamics and computation<br />
in a unified way.“ Aus dem, was Sie eingangs sagten,<br />
kann man also schließen, dass sich die Herausforderungen<br />
<strong>im</strong> Bereich Design in den letzten fünf Jahren <strong>im</strong>mer weiter<br />
verringert haben. Warum sollte uns die über 80 Jahre erfolgreich<br />
eingesetzte und kontinuierlich weiterentwickelte<br />
Abstraktion der Kybernetik und der Systemtheorie nicht<br />
mehr ausreichen? Reden wir hier am Ende nicht doch über<br />
alten Wein in neuen Schläuchen?<br />
STEFAN KOWALEWSKI: Nein, finde ich nicht. Lee forderte<br />
ja eine einheitliche Beschreibung für alles, die diskrete Welt<br />
des Rechners, die physikalische Welt der automatisierten<br />
Anlage und die der Netzwerke. Das halte ich für illusorisch.<br />
Es wird <strong>im</strong>mer unterschiedliche Beschreibungen, eine unterschiedliche<br />
Mathematik geben. Das muss man eben verbinden.<br />
Methodisch geht es um hybride Systeme, also Systeme<br />
die diskrete und kontinuierliche Dynamik verknüpfen. In der<br />
Forschung befassen wir uns schon seit den 90er-Jahren damit,<br />
beispielsweise <strong>im</strong> DFG-Schwerpunkt-Programm Kondisk<br />
(Analyse und Synthese kontinuierlich-diskreter Systeme,<br />
1996-2002, Anm. der Redaktion) Mittlerweile hat sich eine<br />
internationale Community aufgebaut, etwa die Tagung Hybrid<br />
Systems: Computation and Control, bei der Informatiker und<br />
Regelungstechniker zusammenkommen.<br />
Diese Tagung, die es seit rund 15 Jahren gibt, ist nun interessanterweise<br />
unter das Dach der CPS Week gerutscht.<br />
Das Beispiel hybride Systeme zeigt mir, dass die<br />
Kybernetik oder die klassische Regelungstechnik nicht<br />
ausreicht. Methodisch kämpfen wir <strong>im</strong>mer noch damit,<br />
hybride Systeme skalierbar zu analysieren. Die diskrete<br />
und kontinuierliche Seite bekommt man jeweils einzeln<br />
in den Griff; durch die Kombination haben wir einen prinzipiell<br />
schwierig zu behandelnden Zustandsraum, bei dem<br />
verschiedene Abstraktionstechniken zur Analyse genutzt<br />
werden müssen. Da sind wir einfach noch nicht so weit,<br />
wie wir für eine breite praktische Anwendung sein<br />
müssten, obwohl wir seit 15 Jahren daran arbeiten. Wir<br />
können zwar die Systeme beschreiben und s<strong>im</strong>ulieren, es<br />
sind aber bessere Methoden zur mathematisch rigorosen<br />
Analyse gefragt.<br />
<strong>atp</strong> <strong>edition</strong>: Damit ist eine Wissenslücke identifiziert gibt<br />
es weitere „Roadblocker“ auf dem Weg zu den cyber-physischen<br />
Systemen?<br />
STEFAN KOWALEWSKI: Wir können bei diesen Systemen<br />
eigentlich <strong>im</strong>mer nur die Komponenten entwickeln. Wir<br />
bauen sie nicht als Ganzes, mit allen Anforderungen, die<br />
12<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
PROF. DR.-ING.<br />
STEFAN KOWALEWSKI<br />
ist seit November 2003<br />
Professor an der Fakultät<br />
für Mathematik, Informatik<br />
und Naturwissenschaften<br />
an der RWTH<br />
Aachen. Seinen<br />
Forschungsschwerpunkt<br />
bilden Entwurfs- und<br />
Analysemethoden für<br />
softwareintensive<br />
eingebettete Systeme.<br />
sich während der Lebenszeit der Systeme ergeben. Wir<br />
entwerfen also die Komponenten mit Unsicherheiten. Wir<br />
wissen nicht, in welchem Kontext die Komponenten benutzt<br />
werden und in welchen Systemen sie kommunizieren<br />
müssen. Schnittstellen sind dabei viel wichtiger als<br />
bei einer integrierten Systementwicklung. Dabei benötigen<br />
wir mehr als die Syntax, nämlich auch semantische<br />
Informationen. Einige Ansätze gibt es bereits, sie sind<br />
aber noch nicht in die Praxis übertragen worden.<br />
<strong>atp</strong> <strong>edition</strong>: Wenn ich mir die Ansätze aus der Informatik<br />
anschaue, sind das alles verkürzte Beschreibungen von<br />
„Services“ diese hören aber üblicherweise vor der formalen<br />
Beschreibung der Funktion auf. Ich kenne momentan<br />
keine Servicebeschreibungssprache der Informatik, mit<br />
der ich ausdrücken kann: Dieser Service hat diese spezifische<br />
Aufgabe.<br />
STEFAN KOWALEWSKI: Für mich bedeutet ein serviceorientierter<br />
Ansatz, dass er mit dieser Problematik zurechtkommt.<br />
Das heißt, ich entwerfe Systeme und weiß<br />
noch nicht genau, wie sie zusammenwirken. Da sind Dienste<br />
geeignet, weil sie allgemein formuliert sind und kontext-<br />
und situationsabhängig angefordert werden können.<br />
Aber: Sie haben Recht, der Dienst muss sagen, was er<br />
kann. Sicherlich ein Thema, das man sich anschauen muss.<br />
<strong>atp</strong> <strong>edition</strong>: Das leitet über zu einem anderen Thema.<br />
Offensichtlich ist die Problematik disziplinübergreifend.<br />
Da müssen Bündnisse eingegangen werden. Welche Allianzen<br />
müssen auf nationaler, europäischer – beispielsweise<br />
<strong>im</strong> Forschungsrahmenprogramm Horizon 2020 – und<br />
weltweiter Ebene geschmiedet werden, um hier voranzukommen?<br />
In welchen Allianzen ist die deutsche Automatisierungstechnik<br />
vertreten?<br />
STEFAN KOWALEWSKI: Vor allem in den Ausschüssen der<br />
GMA, in denen Automatisierer und Informatiker zusammen<br />
kommen, arbeiten wir daran. Es gibt die wissenschaftlichen<br />
Communites, beispielsweise rund um hybride Systeme,<br />
die schon länger existieren und nun CPS in den Fokus<br />
genommen haben. Es gibt die Industrie 4.0-Plattform, die<br />
stark von Informationstechnik und Industrie geprägt wird.<br />
Was Horizon 2020 in der Hinsicht enthalten wird, da bin ich<br />
selber gespannt.<br />
<strong>atp</strong> <strong>edition</strong>: Welchen entscheidenden Beitrag leistet dabei<br />
die Automatisierungstechnik für die Weiterentwicklung von<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
13
INTERVIEW<br />
CPS? Es müsste etwas sein, was die Informatik nicht kann,<br />
aber auch etwas, was die Anwendung nicht kann. Ich sehe<br />
die Automatisierer heute als Bindeglied der Prozess- und<br />
Produktionsdomäne und der informatischen Darstellung.<br />
Wo liegt eigentlich unsere Kernkompetenz?<br />
STEFAN KOWALEWSKI: Ich sehe das genauso. Wir kennen<br />
ja die Skeptiker, die beispielsweise das Acatech-Papier<br />
„Cyber-Physical Systems“ als nicht realisierbar ablehnen.<br />
Der Wert dieses Papieres ist aber gerade die Entwicklung<br />
einer Vision. Die Aufgabe der Automatisierer ist es jetzt,<br />
diesen Visionen Bodenhaftung zu geben, das heißt, wirkliche<br />
Anforderungen einzubringen.<br />
Ich kenne die Kommunikationsschwierigkeiten zwischen<br />
Ingenieuren und Informatikern sehr gut aus eigener Erfahrung.<br />
Ich bin selbst „gelernter“ Elektrotechniker, arbeite<br />
seit über 20 Jahren mit Informatikern zusammen<br />
und bin schließlich selbst einer geworden. Bevor sich ein<br />
Informatiker und ein Automatisierer verstehen, vergeht<br />
eine gewisse Zeit. Automatisierungstechniker wissen,<br />
dass sie eine technische Anlage – vor allem ihre Dynamik<br />
– verstehen müssen. Wenn sie die nicht begriffen haben,<br />
können sie auch das System nicht automatisieren. Ich<br />
glaube, dieser wesentliche Punkt kommt bei den Visionen<br />
zu CPS noch zu kurz. Eine Aufgabe der Automatisierungstechniker<br />
wäre, ihr Verständnis hier einzubringen. Andererseits<br />
sind auch die Methoden, mit denen Automatisierer<br />
arbeiten, als fundiertes Know-how zu verstehen. Wir<br />
müssen einfach besser darüber informieren, was wir bereits<br />
können. Da gibt es exzellentes Wissen in den Bereichen<br />
Regelungstechnik, hybride Systeme, Safety sowie<br />
Methoden für sich ändernde Anforderungen und Regulationen.<br />
Mittlerweile ist die Automation auch <strong>im</strong> Bereich<br />
Informationssicherheit gut unterwegs.<br />
„Unter cyber-physischen Systemen<br />
verstehe ich die Technologie,<br />
mit der man Industrie 4.0 realisiert.“<br />
<strong>atp</strong> <strong>edition</strong>: Sie haben das Acatech-Papier angesprochen.<br />
Da kommt einem natürlich sofort „Industrie 4.0“ in den<br />
Sinn. Mir fällt es schwer, eine Grenze zwischen Industrie<br />
4.0 und CPS zu ziehen. Brauchen wir CPS, um die in dem<br />
Papier beschriebenen Use Cases umzusetzen oder ist mit<br />
„Industrie 4.0“ etwas komplett anderes gemeint?<br />
STEFAN KOWALEWSKI: Es gibt große Überschneidungen.<br />
Unter CPS würde ich die Technologie verstehen, mit der<br />
man „Industrie 4.0“ realisiert. Wir haben schon die Automatisierungssysteme,<br />
die mit den physikalischen Anlagen<br />
zusammenarbeiten. Durch die Vernetzung erhalten wir die<br />
cyber-physischen Systeme. Das ist ein wesentlicher Teil<br />
von „Industrie 4.0“. Die Initiative ist derzeit fokussiert auf<br />
industrielle Produktion. CPS sind jedoch mehr. Die Beispiele<br />
<strong>im</strong> Acatech-Papier betreffen unser ganzes tägliches<br />
Leben: Verkehr, Gesundheitssysteme oder Smart Cities<br />
etwa. Alles, was man sich vorstellen kann, wird in diesem<br />
Papier vernetzt. Wir finden CPS auch in der Produktautomatisierung,<br />
die bei „Industrie 4.0“ keine Rolle spielt. Inhaltlich<br />
ist CPS also breiter gefasst. Auf der anderen Seite<br />
geht es bei „Industrie 4.0“ auch um Prozessfragen und<br />
Geschäftsmodelle; das geht nach meinem Verständnis<br />
über CPS als Technologiebegriff hinaus.<br />
<strong>atp</strong> <strong>edition</strong>: Wir verlagern also Funktionen, die heute noch<br />
Menschen innehaben, in diese Systeme. Wir automatisieren<br />
die Automatisierung. Haben wir die Methoden dafür?<br />
Können wir diese in einem eingebetteten System, mit dessen<br />
beschränkten Ressourcen, unterbringen?<br />
STEFAN KOWALEWSKI: Die Systeme müssen mit verstärkter<br />
lokaler Intelligenz ausgestattet sein, da man nicht genau<br />
weiß, in welchem Umfeld sie später arbeiten. Sie müssen<br />
adaptiv, selbst organisiert und selbst heilend werden. Das<br />
kann man zunächst versuchen, in einem begrenzten Umfang<br />
deterministisch zu realisieren. So wird man vielleicht<br />
anfangen, irgendwann muss man aber auch mächtigere<br />
Adaptionsmethoden wie Künstliche Intelligenz einbringen.<br />
Ich glaube, dass in fünf oder zehn Jahren eine Lernkomponente<br />
in CPS selbstverständlich sein wird. Die Frage ist<br />
dann natürlich: Wie sichern wir das ab? Es ist auch noch<br />
unklar, welche Anwendungsfelder das betreffen wird.<br />
<strong>atp</strong> <strong>edition</strong>: An welchen Stellen kann das Gefundene bereits<br />
heute mit einem passenden Geschäftsmodell in Innovation<br />
umgesetzt werden? In welchen Bereichen erwarten<br />
Sie die ersten CPS-Produkte?<br />
STEFAN KOWALEWSKI: Die Grenze von herkömmlichen<br />
Systemen zu CPS ist ja fließend. Wir haben heute bereits SPS,<br />
die mit dem Internet verbunden sind. Natürlich wird der Weg<br />
über einfache Anwendungen gehen. Es wäre zum Beispiel<br />
schon interessant, Wetterdaten in die Automatisierung best<strong>im</strong>mter<br />
Prozesse eingehen zu lassen, die Anlage also gemäß<br />
vorher gesagter Temperaturentwicklungen zu steuern.<br />
14<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
<strong>atp</strong> <strong>edition</strong>: Welche Entwicklungsstufen werden wir wahrnehmen?<br />
STEFAN KOWALEWSKI: Die Architekturen müssen sicher<br />
sein. Zuerst werden die betriebs- oder firmeneigenen<br />
Cloud-Dienste kommen, in überschaubarer Zeit aber auch<br />
wirklich offene Architekturen. Letztendlich bleibt die Frage,<br />
was entscheidet: Die Sicherheitsrisiken durch die Öffnung<br />
– die man in den Griff bekommen kann – oder der<br />
Flexibilitäts- und Effizienzgewinn?<br />
<strong>atp</strong> <strong>edition</strong>: Der GMA-Fachausschuss 7.20 wurde <strong>im</strong> Mai<br />
vergangenen Jahres gegründet. Als erstes nach außen<br />
sichtbares Ergebnis veröffentlichte der Ausschuss zur Hannover<br />
Messe 2013 ein viel beachtetes Positionspapier rund<br />
um die Thematik CPS. Wie sieht die weitere Roadmap des<br />
Fachausschusses aus? Welchen Beitrag können wir aus dem<br />
Fachausschuss zur aktuellen Diskussion erwarten?<br />
STEFAN KOWALEWSKI: Das Papier hat die CPS gut zusammengefasst<br />
und eine von Vielen getragene, praktisch<br />
brauchbare Definition geliefert. Zielführend sind auch die<br />
formulierten Thesen, die erläutern, was künftig wichtig<br />
wird. Zurzeit erarbeiten wir unter anderem Referenzszenarien,<br />
die anhand konkreter Beispielanlagen den Unterschied<br />
zwischen herkömmlicher und CPS-basierter Automatisierung<br />
illustrieren, den Nutzen von CPS deutlich<br />
machen und den bestehenden Forschungsbedarf identifizieren.<br />
Eine weitere Aufgabe besteht in der Schärfung von<br />
CPS-bezogenen Begriffen. Hier arbeiten wir eng mit dem<br />
GMA-Fachausschuss 7.20 Industrie 4.0 zusammen, der die<br />
dort relevante Begriffswelt <strong>im</strong> Hinblick auf die nötige Normierung<br />
behandelt.<br />
<strong>atp</strong> <strong>edition</strong>: Zuletzt: Können Sie bereits Anstrengungen<br />
beobachten, den Ingenieurnachwuchs auf die Herausforderungen<br />
der CPS vorzubereiten? Wird es ein Curriculum<br />
CPS geben?<br />
STEFAN KOWALEWSKI: Es braucht keine CPS-Studiengänge.<br />
Erstens handelt es sich bei konkreten Technologien<br />
<strong>im</strong>mer um vergängliches Wissen, zweitens würde man von<br />
den Studenten eine zu starke Spezialisierung verlangen.<br />
Das Thema gehört in die einschlägigen Studiengänge Elektrotechnik,<br />
Automatisierungstechnik oder Informatik. CPS<br />
werden in Teams unter anderem aus Informatikern und<br />
Elektrotechnikern entwickelt werden. Leute mit Spezialkenntnissen<br />
ihrer Domänen müssen an einem Tisch sitzen.<br />
Das ist wichtig. Die Disziplinarität des Einzelnen ist Voraussetzung<br />
für ein erfolgreiches interdisziplinäres Projekt.<br />
Für CPS werden Themen wie Modellierung, hybride Systeme,<br />
S<strong>im</strong>ulation, diskrete und kontinuierliche Systeme<br />
und Software-Engineering gebraucht. Wir sollten Studenten<br />
dann jedoch auch an cyber-physischen Systemen<br />
ausbilden. Bislang arbeiten wir in lokal angelegten Laboren.<br />
In der Initiative TuLaut (Theorie und Lehre der Automatisierungstechnik,<br />
www.tulaut.de) haben wir begonnen,<br />
Demonstratoren über große Distanzen mittels Internet zu<br />
verbinden und so große CPS zu realisieren. Das werden<br />
wir weiter ausbauen.<br />
Die passende Füllstand- und Druckmesstechnik<br />
können Sie lange suchen ...<br />
... oder schnell finden.<br />
Das Einfacher-ist-besser-Prinzip<br />
von VEGA.<br />
VEGA hat das „Einfacher-ist-besser“-Prinzip konsequent<br />
zu Ende gedacht. Die Geräteplattform plics ® löst alle<br />
Messaufgaben rund um Füllstand und Druck, und dies<br />
seit 10 Jahren.<br />
9 leichte Geräteauswahl<br />
9 schnelle Lieferung<br />
9 kinderleichte Montage<br />
www.vega.com/plics<br />
9 einfache Inbetriebnahme<br />
9 sicherer Betrieb<br />
9 schneller Service<br />
<strong>atp</strong> <strong>edition</strong>: Prof. Kowalewski, wir danken Ihnen für dieses<br />
Gespräch.
PRAXIS<br />
Steuerungstechnik ermöglicht effiziente Kühlung<br />
<strong>im</strong> Frankfurter Rechenzentrum von BT Germany<br />
Mischbetrieb zwischen freier Kühlung und Kältemaschinen spart Energiekosten<br />
Energieeinsparung wird für Rechenzentren <strong>im</strong>mer<br />
wichtiger. Daher sollen neue Kühlsysteme nachhaltig<br />
arbeiten und damit Energiekosten einsparen. Auch in<br />
bestehenden Rechenzentren ist eine Opt<strong>im</strong>ierung des<br />
Kühlkonzepts sinnvoll, weil dadurch die Wirtschaftlichkeit<br />
erhöht wird. Die Verbesserung wird zum einen<br />
durch einen hohen Wirkungsgrad der eingesetzten Komponenten,<br />
aber auch durch die Nutzung einer zusätzlichen<br />
Freikühlung erreicht.<br />
Bei der freien Kühlung erkaltet das Medium durch die<br />
Umgebungsluft, also ohne dass Kältemaschinen zum<br />
Einsatz kommen. Um einen Mischbetrieb zwischen freier<br />
Kühlung und Kältemaschinen fahren zu können, ist<br />
eine stetige Regelung erforderlich, die sich mit intelligenter<br />
Steuerungstechnik realisieren lässt. Die SPS von<br />
Phoenix Contact erfüllen alle Anforderungen und tragen<br />
somit dazu bei, die Energieeffizienz und Nachhaltigkeit<br />
von Rechenzentren zu steigern.<br />
ERARBEITUNG EINES UNTERBRECHUNGSFREIEN<br />
KLIMATISIERUNGSKONZEPTS FÜR BT GERMANY<br />
In Rechenzentren verursachen nicht nur die Server Energiekosten.<br />
Zu den großen Verbrauchern zählt darüber<br />
hinaus die gesamte Peripherie wie die Kühlung oder die<br />
Unterbrechungsfreie Stromversorgungs-(USV-)Anlage.<br />
Werden diese Anlagenteile energieeffizient und nachhaltig<br />
ausgelegt, lassen sich die Betriebskosten erheblich<br />
senken. Allerdings müssen die hohen Ansprüche an die<br />
Verfügbarkeit des Rechenzentrums weiterhin berücksichtigt<br />
und möglichst ohne Einfluss auf die Effizienz<br />
erfüllt werden. In dem Rechenzentrum von BT Germany<br />
sorgen die Steuerungen der Produktfamilie Inline und<br />
das Redundanzkonzept von Phoenix Contact für eine<br />
unterbrechungsfreie Funktion bei gleichzeitig niedrigem<br />
Energieverbrauch.<br />
Die Bereitstellung von IT-Infrastruktur und somit der<br />
Betrieb von Rechenzentren gehört zu den Hauptgeschäftsfeldern<br />
der BT Germany, einem Tochterunternehmen der<br />
BT Group (British Telecommunications). Der Anbieter von<br />
Kommunikationslösungen und -services unterhält weltweit<br />
45 Rechenzentren, davon zwei in Frankfurt am Main.<br />
Einer der beiden Standorte wurde gerade neu errichtet und<br />
entspricht daher dem aktuellen Energieeffizienzstandard.<br />
DAS NEUE KÜHLSYSTEM bei BT in Frankfurt-<br />
Bonames senkt die Betriebskosten erheblich.<br />
MISCHBETRIEB KANN ENERGIEVERBRAUCH UM BIS ZU<br />
2,8 MILLIONEN KWH PRO JAHR SENKEN<br />
Um den Stromverbrauch des in den 1990er-Jahren erbauten<br />
Rechenzentrums in Frankfurt-Bonames zu verringern,<br />
wurde das Unternehmen Bit mit der Detailplanung und<br />
Umsetzung eines durch die Fachabteilung von BT Germany<br />
erarbeiteten, energieeffizienteren Kl<strong>im</strong>atisierungskonzepts<br />
beauftragt. Bit ist als Generalunternehmen <strong>im</strong> Rechenzentrumsbau<br />
tätig. Als Solution Partner von Phoenix<br />
Contact <strong>im</strong> Umfeld von Rechenzentren hat Bit das Projekt<br />
von BT Germany auf Basis der Geräte des Blomberger Herstellers<br />
von Automatisierungstechnik umgesetzt.<br />
Nach Abschluss der Umbauarbeiten weist das Rechenzentrum<br />
in Frankfurt-Bonames eine höhere Energieeffizienz<br />
auf. „Bei der Modernisierung wurden die herkömmlichen<br />
Split-Kl<strong>im</strong>ageräte mit einem eher hohen Stromverbrauch<br />
gegen eine wirkungsvollere Kl<strong>im</strong>atisierung auf<br />
der Grundlage von hoch effizienten Kältemaschinen und<br />
freier Kühlung ausgetauscht“, erläutert Michael Botzem,<br />
Programmierer bei Bit. „Das neue Kl<strong>im</strong>akonzept senkt<br />
den Energieverbrauch für die Kl<strong>im</strong>atisierung <strong>im</strong> Sommer<br />
um 50 Prozent und <strong>im</strong> Winter sogar um 85 Prozent. In<br />
absoluten Zahlen ausgedrückt bedeutet dies eine jährliche<br />
Einsparung von 2,8 Millionen kWh, was einem sechsstelligen<br />
Euro-Betrag entspricht.“ Dies gilt unter der Annahme<br />
einer konstanten IT-Last.<br />
Um das Projekt zu realisieren, suchte Bit eine flexible<br />
und redundante Steuerungslösung mit verschiedenen<br />
Möglichkeiten der Kommunikation und Visualisierung.<br />
Zudem kam der Redundanzfähigkeit der Geräte eine große<br />
Bedeutung zu, da die Ausfallsicherheit neben der<br />
Energieeffizienz der wichtigste Faktor für die Peripherie<br />
eines Rechenzentrums ist.<br />
16<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
MICHAEL BOTZEM, PROGRAMMIERER BEI BIT:<br />
„Das neue Kl<strong>im</strong>akonzept senkt den<br />
Energieverbrauch für die Kühlung<br />
<strong>im</strong> Sommer um 50 Prozent und <strong>im</strong><br />
Winter sogar um 85 Prozent.“<br />
DIE INLINE-STEUERUNG ILC 370 PN<br />
von Phoenix Contact fungiert als<br />
zentrale Einheit des Kühlsystems.<br />
REDUNDANTER AUFBAU DER KÄLTEMASCHINEN<br />
SICHERT HOHE VERFÜGBARKEIT<br />
Im modernisierten Rechenzentrum in Frankfurt-Bonames<br />
kommen unterschiedliche Komponenten von<br />
Phoenix Contact wie Steuerungen, Switches, Bedienenund-Beobachten-<br />
sowie Energiemessgeräte zum Einsatz.<br />
Die hohen Anforderungen an die Verfügbarkeit bedingen<br />
dabei einen redundanten Aufbau der Kältemaschinen<br />
sowie der Pumpen und Sensoren. Denn ein Ausfall der<br />
Kl<strong>im</strong>atisierung als Single Point of Failure (SPoF) muss<br />
ausgeschlossen werden, um den Betrieb der Server zu<br />
jeder Zeit sicherstellen zu können. Daher wurden die<br />
Kälteanlagen in zwei baugleichen Räumen mit identischer<br />
Ausstattung installiert. „Die Möglichkeit der redundanten<br />
Verschaltung der Inline-Controller ILC 370 PN<br />
mittels applikativer Systemredundanz garantiert hier<br />
eine hohe Verfügbarkeit“, erklärt Botzem. „Im Notfall<br />
schaltet das System sofort von der einen auf die andere<br />
Kälteanlage um, die die Leistung dann komplett übern<strong>im</strong>mt.<br />
Alle Anlagenwerte werden zentral in der Steuerung<br />
gesammelt und verarbeitet.“<br />
Die Regelung der Kl<strong>im</strong>atisierung zwischen freier Kühlung<br />
und Kältemaschinen spielt eine besondere Rolle. Je<br />
länger ein Mischbetrieb zwischen beiden Varianten umsetzbar<br />
ist, desto mehr Energie wird eingespart. Eine<br />
möglichst genaue Regelung best<strong>im</strong>mt hier, wie effizient<br />
und damit wirtschaftlich die Kühlung arbeitet. Für diesen<br />
Prozess zeichnet die Inline-Steuerung ILC 370 PN<br />
mit selbstopt<strong>im</strong>ierenden PDPI-Reglern verantwortlich,<br />
wobei sich die entsprechenden Funktionsbausteine als<br />
vordefinierte Bibliothek in die Engineering-Software PC<br />
Worx von Phoenix Contact integrieren lassen.<br />
DAS BEDIENEN-UND-BEOBACHTEN-GERÄT ERFASST<br />
ALLE RELEVANTEN BETRIEBSDATEN<br />
In der Anlage werden rund 250 digitale und analoge Signale<br />
kontinuierlich erfasst und verarbeitet. Das Rechenzentrum<br />
musste <strong>im</strong> laufenden Betrieb ohne Ausfallzeiten<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
17
PRAXIS<br />
DAS BEDIENEN-UND-BEOBACHTEN-GERÄT<br />
von Phoenix Contact zeigt die Energiedaten und<br />
Kälteleistung der Kälteanlage an.<br />
modernisiert werden. Aufgrund der Erweiterbarkeit der<br />
Steuerung um die I/O-Module aus dem Inline-Automatisierungsbaukasten<br />
war ein flexibler Aufbau und somit eine<br />
genaue Anpassung an die benötigten Ein- und Ausgangssignale<br />
möglich. Zudem lässt sich die Anlage bis zum Erreichen<br />
der endgültigen Kälteleistung weiter ausbauen.<br />
Die Kommunikation über Profinet und Modbus TCP/<br />
RTU sowie ein passendes Redundanzkonzept waren zusätzliche<br />
Gründe, weshalb sich Bit für den ILC 370 PN<br />
von Phoenix Contact entschieden hat. Durch seine Flexibilität,<br />
die einfache Diagnose sowie die Nutzung von<br />
Redundanzmechanismen <strong>im</strong> Bedarfsfall erweist sich die<br />
Steuerung als besonders gut für die Verwendung in Rechenzentren<br />
geeignet. „Zu ihren Aufgaben gehören neben<br />
der Regelung die Erfassung der Betriebsstunden, das<br />
Melden von Störungen und Einsammeln der Daten der<br />
Kältemengenzähler, die Steuerung der Pumpen sowie<br />
die Aufnahme der momentanen Leistung und Messung<br />
der erzeugten Energie“, sagt Michael Botzem. „Die Betriebsdaten<br />
werden dann der Gebäudeleittechnik zur<br />
Verfügung gestellt und auf einem Bedienen-und-Beobachten-Gerät<br />
zur Anzeige gebracht.“ Der Datenaustausch<br />
mit den Kältemaschinen erfolgt über Modbus TCP, während<br />
das Energiemessgerät der Produktfamilie EMpro<br />
von Phoenix Contact die Leistung erfasst und via Modbus<br />
RTU an den ILC 370 PN überträgt.<br />
Durch den Aufbau des Profinet-Systems besteht die<br />
Möglichkeit, in Zukunft die einzelnen Server-Räume mit<br />
weiteren Profinet-Kopplern auszustatten und in die vorhandene<br />
Lösung zu integrieren. Die dafür beispielsweise<br />
aus den Umluftkühlgeräten erfassten Betriebsdaten<br />
lassen sich von der MSR-Steuerung (Kälteerzeugung)<br />
bereitstellen und können direkten Einfluss auf die Regelung<br />
nehmen. Das führt dazu, dass die Anlage besser auf<br />
den tatsächlichen Bedarf ausregelt werden kann.<br />
AUTOR<br />
BENJAMIN HOMUTH<br />
B.Sc. ist Mitarbeiter <strong>im</strong><br />
Produktmarketing des<br />
Geschäftsbereichs Control<br />
Systems bei Phoenix<br />
Contact Electronics GmbH<br />
in Bad Pyrmont.<br />
DIE KÄLTEANLAGEN wurden in zwei baugleichen Räumen mit<br />
identischer Ausstattung installiert. Bilder: Phoenix Contact<br />
Phoenix Contact GmbH & Co. KG,<br />
Flachsmarktstraße 8, D-32825 Blomberg,<br />
Tel. +49 (0) 5235 300,<br />
E-Mail: bhomuth@phoenixcontact.com<br />
18<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
Engineering von<br />
Prozessleitsystemen<br />
– so geht‘s<br />
Das praxisorientierte Lehrbuch befasst sich mit der Einrichtung von<br />
Prozessleitsystemen. Anhand einer exper<strong>im</strong>entellen Forschungsanlage<br />
werden die Herausforderungen hinsichtlich Anlagensicherheit und Anlagenverfügbarkeit<br />
dargestellt. Auch auf Modularisierung und virtuelle<br />
Inbetriebnahme von Anlagen geht der Autor ein.<br />
Hrsg.: Leon Urbas<br />
1. Auflage 2014<br />
ca. 300 Seiten, schwarz/weiß mit Schmuckfarbe, Hardcover<br />
ISBN: 978-3-8356-3362-9<br />
Preis: € 49,80<br />
www.di-verlag.de<br />
Das Buch erscheint <strong>im</strong> DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München<br />
Jetzt bestellen!<br />
WISSEN FÜR DIE<br />
ZUKUNFT<br />
Bestellung per Fax: +49 201 / 820 Deutscher 02-34 Industrieverlag oder GmbH abtrennen | Arnulfstr. und 124 <strong>im</strong> | Fensterumschlag 80636 München einsenden<br />
Ja, ich bestelle gegen Rechnung 3 Wochen zur Ansicht<br />
___Ex.<br />
Engineering von Prozessleitsystemen<br />
1. Auflage 2014 – ISBN: 978-3-8356-3362-9 für € 49,80 (zzgl. Versand)<br />
Firma/Institution<br />
Vorname, Name des Empfängers<br />
Straße / Postfach, Nr.<br />
Land, PLZ, Ort<br />
Telefon<br />
Telefax<br />
Antwort<br />
Vulkan-Verlag GmbH<br />
Versandbuchhandlung<br />
Postfach 10 39 62<br />
45039 Essen<br />
E-Mail<br />
Branche / Wirtschaftszweig<br />
Bevorzugte Zahlungsweise Bankabbuchung Rechnung<br />
Bank, Ort<br />
Widerrufsrecht: Sie können Ihre Vertragserklärung innerhalb von zwei Wochen ohne Angabe von Gründen in Textform (z.B.<br />
Brief, Fax, E-Mail) oder durch Rücksendung der Sache widerrufen. Die Frist beginnt nach Erhalt dieser Belehrung in Textform.<br />
Zur Wahrung der Widerrufsfrist genügt die rechtzeitige Absendung des Widerrufs oder der Sache an die Vulkan-Verlag GmbH,<br />
Versandbuchhandlung, Postfach 10 39 62, 45039 Essen.<br />
Bankleitzahl<br />
Ort, Datum, Unterschrift<br />
Kontonummer<br />
PAEVPL2013<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, dass ich<br />
vom DIV Deutscher Industrieverlag oder vom Vulkan-Verlag per Post, per Telefon, per Telefax, per E-Mail, nicht über interessante, fachspezifische Medien und Informationsangebote informiert und beworben werde.<br />
Diese Erklärung kann ich mit Wirkung für die Zukunft jederzeit widerrufen.
PRAXIS<br />
Neue Mess- und Steuerungstechnik sichert die<br />
Hochspannungsversuchsfelder der TU München<br />
Anpassung an aktuelle Anforderungen der Norm EN 50191:2010 gelang mit Lösung aus einer Hand<br />
DER 2,4 MV-STOSSSPANNUNGSGENERATOR ist durch eine<br />
Sicherheitslösung aus einer Sicherheits-SPS Pluto von ABB und<br />
einem LWL-Konverter von Phoenix geschützt. Bilder: ABB<br />
DIE 18 M HOHE TRANSFORMATORENKASKADE liefert<br />
eine max<strong>im</strong>ale Prüfwechselspannung von 1,2 MV.<br />
SICHERHEITS-SPS<br />
PLUTO B20 VON ABB<br />
und LWL-Konverter<br />
PSI-MOS-DNET CAN/FO<br />
von Phoenix für die<br />
galvanisch getrennte<br />
Datenübertragung<br />
zwischen dem<br />
2,4 MV-Stoßspannungsgenerator<br />
und dem<br />
Steuerstand.<br />
Am Lehrstuhl für Hochspannungs- und Anlagentechnik<br />
der Technischen Universität München wurden<br />
in den letzten Monaten sukzessive alle Hochspannungsversuchsfelder<br />
modernisiert. Soweit möglich und wirtschaftlich<br />
sinnvoll, wurden dabei die Hochspannungserzeuger<br />
weiterverwendet. Die zugehörige Mess- und<br />
Steuerungstechnik wurde jedoch komplett erneuert und<br />
in den sicherheitstechnischen Belangen an die aktuellen<br />
Anforderungen der Norm EN 50191:2010 angepasst. Zum<br />
Einsatz kamen dabei überwiegend Sicherheitskomponenten<br />
von ABB Stotz-Kontakt, die sich besonders gut in<br />
das spezielle Umfeld von Hochspannungsversuchsfeldern<br />
integrieren lassen.<br />
Dem Lehrstuhl für Hochspannungstechnik an der TU<br />
München stehen eine große Hochspannungs-Versuchshalle<br />
und zwei kleinere Hochspannungsversuchsfelder<br />
mit Prüfanlagen für hohe Wechsel-, Gleich- und Stoßspannungen<br />
sowie eine Prüfanlage für <strong>im</strong>pulsförmige Stoßströme<br />
zur Verfügung. Zusätzlich sind zehn Kleinversuchsstände<br />
mit Prüfspannungen von max<strong>im</strong>al 100 kV AC<br />
vorhanden, die auch der Lehre dienen. Erforscht werden<br />
auch Grundsatzfragen des Isoliervermögens und der Zustandsbewertung<br />
von hochspannungstechnischen Betriebsmitteln<br />
mit Gas- und Feststoffisolierungen sowie die<br />
Eigenschaften polymerer Isolierwerkstoffe.<br />
IMPULSFÖRMIGE STOSSSPANNUNGEN BIS 2,4 MV<br />
In den Generatoren zur Erzeugung <strong>im</strong>pulsförmiger Stoßspannungen<br />
werden <strong>im</strong>pulsförmige Prüfspannungen mit<br />
doppelexponentiellem Verlauf und einem Scheitelwert<br />
von bis zu zirka 2 400 kV erzeugt. Bei max<strong>im</strong>aler Ladespannung<br />
ist in den Kondensatoren des Stoßgenerators<br />
eine Energiemenge von 120 kJ elektrisch gespeichert. Vor<br />
dem Betreten des Versuchsfelds muss daher unbedingt<br />
sichergestellt sein, dass alle Kondensatorgruppen des<br />
Stoßgenerators auf ungefährliche Spannungen entladen<br />
sind. Hierfür stehen Entlade- und Kurzschlusseinrichtungen<br />
zur Verfügung.<br />
Hohe Prüfwechselspannungen von bis zu 1 200 kV(eff)<br />
werden mit Hilfe einer Transformatorenkaskade erzeugt.<br />
Über einen Einweggleichrichter und einen fest <strong>im</strong> Versuchsfeld<br />
installierten Kondensator können daraus hohe<br />
Gleichspannungen erzeugt werden. Auch hier muss sichergestellt<br />
sein, dass der Kondensator mit einer Glättungskapazität<br />
von 16 nF bei einer max<strong>im</strong>alen Spannung<br />
von 1 400 kV auf für Menschen ungefährliche Werte entladen<br />
ist. Dazu dient eine elektromechanisch betätigte<br />
Entladeeinrichtung.<br />
QUICK GUARD SICHERT HOCHSPANNUNGSFELDER<br />
Unter Berücksichtigung aller sicherheitsrelevanten Aspekte<br />
entsprechend EN 50191 und BGI 891 ergab sich für<br />
die Prüfanlagen aus der Risikobeurteilung ein erforderlicher<br />
Performance-Level von d (PLr=d) für einige wenige<br />
Sicherheitsfunktionen.<br />
Um die Sicherheitsanforderungen umsetzen zu können,<br />
wurde jedes Hochspannungsversuchsfeld mit<br />
einem Sicherheitszaun Quick-Guard zur Abtrennung<br />
20<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
des Steuerbereiches vom Prüfbereich und mit einer<br />
Sicherheits-SPS Pluto ausgestattet. Sie übern<strong>im</strong>mt die<br />
Abfrage sämtlicher sicherheitsrelevanter Sensoren<br />
(Not-Aus-Taster, Türsensoren, Überwachung von Erdungseinrichtungen)<br />
und die Ansteuerung der Warnlampen<br />
und Türzuhaltungen des entsprechenden<br />
Hochspannungsversuchsfeldes. Besonderes Augenmerk<br />
wurde hierbei auf ein durchgängiges und kompatibles<br />
System aus Sicherheitszaun, Sicherheitssteuerungen<br />
und Sensoren gelegt, das zum einen den in<br />
einem Hochspannungsversuchsfeld vorherrschenden<br />
elektromagnetischen Umgebungsbedingungen widerstehen<br />
kann, etwa bei Verwendung doppelt geschirmter<br />
Sensorleitungen und dem Einsatz von Überspannungsableitern.<br />
Zum anderen erlaubt das System eine<br />
einfache und strukturierte Verkabelung.<br />
SICHERHEITSSTEUERUNGEN VERNETZEN<br />
Im Idealfall wird auch bei der Kaskadierung von Sicherheitssensoren<br />
noch ein hoher Performance-Level erreicht.<br />
Die Sicherheitssteuerungen der Pluto-Familie erfüllen<br />
zusammen mit den Not-Aus-Tastern der Serie Inca und<br />
den Sicherheitssensoren des Typs Eden diese Kriterien.<br />
Pluto ist ein Sicherheitscontroller „All Master“, der den<br />
Entwurf von Sicherheitssystemen vereinfacht und den<br />
Performance Level e nach EN ISO 13849-1 sowie SIL 3<br />
nach EN 62061 unterstützt. Zusätzlich bieten die Geräte<br />
der Pluto-Familie noch die Möglichkeit, mehrere Sicherheitssteuerungen<br />
miteinander zu vernetzen und diese in<br />
ein gemeinsames Projekt zu integrieren. Dadurch kann<br />
<strong>im</strong> vorliegenden Anwendungsfall beispielsweise der<br />
Leistungsteil der Prüfspannungsquelle, in dem sich die<br />
redundanten Schaltgeräte zur sicheren Energietrennung<br />
nebst deren Spiegelkontakten und eventuell einigen Erdungseinrichtungen<br />
befinden, von der eigentlichen Laborsicherheitssteuerung<br />
abgesetzt werden.<br />
INTEGRIERT IN FAHRBARE FARADAY-KUGEL<br />
Da die Pluto-Sicherheitssteuerungen zur Vernetzung den<br />
<strong>im</strong> Industriebereich üblichen CAN-Bus verwenden,<br />
konnte hier durch Einsatz von LWL-Signalumsetzern des<br />
Typs PSI-MOS-DNET-CAN/FO von Phoenix Contact mit<br />
einfachen Mitteln eine sichere galvanische Trennung<br />
und damit eine deutliche Reduzierung der EMV-Problematik<br />
der einzelnen Teilbereiche der Sicherheitsanlagen<br />
erreicht werden.<br />
Die Möglichkeit der Vernetzung mehrerer Sicherheitssteuerungen<br />
innerhalb eines Projektes erlaubt auch die<br />
Realisierung von Sonderlösungen wie etwa die Integration<br />
einer fahrbaren Faraday-Kugel. Die Faraday-Kugel<br />
wird für Vorführungen <strong>im</strong> Rahmen von Exper<strong>im</strong>entalvorlesungen<br />
für die Studierenden der Elektrotechnik<br />
und Informationstechnik benutzt und muss zu diesem<br />
Zweck mit einer Person besetzt werden.<br />
Da sich die Faraday-Kugel <strong>im</strong> Prüfbereich und damit<br />
innerhalb der Verbotszone nach EN 50191 befindet,<br />
musste auch diese mit Sicherheitseinrichtungen wie<br />
Türsensoren, Not-Aus-Taster und einer Türzuhaltung<br />
ausgerüstet werden. Die magnetische Zuhaltung Magne<br />
in Verbindung mit Sicherheitssensoren Eden und Not-<br />
Aus-Taster Inca übernehmen hier wichtige Sicherheitsfunktionen.<br />
Zur Ansteuerung dieser Komponenten wurde<br />
ebenfalls eine Pluto-Sicherheitssteuerung in die Faraday-Kugel<br />
integriert, die über LWL mit der übergeordneten<br />
Laborsicherheitssteuerung vernetzt ist.<br />
TÜRSICHERUNG MIT 1 500 N ZUHALTEKRAFT<br />
Die elektromagnetische Zuhaltung Magne 1B kann eine<br />
Tür oder Klappe mit einer Zuhaltekraft von bis zu<br />
1 500 N geschlossen halten. Dabei überwacht das drahtlos<br />
arbeitende Sensor-Paar Eden, dass die Tür oder Klappe<br />
sicher geschlossen ist. Es besteht aus dem aktiven,<br />
elektrisch verdrahteten Teil Adam und dem passiven,<br />
als Betätiger wirkenden Teil Eva. Der Sensor ist nur bei<br />
geschlossener Tür aktiviert, wenn sich Adam und Eva<br />
gegenüber stehen.<br />
Die Sicherheits-Komplettlösung aus einer Hand von<br />
ABB Stotz-Kontakt überzeugt die Anwender am Lehrstuhl<br />
für Hochspannungs- und Anlagentechnik der TU<br />
München. Neben der leicht verständlichen Produktdokumentation,<br />
der problemlosen Montage, der hohen<br />
EMV-Verträglichkeit und der einfachen und intuitiven<br />
Bedienung der eingesetzten Sicherheitsprodukte von<br />
ABB sorgten auch kompetente Beratung und gut aufeinander<br />
abgest<strong>im</strong>mte Kundenschulungen zum Thema Maschinensicherheit<br />
für Zufriedenheit.<br />
AUTOREN<br />
Dr.-Ing. THOMAS HINTERHOLZER ist als<br />
Akademischer Oberrat am Lehrstuhl für<br />
Hochspannungs- und Anlagentechnik der<br />
TU München mit der Betreuung der<br />
Hochspannungs-Versuchsstände betraut.<br />
Technische Universität München,<br />
Lehrstuhl für Hochspannungs- und Anlagentechnik,<br />
Arcisstraße 21, D-80333 München,<br />
Tel. +49 (0) 89 28 92 20 09,<br />
E-Mail: thomas.hinterholzer@tum.de<br />
Elektrotechniker GÜNTHER BISSLE ist Key<br />
Account Manager bei ABB Stotz-Kontakt.<br />
ABB Stotz-Kontakt GmbH,<br />
Max-Planck-Straße 21, D-78549 Spaichingen,<br />
Tel. +49 (0) 7424 95 86 50,<br />
E-Mail: guenther.bissle@de.abb.com<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
21
PRAXIS<br />
Safe Human-Robot Collaboration Combines<br />
Expertise and Precision in Manufacturing<br />
A Paradigm for Industrial Assembly in Mixed Environments<br />
USER INTERFACE for the HRC assembly station.<br />
During the past decade, the interest in safe humanrobot<br />
collaboration (HRC) for applications in industrial<br />
production has developed from a niche research<br />
topic to a broad effort encompassing activities from basic<br />
research to application profiles and from standardization<br />
to biomechanics and ergonomics. The driving<br />
force behind the entire effort is the vision that practically<br />
relevant industrial scenarios will include both<br />
human workers with their specific expertise and robotic<br />
production assistants with their characteristic strengths,<br />
combining forces to empower a production facility with<br />
superior productivity and flexibility. A drawback of present<br />
prototypical HRC <strong>im</strong>plementations is that the basic<br />
reaction in the event of an <strong>im</strong>pending risk to a human<br />
worker is to stop robot motion, thus interrupting the<br />
application and curtailing productivity.<br />
To avoid productivity loss due to such down-t<strong>im</strong>es,<br />
the situations causing them must be avoided. Solving<br />
this by requiring workers to adhere to very rigid behavior<br />
requirements would result in serious difficulties in<br />
the acceptance of HRC technology in the production<br />
workplace. If, on the other hand, it is the collaborative<br />
robot that adapts its behavoir appropriately, the acceptance<br />
of the technology may actually be furthered. Such<br />
adaptivity must be designed to ensure worker safety<br />
while s<strong>im</strong>ultaneously upholding productivity to the<br />
highest extent possible.<br />
ENABLING INDUSTRIAL ROBOTS FOR SMALL LOT SIZES<br />
Present trends in production opt<strong>im</strong>ization for consumer<br />
products, such as 3C (Computing, Communication and<br />
Consumer Electronics) devices, are driving manufacturing<br />
paradigms away from mass production towards<br />
what is somet<strong>im</strong>es referred to as mass customization,<br />
the extreme at which each unit produced is unique to<br />
meet individual customer needs and taste. In this process<br />
to accommodate as much customer individualism<br />
as possible in modern technology products, manufacturers<br />
are striving to salvage as much as possible of the<br />
advantages of mass production. Relevant issues here are<br />
quality and reproducibility, as well as cost advantages<br />
in the economy of scale. In discrete manufacturing, one<br />
possible enabler for quality and reproducibility is the<br />
use of automation.<br />
Fixed automation is the most inflexible choice, and<br />
does not allow for product variants in a cost-efficient<br />
manner. The introduction of robotic automation has<br />
introduced an <strong>im</strong>portant d<strong>im</strong>ension of flexibility for<br />
the past decades. Presently, manufacturers are at<br />
t<strong>im</strong>es facing the l<strong>im</strong>itations of the fully automated<br />
robotic approach, since the automation of certain manufacturing<br />
steps in a sufficiently flexible manner still<br />
escapes economical realization. At present, only manual<br />
work is economical in this area. With the advent<br />
of safety-rated robot controllers, manufacturing now<br />
has access to a new d<strong>im</strong>ension of flexibility in production<br />
processes. It becomes possible to realize partial<br />
automation by distributing manufacturing steps<br />
among robots and human workers in the mixed production<br />
environment, while still maintaining personnel<br />
safety. Robots can be assigned to tasks for which<br />
they are best suited and in which they bring to bear<br />
22<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
The figure shows the dependence of unit cost on production<br />
volume in a schematic way, including manual<br />
assembly, fixed automation, conventional robotic automation,<br />
and HRC. Note that, depending on the production<br />
volume, different approaches will lead to the lowest<br />
cost per unit produced. Human-robot collaboration<br />
thus serves to extend the applicability of robots in<br />
industrial production to smaller lot sizes than is presently<br />
economical.<br />
IMPROVING PRODUCTIVITY IN COLLABORATION<br />
To analyze the collaborative application with regard to<br />
safety and productivity, this section introduces terminology<br />
and a descriptive formalism. Whenever specificity<br />
is required, the application type that we consider is<br />
industrial assembly in a collaborative setting.<br />
DIFFERENT MANUFACTURING PARADIGMS<br />
and their areas of relevance.<br />
their traditional strengths, such as precision and repeatability,<br />
and human workers handle the tasks that<br />
require understanding of context, adaptation to variability,<br />
and even manipulation tasks needing complex<br />
dexterity skills. For future production topologies, a<br />
new instrument to realize lean aspects in production<br />
thus has become available.<br />
Production Behavior: Maintain productivity and<br />
avoid safety-critical situations<br />
Safety and Productivity (S&P) Exception: Irregular<br />
situation which either interferes with productivity<br />
or compromises workers safety<br />
Exception Behavior consists of:<br />
Exception Reaction: execution of S&P functions to<br />
uphold productivity and to ensure worker safety<br />
Exception Recovery: dedicated set of commands<br />
to restore regular productive operation after Exception<br />
Reaction<br />
In the normal operation, collaborative robots run with<br />
production behavior. Safety and productivity exceptions<br />
which either interfere with productivity or compromise<br />
workers safety are caught by the corresponding exception<br />
reaction. A dedicated set of commands in exception<br />
Living FieLdbus<br />
Keeps Your process running<br />
Halle 7A<br />
stand 338<br />
Zukunftstechnologie für mehr verfügbarkeit<br />
▪ Advanced Diagnostic Gateways mit I/O Funktion<br />
▪ Segment Protectoren mit intelligenter Fehlerisolation<br />
▪ Diagnosefähiger Blitzschutz mit Leittechnikanbindung ohne<br />
wiederkehrende Prüfungen<br />
▪ Leckagesensoren für garantiert wasserdichte Installationen<br />
Feldbus mit intelligenter diagnose: www.pepperl-fuchs.de/living-fieldbus<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
23
PRAXIS<br />
HUMAN-ROBOT<br />
COLLABORATION<br />
in different states.<br />
recovery restores the regular productive operation after<br />
exception reaction.<br />
TESTING HRC IN AN EXPERIMENTAL SETUP<br />
To exper<strong>im</strong>ent with the proposed concept, a demonstrator<br />
is set up. In the exper<strong>im</strong>ent, the assembly station<br />
consists of a workbench with the ABB Dual-Arm Concept<br />
Robot. The robot is designed as a harmless robotic coworker<br />
for industrial assembly. It consists of two robotic<br />
arms with 7 DOF in each arm, which can be controlled<br />
individually or synchronously. The robot is able to collaborate<br />
with a human worker on the assembly of a PLC<br />
I/O module as shown in the trade shows Hannover Fair<br />
2011 and Automatica 2012.<br />
The assembly scenario is observed with two depth cameras,<br />
which detect the worker’s positions, for workspace<br />
supervision. Two interaction zones in which direct<br />
contact between the robot and the human might occur<br />
are designated in this scheme. One zone is located between<br />
the robot and the human side-by-side, and the other<br />
face-to-face.<br />
A user interface is <strong>im</strong>plemented. Distance thresholds<br />
δ 1 , δ 2 and δ 3 , specified in advance by the user, are introduced<br />
to define the events (like elbow-down, speed reduction,<br />
standstill) of threshold crossing.<br />
When the human worker approaches the robot and<br />
crosses the distance threshold δ 1 , this is interpreted as<br />
an exception. As a reaction, the robot moves its elbow<br />
down, keeping the position and orientation of its toolcenter<br />
point to continue with its normal work. When<br />
the human worker approaches further and crosses the<br />
distance threshold δ 2 , this generates another exception<br />
and the robot reaction is speed reduction. When the<br />
human worker crosses the distance threshold δ 3 , this<br />
exception leads to the robot reaction of standstill. Once<br />
the distance increases beyond the threshold δ 1 again,<br />
the system automatically recovers to its normal production<br />
behavior.<br />
In case of a communication failure or a failure in the<br />
robot controller, this exception generates a protective<br />
stop regardless of the current system state. Only manual<br />
recovery is allowed in this case.<br />
IMPROVING UPTIME OF COLLABORATIVE ASSEMBLY<br />
Exper<strong>im</strong>entation with this setup has shown that the upt<strong>im</strong>e<br />
of the collaborative assembly application can be<br />
AUTHORS<br />
HAO DING (born in 1980), is<br />
Scientist in the Robotics and<br />
Manufacturing group at ABB<br />
Corporate Research in Germany.<br />
He obtained his PhD in the<br />
area of opt<strong>im</strong>ized robotic<br />
manipulation for safely interacting<br />
with humans. He has<br />
5+ years of experience in<br />
industrial robotics, control, safety, and humanrobot<br />
collaboration.<br />
ABB AG, Corporate Research Center,<br />
Wallstadter Straße 59, D-68526 Ladenburg,<br />
Tel. +49 (0) 6203 71 60 28,<br />
E-Mail: hao.ding@de.abb.com<br />
24<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
www.<strong>atp</strong>-<strong>edition</strong>.de<br />
Jetzt bestellen!<br />
Die Referenzklasse für die<br />
Automatisierungstechnik<br />
EXAMPLE SETUP for HRC in<br />
industrial assembly.<br />
<strong>atp</strong> <strong>edition</strong> ist das Fachmagazin für die Automatisierungstechnik.<br />
Die Qualität der wissenschaftlichen Hauptbeiträge<br />
sichert ein strenges Peer-Review-Verfahren. Bezug zur<br />
automatisierungstechnischen Praxis nehmen außerdem<br />
die kurzen Journalbeiträge aus der Fertigungs- und Prozessautomatisierung.<br />
Sichern Sie sich jetzt diese erstklassige Lektüre! Als<br />
exklusiv ausgestattetes Heft oder als praktisches ePaper<br />
– ideal für unterwegs, auf mobilen Endgeräten oder zum<br />
Archivieren.<br />
Wählen Sie einfach das Bezugsangebot, das Ihnen zusagt:<br />
als Heft, ePaper oder Heft + ePaper!<br />
<strong>im</strong>proved, particularly in this example by moving<br />
down the elbow in case that the worker’s arm approaches.<br />
The robot does not have to stop as frequently<br />
due to human intervention. Speed reduction or standstill<br />
is mostly sufficient, which can be automatically<br />
recovered to normal operation from exception to<br />
uphold the productivity. As a result, this reduces the<br />
frequency of unintended contacts between worker<br />
and robot.<br />
BJÖRN MATTHIAS (born in<br />
1961), is Senior Principal<br />
Scientist for Robotic Automation<br />
at ABB Corporate Research<br />
in Germany, where he has<br />
gained extensive experience in<br />
robotics research & development<br />
for 10+ years, working<br />
on robotic automation applica<br />
tions, safety, and human-robot collaboration. He is<br />
a member of national and international standardization<br />
committees on robot safety and collaborative<br />
robots (ISO TC 184/SC2/WG3). He obtained his<br />
PhD in physics in 1990 at Yale University.<br />
ABB AG, Corporate Research Center,<br />
Wallstadter Straße 59, D-68526 Ladenburg,<br />
Tel. +49 (0) 6203 71 61 45,<br />
E-Mail: bjoern.matthias@de.abb.com<br />
<strong>atp</strong> <strong>edition</strong> erscheint in der DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München
PRAXIS<br />
Industrial WLAN erlaubt auch zuverlässige<br />
Kommunikation mit Echtzeitanforderungen<br />
Wireless vom Feld in die Welt: Sicher drahtlos kommunizieren <strong>im</strong> Automatisierungsumfeld, Teil 2<br />
Drahtlostechnologien werden für die Automatisierungstechnik<br />
<strong>im</strong>mer wichtiger. Der erste Teil dieses<br />
Beitrags in <strong>atp</strong> <strong>edition</strong> 9/2013 stellte die Möglichkeiten<br />
von WirelessHart und die Grundzüge der WLAN-Standards<br />
dar. Die zweite und letzte Folge beschreibt nun<br />
konkrete industrielle WLAN-Anwendungen und die<br />
Möglichkeiten der Mobilfunknetze.<br />
Die WLAN-Standards, die <strong>im</strong> ersten Teil dieses Beitrags<br />
beschrieben wurden, bieten verschiedene Ansatzpunkte<br />
für industrielle Anwendungen. Allerdings sind<br />
He<strong>im</strong>-/Büronetzwerke nicht einfach auf den Industrieeinsatz<br />
übertragbar. Erforderlich ist ein Industrial Wireless<br />
LAN (IWLAN). Dafür müssen zum einen funktechnische<br />
Opt<strong>im</strong>ierungen durchgeführt werden. Zum<br />
anderen muss die Hardware für die besonderen industriellen<br />
Bedingungen ausgelegt werden (Bild 8). Denn<br />
hier wird nicht nur mit direkten Endteilnehmern wie<br />
etwa einem Laptop, Tablet-PC oder Smartphone über<br />
WLAN kommuniziert, sondern häufig auch mit kleinen,<br />
mobilen Netzwerken mit mehreren Geräten, die über<br />
Kabel an einem Wireless-LAN-Client-Modul angebunden<br />
sind.<br />
BÜRO-WLAN SCHEITERT IN INDUSTRIE-NETZWERKEN<br />
Ein gutes Beispiel hierfür ist ein fahrerloses Transportsystem:<br />
Hier sind neben einer lokalen Steuerung oft<br />
auch noch Kameras, Touchpanels (HMIs) und zusätzliche<br />
dezentrale Peripherie an Bord, welche mit einer<br />
zentralen Steuerung kommunizieren (Bild 9). WLAN,<br />
wie es heute in vielen He<strong>im</strong>- und Büronetzwerken installiert<br />
ist, kann bei derartigen Netzen nicht gewährleisten,<br />
dass die einzelnen WLAN-Client-Module <strong>im</strong>mer<br />
direkten Zugriff auf „ihren“ Wireless Access Point<br />
erhalten. Sie müssten folglich warten, bis sie „an der<br />
Reihe“ sind. Damit geht die für Feldbussysteme und<br />
insbesondere für Sicherheitsaufgaben relevante Deterministik<br />
bei der Kommunikation verloren. Im<br />
schl<strong>im</strong>msten Fall könnte es zu einem Not-Stopp und<br />
einem teuren Anlagenstillstand kommen, wenn ein sicherheitsrelevantes<br />
Signal nicht rechtzeitig be<strong>im</strong> Endteilnehmer<br />
ankommt. Gefährliche Situationen können<br />
aufgrund der Verwendung von Safety-Protokollen erst<br />
gar nicht entstehen.<br />
POLLINGVERFAHREN VERMEIDET KOLLISIONEN<br />
Um dennoch eine zuverlässige Kommunikation auf der<br />
Feldbusebene über WLAN zu ermöglichen, sind für die<br />
Kommunikation mit Echtzeitanforderungen Erweiterungen<br />
gegenüber den Standards notwendig. Das Problem<br />
der Echtzeitkommunikation in Feldbussen in Verbindung<br />
mit sicherheitsgerichteter Kommunikation wird<br />
beispielsweise durch die iPCF-Funktion der IWLAN-<br />
Produkte von Siemens gelöst, die häufig in Verbindung<br />
mit Leckwellenleitern zum Einsatz kommt.<br />
Die Technologie iPCF basiert auf dem Medienzugriffsverfahren<br />
Point Coordination Function (PCF), welches<br />
schon seit 1999 Bestandteil des IEEE 802.11-legacy-Standards<br />
ist. PCF ist ein Pollingverfahren, bei dem der Access<br />
Point als zentrale Station den Zugriff über die einzelnen<br />
Stationen koordiniert, um Kollisionen zu vermeiden.<br />
Mit iPCF wird ein vergleichbares Pollingverfahren<br />
verwendet, kombiniert mit einer Methode, welches<br />
schnelleres Roaming ermöglicht. Damit ist sichergestellt,<br />
dass jedes verbundene Wireless-Client-Modul mit dem<br />
Access Point mindestens einmal innerhalb des ausgewählten<br />
Feldbuszyklus Daten austauschen kann.<br />
Ein Leckwellenleiter wird dann eingesetzt, wenn sich<br />
die drahtlose Kommunikation an einer vorgegebenen<br />
Wegstrecke orientieren soll oder muss und die Verwendung<br />
üblicher Antennen nicht möglich ist, weil es beispielsweise<br />
Schwierigkeiten bei der Ausleuchtung gibt<br />
oder Interferenzen zu erwarten wären. Beispiele hierfür<br />
sind die Einschienenhängebahn oder ein schienengeführtes,<br />
fahrerloses Transportsystem. Der Leckwellenleiter<br />
stellt durch seine definierte Abstrahlung eine sehr<br />
zuverlässige drahtlose Verbindung zur Verfügung und<br />
kann, abhängig vom verwendeten Frequenzband, Segmentlängen<br />
von bis zu 300 Meter pro Wireless Access<br />
Point abdecken (Bild 10).<br />
ROAMINGZEITEN KÜRZER ALS 50 MS<br />
Roaming auf den nächstgelegenen Access Point ist notwendig,<br />
weil nicht jede Applikation auf eine max<strong>im</strong>ale<br />
Segmentlänge von 300 Meter eingeschränkt werden<br />
kann. Dabei muss die Zeit für das Roaming so kurz wie<br />
möglich gehalten werden, weil während dieses Vorgangs<br />
die Kommunikation unterbrochen wird. Kombiniert<br />
mit einer vorgegebenen Strecke lässt iPCF sogar<br />
Roamingzeiten von unter 50 ms zu. Hierdurch können<br />
echtzeitfähige Netzwerke drahtlos über große Entfernungen<br />
betrieben werden, ohne die Applikation weiter<br />
einzuschränken.<br />
Für Applikationen, in denen frei bewegliche Wireless-<br />
Client-Module eingesetzt werden wie Mobile Panels mit<br />
Not-Aus, die von Personen getragen werden oder fahrerlose<br />
Transportsysteme <strong>im</strong> weitflächigen Bereich ist eine<br />
Ergänzung dieser Technologie erforderlich. Denn hier<br />
ist es aufgrund der freien Beweglichkeit nicht möglich,<br />
vorherzusagen, zu welchen Access Point das Wireless-<br />
Client-Modul als nächstes Verbindung aufnehmen (roamen)<br />
wird. Um trotz dieser freien Beweglichkeit die<br />
Roamingzeiten so kurz wie möglich zu halten, kommt<br />
hier iPCF-MC (industrial Point Coordination Function<br />
– Management Channel) ins Spiel.<br />
DATA CHANNEL UND MANAGEMENT CHANNEL<br />
Für iPCF-MC werden Access Points mit zwei integrierten,<br />
aber getrennten Funkinterfaces benötigt. Ein<br />
Funkinterface wird für den Datenaustausch (Data<br />
Channel) gebraucht und das zweite für das Versenden<br />
von Wireless-LAN-Management-Informationen (Management<br />
Channel). Dieser Management Channel<br />
sendet administrative Informationen über den Data<br />
Channel mittels sogenannter Beacons und muss in<br />
der kompletten Anlage auf den gleichen Funkkanal<br />
eingestellt werden.<br />
26<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
BILD 11: Mobile Panel mit Not-Aus<br />
in einer Sicherheitsanwendung.<br />
Der Management Channel überträgt<br />
administrative Informationen.<br />
BILD 9: Im Industrieeinsatz sind WLANs meist deutlich<br />
komplexer als <strong>im</strong> Büroumfeld. Das zeigt beispielsweise<br />
dieser Aufbau eines WLANs in einem Container-<br />
Terminal mit fahrerlosen Transportsystemen.<br />
BILD 12: Klassische Telecontrol-Anwendungen finden sich in<br />
Wasseraufbereitung oder Trinkwasserversorgung. Bild: Siemens<br />
BILD 10: Eine drahtlose Schraubersteuerung<br />
in der Automobilproduktion mit iPCF und<br />
Leckwellenleiter: Die Pollingfunktion iPCF<br />
ermöglicht hier die Echtzeitkommunikation.<br />
Wenn ein Wireless Client sich nicht <strong>im</strong> Datenaustausch<br />
befindet, kann er nach Access Points mit einer<br />
besseren Empfangsqualität suchen – das ist Standard<br />
bei jedem WLAN. Er scannt die Kanäle ab und entscheidet<br />
nach Abschluss, zu welchem Access Point er Verbindung<br />
aufn<strong>im</strong>mt. Das Scannen aller Kanäle führt<br />
allerdings zu erheblichen Kommunikationsunterbrechungen,<br />
weil während des Vorgangs kein Datenaustausch<br />
stattfinden kann. Diese relativ lange Unterbrechung<br />
ist in der Feldbuskommunikation nicht gewünscht<br />
und würde zu einem Busfehler führen, was<br />
einen Anlagestillstand zur Folge haben könnte. Durch<br />
die Verwendung von iPCF-MC beschränkt sich der Scanvorgang<br />
des gesamten Netzwerks auf einen einzigen<br />
Funkkanal. Hierbei werden die Informationen von Access<br />
Points, die sich in Reichweite befinden, zur gleichen<br />
Zeit empfangen, damit wird erheblich Zeit eingespart.<br />
Der Wireless Client entscheidet nach dem Scanvorgang<br />
direkt, mit welchem Access Point er über welchen Kanal<br />
Daten austauschen möchte (Bild 11).<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
27
PRAXIS<br />
MOBILFUNK ÜBERBRÜCKT DIE GRÖSSTEN STRECKEN<br />
Bei weit verteilten Applikationen oder bei Dienstleistungen<br />
aus der Ferne müssen bestehende Infrastrukturen<br />
wie Telefon- oder Mobilfunknetze genutzt werden,<br />
da WirelessHart und WLAN dies nicht leisten können.<br />
Mobilfunk basiert auf einer zellenartig aufgebauten<br />
Netzwerkinfrastruktur. Mit individuellen nationalen<br />
Implementierungen bieten diese Netzwerke einen nahezu<br />
weltweiten Fernzugriff auf industrielle Anlagen.<br />
Besonders bei schwer zugänglichen, verteilten Anlagen,<br />
ohne festverdrahtete Kommunikationsinfrastruktur<br />
oder bei mobilen Objekten wird die Anbindung der<br />
Teilnehmer an zentrale Leitstellen über Mobilfunk<br />
realisiert. Durch steigende Geschwindigkeiten und<br />
Bandbreiten bei gleichzeitig fallenden Kosten ermöglichen<br />
es die neuen Mobilfunk-Generationen UMTS<br />
(Universal Mobile Telecommunications System) und<br />
LTE (Long Term Evolution), ganz neue Applikationen<br />
wie Videoübertragung umzusetzen.<br />
Klassische Fernwirklösungen bei Öl- und Gaspipelines,<br />
<strong>im</strong> Bereich der Wasserversorgung und Abwasserentsorgung<br />
sowie <strong>im</strong> Energiesektor stellen hohe Anforderungen<br />
an die Fernwirktechnik. Außen- und Messstationen<br />
müssen mit zum Teil großen Datenvolumina über<br />
weite Entfernungen mit der zentralen Leitstelle kommunizieren,<br />
oft auch über die verschiedensten Telekommunikationsnetze.<br />
In unterschiedlichen Branchen und Regionen<br />
werden zudem spezielle Fernwirkprotokolle<br />
vorgeschrieben. Typische Anwendungen sind die Steuerung<br />
prozesstechnischer Anlagen wie etwa be<strong>im</strong> opt<strong>im</strong>ierten<br />
Betrieb kommunaler Einrichtungen zur Wasseraufbereitung,<br />
Energieverteilung und Verkehrsüberwachung<br />
sowie <strong>im</strong> Gebäudemanagement (Bild12).<br />
ANLAGENÜBERWACHUNG AUS DER FERNE<br />
Ein weiterer Anwendungsbereich, der Mobilfunk nutzt,<br />
ist die wirtschaftliche Anlagenüberwachung und -wartung<br />
aus der Ferne. Teleservice ist der Datenaustausch<br />
mit räumlich weit auseinander liegenden technischen<br />
Maschinen, Anlagen, Computern zum Zweck der Fehlererkennung,<br />
Diagnose, Wartung, Reparatur oder Opt<strong>im</strong>ierung.<br />
Denn <strong>im</strong>mer häufiger werden Maschinen und Anlagen<br />
an Orten betrieben, die weit vom Lieferanten entfernt<br />
sind. Dennoch müssen Anlagenbauer bei Fehlern<br />
oder zur vorbeugenden Instandhaltung Service-Leistungen<br />
anbieten. Teleservice trägt wesentlich dazu bei, Reiseund<br />
Personalkosten bei Serviceeinsätzen einzusparen.<br />
Darüber hinaus kann Kunden auf Basis der Remote-<br />
Kommunikation Mehrwert angeboten werden, beispielsweise<br />
Condition Monitoring. Dabei werden permanent<br />
Zustandsdaten einer Maschine oder Anlage<br />
erfasst. Auf Basis dieser Erhebungen können vorbeu-<br />
GSM<br />
(2.Generation)<br />
UMTS<br />
(3. Generation)<br />
LTE<br />
(4. Generation)<br />
Datenrate Uplink 384 kBit/s (EDGE) 5,76 MBit/s (HSPA+) 50 MBit/s<br />
Datenrate Downlink 384 kBit/s (EDGE) 14,4 MBit/s (HSPA+) 100 MBit/s<br />
Weltweite Verfügbarkeit (zukünftig) ++ +++ +(++)<br />
Netzabdeckung (zukünftig) +++ + +(++)<br />
Standardisierte Frequenzbänder 3 6 40 + x<br />
BILD 13: Die existierenden<br />
Mobilfunktechnologien:<br />
Höchste Geschwindigkeit und<br />
eine weltweit relative gute<br />
Netzabdeckung soll Prognosen<br />
zufolge LTE erreichen.<br />
BILD 14: Durch geeignete Maßnahmen,<br />
vor allem in der Planungsphase, lässt sich<br />
die Koexistenz verschiedener Funksysteme sicherstellen,<br />
sodass alle ungestört arbeiten können.<br />
28<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
gend Wartungseinsätze durchgeführt werden, bevor es<br />
zu teuren Stillstandszeiten bedingt durch den Ausfall<br />
einer Maschine oder Anlage kommt. Immer häufiger<br />
werden auch sichere Lösungen über das Internet nachgefragt.<br />
Basis für eine opt<strong>im</strong>ale Fernwartung sind: zuverlässige,<br />
<strong>im</strong>mer verfügbare, gesicherte und preisgünstige<br />
Datenverbindungen.<br />
GSM IST ETABLIERT ABER RELATIV LANGSAM<br />
GSM (Groupe Spécial Mobile) ist der erste, nahezu weltweit<br />
verfügbare Mobilfunkstandard, der sich besonders<br />
<strong>im</strong> industriellen Umfeld <strong>im</strong>mer noch großer Beliebtheit<br />
erfreut. Vorteile sind die hohe Verfügbarkeit der Technologie<br />
in vielen Ländern, die gute Netzabdeckung der<br />
einzelnen Zellnetze sowie niedrige Anschaffungs- und<br />
Betriebskosten. Da in der Regel Telecontrol- und Teleservice-Applikationen<br />
eher geringe Anforderungen an die<br />
Bandbreite stellen, werden die vergleichsweise niedrigen<br />
Datenraten von GSM in Kauf genommen.<br />
Der UMTS-Standard sollte dem GSM-Standard nachfolgen<br />
und hohe Datenraten bieten. Die anfänglichen<br />
Hoffnungen auf eine schnelle Einführung haben sich bis<br />
heute nicht erfüllt. Praktisch ist der 3G-Standard in<br />
Deutschland nur in dicht besiedelten Gebieten verfügbar<br />
und die Datenraten des UMTS-Standards liegen nicht<br />
deutlich genug über jenen von GSM-Netzen. Erst durch<br />
neue Dienste, wie HSPA (High Speed Packet Access) und<br />
HSPA+, ist ein markanter Unterschied gegenüber den<br />
GSM-Netzen spürbar. Darüber hinaus ist UMTS der erste<br />
Mobilfunkstandard, der garantiert auch weltweit verfügbar<br />
ist.<br />
Mit LTE, der vierten Generation Mobilfunk, versucht<br />
die Branche nun aus den Fehlern der Vergangenheit zu<br />
lernen. LTE dürfte zukünftig weltweit verfügbar sein. In<br />
vielen Ländern hat der Netzausbau bereits begonnen und<br />
geht schneller voran, als prognostiziert. Getrieben wird<br />
diese rasante Entwicklung vorrangig vom Endanwender,<br />
der mit mobilen intelligenten Geräten permanent mit<br />
dem Internet verbunden sein möchte (Bild13).<br />
KOEXISTENZ-MANAGEMENT VERMEIDET KONFLIKTE<br />
WirelessHart und WLAN arbeiten <strong>im</strong> weltweit lizenzfreien<br />
Frequenzbereich 2,4 GHz. In diesem Bereich tummeln<br />
sich aber noch einige andere: Bluetooth, RFID (Radio<br />
Frequency Identification), WSAN (Wireless Sensor<br />
and Actor Network) und DECT (Digital Enhanced Cordless<br />
Telecommunications). Sobald mehrere Systeme am<br />
gleichen Ort, zur gleichen Zeit und auf der gleichen Frequenz<br />
funken, besteht die Möglichkeit einer gegenseitigen<br />
Funkbeeinflussung, was den reibungslosen Ablauf<br />
in einer Anlage stören könnte.<br />
Mittels Koexistenz-Management lässt sich aber ein<br />
störungsfreier Betrieb trotz gegenseitiger Funkbeeinflussung<br />
gewährleisten. Die beste Wirkung lässt sich erzielen,<br />
wenn das Koexistenz-Management in der Planungsund<br />
Projektierungsphase umgesetzt wird. Denn hier<br />
lassen sich mögliche Konflikte frühzeitig erkennen und<br />
berücksichtigen.<br />
Der wichtigste Baustein hierbei ist die Funkfeldplanung<br />
(site survey). Damit kann der Projektierungsingenieur<br />
bei der Einbettung der Funkapplikation in die<br />
vorhandene Anlage auf die Platzierung, Antennenauswahl<br />
und Frequenzvergabe Einfluss nehmen. Ziel ist,<br />
dass sich Funkfelder nicht überlappen und nicht gegenseitig<br />
stören. Bei WirelessHart bietet es sich an, die von<br />
anderen Funktechnologien belegten Kanäle in eine<br />
‚Blacklist‘ einzutragen und sie nicht mehr für die Kommunikation<br />
zu nutzen. Dadurch wird eine Koexistenz<br />
mit anderen drahtlosen Kommunikationssystemen <strong>im</strong><br />
2,4-GHz-ISM-Band gewährleistet. Bei WLAN hingegen<br />
kann ein Wechsel in das 5-GHz-ISM-Band Störungen mit<br />
dem 2,4-GHz-SM-Band vermeiden.<br />
ZUKUNFTSSICHER MIT GANZHEITLICHEM KONZEPT<br />
Der Einsatz von Funktechnologien bietet also erhebliches<br />
Potenzial für industrielle Automatisierungsanwendungen<br />
und wird deshalb weiter zunehmen. Die Akzeptanz<br />
wird besonders <strong>im</strong> Hinblick auf Flexibilität und Zuverlässigkeit<br />
<strong>im</strong> Feld <strong>im</strong>mer mehr wachsen (Bild14). WirelessHart<br />
sorgt für den Transport der Daten von der Feldzur<br />
Steuerungsebene, Industrial Wireless LAN übern<strong>im</strong>mt<br />
die drahtlose Vernetzung der Steuerungsebene<br />
und Mobilfunk ermöglicht den Zugriff auf weltweit entfernte<br />
Anlagenteile. Mit diesem ganzheitlichen Konzept<br />
der drahtlosen Datenübertragung sind Anlagenbauer<br />
sowie -betreiber heute und in Zukunft bestens gerüstet.<br />
AUTOREN<br />
Dipl.-Ing. JENS GREBNER ist<br />
Product Manager für Industrial Remote<br />
Commu nication bei Siemens.<br />
Siemens AG,<br />
Gleiwitzer Str. 555, D-90475 Nürnberg,<br />
Tel. +49 (0) 911 895 28 94,<br />
E-Mail: jens.grebner@siemens.com<br />
BSc SANDER ROTMENSEN ist<br />
Product Manager Industrial Wireless<br />
LAN bei Siemens.<br />
Tel. +49 (0) 911 895 46 92,<br />
E-Mail: sander.rotmensen@siemens.com<br />
Dipl.-Betriebswirtin ROSWITHA SKOWRONEK<br />
ist Marketing Manager für industrielle<br />
Netzwerk komponenten bei Siemens.<br />
Tel. +49 (0) 911 895 43 09,<br />
E-Mail: roswitha.skowronek@siemens.com<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
29
HAUPTBEITRAG<br />
<strong>Konfigurationsmanagement</strong><br />
<strong>im</strong> <strong>Anlagenlebenszyklus</strong><br />
Effiziente Versionsverwaltung von Komponenten<br />
Ausgehend von Anlagenlebenszyklen zwischen 15 und 20 Jahren, kann die Integration<br />
von Messgeräten in Leitsystemen eine komplexe und aufwendige Angelegenheit sein. Im<br />
Beitrag wird eine Lösung zur Verfügbarkeit der Gerätetreiber über den gesamten Lebenszyklus<br />
beschrieben. Dieser setzt protokollspezifische Identifikationsmerkmale der jeweiligen<br />
Feldgeräte <strong>im</strong> Feld mit herstellerinternen Produktarten in Beziehung, um Abläufe<br />
des <strong>Konfigurationsmanagement</strong>s bei Engineering, Inbetriebnahme und Instandhaltung<br />
effizient zu unterstützen.<br />
SCHLAGWÖRTER <strong>Konfigurationsmanagement</strong> / <strong>Anlagenlebenszyklus</strong> / Geräteintegration /<br />
Gerätetausch<br />
Configuration Management in the Plant Life Cycle –<br />
Efficient Version Management of Components<br />
In view of plant life cycles of 15 to 20 years, the integration of instruments in a control<br />
system can be a complex and costly affair. A solution is described for the availability of<br />
the device driver for the entire life cycle. Protocol specific identification attributes of the<br />
field device are put in relation with vendor internal product data in order to efficiently<br />
support the configuration management processes for engineering, commissioning and<br />
maintenance.<br />
KEYWORDS configuration management / life cycle management / device integration /<br />
device exchange<br />
30<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
GÜNTHER GREDY, JÖRG HÄHNICHE, MIRKO BRCIC, Endress+Hauser Process Solutions<br />
Mit zunehmender Intelligenz der Feldgeräte und<br />
deren Integration in Leitsysteme gewinnen<br />
Gerätetreiber <strong>im</strong> Lebenszyklus einer Automatisierungsanlage<br />
<strong>im</strong>mer größere Bedeutung. Da<br />
alle Komponenten einer Automatisierungsanlage<br />
wie Leitsystem (Anzeige- und Bedienkomponenten<br />
(ABK), prozessnahe Komponenten (PNK) [1]), die Feldgeräte<br />
und deren Gerätetreiber einer stetigen Weiterentwicklung<br />
unterliegen, besteht das Risiko von Inkompatibilitäten.<br />
Deshalb müssen die verschiedenen Versionen der<br />
Komponenten sorgfältig aufeinander abgest<strong>im</strong>mt werden.<br />
In den Feldbus-Spezifikationen wurden Festlegungen für<br />
die Gerätebeschreibungsversionen in Abhängigkeit von den<br />
Gerätetreiberversionen getroffen [2]. Diese Festlegungen<br />
allein reichen jedoch nicht aus. Um genügend Information<br />
zur Verträglichkeit der verschiedenen Versionen, insbesondere<br />
in Bezug auf die Leitsystemversionen zu erhalten,<br />
werden aufwendige Integrationstests be<strong>im</strong> Leitsystem- und<br />
Feldgerätehersteller durchgeführt. Die Ergebnisse der Integrationstests<br />
und die Versionsfortschreibungen aller Komponenten<br />
lassen sich mittels geeigneter Datenbankstrukturen<br />
sehr gut in Beziehung zueinander setzen und dem jeweils<br />
Verantwortlichen einer Lebenszyklusphase zur Verfügung<br />
stellen.<br />
Wie sich eine Inkompatibilität auswirkt, verdeutlicht das<br />
folgende Beispiel. Be<strong>im</strong> Bau des Gotthard-Basistunnels fällt<br />
ein Messgerät aus. Ein Servicetechniker tauscht das Gerät<br />
gegen ein neueres Gerät aus. Am nächsten Tag soll die Bohranlage<br />
wieder in Betrieb genommen werden, jedoch kann das<br />
neue Gerät nicht parametriert werden, da der Treiber auf dem<br />
Leitsystem nicht kompatibel mit dem neuen Gerät ist. Neben<br />
dem Gerätetausch hätte auch der Gerätetreiber aktualisiert<br />
werden müssen. Dies ist sicher kein Einzelfall. In der Konsequenz<br />
geht ein Tag verloren, da der Servicetechniker abermals<br />
einfahren muss, um den richtigen Treiber zu installieren.<br />
Bei dem beschriebenen Fall sind mehrere Aspekte zu<br />
betrachten:<br />
1 | Wie kann eine Aussage zu der Kompatibilität der<br />
Gerätetreiber mit der entsprechenden Feldgeräteversion<br />
getroffen werden?<br />
2 | Wie kann der Servicetechniker wissen, dass er<br />
neben dem Tausch des Feldgerätes auch den Gerätetreiber<br />
aktualisieren muss?<br />
3 | Wie kann derartige Information auch dem Endanwender<br />
in anderen Lebenszyklusphasen von Komponenten<br />
einer Anlage bereitgestellt werden?<br />
Der Beitrag betrachtet die Aspekte der Kompatibilitäten<br />
Feldgerät/Gerätetreiber und Gerätetreiber/Automatisierungssystem<br />
über den Lebenszyklus einer Automatisierungsanlage.<br />
Aufgrund der Lebensdauer von Automatisierungsanlagen<br />
in der Prozessindustrie von 15 bis 20<br />
Jahren spielen diese Gesichtspunkte eine Rolle, um die<br />
gesamte Anlage während dieses Zeitraums betriebsfähig<br />
zu halten. Um zu jedem Zeitpunkt Aussagen über<br />
die Kompatibilität mit min<strong>im</strong>alem Aufwand tätigen zu<br />
können, sind mit Hilfe von Asset-Information und deren<br />
systematischer Verwaltung, entweder seitens der Gerätehersteller<br />
oder der Anlagenbetreiber, entsprechende<br />
Dienste zur Verfügung zu stellen. Exemplarisch wird<br />
anhand vorhandener Asset-Information aufgezeigt, wie<br />
sich eine Verwaltung der Feldgeräte und Gerätetreiber<br />
realisieren lässt und welche unterstützenden Dienste<br />
den Anwendern bezüglich Geräteintegration bereitgestellt<br />
werden können.<br />
1. ANFORDERUNGEN DER ANWENDER<br />
Der steigende Wettbewerbsdruck fordert effizientere<br />
Anlagen mit hoher Verfügbarkeit, die sich durch einen<br />
deutlich wachsenden Automatisierungsgrad und damit<br />
Digitalisierung der Komponenten bemerkbar macht. Die<br />
Folge: Automatisierungssysteme und die zu integrierenden<br />
Feldgeräte werden komplexer und unterliegen kürzeren<br />
Entwicklungszyklen, währenddessen die Anforderung<br />
an die Lebensdauer einer Anlage bestehen bleibt.<br />
Der <strong>Anlagenlebenszyklus</strong> in der Prozessindustrie (siehe<br />
Bild 1) unterscheidet sich wesentlich von dem der<br />
Automatisierungssysteme und dem der Feldgeräte. Natürlich<br />
arbeiten die Automatisierungskomponenten vie-<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
31
HAUPTBEITRAG<br />
le Jahre zuverlässig, jedoch werden in der Zwischenzeit<br />
neue Versionen freigegeben und zur Verfügung gestellt.<br />
Im Falle eines Austauschs von Altgeräten müssen die<br />
entsprechenden Treiber nahtlos in das Automatisierungssystem<br />
integriert werden [11]. Die Koexistenz verschiedener<br />
Geräteversionen bei einer Anlagenerweiterung<br />
oder die Sicherstellung von kompatiblen Softwareständen<br />
über einen längeren Zeitraum bei einer<br />
neuen Anlage sind ebenfalls zu berücksichtigen.<br />
Dabei spielen für System- und Gerätehersteller folgende<br />
Anforderungen der einzelnen Phasen des <strong>Anlagenlebenszyklus</strong><br />
eine Rolle, um jederzeit kompatibel zu sein<br />
und je nach Bedarf die richtige Asset-Information bereitzustellen.<br />
Planung und Beschaffung:<br />
Auswahl der Feldgeräte entsprechend der<br />
Anlagenanforderungen<br />
Prüfung der Verfügbarkeit der Feldgeräte<br />
(Messtechnik und Aktorik), des Automatisierungssystems<br />
und der benötigten Gerätetreiber<br />
Installation:<br />
Feldgeräte werden montiert und angeschlossen<br />
Gerätetreiber sowie Feldgeräte- und Systemdokumentation<br />
müssen verfügbar sein<br />
Inbetriebnahme:<br />
Feldgeräte werden für den Prozess opt<strong>im</strong>al<br />
eingestellt<br />
Feldgeräte und System sind mit Hilfe der<br />
Geräte treiber in Betrieb zu nehmen<br />
Betrieb:<br />
Anlagenverfügbarkeit sicherstellen und erhöhen<br />
Anlage kann nach Bedarf erweitert werden<br />
Gerätetreiber sind bei Feldgeräteaustausch<br />
jederzeit verfügbar und kompatibel<br />
Feldgerätefehler müssen schnell identifiziert<br />
und behoben werden<br />
Wie in Bild 2 dargestellt, sind dem Betreiber einer Anlage<br />
aus Kosten- und Produktivitätssicht zwei Gesichtspunkte<br />
wichtig: die Inbetriebnahme und die Instandhaltung<br />
seiner Anlagenassets. In beiden Fällen möchte er<br />
die Zeiten min<strong>im</strong>ieren, die er für diese Aufgaben aufwenden<br />
muss. Dies entspricht der Zielsetzung der NE 105<br />
[13]. Der Betreiber möchte so schnell wie möglich über<br />
eine produktivfähige Anlage verfügen (t<strong>im</strong>e to market)<br />
und die Zeiten des Produktionsausfalls während notwendiger<br />
Wartungsarbeiten möglichst kurz halten. Wesentliche<br />
Voraussetzung hierfür ist die Information über<br />
diese Anlagenassets in den zuvor genannten Phasen.<br />
2. ANLAGEN-ASSETS<br />
Im Rahmen dieses Beitrags sind die digital kommunizierenden<br />
Feldgeräte und die zugehörigen Gerätetreiber<br />
die wesentlichen Assets einer Anlage.<br />
Ein digital kommunizierendes Feldgerät ist ein über ein<br />
industrielles digitales Kommunikationssystem (zum Beispiel<br />
Hart, Wireless-Hart, Foundation Fieldbus H1, Profibus<br />
PA, Profibus DP, EtherNet/IP) an ein Leitsystem beziehungsweise<br />
eine SPS angeschlossenes Gerät, das Parameter eines<br />
technischen Prozesses messen und digital an ein Leitsystem<br />
oder eine SPS übertragen kann [3]. Ein Feldgerätetyp ist eine<br />
best<strong>im</strong>mte Ausprägung eines Feldgerätes, zum Beispiel ein<br />
Füllstands-, ein Radar- und Ultraschallmessgerät. Zudem<br />
können innerhalb eines Messprinzips (zum Beispiel Radar)<br />
mehrere Feldgerätetypen existieren. Die Funktionalität von<br />
Feldgeräten wird maßgeblich über eine eingebettete Soft-<br />
BILD 1: <strong>Anlagenlebenszyklus</strong><br />
32<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
ware dargestellt, die Firmware. Ein Feldgerät hat einen Lebenszyklus<br />
und somit fallen Firmware-Versionen an.<br />
Unter Geräterevision verstehen die Autoren die Zusammenfassung<br />
mehrerer bezüglich der Geräteintegration<br />
kompatibler Firmware-Versionen.<br />
Ein Gerätetreiber ist eine <strong>im</strong> Kontext des Leitsystems<br />
gehaltene Integrationskomponente (zum Beispiel GSD,<br />
EDD, DTM), die das Verhalten eines Feldgerätetyps in Betrieb<br />
und bei Konfiguration beschreibt und somit das Feldgerät<br />
repräsentiert. Es besteht eine eindeutige Beziehung<br />
zwischen einem Feldgerätetyp und dessen Gerätetreiber,<br />
wie in Bild 3 dargestellt. Sowohl ein Gerätetreiber als auch<br />
ein Leitsystem haben Lebenszyklen und somit ergeben sich<br />
Gerätetreiberversionen und Leitsystemversionen.<br />
Feldgerätetypen müssen mit neuen Funktionsmerkmalen<br />
und Optionen oftmals an die wachsenden Anforderungen<br />
einer effizienten Anlagenproduktivität oder aufgrund<br />
von technologischen Fortschreibungen (zum Beispiel<br />
standardisierte Diagnose gemäß NE 107 [12]) angepasst<br />
werden. Diese kontinuierliche Innovation führt <strong>im</strong><br />
Lebenszyklus eines Feldgerätetyps zu einer großen Anzahl<br />
von Firmware-Versionen respektive Geräterevisionen<br />
[2]. Dabei gehen die Verfasser von ein bis zwei Firmware-Versionen<br />
innerhalb von zwei Jahren aus.<br />
Die wesentliche Herausforderung ist also, über den gesamten<br />
Lebenszyklus einer Anlage – entlang der Lebenszyklen<br />
der Feldgerätetypen, der Gerätetreiber und des<br />
Leitsystems – <strong>im</strong>mer den korrekten und opt<strong>im</strong>alen Gerätetreiber<br />
bezogen auf eine hundertprozentige Anlagenperformance<br />
<strong>im</strong> Kontext des Leitsystems bereitzustellen.<br />
3. KONFIGURATIONSMANAGEMENT<br />
Bezüglich der Feldgerätetypen und der zugehörigen Gerätetreiber<br />
wird <strong>im</strong> Beitrag ein Begriff aus der Softwareentwicklung<br />
verwendet und deshalb von der Konfiguration<br />
der Anlagentags in einer Anlage gesprochen.<br />
Die Antwort auf die zuvor aufgezeigten Herausforderungen<br />
ist ein <strong>Konfigurationsmanagement</strong>.<br />
Eine weitere D<strong>im</strong>ension dieses <strong>Konfigurationsmanagement</strong>s<br />
entsteht durch die Tatsache, dass bei Lieferung<br />
der Feldgerätetypen zum Anlagenbetreiber mehr als eine<br />
Firmware-Version desselben Feldgerätetyps dort ankommen<br />
kann (produzierte Instanzen einer Feldgeräteklasse);<br />
die Feldgerätetypen werden von unterschiedlichen<br />
Produktionsstandorten des Feldgeräteherstellers oder<br />
aus Lagern von Ingenieurbüros geliefert, sind Bestandteil<br />
von Verpackungseinheiten oder wurden zu unterschiedlichen<br />
Zeitpunkten bestellt [2].<br />
Diese Vielfalt <strong>im</strong> Griff zu behalten ist eine große Herausforderung.<br />
Sie hat zur Konsequenz, Identifikationsmerkmale<br />
der jeweiligen Feldgeräteinstanz <strong>im</strong> Feld (Anlagentag)<br />
mit denen der Feldgeräteklasse abzugleichen.<br />
Im Laufe des Lebenszyklus einer Anlage entsteht somit<br />
in der installierten Basis über alle Komponenten ein<br />
mehrd<strong>im</strong>ensionales Versions- beziehungsweise Revisionsprofil,<br />
dargestellt in Bild 4.<br />
Die Attribute, die einen wesentlichen Bestandteil dieses<br />
geforderten <strong>Konfigurationsmanagement</strong>s bilden, sind<br />
abhängig vom digitalen Kommunikationssystem. Bei<br />
Hart-Kommunikation sind dies zum Beispiel der Feldgerätehersteller,<br />
der Feldgerätetyp, die Firmware-Version<br />
respektive die Feldgeräterevision und die Gerätetreiberversion.<br />
Dies sind Attribute der Hart-Geräteklasse.<br />
Für ein opt<strong>im</strong>ales Tag-bezogenes <strong>Konfigurationsmanagement</strong><br />
sind in der jeweiligen Instanz eines best<strong>im</strong>mten<br />
Anlagen-Tags diese dem Feldbus zuzuordnenden<br />
Attribute über die Serialisierungsinformation<br />
des Feldgerätetyps mit den herstellerinternen Produktdaten<br />
in Beziehung zu setzen [4], zum Beispiel der<br />
Bestellnummer.<br />
ABK<br />
Gerätetreiber<br />
Version des<br />
Gerätetreibers<br />
passt zur<br />
Geräterevision<br />
Feldbus<br />
PNK<br />
BILD 2: Verlauf der durchschnittlichen<br />
Investition pro Betriebsmittel über die Zeit<br />
mit und ohne Asset-Management<br />
Geräterevision<br />
Feldgeräte<br />
BILD 3: Versionen von Treiber und Gerät<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
33
HAUPTBEITRAG<br />
Kompatibilitätsbereich<br />
Firmware 1 Firmware 2<br />
Kompatibilitätsbereich<br />
Firmware 3 Firmware 4<br />
Komp<br />
BILD 4: Zusammenhang zwischen<br />
Geräterevisionen und Gerätetreiberversionen<br />
Geräterevision 1<br />
Geräterevision 2<br />
Lebenszyklus Feldgerätetyp (Innovation)<br />
Lebenszyklus<br />
Gerätetreiber<br />
Gerätetreiberversion 1<br />
Gerätetreiberversion 2<br />
Benutzer<br />
Plant Asset<br />
Management<br />
System<br />
Datenbanksystem<br />
Seriennummer<br />
Gerätetyp<br />
Firmwareversion<br />
Treibername<br />
Treibertyp<br />
Treiberversion<br />
ABK Hersteller<br />
ABK Name<br />
ABK Version<br />
Relationen<br />
Feldgerätetyp<br />
Gerätetreiber<br />
ABK<br />
BILD 5: <strong>Konfigurationsmanagement</strong><br />
BILD 6: Device Integration Manager<br />
Idealerweise sollten die genannten Attribute innerhalb<br />
einer relationalen Datenbank in Beziehung gesetzt<br />
werden (siehe Bild 5). Ein Benutzer oder ein technisches<br />
System, wie ein Plant Asset Management System,<br />
können strukturierte Abfragen durchführen und Reports<br />
generieren.<br />
3.1 Phasen <strong>im</strong> <strong>Anlagenlebenszyklus</strong><br />
Im Lebenszyklus einer Anlage lassen sich folgende Phasen<br />
mit Szenarien identifizieren, während derer das<br />
<strong>Konfigurationsmanagement</strong> den oben gestellten Anforderungen<br />
bezüglich der genannten Assets gerecht werden<br />
muss.<br />
Engineering<br />
Anlagenplanung: In der Phase der Anlagenplanung ist es<br />
wichtig zu wissen, ob für die zu planenden/geplanten<br />
Anlagenkomponenten Leitsystem, digitales Kommunikationssystem<br />
sowie Messtechnik und Aktorik entsprechende<br />
Gerätetreiber zur Verfügung stehen. Schon in dieser<br />
frühen Phase des <strong>Anlagenlebenszyklus</strong> kann das Datenbanksystem<br />
wertvolle Information zur Verfügung stellen.<br />
Inbetriebnahme<br />
Erstinbetriebnahme: Idealerweise lässt der Betreiber einer<br />
Anlage alle kommunizierenden Instanzen der Feldgerätetypen<br />
in einem Plant Asset Management System<br />
verwalten. Auf diese Weise sind alle Feldgerätetypen mit<br />
ihrer jeweiligen Serialisierungsinformation unter einer<br />
zentralen Nummer, einem Kundenaccount, identifizierbar.<br />
Es ist nun einfach, mittels des oben erwähnten Datenbanksystems<br />
ein Paket aller benötigten Gerätetreiber<br />
zusammenzustellen, das vom Betreiber der Anlage heruntergeladen<br />
und <strong>im</strong> Kontext des Leitsystems installiert<br />
werden kann. Ein solches Vorgehen senkt die Inbetriebnahmekosten<br />
und die Inbetriebnahmezeit erheblich.<br />
Anlagenerweiterung: Wir unterscheiden zwei Fälle,<br />
die Erweiterung um A) denselben Feldgerätetyp oder B)<br />
um einen neuen Feldgerätetyp. In beiden Fällen sinken<br />
die Inbetriebnahmekosten und die Inbetriebnahmezeit.<br />
A | Be<strong>im</strong> selben Feldgerätetyp ist die Anlagenerweiterung<br />
oftmals nur auf Basis einer neueren Firmware-Version<br />
des Feldgerätetyps möglich. Das Plant<br />
Asset Management System hat Kenntnis über diese<br />
Erweiterung und eine erneute Anfrage an das Datenbanksystem<br />
ermittelt die gegebenenfalls fehlenden<br />
Gerätetreiber zur Anlagenaktualisierung. Vergleichsfunktionen<br />
für relevante Asset-Information<br />
bieten zusätzlichen Nutzen.<br />
B | Hier gelten die Aussagen der Erstinbetriebnahme<br />
Gerätetausch: Aufgrund der langen Anlagenlaufzeiten<br />
kann der Fall eintreten, dass bei einem Tausch eines Feldgerätetyps<br />
der ursprüngliche Feldgerätetyp vom Hersteller<br />
bereits abgekündigt wurde. In unserem Szenario stünde<br />
zwar ein aus funktionaler Sicht geeigneter Nachfolger<br />
zur Verfügung, er hätte jedoch nicht denselben Feldgerätetyp<br />
wie sein Vorgänger. Auch hier kann das Datenbanksystem<br />
unterstützen, indem es zum Beispiel bei Profibus<br />
dem Benutzer Vorschläge über mögliche Feldgerätetypen<br />
macht, die in der Lage sind, den Vorgänger zu emulieren<br />
(Profibus Profil 3.02 Funktionalität). Die Inbetriebnahmekosten<br />
sinken in diesem Szenario, da unter Umständen<br />
34<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
keine neue GSD installiert werden muss, gleichzeitig aber<br />
die Information über den aktuellen Gerätetreiber für die<br />
Konfiguration angeboten wird [5].<br />
Instandhaltung<br />
Fehlerbehebung bei Feldgerätetypen: Eine Elektronikkomponente<br />
eines Feldgerätetyps muss wegen eines Fehlers<br />
nach längerer Betriebszeit ausgetauscht werden (siehe<br />
Einleitung). Die Elektronikkomponente ist zum Beispiel<br />
mit der aktuellen Firmware-Version des Feldgerätes<br />
vorkonfiguriert, die gegenüber der Vorgängerversion einen<br />
Geräterevisionsübergang mit sich bringt. Unter Umständen<br />
ist der passende Gerätetreiber nicht <strong>im</strong> System<br />
vorhanden und der Austausch der Elektronikkomponente<br />
führt zu einer unerwarteten Ausfallzeit der Anlage<br />
und damit zu einem Produktivitätsverlust. In diesem<br />
Szenario kann das Datenbanksystem in Verbindung mit<br />
der Serialisierungsinformation zur Instanz eine Serviceplanung<br />
ideal unterstützen. Es kann <strong>im</strong> Vorfeld die Entscheidung<br />
getroffen werden, ob die zu ersetzende Elektronikkomponente<br />
mit der alten Feldgerätefirmware<br />
vorkonfiguriert wird, oder aber ob der passende Gerätetreiber<br />
zum Serviceeinsatz mitgebracht und installiert<br />
wird. Die Ausfallzeit wird auf diese Weise min<strong>im</strong>iert.<br />
Funktionserweiterung von Feldgerätetypen: Funktionserweiterungen<br />
von Feldgerätetypen führen in den<br />
allermeisten Fällen zu Geräterevisionsübergängen bei<br />
der Feldgerätefirmware, zum Beispiel infolge von zusätzlichen<br />
Parametern oder erweiterten Enumerationen. Diese<br />
oftmals <strong>im</strong> Sinne einer Steigerung der Anlageneffizienz<br />
kundenseitig erwünschten Updates lassen sich nun<br />
hinsichtlich des damit notwendigerweise einhergehenden<br />
Updates des zugehörigen Gerätetreibers sehr gut<br />
planen. Die Ausfallzeit einer Anlage wird min<strong>im</strong>iert.<br />
Vorausschauende Wartung: Wird ein Plant Asset Management<br />
System eingesetzt, so lässt sich mit dem Datenbanksystem<br />
eine vorausschauende Wartung realisieren.<br />
Es kann ein Wartungsplan oder Wartungsprofil einer<br />
Anlage erstellt werden, mit Aussagen zu Firmware-Versionen,<br />
passenden Gerätetreibern und deren Versionen<br />
oder sogar zu aktualisierten Gerätetreiberversionen,<br />
deren Verwendung die Anlagenproduktivität steigert.<br />
Zur Unterstützung der zuvor erwähnten Phasen wird<br />
ein Datenbanksystem vorgeschlagen.<br />
3.2 Anforderungen an ein Datenbanksystem<br />
Ein relationales Datenbanksystem, das den oben geschilderten<br />
Anforderungen genügt, ist typischerweise webbasiert<br />
und zudem technologisch offen für webbasierte<br />
Zugriffe (Webservices). Es bietet kommunikationssystembezogene<br />
Komplettübersichten über alle Feldgerätetypen<br />
und deren Firmware-Versionen respektive Geräterevisionen.<br />
Eine Darstellung der Kompatibilitätsmatrix<br />
entlang der Historie der Firmware-Versionen bezogen auf<br />
die Gerätetreiber oder Integrationskomponenten (wie<br />
GSD, DTM, EDD) ist ebenso selbstverständlich wie der<br />
schnelle Zugriff auf die Herstellerinformation nach<br />
NE 53 [6]. Eine komfortable Suchfunktion sowohl auf<br />
Basis von Geräteinstanzen, also Tag-bezogen, als auch<br />
Geräteklassen und ein übersichtliches Reporting runden<br />
das Portfolio ab.<br />
Zur Opt<strong>im</strong>ierung der Inbetriebnahme- und Wartungszeiten<br />
kann solch ein System in einer weiteren Ausbaustufe<br />
dem Benutzer in den beschriebenen Szenarien<br />
gezielt Standard Operating Procedures (SOP) an die<br />
Hand geben.<br />
Die Anordnung der notwendigen Attribute in einem<br />
zentralen, relationalen und Web-basierten Datenbanksystem<br />
bringt erhebliche Vorteile mit sich. Es lassen sich<br />
mittels geeigneter SQL-Abfragen nahezu beliebige Datenaggregate<br />
realisieren. Damit ist es möglich, flexibel<br />
auf unterschiedliche Fragestellungen eine Antwort zu<br />
geben. Dabei ist es unerheblich, ob die Abfragen an das<br />
Datenbanksystem durch einen Benutzer über einen Webclient<br />
erfolgen oder durch ein technisches System, wie<br />
zum Beispiel bei einem Plant Asset Management System,<br />
über Webservices.<br />
Einer Umfrage des Namur-AK 2.6 Feldbus zufolge ergaben<br />
sich bei einer Gesamtzahl von 26 untersuchten<br />
Anlagen bei 18 Anlagen Probleme mit der Geräteintegration<br />
bei Erstinbetriebnahme [7]. Das beschriebene <strong>Konfigurationsmanagement</strong><br />
mittels eines relationalen Datenbanksystems<br />
kann einem Großteil der genannten Probleme<br />
wirksam begegnen.<br />
3.3 Implementierung des Systems<br />
Bei Endress+Hauser steht ein Softwarewerkzeug zur<br />
Verfügung, das alle angesprochenen Szenarien unterstützt.<br />
Dabei bildet dieser Device Integration Manager<br />
(siehe Bild 6) den erweiterten Lebenszyklus eines Feldgerätes<br />
unter Einbeziehung der Entwicklungsphase ab<br />
[4]. Der Device Integration Manager wird derzeit intern<br />
genutzt und erprobt.<br />
Neben der eindeutigen Suchfunktion über Seriennummer<br />
besteht die Möglichkeit, ein Feldgerät über den<br />
Suchbaum auszuwählen. Der rechte Teil der Anzeige<br />
ist zweifach gegliedert, <strong>im</strong> oberen Teil findet sich die<br />
Firmware-Historie, <strong>im</strong> unteren Teil die Gerätetreiberinformation<br />
beziehungsweise Detailinformation zu den<br />
Feldgeräten.<br />
Der obere Teil der Applikation bietet dem Nutzer ein<br />
komfortables Compatibility Assessment. Entlang der<br />
Firmware-Historie wird die gerätetreiberrelevante Geräterevision<br />
zusammen mit einer Kompatibilitätsmatrix<br />
bezogen auf die jeweilige Integrationskomponente (grüner<br />
Bereich) dargestellt. Innerhalb des grünen Bereichs<br />
können die Firmware-Versionen der Feldgeräte variieren,<br />
ohne dass in der Anlage ein Gerätetreiber-Update nötig<br />
wäre. Weitere Unterstützung be<strong>im</strong> Compatibility Assessment<br />
bietet die als PDF-Dokument verfügbare Manufacturer<br />
Information nach NE 53 [6]. Für Feldgeräte mit<br />
Profibus-Kommunikation steht die Information über<br />
GSD-kompatible Gerätetypen bereit, die be<strong>im</strong> Feldgerätetausch<br />
von großer Bedeutung ist.<br />
AUSBLICK<br />
Das einwandfreie Zusammenspiel zwischen allen Anlagenkomponenten<br />
setzt ein Verständnis für die Anforderungen<br />
der einzelnen <strong>Anlagenlebenszyklus</strong>phasen voraus.<br />
Darüber hinaus ist eine aktive Beteiligung der Her-<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
35
HAUPTBEITRAG<br />
REFERENZEN<br />
[1] Urbas, L.: Skript Prozessleittechnik SS 2006, Technische Universität<br />
Dresden, 2006<br />
[2] Device Revision and Lifecycle Management Guide, 12.12.2012,<br />
www.eddl.org<br />
[3] Wesner, S., Sommer, R.: Geräteintegration – Schlüssel für erfolgreichen<br />
Feldbuseinsatz. CHEManager, (8/2008), S. 16, 2008<br />
[4] IEC 65/526/NP: Life-Cycle management for systems and products used<br />
in industrial-process measurement, control and automation. May 2013<br />
[5] Diedrich, Ch., Bangemann, Th..: PROFIBUS PA Instrumentation<br />
Technology for the Process Industry. Oldenbourg Industrieverlag, 2007<br />
[6] NE 53: Software und Hardware von Feldgeräten und signalverarbeitenden<br />
Geräten mit Digitalelektronik. Namur 2010<br />
[7] Pelz, M., Seintsch, S.: Gerätekommunikation <strong>im</strong> Wandel, <strong>atp</strong> – Automatisierungstechnische<br />
Praxis 50(4), S. 52-57, 2008<br />
[8] Schrieber, R., Wollschlaeger, M., Mühlhause, M., Niemann, J..:<br />
Kompatibiliät: der zentrale Schlüssel für Nachhaltigkeit. <strong>atp</strong> – Automatisierungstechnische<br />
Praxis 37(9), S. 50–57, 2011<br />
[9] acatech: Umsetzungsempfehlungen für das Zukunftsprojekt Industrie<br />
4.0, Abschlussbericht des Arbeitskreises Industrie 4.0, April 2013<br />
[10] Früh, K.F., Maier, U., Schaudel, D..: Handbuch der Pro zessautomatisierung,<br />
Prozessleittechnik für verfahrenstechnische<br />
Anlagen. München. Oldenbourg 2009<br />
[11] ZVEI: Life-Cycle-Management für Produkte und Systeme der<br />
Automation, Frankfurt, 2010<br />
[12] NE 107: Selbstüberwachung und Diagnose von Feldgeräten.<br />
Namur 2006<br />
[13] NE 105: Anforderungen an die Integration von Feldbusgeräten in<br />
Engineering-Tools für Feldgeräte. Namur 2003<br />
steller an der Weiterentwicklung von Integrationstechnologien<br />
unabdingbar [8].<br />
Es ist zu vermuten, dass sich die Produktlebenszyklen<br />
weiter verkürzen werden und damit der Aufwand, jede<br />
Komponente mit mehreren Softwareversionen kompatibel<br />
zu halten, rasant steigt. Dadurch ergeben sich häufig ungeplante<br />
Änderungen <strong>im</strong> Ablauf der Anlage, weshalb die Beteiligten<br />
<strong>im</strong>mer schneller und effizienter reagieren müssen.<br />
Die Umsetzungsempfehlungen der Forschungsunion<br />
und Acatech für Industrie 4.0 zeigen auf, dass die Bereitstellung<br />
der richtigen Information zur richtigen Zeit und<br />
deren Verwaltung eine <strong>im</strong>mer größere Rolle spielen wird<br />
[9]. Szenarien, in denen Geräte und Systeme automatisch<br />
alle benötigten Information erhalten oder bei der Inbetriebnahme<br />
sich selbst konfigurieren, werden <strong>im</strong>mer<br />
greifbarer. Es stellt sich die Frage, ob dann eine Integration<br />
<strong>im</strong> herkömmlichen Sinne [10] noch sinnvoll ist oder<br />
ob man sich vielmehr auf neuen Technologien basierend<br />
auf die Industrie 4.0-Anwendungsfälle konzentrieren sollte?<br />
Der Schlüssel wäre eine zentrale Datenbank, die unter<br />
anderem Methoden, System-, Gerätefunktionalitäten und<br />
Anlagenanforderungen miteinander verknüpft und auf<br />
Anfrage automatisiert bereitstellt. S<strong>im</strong>ulationen aller<br />
möglichen Szenarien könnten bereits <strong>im</strong> Vorfeld durchgeführt<br />
werden und würden die Anwender nicht mehr<br />
nur zum Reagieren zwingen, sondern ihnen die Durchführung<br />
vorbeugender Maßnahmen ermöglichen.<br />
MANUSKRIPTEINGANG<br />
07.06.2013<br />
Im Peer-Review-Verfahren begutachtet<br />
AUTOREN<br />
Dipl.-Ing.<br />
GÜNTHER GREDY<br />
(geb. 1953) ist<br />
verantwortlich für<br />
die Entwicklung<br />
des Device Integration<br />
Manager<br />
innerhalb der<br />
Endress+Hauser<br />
Process Solutions AG. Er leitet das Test<br />
& Certification Team der FDT Group.<br />
Endress+Hauser Process Solutions AG,<br />
Kägenstraße 2, 4153 Reinach, Schweiz,<br />
E-Mail:<br />
guenther.gredy@solutions.endress.com<br />
Dipl.-Ing. (FH)<br />
MIRKO BRCIC<br />
(geb. 1982) ist<br />
Leiter des Technology<br />
Managements-<br />
Integration<br />
Development<br />
innerhalb der<br />
Endress+Hauser<br />
Process Solutions AG. Sein Arbeitsgebiet<br />
ist die technische Analyse<br />
digitaler Kommunikations- und<br />
Integrationstechnologien für die<br />
Prozessautomatisierung und deren<br />
Überführung in die Entwicklung.<br />
Endress+Hauser Process Solutions AG,<br />
Kägenstraße 2, 4153 Reinach, Schweiz,<br />
Tel. +41 61 715 73 55,<br />
E-Mail: mirko.brcic@solutions.endress.com<br />
Dr.-Ing. JÖRG<br />
HÄHNICHE<br />
(geb. 1957) ist<br />
Leiter der Abteilung<br />
Development<br />
and Integration<br />
Services und<br />
Mitglied der<br />
Geschäftsleitung<br />
der Endress+Hauser Process Solutions<br />
AG. Seine Hauptarbeitsgebiete sind die<br />
Geräteintegration in Automatisierungssysteme<br />
und digitale Kommunikationstechnologien.<br />
Endress+Hauser Process Solutions AG,<br />
Kägenstraße 2, 4153 Reinach, Schweiz,<br />
E-Mail:<br />
joerg.haehniche@solutions.endress.com<br />
36<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
Der Klassiker für die<br />
Prozessautomation geht<br />
ins 21. Jahrhundert<br />
Industrielle Informationssicherheit<br />
Gereviewte Beiträge aus dem Automatisierungsfachtitel <strong>atp</strong> <strong>edition</strong><br />
sind unter dem Schwerpunkt „Industrielle Informationssicherheit“ neu<br />
zusammen gestellt worden. Praxisrelevante Maßnahmen zur Umsetzung<br />
aktueller Normen und Leitfäden sicherer Kommunikation in der<br />
Industrie geben den aktuellen Stand der Wissenschaft wieder.<br />
Hrsg.: Leon Urbas<br />
1. Auflage 2014<br />
96 Seiten, farbig, Broschur<br />
ISBN: 978-3-8356-7113-3<br />
Preis: € 59,–<br />
www.di-verlag.de<br />
Das Buch erscheint <strong>im</strong> DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München<br />
Jetzt bestellen!<br />
WISSEN FÜR DIE<br />
ZUKUNFT<br />
Bestellung per Fax: +49 201 / 820 Deutscher 02-34 Industrieverlag oder GmbH abtrennen | Arnulfstr. und 124 <strong>im</strong> | Fensterumschlag 80636 München einsenden<br />
Ja, ich bestelle gegen Rechnung 3 Wochen zur Ansicht<br />
___Ex.<br />
Industrielle Informationssicherheit<br />
1. Auflage 2014 – ISBN: 978-3-8356-7113-3 für € 59,– (zzgl. Versand)<br />
Firma/Institution<br />
Vorname, Name des Empfängers<br />
Straße / Postfach, Nr.<br />
Land, PLZ, Ort<br />
Telefon<br />
Telefax<br />
Antwort<br />
Vulkan-Verlag GmbH<br />
Versandbuchhandlung<br />
Postfach 10 39 62<br />
45039 Essen<br />
E-Mail<br />
Branche / Wirtschaftszweig<br />
Bevorzugte Zahlungsweise Bankabbuchung Rechnung<br />
Bank, Ort<br />
Widerrufsrecht: Sie können Ihre Vertragserklärung innerhalb von zwei Wochen ohne Angabe von Gründen in Textform (z.B.<br />
Brief, Fax, E-Mail) oder durch Rücksendung der Sache widerrufen. Die Frist beginnt nach Erhalt dieser Belehrung in Textform.<br />
Zur Wahrung der Widerrufsfrist genügt die rechtzeitige Absendung des Widerrufs oder der Sache an die Vulkan-Verlag GmbH,<br />
Versandbuchhandlung, Postfach 10 39 62, 45039 Essen.<br />
Bankleitzahl<br />
Ort, Datum, Unterschrift<br />
Kontonummer<br />
PAATP52013<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, dass ich<br />
vom DIV Deutscher Industrieverlag oder vom Vulkan-Verlag per Post, per Telefon, per Telefax, per E-Mail, nicht über interessante, fachspezifische Medien und Informationsangebote informiert und beworben werde.<br />
Diese Erklärung kann ich mit Wirkung für die Zukunft jederzeit widerrufen.
HAUPTBEITRAG<br />
Geräteintegration und<br />
-management<br />
Teil 1: von der Integration mit EDDL und FDT zu FDI<br />
Gerätemanagement beinhaltet die Integration von intelligenten Feldgeräten und -komponenten<br />
in der Fertigungs- und Prozessautomatisierung. Die Integration dieser Geräte stellt<br />
eine große Herausforderung dar. Field Device Integration (FDI) ist eine neue vielversprechende<br />
Geräteintegrationstechnologie, die sich dieser Aufgabe stellt. Zum einen behandelt<br />
der Beitrag die heute üblichen Geräteintegrationstechnologien EDDL und FDT. Zum anderen<br />
wird der aktuelle technische Status von FDI sowie eine aus der Produktentwicklung<br />
stammende Implementierung vorgestellt, die um FDI erweitert wurde.<br />
SCHLAGWÖRTER Geräteintegration / Gerätemanagement / EDDL / FDT / FDI<br />
Device Management and Integration –<br />
Part 1: From Integration with EDDL and FDT towards FDI<br />
Device management involves the integration of intelligent field devices in both factory<br />
and process automation, and this is still a challenge. Field Device Integration is a promising<br />
new approach. After addressing current device integration by means of EDDL and<br />
FDT, the technical status regarding FDI is described and a product development <strong>im</strong>plementation<br />
is presented which has been enhanced by FDI.<br />
KEYWORDS device integration / device management / EDDL / FDT / FDI<br />
38<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
HOLGER RACHUT, HERMANN RICHTER, STEFAN RUNDE, RONALD LANGE,<br />
ALBERT JUSTUS, JÜRGEN FICKER, KARSTEN SCHNEIDER, Siemens<br />
In Automatisierungssystemen der Fertigungs- und Prozessindustrie<br />
kommen eine Vielzahl von Feldgeräten – Aktoren<br />
und Sensoren – von unterschiedlichen Herstellern<br />
zum Einsatz [1], die wiederum verschiedene Kommunikationsprotokolle<br />
unterstützen. In der Prozessindustrie<br />
sind dies überwiegend FF, Hart und Profibus / Profinet. Neben<br />
der Übertragung der Prozesswerte bilden die Kommunikationsprotokolle<br />
zudem die Grundlage des Versions-,<br />
Update- und Statusmanagements für Feldgeräte. Diese zusätzliche<br />
Information stellt wiederum die Basis für höherwertige<br />
Anwendungen wie Condition Monitoring und Asset<br />
Management dar. Um die Funktionen und Anwendungen<br />
nutzen zu können, sind die Feldgeräte in Supervisory Control<br />
and Data Acquisition (Scada)-Systeme und Distributed<br />
Control Systems (DCS) zu integrieren. Für diese Geräteintegration<br />
sind Gerätemanagement-Werkzeuge verantwortlich.<br />
Dieser Beitrag über Geräteintegration und -management<br />
besteht aus zwei Teilen. Der erste Teil behandelt<br />
das Thema Geräteintegration – Technologien und Realisierung.<br />
Der später erscheinende zweite Teil befasst sich<br />
mit dem Gerätemanagement.<br />
Die Integration intelligenter und -komponenten in ein<br />
SCADA-System und PLS stellt eine große Herausforderung<br />
für Anwender dar. Die Gründe dafür sind die Komplexität<br />
der Feldgeräte mit zahlreichen und vielfältigen Parametern<br />
und Funktionen und die unterschiedlichen Geräteintegrationstechnologien.<br />
Neben verschiedenen Ansätzen <strong>im</strong> wissenschaftlichen<br />
Umfeld, werden in der industriellen Praxis<br />
von Automatisierungssystemen in der Prozessindustrie fast<br />
ausschließlich die Technologien Electronic Device Description<br />
Language (EDDL) und Field Device Technology (FDT)<br />
angewendet – EDDL und FDT unterstützen die genannten<br />
Kommunikationsprotokolle. Die Geräteintegrationstechnologie<br />
Field Device Integration (FDI) vereint die Vorteile von<br />
EDDL und FDT zu einer zukünftigen Lösung.<br />
1. GRUNDLAGEN HEUTE – EDDL UND FDT<br />
Die Geräteintegration ist hinsichtlich des Gerätemanagements<br />
verantwortlich für die semantische Bereitstellung<br />
der Feldgeräte-Information <strong>im</strong> Rahmen eines DCS. Es<br />
bildet die Basis für das Gerätemanagement und stellt<br />
einen elementaren Bestandteil für den opt<strong>im</strong>ierten, automatisierten<br />
Betrieb einer Anlage dar. Die Integration<br />
ist zeitaufwendig sowie fehlerbehaftet [1]. Die Hauptbestandteile<br />
jeder Geräteintegration – unabhängig von<br />
EDDL und FDT – sind:<br />
Gerätebeschreibung: Sie dient der Beschreibung der<br />
notwendigen Information über die Funktion eines<br />
Feldgerätes; unter anderem anhand von Variablen,<br />
Methoden, Graphical User Interface (GUI).<br />
Host: Er bereitet unter anderem die durch die Gerätebeschreibung<br />
bereitgestellten Information eines<br />
Feldgerätes für das jeweilige DCS auf. Die weiteren<br />
Aufgaben eines Host adressieren vor allem das Gerätemanagement,<br />
das in Teil 2 dieses Beitrags behandelt<br />
wird.<br />
Im Zusammenhang mit der Gerätebeschreibung definiert<br />
FDT sogenannte Device Type Managers (DTM) mit<br />
Schnittstellen, zum Beispiel für die Kommunikation mit<br />
einem Feldgerät. Diese DTM werden <strong>im</strong> Host mit Hilfe<br />
einer FDT-Rahmenapplikation ausgeführt. Die definierten<br />
Schnittstellen stellen die Interoperabilität mit dem Host<br />
sicher, wobei der Feldgerätehersteller nur bedingt Restriktionen<br />
hinsichtlich der jeweiligen DTM-Implementierung<br />
hat; zum Beispiel in Bezug auf die Programmiersprache<br />
und der Gestaltung der GUI [1]. Auf der einen Seite<br />
erlaubt dieser Ansatz nahezu uneingeschränkte Freiheiten<br />
in der Gestaltung der GUI. So können untern anderem<br />
3D-Vektor-Diagramme dargestellt werden. Auf der anderen<br />
Seite führen diese Freiheiten zu mannigfaltigen GUI<br />
mit unterschiedlichen Bedienphilosophien, die von der<br />
Anwenderseite nicht gewünscht sind. In FDT wird versucht,<br />
dem mit einem Style Guide zu entgegnen.<br />
Mit Hilfe von EDDL, ebenfalls eine offene und standardisierte<br />
Gerätebeschreibungssprache, werden textbasierte<br />
Gerätebeschreibungen erstellt – Electronic Device Descriptions<br />
(EDD). Die EDD werden von einem EDD-spezifischen<br />
Interpreter verarbeitet. Der Interpreter ist abstrakt betrach-<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
39
HAUPTBEITRAG<br />
tet vergleichbar mit der FDT-Rahmenapplikation. Bei FDT<br />
ist die Rahmenapplikation jedoch firmenunabhängig zu<br />
beziehen. Ein EDD-Interpreter kann zum einen firmenspezifisch<br />
<strong>im</strong>plementiert werden. Zum anderen besteht die<br />
Möglichkeit ein DTM, dessen Logik über EDDL beschrieben<br />
ist, mit einer FDT-Rahmenapplikation zu verarbeiten.<br />
Die EDDL-Sprachelemente sind auf die Geräteintegration<br />
ausgerichtet – das Look and Feel ist daher einheitlich. Es<br />
sind jedoch keine 3D-GUI möglich [2].<br />
2. GERÄTEINTEGRATION ZUKÜNFTIG – FDI<br />
2.1 Motivation und Herausforderungen<br />
aus Anwendersicht<br />
Sämtliche Aspekte eines Automatisierungssystems müssen<br />
sich den Zielen eines automatisierten technischen<br />
Systems unterwerfen (zum Beispiel Produktivitäts- und<br />
Verfügbarkeitszielen) – so auch die Geräteintegration. [3],<br />
[4], [5]. Die Installation und Parametrierung der Geräte<br />
müssen dieses Ziel so gut wie möglich unterstützen –<br />
auch darf der Tausch eines Feldgerätes und die Inbetriebnahme<br />
nicht die Qualität des automatisierten technischen<br />
Prozesses beeinflussen.<br />
In installierten Automatisierungssystemen werden vor<br />
allem die Geräteintegrationstechnologien EDDL und FDT<br />
bei Automatisierungsanwendern und -betreibern eingesetzt<br />
– nicht selten beide Technologien in einer Anlage.<br />
Die installierte Basis der Geräte und Softwareanwendungen<br />
ist groß, Anwender und Betreiber verfügen über<br />
werthaltiges Know-how. Eine neue, vereinheitlichte<br />
Technologie zur Geräteintegration muss darum zu EDDL<br />
beziehungsweise FDT rückwärtskompatibel sein. Damit<br />
muss eine neue Technologie ebenso eine zuverlässige<br />
Umstiegslösung für beide Technologien darstellen. Im<br />
Idealfall ändern die Gerätehersteller jeweils ihre Parametriersoftware<br />
derart, dass sie sowohl den neuen Ansatz<br />
also auch die existierenden Technologien unterstützen.<br />
Das schließt die Forderung nach einem einheitlichen<br />
Parametrierwerkzeug [6] für alle Feldgeräte ein,<br />
unabhängig vom Hersteller. Es muss mit allen Geräten<br />
auf dem Markt funktionieren. Sicher wird es hier auch<br />
eine gewisse Zeit der Umstellung geben, bis es für alle<br />
Geräte eine entsprechend neue Beschreibungsdatei geben<br />
wird. Umso mehr bedarf es der Rückwärtskompatibilität<br />
der Software. Das heißt beispielsweise, dass der<br />
jeweilige Host in der Lage sein muss neben dem entsprechenden<br />
neuen Ansatz ebenfalls „alte“ EDDs beziehungsweise<br />
DTMs verarbeiten kann.<br />
Ein weiterer Schritt in Richtung Investitionssicherheit<br />
ist die Unabhängigkeit von einer Softwareplattform. Der<br />
Umstieg auf ein anderes Betriebssystem oder das Update<br />
auf eine neue Betriebssystemversion darf die Geräteintegration<br />
nicht behindern.<br />
EDDL und FDT unterscheiden sich hinsichtlich der Bedienphilosophie.<br />
Aus Anwendersicht besteht jedoch die<br />
Forderung nach einer einheitlichen Bedienoberfläche über<br />
alle Werkzeuge für Geräteintegration und -management<br />
hinweg [6]. Hier sind die Werkzeug- und Gerätehersteller<br />
hisnsichtlich einer einheitlichen Bedienphilosophie gefordert.<br />
Die darin befindlichen Teile müssen nach einem<br />
einheitlichen Bedienkonzept entwickelt werden, um die<br />
gewünschte Austauschbarkeit der Geräte zu garantieren.<br />
Die Ansätze EDDL und FDT zur Geräteintegration unterscheiden<br />
sich neben der Bedienphilosophie auch<br />
grundlegend in anderen Aspekten; zum Beispiel hinsichtlich<br />
des Basiskonzepts (siehe Abschnitt 1). Diese<br />
Unterschiede sind aus Sicht des Anwenders ungünstig,<br />
Betreiber und Anwender sind für beide Technologien zu<br />
schulen. Zusätzlich erhöht sich die Komplexität in einem<br />
Automatisierungssystem, wenn EDDL und FDT gemeinsam<br />
eingesetzt werden. Nicht zuletzt muss die Auswahl<br />
eines Feldgerätes grundsätzlich unabhängig von der Geräteintegrationstechnologie<br />
und dem Systemumfeld/<br />
DCS erfolgen können – dies ist seit Jahren eine Forderung<br />
der Anwender. In der Praxis ist dies noch lange nicht der<br />
Fall. Aus diesem Grund gaben das EDDL Cooperation<br />
Team (ECT) und die FDT Group <strong>im</strong> April 2007 eine Vereinbarung<br />
über die Entwicklung einer einheitlichen Lösung<br />
für die Field Device Integration (FDI) bekannt [7].<br />
Die Geräteintegrationstechnologie FDI – für Automatisierungssysteme<br />
und Feldbusse der Fertigungs- und<br />
Prozessindustrie – verfolgt zur Vereinheitlichung nicht<br />
den Ansatz, EDDL und FDT aufzuaddieren, was <strong>im</strong> Wesentlichen<br />
einem Nebeneinanderstellen der Technologien<br />
entspricht. Dies ist bereits ohne zusätzliche Spezifikationsarbeiten<br />
möglich und wird von Lösungen umgesetzt,<br />
wie zum Beispiel DTM, dessen Logik über EDDL<br />
beschrieben ist. FDI verfolgt einen synergetischen Ansatz<br />
der Konzepte von EDDL und FDT. Dadurch bietet<br />
FDI auch Möglichkeiten, die heute weder von EDDL noch<br />
von FDT alleine angeboten werden können. Die erwähnten<br />
Forderungen der Anwender lassen sich erstmals vollständig<br />
erfüllen, worauf <strong>im</strong> folgenden Abschnitt zu Konzept<br />
und Realisierung Bezug genommen wird [8].<br />
2.2 FDI-Basiskonzept<br />
Das FDI-Basiskonzept definiert die zentrale Komponente<br />
FDI Device Package sowie den FDI Host. FDI Device<br />
Packages werden vom Gerätehersteller erstellt und zertifiziert.<br />
Sie enthalten die Information, die für eine Geräteintegration<br />
notwendig ist, wie in Bild 1 gezeigt.<br />
Die Device Definition (Def) des FDI Device Package<br />
umfasst Verwaltungsinformation sowie das Gerätemodell.<br />
Die Konsistenzsicherung dieses Modells und die<br />
Kommunikationslogik zum Gerät erfolgt über die Business<br />
Logic (BL). Die Beschreibung der Präsentation der<br />
Geräteparameter und Gerätefunktionen übern<strong>im</strong>mt die<br />
User Interface Description (UID). Diese Bestandteile<br />
sind mit EDDL nach IEC 61804-3 zu beschreiben, wobei<br />
der UID-Teil verpflichtend zu beschreiben ist. Dazu<br />
werden die unterschiedlichen EDDL-Dialekte harmonisiert<br />
[9] – EDDL und ihre Harmonisierung nehmen<br />
40<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
die zentrale Rolle in FDI <strong>im</strong> Allgemeinen und <strong>im</strong> FDI<br />
Device Package <strong>im</strong> Speziellen ein. Zusätzlich können<br />
Oberflächenanteile als programmierte Komponenten<br />
– User Interface Plugin (UIP) – integriert werden, deren<br />
Basiskonzept dem FDT-Konzept nach IEC 62453 entspricht.<br />
Der FDI Host (Bild 2) besteht vor allem aus FDI<br />
Server und FDI Client – die Robustheit und Sicherheit<br />
des FDI-Konzepts wird durch eine klare Trennung der<br />
Systemkomponenten erreicht.<br />
Mittels FDI Server werden FDI Device Packages <strong>im</strong>portiert.<br />
Die Device Definition und Business Logic eines FDI<br />
Device Package werden über die EDD Engine ausgeführt,<br />
die auch als EDD Interpreter bezeichnet wird. Die programmierten<br />
UIP werden vom Server nur verwaltet, jedoch<br />
nicht ausgeführt. Sie werden auf Anfrage von Clients<br />
zu diesen transferiert. Ein FDI Client realisiert die<br />
Schnittstelle zum Anwender. Das Client-Server-Konzept<br />
erlaubt dabei die Verteilung der Clients auf verschiedene<br />
Rechner und den koordinierten und autorisierten Zugriff<br />
mehrerer Clients auf das gemeinsame Informationsmodell.<br />
Clients führen die User Interface Descriptions über<br />
einen Interpreter sowie die UIP aus, um dem Anwender<br />
die Geräteparametrierung, Diagnose, Prozessvariablen<br />
und Gerätefunktionen anzubieten. Dabei interagieren<br />
Clients nicht direkt mit dem Gerät sondern über das Informationsmodell<br />
(zum Beispiel basierend auf OPC UA)<br />
des FDI Servers. So kommunizieren FDI Clients nur über<br />
den FDI Server mit den Geräten.<br />
Da sich Clients be<strong>im</strong> Server authentifizieren müssen,<br />
lässt sich erreichen, dass nur zugelassene Clients Zugriff<br />
bekommen. Sie haben zudem nur lesenden Zugriff auf<br />
best<strong>im</strong>mte Teile des Informationsmodells des Servers.<br />
Eine weitere Sichereitsfunktionalität ist die Rechtekonfiguration<br />
der Clients, wodurch ein unautorisierter Zugriff<br />
auf Betriebsfunktionen verhindert wird. Bei Modifikationen<br />
der Daten durch Clients wird die Konsistenz<br />
des Gerätemodells durch die <strong>im</strong> FDI Server verfügbare<br />
Business Logic sichergestellt. In diesem Zusammenhang<br />
ist auch darauf hinzuweisen, dass die in der UID des FDI<br />
Device Packages beschriebene Anwenderpräsentation der<br />
Geräteparameter <strong>im</strong> FDI Server vorverarbeitet wird. Für<br />
die Darstellung am Client werden vom FDI Server Beschreibungen<br />
erzeugt, die nur noch die für die Anzeige<br />
erforderliche Information erhalten. Somit ist auf Client-<br />
Seite keine EDD Engine nötig. UIP werden <strong>im</strong> FDI Client<br />
zum Ablauf gebracht. Dabei hat ein UIP nur definierte<br />
Schnittstellen zur Verfügung, über die es auf die Client-<br />
Umgebung zugreifen kann. Somit kann ein UIP nicht<br />
direkt mit dem FDI-Server kommunizieren, sondern nur<br />
Aufträge an den Client weitergeben. Dadurch wird eine<br />
definierte Ablaufumgebung (Sandbox) erzeugt, über die<br />
die Ausführung der Plug-ins kontrolliert werden kann.<br />
Die Architektur ist dabei Bus-neutral und durch zusätzliche<br />
Protokollabbildungen erweiterbar – aktuell<br />
werden in FDI konkrete Abbildungen für die Protokolle<br />
Profibus/Profinet, Hart und FF definiert. Dafür können<br />
rein deskriptive und programmierte Erweiterungen,<br />
Communication Server, verwendet werden. Selbst be<strong>im</strong><br />
Communication Server (sein Einsatz ist optional) entscheidet<br />
der FDI Server, wann und welche Daten zum<br />
Gerät übertragen werden – dieser Aspekt wirkt sich positiv<br />
auf die Robustheit aus. Insbesondere in Multi-Client-Umgebungen<br />
werden so eine gegenseitige Beeinflussung<br />
sowie Überlastsituationen vermieden.<br />
Die FDI-Architektur bietet Möglichkeiten, die Anforderungen<br />
der Anwender besser zu erfüllen, als bisher.<br />
Neben der funktionalen Gleichwertigkeit zu EDDL und<br />
FDT hat FDI noch zusätzliche Eigenschaften, die von den<br />
bisherigen Geräteintegrationstechnologien nicht angeboten<br />
werden. Dabei handelt es sich beispielsweise um<br />
die skalierbare Nutzung von deskriptiven und programmierten<br />
Anteilen unter Beibehaltung der Plattformunabhängigkeit<br />
und ein Erweiterungskonzept für zusätzliche<br />
Kommunikationsprotokolle [8].<br />
FDI Client<br />
FDI Package<br />
FDI Device Package<br />
EDDL<br />
encoded<br />
file format<br />
Def BL UID<br />
Electronic Device<br />
Description<br />
Language<br />
(EDDL)<br />
UIP<br />
User<br />
Interface<br />
Plugin<br />
(mandatory)<br />
Windows<br />
Presentation<br />
Foundation<br />
(WPF)<br />
Attachments<br />
Manuals<br />
Certificates<br />
Protocol-specific<br />
files (GSD/ML/etc.)<br />
UID Interpreter<br />
User<br />
Interface<br />
Description<br />
User<br />
Interface<br />
Plug-in<br />
FDI Server<br />
Device Object<br />
Device Object<br />
Device Object<br />
System Communication Hardware<br />
EDD Interpreter<br />
Device<br />
Definition<br />
Business<br />
Logic<br />
Communication<br />
Server<br />
BILD 1: FDI Device Package<br />
BILD 2: FDI Host<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
41
HAUPTBEITRAG<br />
2.3 Realisierung und Varianten<br />
Die geforderte Plattformunabhängigkeit wird von FDI in<br />
mehrfacher Hinsicht adressiert. So basieren wesentliche<br />
Teile des Geräteintegrationskonzepts auf EDDL, welche<br />
als Beschreibungstechnik plattformunabhängig ist und<br />
die Langzeitverfügbarkeit ihrer Geräteintegrationen bereits<br />
bewiesen hat. Da UIP lediglich optionale Bestandteile<br />
sind, kann ein Gerätehersteller ein FDI Device Package<br />
nur mit diesen deskriptiven Mitteln erstellen.<br />
In einem FDI Server werden ausschließlich die deskriptiven<br />
Anteile eines FDI Device Packages zum Ablauf<br />
gebracht. Die UIP werden vom Server nur verwaltet<br />
und an die Clients verteilt. Für diese UIP sind die Anforderungen<br />
genauer zu betrachten: Programmierte<br />
Komponenten sind <strong>im</strong>mer abhängig von einer Basistechnologie,<br />
deren Weiterentwicklung nicht durch die Automatisierungshersteller<br />
beeinflusst wird. Für die Realisierung<br />
der UIP wird die .net-Technologie von Microsoft<br />
verwendet. Diese Technologie ist auf allen aktuellen<br />
PC-basierten Windows-Versionen vorhanden. Sie nutzt<br />
eine Zwischensprache (intermediate language), sodass<br />
eine einmal erstellte und in die Zwischensprache übersetzte<br />
.net-Komponente auf allen Windows-Versionen<br />
lauffähig ist. Die Abstraktion zum Betriebssystem wird<br />
über die .net-Laufzeitumgebung sichergestellt.<br />
Das FDI-Konzept stützt sich nicht darauf, dass .net<br />
auch für Nicht-Windows-Systeme angeboten wird. Stattdessen<br />
spezifiziert FDI die Nutzung von Varianten der<br />
UIP. Die verschiedenen Varianten eines UIP können sich<br />
dabei in dem unterstützten Betriebssystem und in der<br />
unterstützten Client-Umgebung unterscheiden. So kann<br />
es eine Variante für die Nutzung auf einem PC, eine<br />
andere für die Nutzung auf einem Handheld geben.<br />
Mehrere Varianten eines User Interface Plug-ins können<br />
in einem FDI Device Package geliefert werden. Ein FDI<br />
Client lädt nur die Variante vom FDI Server, die für seine<br />
Ablaufumgebung am besten geeignet ist. Wenn ein<br />
Hersteller die Geräteparameter und Gerätefunktionen<br />
über UID <strong>im</strong> FDI Device Package zur Verfügung stellt<br />
und die UIP vor allem für spezialisierte Darstellungen<br />
und Komfortfunktionen nutzt, kann ein FDI Device Package<br />
nichtsdestotrotz sinnvoll eingesetzt werden, zum<br />
Beispiel wenn in einem FDI Client keine der UIP-Varianten<br />
zum Ablauf gebracht werden kann oder aus best<strong>im</strong>mten<br />
Gründen nicht ausgeführt werden soll.<br />
Ausgehend von den genannten Gründen fordern Namur<br />
und WIB die User Interface Description (UID) – basierend<br />
auf EDDL – als verpflichtenden Anteil des FDI<br />
Device Packages. Dies bedeutet, dass beispielsweise die<br />
Inbetriebnahme eines Gerätes ausschließlich über diese<br />
deskriptiven Oberflächeanteile eines FDI Device Packages<br />
möglich ist. So ist die Rückwärtskompatibilität<br />
mit bestehenden EDD gegeben und somit der Schutz der<br />
Investition gewährleistet.<br />
Die FDI Cooperation entwickelt Software-Werkzeuge<br />
und Komponenten, die unter anderem der Validierung<br />
der erarbeiteten FDI-Spezifikationen (IEC 62769 – Field<br />
Device Integration) dienen. Diese werden über die beteiligten<br />
Nutzerorganisationen zur Verfügung gestellt.<br />
Zu diesen Software-Erzeugnissen zählt eine integrierte<br />
Entwicklungsumgebung (IDE), die es dem Gerätehersteller<br />
ermöglicht, FDI Device Packages zu erstellen. Die IDE umfasst<br />
dabei die Packetierung der einzelnen Device-Package-<br />
Bestandteile, die Erstellung der Kataloginformation und<br />
Tokenizer, die die EDD semantisch prüfen und die textuelle<br />
Darstellung in eine maschinell besser auswertbare<br />
Form überführen. Für die Erstellung der UIP <strong>im</strong> Kontext<br />
der IDE wird eine .net Library zur Verfügung gestellt. Diese<br />
Library ermöglicht eine opt<strong>im</strong>ale Integration in gängige<br />
Entwicklungswerkzeuge wie Microsoft Visual Studio. Angefangen<br />
von Editierhilfen wie Intellisense über Online<br />
Hilfe bis hin zu out-of-the-box Lösungen für asynchrone<br />
Nutzung der FDI-Interfaces stehen dem Entwickler damit<br />
sofort zur Verfügung. Die IDE beinhaltet zudem einen Reference<br />
Host, das heißt eine beispielhafte Implementierung<br />
eines FDI-Host-Systems. Damit lassen sich FDI Device Packages<br />
direkt innerhalb der Entwicklungsumgebung testen.<br />
Für die Systemhersteller werden Komponenten für die<br />
mögliche Nutzung <strong>im</strong> Host-System zur Verfügung gestellt.<br />
Zu diesen Komponenten zählen die EDD Engine<br />
und die UI Engine bestehend aus UID Renderer und UIP-<br />
Hosting-Komponente. Ein wichtiges Software-Designprinzip<br />
ist dabei die Unabhängigkeit dieser Komponenten<br />
voneinander. Systemhersteller stehen damit nicht<br />
vor einer „Alles-oder-Nichts“-Entscheidung, sondern<br />
können dediziert evaluieren, welche der FDI-Komponenten<br />
ihre bestehenden Systeme ergänzen können.<br />
Das vorgestellte FDI-Basiskonzept (siehe Abschnitt 2.1)<br />
erlaubt verschiedene Implementierungsvarianten, die<br />
nach den Spezifikationen zertifiziert werden können:<br />
Ein FDI Host (Single User) wird auf einem Gerät wie<br />
einem Notebook, installiert. Nur ein Benutzer kann<br />
zu einer Zeit mit diesem Host arbeiten. Beispiele<br />
sind Device Tools, Stand-alone Device-Management-<br />
Applications und Handheld Devices.<br />
Ein FDI Host (Multi User) wird auf einem Gerät aber<br />
potenziell auch auf mehreren Geräten installiert (zum<br />
Beispiel Client-Server-Architektur). Mehrere Benutzer<br />
können zur gleichen Zeit mit diesem Host arbeiten.<br />
Gleichzeitiger Zugriff auf Gerätedaten und Benutzeroberflächen<br />
gehört zum regulären Benutzungsmodell<br />
für diese Art von Hosts. Beispiele sind Distributed<br />
Host Systems und Asset Management Systems.<br />
Ein FDI Host/OPC UA (Multi User) kann zusätzlich<br />
die FDI Information Model Facet unterstützen. In<br />
diesem Fall unterstützt der FDI Host OPC UA als<br />
Kommunikationsmechanismus und bietet darüber<br />
das Informationsmodell an.<br />
Ein FDI Client (OPC UA) ist eine Client-Applikation,<br />
die getrennt von einem Distributed Control System<br />
(DCS) angeboten wird und typischerweise auch von<br />
einem anderen Hersteller. Der FDI Client (OPC UA)<br />
erfordert einen FDI Host, der die oben angeführte<br />
FDI Information Model Facet unterstützt.<br />
42<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
AUTOREN<br />
Dipl.-Ing. HOLGER RACHUT (geb. 1957) ist seit 2000<br />
<strong>im</strong> Produktmanagement für das Prozessleitsystem<br />
S<strong>im</strong>atic PCS 7 in der Siemens AG tätig. Nach der<br />
Ausbildung zum Betriebs- Mess- und Regelungstechniker<br />
studierte er an der Otto-von-Guericke-<br />
Universität Magdeburg Automatisierungstechnik<br />
und technische Kybernetik. Im Produktmanagement<br />
ist er zuständig für die Themen Feldgeräteintegration/Diagnose<br />
und Assetmanagement.<br />
Siemens AG,<br />
Östliche Rheinbrückenstraße 50,<br />
D-76187 Karlsruhe,<br />
Tel. +49 (0) 721 595 65 56,<br />
E-Mail: holger.rachut@siemens.com<br />
Dipl.-Ing. HERMANN RICHTER (geb. 1954) ist <strong>im</strong><br />
globalen Produktmanagement der Prozessleittechnik<br />
in der Siemens AG tätig. Nach seinem Studium<br />
der Elektrotechnik an der Technischen Universität<br />
München arbeitete er bei Siemens in unterschiedlichen<br />
Funktionen und Regionen <strong>im</strong> Umfeld der<br />
Industrieautomation. Im Produktmanagement für<br />
das Prozessleitsystem S<strong>im</strong>atic PCS 7 leitet er die<br />
Fachgruppe System Hardware.<br />
Siemens AG,<br />
Östliche Rheinbrückenstraße 50,<br />
D-76187 Karlsruhe,<br />
Tel. +49 (0) 721 595 68 74,<br />
E-Mail: hermann.richter@siemens.com<br />
Dr.-Ing. STEFAN RUNDE (geb. 1980) ist in der<br />
Vorfeldentwicklung des Sektors Industry der<br />
Siemens AG seit 2010 Projektleiter für das Thema<br />
Future DCS Architecture und seit 2012 zudem<br />
Programm Manager für das Themenfeld PC-based<br />
Architecture. Nach der Ausbildung zum Energieelektroniker<br />
studierte er Elektro- und Informationstechnik<br />
an der FH Hannover und promovierte<br />
an der Helmut-Schmidt-Universität Hamburg.<br />
Aktuelle Schwerpunkte seiner Arbeit sind die<br />
Verbesserung von Engineering und Architekturen<br />
<strong>im</strong> Umfeld von Scada und DCS.<br />
Siemens AG,<br />
Östliche Rheinbrückenstraße 50,<br />
D-76187 Karlsruhe,<br />
Tel. +49 (0) 721 595 79 77,<br />
E-Mail: stefan.runde@siemens.com<br />
Dipl.-Inf. RONALD LANGE (geb. 1965) ist seit 1989 in der<br />
Siemens AG tätig. Er studierte Informatik an der Universität<br />
Erlangen. Seit 1995 liegt sein Arbeitsschwerpunkt in der<br />
Systemarchitektur der Automatisierungssysteme. Aktuelle<br />
Arbeiten sind dabei die Geräteintegration in Engineeringsysteme<br />
sowie die Architektur des TIA-Portals.<br />
Siemens AG,<br />
Gleiwitzer Straße 555, D-90475 Nürnberg,<br />
Tel. +49 (0) 911 895 26 89,<br />
E-Mail: lange.ronald@siemens.com<br />
Dipl.-Ing. ALBERT JUSTUS (geb. 1960) arbeitet seit 2008 <strong>im</strong><br />
globalen Produktmanagement <strong>im</strong> Bereich der Prozessinstrumentierung<br />
mit den Schwerpunkten Geräteintegration und<br />
Kommunikation. Nach seinem Studium an der Fachhochschule<br />
Bielefeld begann er 1987 seine berufliche Laufbahn als Ingenieur<br />
bei der Siemens AG. Er war mehrere Jahre als Inbetriebsetzer<br />
und Projektleiter <strong>im</strong> In- und Ausland tätig.<br />
Siemens AG,<br />
Östliche Rheinbrückenstraße 50, D-76187 Karlsruhe,<br />
Tel. +49 (0) 721 595 51 08,<br />
E-Mail: albert.justus@siemens.com<br />
Dr. JÜRGEN FICKER (geb. 1971) ist seit 2012 <strong>im</strong> globalen<br />
Produktmanagement der Prozessinstrumentierung in der<br />
Siemens AG tätig. Nach seinem Physikstudium an der Friedrich-Alexander-Universität<br />
Erlangen-Nürnberg promovierte er<br />
<strong>im</strong> Rahmen einer Industriepromotion an der technischen<br />
Universität Darmstadt in Zusammenarbeit mit Siemens. Im<br />
Produktmanagement beschäftigt er sich mit fachübergreifenden<br />
Themen der Prozessinstrumentierung aus Sicht des Marktes.<br />
Siemens AG,<br />
Östliche Rheinbrückenstraße 50, D-76187 Karlsruhe,<br />
Tel. +49 (0) 721 595 35 22,<br />
E-Mail: juergen.ficker@siemens.com<br />
Dipl.-Ing. KARSTEN SCHNEIDER (geb. 1969) absolvierte das<br />
Studium der Elektrotechnik an der Friedrich-Alexander-Universität<br />
Erlangen-Nürnberg. Vor mehr als 15 Jahren startete er<br />
bei der Siemens AG in der zentralen Forschung und Entwicklung.<br />
Seitdem war er dort in verschiedenen Tätigkeitsfeldern<br />
beschäftigt. Im April 2012 wurde er in den Vorstand der<br />
Profibus Nutzerorganisation e.V. gewählt.<br />
Siemens AG;<br />
Gleiwitzer Straßse 555, D-90475 Nürnberg,<br />
Tel. +49 (0) 911 895 43 21,<br />
E-Mail: karsten.schneider@siemens.com<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
43
HAUPTBEITRAG<br />
REFERENZEN<br />
Ein FDI-Host (Single User) und FDI-Host (Multi User)<br />
– mit oder ohne OPC UA – kann eine FDI-Communication-Server-Facet<br />
anbieten. In diesem Fall unterstützt<br />
der Host die Anbindung von FDI Communication<br />
Servern.<br />
Ein FDI Communication Server wird genutzt, um Kommunikationshardware<br />
an ein Kommunikationsnetzwerk<br />
anzuschließen (Network Entry Point). FDI Communication<br />
Server werden über FDI Communication Packages<br />
integriert. Die eigentliche Treibersoftware wird aber separat<br />
installiert oder ist direkt in die Kommunikationshardware<br />
integriert. Der FDI Communication Server<br />
erfordert einen FDI Host, der die oben angeführte FDI<br />
Communication Server Facet unterstützt.<br />
3. FDI-REALISIERUNG MIT SIMATIC PDM<br />
Der S<strong>im</strong>atic Process Device Manager (S<strong>im</strong>atic PDM) von<br />
Siemens ist ein universelles, herstellerneutrales Werkzeug<br />
zur Projektierung, Parametrierung, Inbetriebsetzung,<br />
Diagnose und Wartung von intelligenten Feldgeräten.<br />
Kernfunktionen von S<strong>im</strong>atic PDM sind unter anderem<br />
das Einstellen und Ändern von Geräteparametern,<br />
das Vergleichen (zum Beispiel von Projekt- und Gerätedaten)<br />
sowie Inbetriebsetzungsfunktionen (wie Messkreistests<br />
von Gerätedaten). Hinsichtlich der Unterstützung<br />
der Betriebsführung sind Funktionen wie die einheitliche<br />
Darstellung/Bedienung von Geräten sowie die<br />
Darstellung von Diagnoseinformationen zu nennen. Diese<br />
und weitere Funktionen werden <strong>im</strong> zweiten Beitragsteil<br />
mit dem Schwerpunkt Gerätemanagement behandelt.<br />
[1] Grossmann, D., Bender, K., Danzer, B.: OPC UA based Field Device<br />
Integration. In: Proc. SICE Annual Conference, S. 933 – 938., 2008<br />
[2] Mahnke, W., Gössling, A., Graube, M., Urbas, L.: Information Modeling for<br />
Middleware in Automation. In: Proc. 16th IEEE Int. Conf. Emerging Technologies<br />
and Factory Automation (ETFA’11), S. 1-8. IEEE 2011<br />
[3] NE 91: Anforderungen an Systeme für Anlagennahes Asset Management.<br />
Namur, November 2001<br />
[4] NE 105: Anforderungen an die Integration von Feldbus-Geräten in<br />
Engineering-Tools für Feldgeräte. Namur, September 2008<br />
[5] NE 121: Qualitätssicherung leittechnischer Systeme. Namur, September 2008.<br />
[6] Pelz, M., Seintsch, S.: Gerätekommunikation <strong>im</strong> Wandel.<br />
In: <strong>atp</strong> – Automatisierungstechnische Praxis 50(4), S. 52 –57, 2008<br />
[7] Kumpfmüller, H.G.: Standard für Feldgeräteintegation.<br />
In: <strong>atp</strong> – Automatisierungstechnische Praxis 51(8), S. 10, 2009<br />
[8] Kumpfmüller, H.G, Lange, R.: FDI Device Integration – Best of both worlds.<br />
In: <strong>atp</strong> – Automatisierungstechnische Praxis 52(6), S. 16 –19, 2010<br />
[9] Grossmann, D, John, D., Laubenstein, A.: EDDL Harmonisierung.<br />
In: <strong>atp</strong> – Automatisierungstechnische Praxis 51(10/11), S. 6 – 14, 2009<br />
[10] IEC 62769: Field Device Integration. 2013<br />
S<strong>im</strong>atic PDM basiert auf der Geräteintegrationstechnologie<br />
EDD. Es unterstützt alle mit Hilfe von EDDL – inklusive<br />
der verschiedenen Dialekte (siehe Abschnitt 2.1) – beschriebenen<br />
Geräte. Es ist zudem die Richtlinie der etablierten<br />
Organisationen Profibus & Profinet International<br />
(PI), Hart Communication Foundation (HCF) und Fieldbus<br />
Foundation (FF). Mehrere tausend Geräte von über 200 Herstellern<br />
lassen sich damit beschreiben. Bisher noch nicht<br />
unterstützte Geräte können durch den Import ihrer Gerätebeschreibungen<br />
(EDD) in S<strong>im</strong>atic PDM integriert werden.<br />
Hinsichtlich der FDI-Realisierung mit S<strong>im</strong>atic PDM ist<br />
weiterhin EDDL mit dem gewohnten Komfort unter Bersückichtigung<br />
der Herausforderung Investitionsschutz zu<br />
unterstützen. Darüberhinaus ist unter dem Aspekt Innovation<br />
künftig auf FDI zu setzen – dazu sind die FDI Device<br />
Packages zu verarbeiten. Es wird angestrebt, dass mit<br />
EDDL vertraute Anwender möglichst ohne Umgewöhnung<br />
FDI nutzen können. So soll dahingehend beispielsweise<br />
die vertraute Usability wird nicht gestört werden – unter<br />
Berücksichtigung des geforderten min<strong>im</strong>ierten Aufwands<br />
für Schulungen ein nicht zu vernachlässigendes Argument<br />
(siehe Abschnitt 2).<br />
Ausgehend von der EDDL-Basis unterstützt S<strong>im</strong>atic<br />
PDM ebenfalls die harmonisierte EDDL – auch unabhängig<br />
von FDI. Somit ist S<strong>im</strong>atic PDM vorbereitet, FDI Device<br />
Packages in FDI zu unterstützen. Unter Berücksichtigung<br />
des aktuellen Status von FDI wurde in der Produktentwicklung<br />
ein um FDI erweiterter Stand von S<strong>im</strong>atic<br />
PDM entwickelt. Dieser ist um entsprechende<br />
Funktionen ergänzt worden und erlaubt es, verschiedene<br />
Feldgräte auf Basis von FDI einzubinden – unter anderem<br />
mit UIP (siehe Abschnitt 2.1)<br />
ZUSAMMENFASSUNG<br />
Die Geräteintegrationstechnologie FDI – grundsätzlich<br />
für Automatisierungssysteme und Feldbusse der Fertigungs-<br />
und Prozessindustrie – verfolgt zur Vereinheitlichung<br />
nicht den Ansatz, EDDL und FDT einfach aufzuaddieren.<br />
FDI strebt einen synergetischen Ansatz der<br />
Konzepte von EDDL und FDT an, wobei EDDL eine entscheidende<br />
Rolle zukommt. FDI erfüllt die Forderungen<br />
der Anwender, zum Beispiel eine einheitliche Usability.<br />
Darüber hinaus sichert es EDDL-basierte Investitionen in<br />
bestehenden Anlagen. Siemens zeige auf der Namur-<br />
Hauptversammlung anhand des verbreiteten Gerätemanagement-Werkzeugs<br />
S<strong>im</strong>atic PDM und unter Berücksichtigung<br />
des aktuellen Status von FDI einen um FDI erweiterten<br />
Stand aus der Produktentwicklung. Dieser um FDI<br />
erweiterte Stand aus der Produktentwicklung von S<strong>im</strong>atic<br />
PDM erlaubt die Einbindung verschiedener Feldgräte<br />
auf Basis von FDI. SIMATIC PDM wird wie gefordert in<br />
der Lage sein, neben den neuen FDI Device Packeges in<br />
FDI auch parallel dazu weiterhin „alte“ EDDs bzw. DTMs<br />
zu verarbeiten.<br />
MANUSKRIPTEINGANG<br />
10.06.2013<br />
Im Peer-Review-Verfahren begutachtet<br />
44<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
Wissenschaftlich<br />
fundierte Beiträge zur<br />
Anlagensicherheit<br />
Safety in der Praxis<br />
Die Automatisierungstechnik wird durch neue Forschungen und Entwicklungen<br />
best<strong>im</strong>mt. Damit Ingenieure fit für ihren Job sind und die aktuellen Trends in der<br />
Automatisierungstechnik schnell und praktisch zur Hand haben, hat die Zeitschrift<br />
„<strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische Praxis“ die Buchreihe „<strong>atp</strong> kompakt“<br />
etabliert. Daraus erscheint der mittlerweile sechste Band: „Safety in der Praxis“.<br />
Hrsg.: Leon Urbas<br />
1. Auflage 2014<br />
112 Seiten, farbig, Broschur<br />
ISBN: 978-3-8356-7115-7<br />
Preis: € 59,–<br />
www.di-verlag.de<br />
Das Buch erscheint <strong>im</strong> DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München<br />
Jetzt bestellen!<br />
WISSEN FÜR DIE<br />
ZUKUNFT<br />
Bestellung per Fax: +49 201 / 820 Deutscher 02-34 Industrieverlag oder GmbH abtrennen | Arnulfstr. und 124 <strong>im</strong> | Fensterumschlag 80636 München einsenden<br />
Ja, ich bestelle gegen Rechnung 3 Wochen zur Ansicht<br />
___Ex.<br />
Safety in der Praxis<br />
1. Auflage 2014 – ISBN: 978-3-8356-7115-7 für € 59,– (zzgl. Versand)<br />
Firma/Institution<br />
Vorname, Name des Empfängers<br />
Straße / Postfach, Nr.<br />
Land, PLZ, Ort<br />
Telefon<br />
Telefax<br />
Antwort<br />
Vulkan-Verlag GmbH<br />
Versandbuchhandlung<br />
Postfach 10 39 62<br />
45039 Essen<br />
E-Mail<br />
Branche / Wirtschaftszweig<br />
Bevorzugte Zahlungsweise Bankabbuchung Rechnung<br />
Bank, Ort<br />
Widerrufsrecht: Sie können Ihre Vertragserklärung innerhalb von zwei Wochen ohne Angabe von Gründen in Textform (z.B.<br />
Brief, Fax, E-Mail) oder durch Rücksendung der Sache widerrufen. Die Frist beginnt nach Erhalt dieser Belehrung in Textform.<br />
Zur Wahrung der Widerrufsfrist genügt die rechtzeitige Absendung des Widerrufs oder der Sache an die Vulkan-Verlag GmbH,<br />
Versandbuchhandlung, Postfach 10 39 62, 45039 Essen.<br />
Bankleitzahl<br />
Ort, Datum, Unterschrift<br />
Kontonummer<br />
PAATP62013<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, dass ich<br />
vom DIV Deutscher Industrieverlag oder vom Vulkan-Verlag per Post, per Telefon, per Telefax, per E-Mail, nicht über interessante, fachspezifische Medien und Informationsangebote informiert und beworben werde.<br />
Diese Erklärung kann ich mit Wirkung für die Zukunft jederzeit widerrufen.
HAUPTBEITRAG<br />
Geräteintegration<br />
in AT-Systeme<br />
Bestandsaufnahme und Ausblick<br />
Automatisierungsgeräte sind nicht länger nur Peripherie der Leitsysteme, sondern auch<br />
integrale Systembestandteile. Damit steigt die zu erbringende Integrationsleistung. Die<br />
Bedeutung lässt sich an den entsprechenden Anstrengungen der Systemanbieter ablesen.<br />
Gerätebeschreibungen, Proxy-Funktionsbausteine, Diagnosestrategien und Feldbusprofile<br />
sind Technologien, die gemeinschaftlich für eine vertiefte Integration stehen. Zusätzlich<br />
sind diese <strong>im</strong> gesamten Lebenszyklus der Anlage zu betrachten. Nur aufeinander abgest<strong>im</strong>mte<br />
Integrationsmodelle und -methoden, in Verbindung mit zueinander passenden<br />
Technologien, führen zu Ergebnissen, die die Anwender befriedigen. In diesem Beitrag<br />
werden die Vielschichtigkeit und Lösungsansätze zusammengetragen und bewertet. Besondere<br />
Herausforderungen werden genannt.<br />
SCHLAGWÖRTER Geräteintegration / Gerätemodell / AT-Systemarchitektur / Proxy-<br />
Funktionsbausteine<br />
Device Integration in Automation Systems –<br />
State of the Art and Future Prospects<br />
Automation devices are no longer peripheral components of control systems but are integral<br />
parts of the system. The integration demands are increasing. This becomes apparent<br />
for the activities of main system providers. Device descriptions, proxy function blocks,<br />
diagnosis strategies and fieldbus profiles are technologies which stand for deep integration.<br />
Additionally, they are relevant for the overall life cycle of the plant. Only consistent<br />
integration models and integration methods together with suitable technologies lead to<br />
satisfactory benefits for the end users. The multiple facets of existing approaches are reported<br />
and assessed. Recommendations are made for future developments.<br />
KEYWORDS device integration / device model / system architecture for automation / proxy<br />
function blocks<br />
46<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
CHRISTIAN DIEDRICH, THOMAS HADLICH, Otto-von-Guericke-Universität Magdeburg<br />
Geräteintegration wird oft mit dem Thema der<br />
Gerätebeschreibungstechniken EDD, FDT und<br />
FDI gleichgesetzt. Dies deckt vor allem die<br />
Inbetriebnahme und den Service für ein AT-<br />
Gerät ab. Im Allgemeinen muss ein AT-Gerät<br />
jedoch mit dem Automatisierungssystem und übergeordneten<br />
Ebenen der Unternehmens-IT-Struktur (MES/<br />
ERP) integriert werden. Damit dies in ausreichender<br />
Tiefe gelingt, muss eine Vielzahl von Teilaspekten so<br />
gelöst werden, dass die Komponenten, die das System<br />
bilden, kompatibel zueinander sind beziehungsweise<br />
miteinander interoperieren können. In diesem Beitrag<br />
werden ausschließlich Geräte mit digitaler Informationsverarbeitung<br />
betrachtet. Für diese Geräte muss bei<br />
allen kooperierenden Systemkomponenten ein gemeinsames<br />
Verständnis der verwendeten Daten und Kommunikationssysteme<br />
sowie der Anwendungsfunktionen<br />
vorliegen.<br />
Die technologische Basis für die verschiedenen Integrationen<br />
wird gebildet durch:<br />
Beschreibungssprachen<br />
Objekt- und Informationsmodelle<br />
Schnittstellenfunktionen<br />
Datensemantik<br />
Funktionsabstraktion<br />
Die Diskussion in diesem Beitrag stellt die Integrationsaufgaben<br />
der Geräte in Bezug zum Lebenszyklus<br />
der Anlagen detaillierter dar. Bild 1 zeigt einen Querschnitt<br />
an Aufgaben <strong>im</strong> Lebenszyklus, in dem Integrationsaufgaben<br />
zu lösen sind. Integrationsaufgaben<br />
basieren oft auf Normen, da nur dadurch ein gleiches<br />
Verständnis sowie kompatible und interoperable<br />
Schnittstellen für die Integration geschaffen werden<br />
können. Um die Vielfalt der zu behandelnden Aspekte<br />
darzustellen, werden die Normen beispielhaft und<br />
stellvertretend für Technologien betrachtet. Querschnittsthemen,<br />
wie Security und Safety sind intrinsisch<br />
zu betrachten, werden aber nur am Rande erwähnt.<br />
1. MODELL DES ZU INTEGRIERENDEN GERÄTES<br />
Integration bezeichnet den Zusammenschluss zu Einheiten<br />
beziehungsweise die Bildung übergeordneter<br />
Ganzheiten [1]. Charakteristisch für die Integration ist,<br />
dass die Teilsysteme erhalten bleiben und dass diese<br />
Teilsysteme in Wechselwirkung stehen. Zusammen entsteht<br />
etwas Neues. Es gibt sehr viele Integrationsaspekte,<br />
beispielsweise:<br />
Daten-, Funktions-, Struktur-, Prozessintegration<br />
Vertikale und horizontale Integration<br />
Lebenszyklusintegration<br />
In diesem Beitrag wird die Integration von Automatisierungsgeräten<br />
(AT-Geräten) betrachtet, insbesondere von<br />
Feldgeräten. Dabei liegt folgendes Gerätemodell zugrunde<br />
(Bild 2). Ein Gerät (Device, informationstechnisch<br />
auch als Node bezeichnet) ist ein räumlich materiell abgegrenzter<br />
Gegenstand, der signalumsetzende Aufgaben<br />
erfüllt (in der Abgrenzung zu energie- und stoffumsetzenden<br />
Aufgaben). In IEC 62390 wird ein Gerät wie folgt<br />
definiert: „independent physical entity of an industrial<br />
system capable of performing specified functions in a<br />
particular context and del<strong>im</strong>ited by its interfaces“ [2].<br />
Heute werden diese Geräteaufgaben <strong>im</strong>mer mehr mit<br />
Unterstützung von Software realisiert. Dazu dient eine<br />
in das Gerät eingebundene und an den technischen Kontext<br />
angepasste Recheneinheit (eingebettetes System).<br />
Zunehmend werden die Geräte in digitalen Netzverbünden<br />
eingesetzt (Intelligente Geräte, Smart Devices). Sind<br />
die Netzverbünde mit dem Internet verbunden, können<br />
Geräte als Komponenten von cyber-physischen Systemen<br />
(CPS) betrachtet werden. Automatisierungsgeräte stellen<br />
spezifische Funktionen bereit, zum Beispiel zum Messen,<br />
Stellen, Steuern, Regeln, Alarmieren. Feldgeräte<br />
sind Geräte, die in der direkten Prozessumgebung eingesetzt<br />
werden. Sie werden in der Prozess- und der Fertigungsindustrie<br />
eingesetzt.<br />
AT-Geräte können hardwaretechnisch und logisch modular<br />
sein (siehe Bild 2b). Module können funktionale<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
47
HAUPTBEITRAG<br />
Elemente (FE) enthalten, die je nach Technologie und Einsatzgebiet<br />
als Objekte, Funktionsbausteine oder Parameterlisten<br />
ausgeprägt sind (Bild 2c). Die funktionalen Elemente<br />
stellen die spezifischen Funktionen der AT-Geräte<br />
bereit. Funktionale Elemente enthalten Parameter, die über<br />
die Schnittstellen der Feldgeräte ausgetauscht werden. Die<br />
Gerätestrukturelemente (Module, funktionale Elemente<br />
und Parameter) können hierarchisch aufgebaut sein.<br />
Feldgeräte, als eine Untermenge der AT-Geräte, stellen<br />
laut IEC 62390 aus funktionaler Sicht die folgenden<br />
Schnittstellen zur Verfügung [2], (siehe Bild 2c):<br />
Schnittstelle zur Informationsankopplung an das<br />
Feld (Maschine, Anlage) (process interface)<br />
Schnittstelle zu einem AT-Gerät, mit dem die<br />
prozessbezogenen Daten ausgetauscht werden<br />
sollen, zum Beispiel zwischen Messumformer und<br />
Steuerung (control interface)<br />
Schnittstelle, über die Parametrisierung und<br />
Konfiguration durchgeführt werden (parameterisation<br />
and configuration interface)<br />
Schnittstelle, die für Diagnosezwecke verwendet<br />
wird (diagnosis interface)<br />
Zwischen den informationsbezogenen Schnittstellen des<br />
AT-Gerätes und den durch die Hardware untersetzten<br />
Schnittstellen gibt es unterschiedliche Kombinationen.<br />
So können zum Beispiel über eine hardwaretechnische<br />
Schnittstelle zur industriellen Kommunikation (typische<br />
Kommunikationsschnittstellen sind beispielsweise<br />
in IEC 61158/IEC 61784 standardisiert) die prozessbezogenen<br />
Daten ausgetauscht (control interface) und die<br />
Parametrisierung und Konfiguration (parameterisation<br />
and configuration interface) sowie Diagnose (diagnosis<br />
interface) durchgeführt werden. Parametrierung, Konfiguration<br />
und Diagnose benötigen zusätzliche Software-<br />
Werkzeuge und -beschreibungskomponenten, zum Beispiel<br />
EDDL (IEC 61804-3 bis -5), FDT (IEC 62453) und FDI<br />
(IEC 62769). Sensoren und Aktoren sind in der Regel als<br />
separate Hardware an das AT-Gerät gekoppelt.<br />
ISO 15745 [3] beschreibt umfassend die beteiligten Elemente<br />
zur Integration in ein Enterprise-System (AT-Systemtechnik<br />
aber auch Anlagentechnik, Material, Personal).<br />
Ein Teilaspekt ist die Geräteintegration. Die definierten<br />
Strukturelemente Device Manager, Device Identity,<br />
Device Function und Application Process werden<br />
in der IEC 62390 als Functional Element abstrahiert (Bild<br />
2b), was in dem betrachteten Gerätemodell übernommen<br />
wird. Konkrete Details für die Geräteintegration beziehen<br />
sich in ISO 15745 auf die Kommunikationsintegration,<br />
für die die notwendigen Technologien, wie GSD<br />
und FDCML, standardisiert werden (siehe Abschnitt 2.2).<br />
Eine Übersicht über die verschiedenen Aspekte von Geräten<br />
zeigt Bild 3.<br />
Diese Aspekte müssen bei der Integration von Geräten<br />
betrachtet werden. Dabei liegt der Fokus in unterschiedlichen<br />
Phasen des Lebenszyklus auf unterschiedlichen<br />
Aspekten des Geräts.<br />
2. INTEGRATIONSLANDSCHAFT<br />
Die Integrationslandschaft für ein Feldgerät setzt sich<br />
zusammen aus dem Automatisierungssystem (AT-System)<br />
und den überlagerten Systemen, zum Beispiel Manufacturing<br />
Execution System (MES), Produktionsplanungssystem<br />
(PPS) oder Enterprise Resource Planning<br />
(ERP) (siehe Bild 4). Je nach Integrationsaufgabe und<br />
-partner gibt es verschiedene Integrationsprinzipien und<br />
-technologien.<br />
BILD 1: Themenvielfalt der Geräteintegration<br />
BILD 2: Gerät – Modellstruktur<br />
48<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
Zusätzlich zu der Integration von Geräten und Komponenten<br />
zu einem AT-System ist deren Lebenszyklus zu<br />
betrachten. Entsprechend der ZVEI-Guideline Lifecycle<br />
Management, besteht ein Unterschied zwischen dem Lebenszyklus<br />
eines AT-Systems und den Lebenszyklen seiner<br />
Komponenten [13]. Jede Komponente (und damit jedes<br />
Gerät) durchläuft seinen eigenen Lebenszyklus innerhalb<br />
des Rahmens, der vom System-Lebenszyklus vorgegeben<br />
wird. Dabei hat die Komponente kompatibel zu sein. Kompatibilität<br />
wird nach [1] als Fähigkeit verstanden, die Austauschbarkeit,<br />
Konsistenz oder Äquivalenz von Eigenschaften<br />
zu gewährleisten. Diese Eigenschaften lassen<br />
sich nach IEC 81346-2 in die Aspekte Funktion, Gerät und<br />
Örtlichkeit klassifizieren (siehe Bild 5).<br />
In [13] wird basierend auf diesen Aspekten ein Kompatibilitätsmodell<br />
aufgebaut, das Graduierungen in Bezug<br />
auf Erfüllungsstufen, aber auch bezogen auf die<br />
Funktionen, Signale, Konstruktion und weiteres mehr<br />
einführt (siehe zum Beispiel [13], Tabelle 1). Hier wird<br />
die Detailtiefe für die Integrationsaufgaben sowie die<br />
Verflechtung von Teilaufgaben sichtbar.<br />
2.1 Planungsintegration und Beschaffungsintegration<br />
Bei Planungs- und Beschaffungsprozessen müssen die<br />
Funktionen und Eigenschaften der Geräte prägnant repräsentiert<br />
werden. Planer und Gerätehersteller stehen dabei<br />
in enger Wechselwirkung, weil die funktionalen und nichtfunktionalen<br />
Eigenschaften detailliert abzust<strong>im</strong>men sind.<br />
Die Repräsentation der Geräteeigenschaften erfolgt vorzugsweise<br />
durch signifikante Merkmale. In den Werkzeugen<br />
müssen deshalb diese Merkmale verfügbar sein, sowohl<br />
zur Beschreibung der Anforderungen für die Rollen, in der<br />
die Geräte verwendet werden sollen, als auch zur Zusicherung<br />
durch die Geräte. Planer und Hersteller müssen deshalb<br />
die gleiche Merkmalterminologie verwenden [5].<br />
Prolist und eCl@ss sind prominente Vertreter für standardisierte<br />
Merkmalterminologien, deren Nutzung bei<br />
der Planung oder der Instandhaltung (zusätzlich zum<br />
Beschaffungsprozess) sich erst am Anfang befindet.<br />
2.2 Integration der Geräte in Kommunikationssysteme<br />
Bevor auf Gerätefunktionen und Gerätedaten zugegriffen<br />
werden kann, muss eine Integration des Gerätes in das<br />
Kommunikationssystem erfolgen. Eine zum geplanten<br />
System passende Kommunikationsschnittstelle des Gerätes<br />
muss entsprechend konfiguriert werden.<br />
Die Kommunikationsfähigkeiten eines zu integrierenden<br />
Gerätes (zum Beispiel unterstützte Protokolle, Baudraten)<br />
müssen erfasst werden. Das jeweilige Gerät muss<br />
passend zur Umgebung (bestehend aus anderen Geräten,<br />
Kommunikationsinfrastruktur und Steuerungshardware)<br />
konfiguriert werden, und die Kommunikationsverbindungen<br />
müssen etabliert werden. Technologien, die die Kommunikationsintegration<br />
von Geräten unterstützen, sind<br />
Beschreibungssprachen wie GSD, FDCML und EDS, aber<br />
auch OO-orientierte Technologien wie FDT.<br />
2.3 Abbildung auf die Kommunikation<br />
Gerätefunktionen, seien es die Produktivfunktionen, wie<br />
Messen, Stellen, Zählen und Signalkonfektionierung<br />
oder die Hilfsfunktionen für den Betrieb der Geräte, werden<br />
durch ihre Variablen und Parameter <strong>im</strong> Kommunikationssystem<br />
abgebildet. Außerdem stellen diese Gerätefunktionen<br />
Diagnosedaten zur Verfügung. Ziel dieser<br />
BILD 3: Aspekte von Geräten<br />
BILD 4: Integrationslandschaft<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
49
HAUPTBEITRAG<br />
Integration eines Feldgerätes ist es, ihre Daten mit der<br />
Steuerungsanwendung oder anderen Hosts auszutauschen.<br />
Dafür müssen die Prozess- und Diagnosedaten<br />
und Parameter in einer zur Dynamik der Anwendung<br />
äquivalenten Weise durch das Kommunikationssystem<br />
transportiert werden. Partner der Integration sind die<br />
Geräteanwendungsfunktionen und die Dienstpr<strong>im</strong>itiven<br />
der jeweiligen Kommunikationssysteme.<br />
Industrielle Kommunikationssysteme bieten in der<br />
Regel zyklische Verbindungen für die prozessrelevanten<br />
Daten (ehemals Einheitssignale), azyklische Verbindungen<br />
für die Parameter und Alarm-Diagnose-Verbindungen<br />
für das Ereignishandling.<br />
Bei der Abbildung der Anwendungsfunktionen auf die<br />
Dienste (siehe Bild 6) unterscheiden sich die Kommunikationssysteme.<br />
Zum Beispiel erfolgt bei Profibus und<br />
Profinet diese Abbildung durch Module, welche die Daten<br />
mit Index adressieren. Modellmäßig verbergen sich<br />
dahinter Objektverzeichnisse, wie sie nur bei einigen<br />
Kommunikationssystemen verwendet werden. Entsprechend<br />
dem erweiterten ISO/OSI-Referenzmodell [6]<br />
kommt das ASE/APO-Modell zum Einsatz, wie es zum<br />
Beispiel in [7] beschrieben ist.<br />
2.4 E/A-Datenintegration in die Steuerung<br />
Heutige Steuerungen arbeiten nach dem Softwaremodell<br />
von IEC 61131-3. Die Prozessdaten aus den Geräten müssen<br />
in das Prozessabbild der Steuerungen gelangen. Dazu<br />
muss die Eingangs-Ausgangsdatenstruktur (E/A-Struktur)<br />
der Geräte in die Prozessabbildstruktur der Steuerung<br />
eingeordnet werden.<br />
Feldbusgekoppelte Geräte ersetzen die E/A-Steckmodule<br />
(mit Einheitssignalen) an den Steuerungen. Die Punktzu-Punkt-Verdrahtung<br />
jedes einzelnen Signals zu den<br />
Sensoren und Aktoren wird durch das industrielle Kommunikationssystem<br />
ersetzt. Die Zuordnung der E/A-Daten<br />
in das Prozessabbild der Steuerungen erfolgte bei der<br />
Punkt-zu-Punkt-Verdrahtung durch Projektierung. Die<br />
Vereinbarung des Prozessabbildes hat darauf zu referenzieren.<br />
Heute transportiert nur ein Kommunikationsmedium<br />
eine Vielzahl von Daten, deren Zuordnung ins<br />
Prozessabbild bei heutigen Systemen ebenfalls durch<br />
Vorabkonfiguration durchgeführt wird. Dafür sind entsprechende<br />
Beschreibungsdateien vorhanden, zum Beispiel<br />
GSD, EDS und FDCML. Die Kommunikationskenngrößen<br />
und -parameter sind deskriptiv in diesen Dateien<br />
enthalten. Diese Beschreibungen werden durch Kommunikationskonfiguratoren<br />
verarbeitet.<br />
2.5 Funktionsintegration<br />
Feldgeräte übernehmen Funktionen, die bei signalorientierten<br />
Punkt-zu-Punkt-Verbindungen in den Steuerungen<br />
ausgeführt wurden. Dazu sind auf Steuerungsseite<br />
best<strong>im</strong>mte Abläufe einzuhalten und oft zusätzliche<br />
Parameter auszutauschen, die die best<strong>im</strong>mungsgemäße<br />
Nutzung der Gerätefunktionen sicherstellen. Die Funktionen<br />
der Steuerung und die der Geräteanwendung<br />
müssen deshalb zusammenarbeiten, was eine Kooperation<br />
zusätzlich zum Prozessdatenaustausch erfordert.<br />
Für diese Integration haben sich Proxy-Funktionsbausteine<br />
(FB) durchgesetzt (siehe Bild 7). Dies ist beispielsweise<br />
bei der verfahrenstechnischen AT für die gesamte<br />
Mess- und Stelltechnik der Fall (zum Beispiel Profibus<br />
PA-Profile) und in der Fertigungstechnik Standard in Taktstraßen<br />
und Roboterzellen für die Antriebe, Schrauber,<br />
Drehtische, Barcodeleser. Diese Gerätestellvertreter erlauben<br />
einen Programmentwurf mit den Mitteln der Steuerungsprogrammentwicklung<br />
und weisen in dem jeweiligen<br />
Kontext eine standardisierte Schnittstelle (FB-E/A)<br />
auf. Gerätehersteller kapseln darin den zum Teil umfangreichen<br />
und komplexen Umgang mit den Gerätefunktionen.<br />
Die Kooperation zwischen den Proxy-FB in den Steuerungen<br />
und den Geräten wird in den Proxy-Algorithmen<br />
organisiert. Prominente Beispiele sind die PLCopen-Antriebsbausteine<br />
und die Indent- und Waagenprofile der<br />
PNO. Der Integrationsaufwand sinkt um ein Vielfaches,<br />
wobei zusätzlich die Qualität der Integration steigt.<br />
2.6 Integration in Diagnose- und<br />
Parametrierungs anwendungen<br />
Analoge AT-Geräte mit einfachen Funktionen konnten<br />
noch mit Schraubendreher parametriert und mit einfachen<br />
Messgeräten diagnostiziert werden. Seit die digitalen<br />
Feldgeräte über Kommunikationssysteme kommunizieren<br />
und komplexe Funktionen bereitstellen, reicht<br />
dies nicht mehr aus. Heutige Geräte werden über eine<br />
Vielzahl von Parametern konfiguriert und bieten eine<br />
Reihe von Diagnosefunktionen. Um auf diese Parameter<br />
und Diagnosefunktionen zuzugreifen, wird spezielles,<br />
gerätespezifisches Know-how benötigt.<br />
Die Integrationstechnologien EDD [10], FDT [11] und<br />
FDI [12] bieten dieses Wissen in elektronischer Form, sodass<br />
es in Host-Systeme integriert werden kann. Bei allen<br />
diesen Technologien wird für das jeweilige Gerät eine<br />
Software-Komponente (Package) bereitgestellt, die in das<br />
Host-System integriert werden muss. Diese Packages stellen<br />
die Businesslogik für den konsistenten Informationszugriff<br />
über die verfügbaren Prozessdaten, Parameter und<br />
Funktionen des Gerätes bereit und unterstützen den Nutzer<br />
mittels einer speziell für das Gerät geeigneten GUI.<br />
2.7 HMI-Integration<br />
Be<strong>im</strong> Betreiben einer Anlage besteht die Notwendigkeit,<br />
die Anlage insgesamt und die Bestandteile der Anlage<br />
einzeln beobachten und bedienen (B&B) zu können. Für<br />
ein einzelnes Gerät muss eine HMI vorhanden sein, die<br />
in das HMI der Anlage integriert werden muss.<br />
Die Zuordnung von Faceplates zu den Geräten ist ein<br />
Standard. Attributierte Symbole werden für Gerätetypen<br />
vorgehalten, die dann bei der B&B-Konfiguration aus<br />
Bibliotheken eingebaut werden. Voraussetzung ist, dass<br />
die Interfaces der Geräte (siehe Abschnitt 2.2) eindeutig<br />
und bekannt sind. Hier kommen die Feldbusprofile zum<br />
Einsatz, wobei einige Systeme für die Steuerungen HMI-<br />
Proxies anbieten.<br />
Für die bisher genannten Integrationsaufgaben (2.2 bis<br />
2.7) schaffen die Feldbusprofile die notwendigen Daten-,<br />
Parameter- und Diagnosestandardisierungen, wie sie als<br />
50<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
BILD 5: Kompatibilitätsaspekte <strong>im</strong> Lebenszyklus [13]<br />
BILD 6: Kommunikationsintegration der Gerätefunktionen<br />
Proxy-FB<br />
Rumpfalgorithmus<br />
Visualisierung, Scada, Leitsystem<br />
Faceplate<br />
Engineering<br />
System<br />
BILD 8:<br />
OPC UA-Architektur<br />
nach [8] S.324<br />
FB Anwendung<br />
FB Anwendung<br />
Steuerung<br />
zyklisch<br />
Komm.<br />
FBs<br />
azyklisch<br />
Alarm<br />
Feldgerät<br />
Feldgerät<br />
FB<br />
Feldgerät<br />
zyklisch<br />
FB<br />
Alg.<br />
azyklisch<br />
Alarm<br />
FB<br />
Alg.<br />
Feldgerät<br />
Maschine/Anlage<br />
Kommunikations-FB<br />
Kommunikation zwischen Proxy und Hauptjunktion<br />
Kommunikation zwischen übergeordneter Anwendung und Proxy<br />
BILD 7: Proxy-Integration in Steuerungen und Leitsystemen<br />
Ablösung für die Einheitssignale notwendig sind. Sie<br />
bieten jedoch auch eine neue Qualität, weil nicht nur die<br />
Syntax, sondern auch die Bedeutungsinhalte (Semantik)<br />
der Signale sowie wichtige Kooperationsvorschriften<br />
(zum Beispiel Gerätemodi) standardisiert werden. Die<br />
gestiegene Integrationskomplexität wird so beherrschbarer.<br />
Bedauerlich ist nur, dass die verschiedenen Kommunikationsfamilien<br />
jeweils unterschiedliche Lösungen<br />
gewählt haben. Technologiehersteller von Kommunikationslösungen<br />
stellen deshalb neutrale Schnittstellen<br />
zwischen Geräteanwendung und Kommunikationssystem<br />
zur Verfügung. Proxies und Beschreibungstechnologien<br />
ermöglichen profilbezogene Softwarekomponenten,<br />
wie Proxy-FBs und Profil-GSD, -DTM, -EDD, die <strong>im</strong><br />
Gegensatz zu Aussagen von Hodek et.al. [8] eine hohe<br />
Integrationsleistung erbringen. Diese Komponenten bilden<br />
die Geräte as-built mit den Daten und der Business-<br />
Logik ab und offerieren so den verschiedenen Host-Anwendungen<br />
die Gerätefunktionalität. Diese <strong>im</strong> System<br />
neu nachzubilden, widerspricht dem Kapselungs-, Wiederverwendungs-<br />
und Modularitätsprinzip. Wird aus<br />
technologischen oder architektonischen Gründen eine<br />
IT-bezogene, das heißt eine mit loser Kopplung arbeitende<br />
Kommunikation verwendet, so kann diese durch<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
51
HAUPTBEITRAG<br />
Web-Services unter Verwendung des ASE/APO-Modells<br />
bereitgestellt werden, wie in [14] beschrieben.<br />
2.8 Wartungsintegration und MES/ERP-Integration<br />
Entsprechend Vogel-Heuser et.al. ergibt sich eine Öffnung<br />
des AT-Systems für den Zugriff durch das MES beziehungsweise<br />
ERP. [4] Dabei werden bisher vor allem Daten<br />
direkt aus den Feldgeräten übernommen. Die für ein MES<br />
interessante Information findet sich hauptsächlich in Prozessdaten,<br />
die die Qualität des Verarbeitungsprozesses<br />
beschreiben (zum Beispiel Temperatur be<strong>im</strong> Sintern), beziehungsweise<br />
in statistischen Daten (wie Menge des verarbeiteten<br />
Werkstoffs). Besonders für die Bereitstellung<br />
der statistischen Daten müssen die Geräte spezielle Funktionen<br />
vorhalten (zum Beispiel zur Aggregation des aktuellen<br />
Durchflusswertes) beziehungsweise die Konfiguration<br />
weiterer Funktionen ermöglichen (zum Beispiel<br />
durch Programmierung). Im Sinne der Öffnung kommen<br />
auch Daten hinzu, die sich nicht in der Dynamik des Prozesses<br />
verändern. Neben der Typenschildinformation<br />
kann dies der aktuelle Parametersatz zur Online-Dokumentation<br />
sein. Hier bieten die Profildefinitionen und die<br />
Proxy-Technologie [21] Ansatzpunkte.<br />
Die Integration in diese MES verlässt das klassische<br />
AT-System. Nicht der operative Betrieb steht <strong>im</strong> Mittelpunkt,<br />
sondern dispositive Aufgaben, die das Gerät über<br />
azyklische Anforderungen abdeckt. Zwei Herangehensweisen<br />
sind typisch. Die Parametrierwerkzeuge FDT und<br />
FDI öffnen sich für Host-Systeme und OPC UA bietet mit<br />
seinem Objektmodell und Zusatzkonzepten (zum Beispiel<br />
device model security) eine Integrationsplattform<br />
(siehe Bild 8). Umfangreiche Arbeiten wurden <strong>im</strong> Rahmen<br />
des EU-Projektes Socrades vorgenommen [15].<br />
2.9 Safety-Integration<br />
AT-Systeme müssen die Sicherheit für den Menschen<br />
und die Umwelt sicherstellen. Je nach Natur des automatisierten<br />
Produktionsprozesses gibt es unterschiedliche<br />
Anforderungen an die Sicherheit, die in Safety Integrity<br />
Level (SIL) ausgedrückt wird. Betreiber der Anlage legen<br />
das notwendige SIL-Niveau fest. Ein Gerät, das in eine<br />
Anlage mit SIL ≥ 1 integriert werden soll, muss als Safety-Gerät<br />
entwickelt worden sein. Die Kommunikationsintegration<br />
muss zusätzlich funktional sicher sein und<br />
erfolgt in der Regel durch eine weitere Kommunikationsschicht<br />
oberhalb der Schicht 7. Die Kommunikation<br />
selbst wird dann als Black-Channel betrachtet. Die verschiedenen<br />
Kommunikationssysteme stellen dafür entsprechende<br />
Lösungen bereit, die in der IEC 61158 standardisiert<br />
sind.<br />
2.10 Security-Integration<br />
Geräte in AT-Anlagen müssen schon <strong>im</strong>mer gegen den<br />
unautorisierten Zugriff von Menschen geschützt werden,<br />
zum Beispiel die Konfiguration oder Parametrierung<br />
durch unautorisierten lokalen Zugriff oder in einer vernetzten<br />
Umgebung der unautorisierte Remote-Zugriff.<br />
Security wird noch mehrheitlich als organisatorische<br />
Maßnahme in der industriellen Produktion wahrgenommen.<br />
Verhinderung der Parameterveränderung durch<br />
Passwortschutz und Jumper sind jedoch Stand der Technik.<br />
Weitere technische Maßnahmen, wie Firewalls,<br />
VPN und Verschlüsselung, werden noch nicht bei AT-<br />
Geräten eingesetzt. Hier beginnen erste Initiativen [16].<br />
3. INTEGRATIONSLÖSUNGEN UND HERAUSFORDERUNGEN<br />
Bei der Bewertung existierender Integrationslösungen<br />
für den operativen Betrieb ergibt sich folgende Situation:<br />
Prozess- und Diagnosedaten sowie Parameter der<br />
Geräte sind durch das ASE/APO-Modell <strong>im</strong> Kommunikationssystem<br />
verfügbar.<br />
Die Abbildung der E/A-Daten der Geräte auf das Prozessabbild<br />
der Steuerungen wird durch Beschreibungsdateien<br />
(zum Beispiel GSD) organisiert.<br />
Die funktionale Repräsentation der Geräte <strong>im</strong> Steuerungsprogramm<br />
und <strong>im</strong> Faceplate der B&B-Anwendung<br />
erfolgt durch Proxy-FB.<br />
Diese vertikale Integration beruht auf enger Signalkopplung.<br />
Ein Gerätetausch berührt alle diese Integrationstechnologiebestandteile.<br />
Geräte, die in all diesen Bestandteilen<br />
schnittstellenkompatibel sind, lassen sich<br />
per se austauschen. Ist dies nicht der Fall, muss das System<br />
umgebaut werden (siehe [13]). Vor allem müssen<br />
dann die Proxy-FBs ausgetauscht werden. In manchen<br />
Steuerungsprogrammsystemen kann dies während des<br />
operativen Betriebs geschehen. Dies entspricht der Anforderung<br />
an Flexibilität.<br />
Methodische Grundlage für diesen Teil der Geräteintegration<br />
ist die Trennung der planerischen Entwicklung<br />
des gesamten Steuerungs- und Leitsystems mit dem Steuerungsprogramm<br />
<strong>im</strong> Zentrum der Anwendung von dem<br />
operativen Betrieb, bei dem nur ein Austausch existierender<br />
Komponenten ohne strukturellen Umbau vorgesehen<br />
ist. Die funktionale Dezentralisierung löst diese<br />
zentrale Steuerungssicht nicht auf. Veränderungen der<br />
Steuerungsanwendung <strong>im</strong> Rahmen der vorgedachten Flexibilität<br />
der Steuerungsstruktur sind zum Beispiel durch<br />
Veränderungen <strong>im</strong> Funktionsbausteinnetzwerk möglich.<br />
Eine Systemkonfiguration Bottom-up, das heißt durch<br />
operatives Zusammensetzen der Geräte zu AT-Systemen,<br />
ist mit den erwähnten Technologien nicht vorgesehen.<br />
Aus der Bewertung existierender Integrationslösungen<br />
für die Diagnose <strong>im</strong> operativen Betrieb, ergibt sich:<br />
Diagnose ist für diesen vertikalen Pfad eng in das<br />
Abtastinterval des Steuerungsprogramms integriert,<br />
<strong>im</strong> Steuerungsprogramm wird ereignisbezogen reagiert<br />
und die Information wird zum Anlagenfahrer<br />
weitergeleitet.<br />
Diagnose für den Service- und Wartungsfall ist<br />
durch die Gerätebeschreibungstechnologien (EDD,<br />
FDT, FDI) mit hoher Qualität gegeben. Störend sind<br />
noch die Technologievielfalt und gewisse Besonderheiten<br />
in unterschiedlichen Kommunikationssystemen<br />
sowie das Handling der Variantenvielfalt. Wegen<br />
der steuerungszentrierten Sicht sind Gerätezu-<br />
52<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
Bilanzraum der Integration Integrationstechnologien Angebote zur Initiative Industrie 4.0<br />
Planung von Geräten mittels Merkmalsystemen<br />
vor oder getrennt vom<br />
operativen Betrieb<br />
Parametrierung, Diagnose und Test in<br />
Wartung und Service für Einzelgeräte<br />
als enge Punkt-zu-Punkt-Kopplung<br />
Episodische Parametrierung und<br />
Diagnose <strong>im</strong> operativen Betrieb<br />
Prozessdaten, Parameter und Diagnose-<br />
Datenaustausch als lose Kopplung für<br />
sporadische geräteübergreifende<br />
Host-Anwendungen (wie Wartung,<br />
Inventory Control)<br />
Zyklisch getaktete zeitdiskrete<br />
Steuerungs- und Regelungsfunktionen<br />
Merkmalleistenstandardisierung<br />
Geräterepräsentanten durch EDD,<br />
FDT/DTM, FDI/Device Package mit<br />
Businesslogik der Geräte<br />
Proxy-Funktionen in der Steuerung<br />
Feldbusprofilbildung<br />
OPC/OPC UA-Schnittstelle und FDT/<br />
Frame und FDI-Host-Anwendungen<br />
Zyklische Kommunikation<br />
der Prozessdaten zwischen den<br />
beteiligten Geräten<br />
Feldbusprofilbildung<br />
Merkmale sind Ansätze für Ontologien zur Nutzung von<br />
semantischen Technologien.<br />
Gerätestellvertreter (Repräsentant mit Businesslogik zur<br />
Konsistenzgewährleistung) als Softwarekomponente für<br />
die Kopplung ins IT-System<br />
Ausstattung der Proxies mit Dienstschnittstellen (zum<br />
Beispiel Web-Services) ermöglicht die lose Kopplung zu<br />
AT-Geräte-Daten<br />
Standardisierte Web-Service-orientierte Schnittstellen mit<br />
integriertem Informationsmodell. Hier könnten Gerätestellvertreter<br />
(für Einzelgeräteintegration <strong>im</strong> Sinne von<br />
Gateways) oder Informationsaggregation (<strong>im</strong> Sinne von KPI<br />
oder Mediatoren) integriert werden.<br />
Nicht <strong>im</strong> Fokus<br />
TABELLE 1: Beziehungen von Geräte-Integrationstechnologien zu Industrie 4.0<br />
griffe entweder nur vor Ort oder durch spezielle<br />
Maßnahmen zwischen System- und Gerätehersteller<br />
durchführbar. Die Schnittstellen zwischen diesen<br />
Gerätebeschreibungskomponenten und übergeordneten<br />
Host-Systemen (Anwendungen der MES-Ebene,<br />
zum Beispiel nach IEC 62264 Wartung, Lagerverwaltung,<br />
Qualitätsmanagement) werden bisher<br />
kaum gelebt. Die Integration verbleibt oft systemherstellerspezifisch.<br />
Ein Firmware-Update für AT-Geräte<br />
<strong>im</strong> Feld ist heute noch ein Albtraum.<br />
Methodisch ist damit nur eine reaktive Diagnose<br />
möglich, obwohl in den Geräten in vielen Fällen<br />
Grundlagen, zum Beispiel für Condition Monitoring,<br />
bereits vorhanden sind [17]. Hier fehlt noch die Integration<br />
in übergeordnete Systeme.<br />
Bei Bewertung existierender Integrationslösungen für<br />
die dispositive MES/ERP-Integration, ergibt sich:<br />
OPC UA ist eine sehr leistungsfähige und am Markt<br />
eingeführte Technologie, die der Natur der dispositiven<br />
Aufgaben entsprechend die lose Kopplung zwischen<br />
den Geräten und Host-Anwendungen anbieten<br />
kann. Die benötigten Informationsmodelle sind prinzipiell<br />
vorhanden, haben aber noch nicht die Verbreitung<br />
gefunden, um so den erhofften Mehrwert zu<br />
erzielen. Ein prominentes Beispiel sind die I&M-<br />
Funktionen, die jedes Profibus- und Profinet-Gerät<br />
unterstützt [18]. Dies sind standardisiert auslesbare<br />
Auskunftsfunktionen mit Typenschildinhalten einschließlich<br />
einer möglichen Verlinkung zur Webseite<br />
der Hersteller. Nennenswerte Anwendungsfälle hat<br />
es leider noch nicht gegeben. Ebenso ist die Standardisierung<br />
von KPIs schwach entwickelt, was die<br />
Systemhersteller-spezifischen Lösungen bevorzugt.<br />
Die Kombination von OPC UA mit Gerätebeschreibungen<br />
weist die größten Möglichkeiten auf, da die<br />
Businesslogik <strong>im</strong> OPC UA-Server den konsistenten<br />
Zugriff auf die Geräte erlaubt.<br />
Methodisch sind damit die in der Industrie 4.0-Initiative<br />
angedachten flexiblen Szenarien durchführbar.<br />
Es gibt eine Vielzahl von Herausforderungen, von denen<br />
der Beitrag zwei wesentliche behandelt. Zunächst das<br />
scheinbare Detail der Software-Komponentenidentifikation,<br />
auf deren Basis das Zusammenspiel der einzelnen<br />
Integrationskomponenten beruht:<br />
Jede einzelne Integrationsaufgabe stellt eine oder mehrere<br />
technologische Möglichkeiten der Identifikation zur<br />
Verfügung. Diese sind separat aus ihrem jeweiligen Gewerk<br />
gewachsen. Dadurch sind Querbezüge zwischen<br />
ihnen zurzeit nur manuell herstellbar. Am Beispiel verfahrenstechnischer<br />
AT-Geräte und Komponenten ist folgende<br />
Identifikationskette zu meistern (auszugsweise):<br />
R&I-Fließbild – PLT-Stellennummer und einige<br />
Kenngrößen (Prozessvariable (T, P, …), Verarbeitungsfunktionen<br />
(wie I, R, C, A)<br />
PLT-Stellenblatt – PLT-Stellennummer und Merkmale<br />
PLT-Stellenplan – PLT-Stellennummer und Signalpfad<br />
Funktionsblockdiagramm – Proxy-FB Bezeichner<br />
und Version<br />
Kommunikationskonfiguration – Dateibezeichnung<br />
(zum Beispiel GSD Ident-number <strong>im</strong> Dateinamen<br />
und Typenschildinformationen in der<br />
Datei sowie Kennungsbyte, das heißt digital<br />
kodierte Repräsentation des zyklischen Signals)<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
53
HAUPTBEITRAG<br />
Dispositive Aufgaben für<br />
AT-System<br />
Operativer<br />
Betrieb<br />
Visualisierung – Faceplate-Bezeichner und Version<br />
Parametrierung und Diagnose – zum Beispiel<br />
Dateinamen und interne Typenschildinformationen<br />
bei EDD, DTM und FDI-Device-Package<br />
Host-Integration von Feldgeräten über OPC/ OPC UA<br />
– auslesbares Typenschild, Mapping in OPC/OPC UA-<br />
Objektraum frei wählbar von OPC-Softwareanbieter<br />
Host-Integration von SPS nach IEC 61131-3 – Abbildungsvorschrift<br />
bereitgestellt durch PLCopen<br />
Diese grobe Zusammenstellung zeigt, dass eine durchgängige<br />
Geräteidentifikation in den verschiedenen Sichten<br />
nicht erreicht ist. Gleiches gilt für die Prozess- und<br />
Diagnosedaten- und Parameteridentifikation in den einzelnen<br />
Sichten.<br />
Die aus Sicht der Autoren wichtigste Aufgabe ist die<br />
eindeutige Beschreibung der Semantik der Gerätedaten<br />
und Information für den planerischen Prozess und für<br />
den operativen Betrieb. Sie müssen aber einerseits für<br />
den Einsatz <strong>im</strong> Sinne von Ontologien für die einzelnen<br />
Geräteklassen und Gewerke ausgebaut werden. Die benannten<br />
Merkmalleisten und -klassifikationen sind dafür<br />
ein wichtiger Ansatzpunkt [20]. So wie die Merkmale<br />
müssen alle anderen Daten (Prozess-, Diagnosedaten<br />
und Parameter) mit maschinenlesbaren Kennzeichen<br />
versehen werden, die auf semantische Definitionen verweisen.<br />
Das ist bei den Profilen bisher nicht der Fall. Nur<br />
so lassen sich aber rechnergestützte Integrationsaufgaben<br />
durchführen. Es muss auch angemerkt werden, dass<br />
sich der Einsatz von semantischen Technologien in diesem<br />
Umfeld noch in einem frühen Stadium befindet.<br />
Nur be<strong>im</strong> Einsatz aller oben dargestellten Integrationsmethoden<br />
zusammen mit einer konsistenten Identifizierung<br />
der jeweiligen Geräte-Repräsentanten, ergibt sich die Fähigkeit,<br />
alle Information zu dem Gerät zu integrieren. Ein Ansatz<br />
für diese Art der Integration ist in [19] dargestellt.<br />
IEC 62264<br />
Modelle (MES)<br />
Ethernet<br />
ERP, MES,<br />
Engineering des AT-Systems<br />
Gerätemanagement (Diagnose, Service)<br />
IEC 61512<br />
Modell (Batch)<br />
Profile, Merkmale<br />
Operation<br />
Ethernet<br />
BILD 9: Migrationsschritt der klassischen Automatisierungspyramide<br />
zu offener IT-Architektur<br />
Modellbasierte Dienste auf die<br />
AT-Komponenten mit Semantik<br />
(lose Kopplung)<br />
IEC 61131-3<br />
Modell<br />
Fieldbus<br />
Operativer Datenaustausch<br />
(enge Kopplung)<br />
IEC 62390<br />
Feldgerätemodell<br />
ZUSAMMENFASSUNG UND AUSBLICK<br />
In diesem Beitrag steht das AT-Gerät <strong>im</strong> Mittelpunkt.<br />
Ausgehend von einem allgemeingültigen AT-Gerätemodell<br />
sowie einer Einordnung der Geräte-Kompatibilität<br />
für Lebenszyklusaufgaben werden die wesentlichen<br />
Konzepte<br />
Kommunikationsintegration in die Geräte mit dem<br />
APO/ASE-Modell,<br />
Proxy-Modell für die Steuerungs- und Visualisierungsintegration,<br />
Gerätebeschreibungstechnologie<br />
und die dafür umspannende Profilbildung und<br />
Merkmaldefinition als Ansatz für semantische<br />
Inhalte<br />
vorgestellt. Es wird deutlich, dass die Integration für die<br />
enge Kopplung der Komponenten vorzugsweise <strong>im</strong> Sinne<br />
des Signalflusses sehr weit fortgeschritten ist. Die<br />
Profilbildung und die Merkmaldefinitionen bilden hier<br />
einen wertvollen Ansatz, der jedoch einer Weiterentwicklung<br />
bedarf.<br />
Es wird jedoch auch erkennbar, dass die dispositiven<br />
und Management-Aufgaben mit diesen Ansätzen bisher<br />
nicht befriedigend gelöst wurden. Die Erzielung des Mehrwertes<br />
der digitalen AT-Geräte, zum Beispiel für Diagnose<br />
oder Geräteverwaltung, wird durch die geschlossene<br />
Architektur der Leitsysteme behindert. Hier beflügelt die<br />
Initiative Industrie 4.0 einen Aufbruch dieser Strukturen.<br />
Als Ansatz für evolutionäre Schritte der Industrie<br />
4.0-Revolution wird vorgeschlagen, die dispositiven Aufgaben<br />
als Ausgangspunkt für offenere Architekturen<br />
basierend auf IT-Technologien zu verwenden, wie Web-<br />
Services und SOA. Hierzu müssen Schnittstellen geschaffen<br />
werden, zum Beispiel über OPC UA, die mit den<br />
domänenspezifischen Modellen und deren semantischen<br />
Definitionen ausgerüstet werden (Bild 9). Dadurch wird<br />
eine Transformation von signalorientierter enger Kopplung<br />
in Web-service-basierter loser Kopplung ermöglicht.<br />
Diagnose und Condition-Monitoring-Aufgaben sind sehr<br />
geeignete Kandidaten für dieses Vorgehen.<br />
Wenn die Anforderungen an AT-Systeme aus technologischer<br />
Sicht betrachtet werden, die die Initiative Industrie<br />
4.0 stellt, so lassen sich vor allem<br />
mehr Flexibilität der funktionalen Struktur auch<br />
während des operativen Betriebs<br />
offenere Schnittstellen von den AT-Systemen für<br />
IT-orientierte Anwendungen<br />
Bereitstellung semantischer Information<br />
identifizieren. Wegen der unterschiedlichen Anforderungen<br />
für die Geräteintegration lassen sich Bilanzräume der<br />
Integration (Tabelle 1) best<strong>im</strong>men. Als Kriterium gelten<br />
die Integrationspartner der Geräte, gepaart mit dem zeitlichen<br />
Charakter der Interaktionen. Neben der Zuordnung<br />
der beschriebenen Integrationstechnologien werden<br />
Ansätze für die technologische Kopplung mit IT-Systemen<br />
vorgeschlagen.<br />
MANUSKRIPTEINGANG<br />
09.06.2013<br />
Im Peer-Review-Verfahren begutachtet<br />
54<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
AUTOREN<br />
Prof. Dr.-Ing. CHRISTIAN DIEDRICH<br />
(geb. 1957) leitet den Lehrstuhl Integrierte<br />
Automation an der Otto-von-<br />
Guericke-Universität Magdeburg.<br />
Außerdem ist er stellvertretender<br />
Institutsleiter des Ifak e.V. in Magdeburg.<br />
Seine Hauptarbeitsfelder umfassen<br />
Beschreibungsmethoden für<br />
Automatisierungsgeräte und -systeme<br />
(Funktionsblocktechnologie, Feldbusprofile, Gerätebeschreibungen<br />
(EDD), FDT, IEC 61131), Engineeringmethoden und<br />
Informationsmanagement (Objektorientierte Analyse und<br />
Design, UML, Web-Technologien, Wissensverarbeitung),<br />
formale Methoden in der Automatisierungstechnik. Er ist in<br />
nationalen und internationalen Standardisierungs- und<br />
Fachgremien (IEC, DKE, ZVEI, PNO) tätig.<br />
THOMAS HADLICH (geb. 1967) ist<br />
wissenschaftlicher Mitarbeiter<br />
am Lehrstuhl Integrierte Automation<br />
an der Otto-von-Guericke-<br />
Universität Magdeburg. Zuvor<br />
hatte er eine leitende Stelle in der<br />
Industrie <strong>im</strong> Bereich der Softwareentwicklung<br />
automatisierungstechnischer<br />
Komponenten.<br />
Seine Arbeitsfelder sind insbesondere System<br />
Engneering, Geräteintegration und die digitale<br />
Fabrik. Er ist auf diesen Gebieten in nationalen und<br />
internationalen Standardisierungs- und Fachgremien<br />
(IEC, DKE, FDT Group) tätig.<br />
Otto-von-Guericke-Universität Magdeburg,<br />
Institut für Automatisierungstechnik,<br />
PF 4120, D-39016 Magdeburg,<br />
Tel. +49 (0) 391 671 84 99, E-Mail: christian.diedrich@ovgu.de<br />
Otto-von-Guericke-Universität Magdeburg,<br />
Institut für Automatisierungstechnik,<br />
PF 4120, D-39016 Magdeburg,<br />
Tel. +49 (0) 391 671 88 78, E-Mail: thomas.hadlich@ovgu.de<br />
REFERENZEN<br />
[1] Integration, Wikipedia, http://de.wikipedia.org/wiki/Integration,<br />
abgerufen am 07.06.2013.<br />
[2] IEC, IEC 62390: Profile development Guideline, 2004.<br />
[3] ISO 15745-1: Industrial automation systems and integration — Open<br />
systems application integration framework — Part 1: Generic reference<br />
description, ISO, 2002.<br />
[4] Vogel-Heuser, B.; Kegel, G.; Bender, K.; Wucherer, K.: Global Information<br />
Architecture for Industrial Automation. <strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische<br />
Praxis 51(1-2), S. 108–115, 2009<br />
[5] Prinz, J., Suchold, N., Drath, R., Lüder, A.: Integriertes Engineering<br />
durch die standardisierte Beschreibung mechatronischer Objekte<br />
durch Merkmale. <strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische Praxis<br />
51(7-8), S. 62–69, 2011<br />
[6] ISO: ISO 7498-1: Information technology – Open Systems Interconnection<br />
– Basic Reference Model: The Basic Model (1994).<br />
[7] Hadlich, T.; Diedrich, C.; Eckert, K.; Frank, T.; Fay, A.; Vogel-Heuser, B.:<br />
Common communication model for distributed automation systems. In<br />
Proc. IEEE 9th Int. Conf. Industrial Informatics (INDIN), S. 131; 136-141.<br />
IEEE 2011<br />
[8] Hodek, St, Loskyll, M., Schlick, J.: Feldgeräte und semantische<br />
Informationsmodelle. <strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische<br />
Praxis 54(12), S.44. – 51, 2012<br />
[9] FDT2.0 Technical Specification, FDT Group AISBL, Jodoigne,<br />
Belgium 2012.<br />
[10] Riedl, M., Naumann, F.: EDDL. Oldenbourg-Industrie Verlag 2011.<br />
[11] S<strong>im</strong>on, R., Kleegrewe, T., Birkhofer, R., Jeske, J.; Field Device Tool:<br />
FDT, Oldenbourg-Industrie Verlag, München 2005.<br />
[12] IEC 62769 Devices and integration in enterprise systems;<br />
Field Device Integration, CD; 2012<br />
[13] R. Birkhofer et al., Life-Cycle-Management für Produkte und Systeme<br />
der Automation: Ein Leitfaden des Arbeitskreises Systemaspekte <strong>im</strong><br />
ZVEI Fachverband Automation, Zentralverb. Elektrotechnik- und<br />
Elektronikindustrie, Fachverb. Automation, Frankfurt, M, 2010<br />
[14] Diedrich, Chr.; Mühlhause, M.; Riedl, M.; Bangemann, Th.: Mapping of<br />
smart field device profiles to web services. In: 7th IEEE Int. Workshop<br />
Factory Communication Systems (WFCS) – Communication in<br />
Automation, [CD]. IEEE 2008<br />
[15] Karnouskos, St., Bangemann, Th., Diedrich, Ch.: Integration of Legacy<br />
Devices in the Future SOA-based Factory. In: Proc. 13th IFAC Symposium<br />
on Information Control Problems in Manufacturing (INCOM 09),<br />
[CD], IFAC 2009<br />
[16] M. Runde, C. Tebbe, K. Niemann: IT-Security in Automatisierungsnetzwerken<br />
unter Verwendung kryptografischer Maßnahmen. In: Konferenzband<br />
KommA 2013, S. 157-165, Selbstverlag ifak/inIT 2012.<br />
[17] J. Kiesbauer: Von der Handdrossel zum smarten Stellgerät. Vortrag<br />
Namur Hauptsitzung 2013, Bad Neuenahr<br />
[18] PROFIBUS International, PROFIBUS Profile Guidelines, Part1<br />
„Identification & Maintenance Functions“, Version 1.1, 2003.<br />
[19] T. Hadlich, M. Muehlhause, C. Diedrich, in ETFA 2010: Discovery and<br />
integration of information in a heterogeneous environment. In: Proc.<br />
IEEE Int. Conf. Emerging Technologies and Factory Automation<br />
(ETFA’10), CD, IEEE 2010<br />
[20] S. Sokolov, C. Diedrich: Stammdaten <strong>im</strong> Engineering.<br />
In: at – Auto matisierungstechnik 61(6), S. 427-435, 2013.<br />
[21] PROFIBUS Guideline: PROFIBUS Communication and Proxy Function<br />
Blocks acc. to IEC 61131-3. Version 1.20, Juli 2001 Order No. 2.182.<br />
[22] Z. Liu, S. Sokolov, Ch. Diedrich: Flexible Fertigung (in the) cloud. In:<br />
Tagungsband Automation 2013. S. 415 – 419, VDI 2013.<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
55
HAUPTBEITRAG<br />
Selbsterklärende Geräte<br />
Abbildung semantischer Information auf Parameter mit EDD<br />
Aktuelle Integrationstechnologien reichen noch nicht aus, um Feldgeräte automatisch zu<br />
parametrieren. In diesem Beitrag wird ein neuer Ansatz vorgestellt – basierend auf den<br />
Anforderungen an die Feldgeräte, die bereits <strong>im</strong> Engineering und bei der Gerätewahl<br />
entstehen. Die Basis dafür stellen existierende Klassifikationssysteme dar. Die Abbildung<br />
von diesen Systemen auf die eigentlichen Parameter der Feldgeräte wird direkt in den<br />
Gerätebeschreibungen definiert. Diese werden direkt vom Gerätehersteller bereitgestellt<br />
und sind daher der ideale Ort für zusätzliche semantische Information. Der Ansatz ist<br />
kompatibel zu bestehenden Geräten und Gerätebeschreibungen und erlaubt eine schrittweise<br />
Unterstützung von Klassifikationsmerkmalen.<br />
SCHLAGWÖRTER Gerätebeschreibung / Geräteintegration / Merkmale / Engineering<br />
Self Describing Devices –<br />
Mapping Semantic Information to EDD Parameters<br />
Integration technologies have lacked features for automatic parameterization of field devices.<br />
A new approach is presented that considers the requirements that arise during<br />
engineering and device selection. It is based on existing classification systems. The mapping<br />
to the actual device parameters is defined directly in the device descriptions. These<br />
are provided by the device manufacturer and are therefore the ideal place for additional<br />
semantic information. This approach is compatible with existing devices and device<br />
descriptions and thus enables the step-by-step support of classification properties.<br />
KEYWORDS device description / device integration / properties<br />
56<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
DIRK JOHN, BENJAMIN DANZER, ABB<br />
MATTHIAS RIEDL, HOLGER ZIPPER, Ifak<br />
Feldgeräte besitzen eine Vielzahl von Parametern,<br />
um sie an Produktionsprozesse genau anpassen<br />
zu können. Das erschwert die Erstinbetriebnahme<br />
und den Tausch zweier Geräte bei Wartung<br />
oder Defekt – vor allem, wenn es sich um Feldgeräte<br />
mit unterschiedlicher Firmware oder um Geräte<br />
verschiedener Hersteller handelt.<br />
Derzeit werden Feldgeräte über eine Konfigurations-,<br />
Parametrier- und Diagnosesoftware (CPD Tool) an den<br />
Prozess angepasst. Die direkte Übernahme der Planungsdaten<br />
in diese Tools ist jedoch nur schwer möglich, da<br />
die Gerätemodelle der beiden Welten Planung und Inbetriebnahme<br />
zu verschieden sind. Die Geräteparametrierung<br />
muss daher noch zusätzlich auf Basis der Planungsdaten<br />
und der Gerätedokumentation erstellt werden.<br />
Dabei bieten Kommunikationsprotokolle wie Profibus<br />
PA/Profinet [1] oder Hart [2], vielfältige Möglichkeiten zur<br />
Auskunft und Übertragung benutzerdefinierter beziehungsweise<br />
großer Datenmengen und zur Geräteidentifikation.<br />
Allerdings lassen sich aus den Planungsdaten noch<br />
keine Datensätze für die Geräteparametrierung ableiten.<br />
Der Gerätetausch funktioniert be<strong>im</strong> Ersatz des gleichen<br />
Gerätetyps eines Herstellers. In Profibus PA 3.02 [3] wurden<br />
zudem Vorkehrungen getroffen, Information über die<br />
Abwärtskompatibilität der Gerätefirmware zu erhalten<br />
beziehungsweise das Gerät gezielt auf das Verhalten einer<br />
Vorversion setzen zu können. Diese Information lässt sich<br />
von den Integrationstechnologien wie EDDL, FDT oder FDI<br />
direkt für die Inbetriebnahme und Wartung benutzen.<br />
Um den Gerätetausch zu automatisieren, muss ein Leitsystem<br />
best<strong>im</strong>mte Basisfunktionalitäten unterstützen.<br />
Dabei handelt es sich um: Identifikation eines Gerätes,<br />
Auslesen und Schreiben der Konfiguration und Parameter,<br />
Benachrichtigung über die Notwendigkeit der Parametrierung,<br />
Validierung des Parametersatzes und automatische<br />
Zuordnung der Anforderungen (des Prozesses,<br />
für Regelung und so weiter) zu Geräteparametern. Es geht<br />
also um Kommunikations- und Semantikfunktionen.<br />
Die Kommunikationsfunktionen lassen sich in Kombination<br />
mit den standardisierten Kommunikationsprotokollen<br />
und den oben genannten Geräteintegrationstechnologien<br />
realisieren, zum Beispiel Identificationand-Maintenance-Funktionen<br />
(I&M) [4] zur Identifizierung<br />
oder Alarme für die Benachrichtigung.<br />
Momentan fehlt diesen Technologien semantische Information<br />
über die Bedeutung der Parameter, eine automatische<br />
Transformation auf Basis des Parameternamens<br />
ist nicht realistisch. Verschiedene Feldbusse definieren<br />
Profile, die für einen Basissatz die Bedeutung von<br />
Parametern herstellerübergreifend definieren. Die über<br />
das Profil beschriebenen Parameter können also zu einem<br />
gewissen Grad automatisiert verarbeitet werden.<br />
Problematisch bleibt jedoch die Nutzung herstellerspezifischer<br />
Parameter, da für diese die Bedeutung in der<br />
Regel nur <strong>im</strong> Handbuch beziehungsweise der Gerätedokumentation<br />
nachgelesen werden kann.<br />
1. NUTZUNG STANDARDISIERTER MERKMALE<br />
In frühen Planungsphasen einer Anlage sind die groben<br />
technischen Abläufe bekannt und liegen oft als Fließbilder<br />
oder in ähnlicher Form vor. Daraus ergeben sich erste<br />
Anforderungen an die Geräte der Anlage und Signale zwischen<br />
den Geräten. In den nachfolgenden Planungsschritten<br />
kommen weitere funktionale und nichtfunktionale<br />
Anforderungen hinzu. Auf Basis dieser Anforderungen<br />
wurden Geräte ausgewählt, mit denen die entsprechende<br />
Automatisierungsfunktion verwirklicht werden soll.<br />
Ein Beispiel: Ein pneumatisches Stellventil soll abhängig<br />
von einer Temperatur geregelt werden. Der Regler<br />
wird für diesen Fall <strong>im</strong> SPS-Programm realisiert. Der<br />
Temperatursensor besitzt einen Temperaturmessbereich<br />
zwischen 0 °C und 100 °C. Der Sensor wandelt den Temperaturwert<br />
in einen korrespondierenden Widerstandswert<br />
um, der <strong>im</strong> Temperaturtransmitter entsprechend<br />
aufbereitet wird (Linearisierung, Einheitenanpassung).<br />
Vom Temperaturtransmitter wird dieser Wert über ein<br />
Profibus-Telegramm, das <strong>im</strong>mer noch die gleiche, gemessene<br />
Temperatur repräsentiert, weitergegeben. Der Wert<br />
wird von der Steuerung interpretiert und verarbeitet.<br />
Daraus könnte sich beispielsweise ein Stellwert von<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
57
HAUPTBEITRAG<br />
20 mm für das pneumatische Stellventil ergeben. Dieser<br />
Sollwert würde über ein Profibus-Telegramm an das Gerät<br />
gesendet und dort in einen Druck umgewandelt werden,<br />
der zur Bewegung von 20 mm führt.<br />
Daher sind alle Anforderungen an die Geräte und Geräteparameter<br />
bekannt: zum einen durch die Anforderungen<br />
des Prozesses, zum anderen ergeben sie sich aus<br />
der Signalkette, zum Beispiel Einheiten, Darstellung,<br />
Messgröße.<br />
Schlussfolgerung: Wenn diese Information ausreicht,<br />
um festzustellen, dass ein Gerät alle Anforderungen<br />
erfüllen kann, muss sie auch zum Parametrieren<br />
ausreichen.<br />
Fragestellung: Lässt sich eine Abbildung von dieser<br />
Information auf die Parameter eines Feldgerätes<br />
finden?<br />
Während der Planung einer Anlage entsteht Information,<br />
die die Parametrierung zur Inbetriebnahme oder Laufzeit<br />
erleichtert (siehe Bild 1). Wichtig ist, dass diese<br />
Merkmale während des Engineerings so aufgenommen<br />
werden, dass sie später bei der Geräteparametrierung zur<br />
Verfügung stehen und zudem in einem maschinenlesbaren<br />
Format vorliegen. Dieses Format muss Name und<br />
zugehörige Werte der Merkmale enthalten und umfassende<br />
semantische Information und Beziehungen zwischen<br />
den Merkmalen abbilden. In Bild 2 sind die Vorteile<br />
bei der durchgängigen Nutzung von Merkmalen<br />
schematisch dargestellt. Der obere Teil beschreibt den<br />
aktuellen Stand, darunter befinden sich weitere Möglichkeiten<br />
der Nutzung von Merkmalen.<br />
1.1 Was sind Merkmale?<br />
Detaillierte Beschreibungen, was solche Merkmale bedeuten,<br />
sind bereits <strong>im</strong> E-Commerce-Umfeld entstanden.<br />
Klassifikationssysteme zur standardisierten Beschreibung<br />
von Geräteeigenschaften haben sich etabliert.<br />
Diese sollen durch standardisierte Austauschformate<br />
den E-Commerce vereinfachen, was durch die<br />
steigende Komplexität der Produkte in der Automatisierungstechnik<br />
und somit die der Kataloge zunehmend<br />
wichtig wird. Beispiele für solche Systeme sind:<br />
eCl@ss (enthält Prolist/NE 100 [5]), UNSPSC oder Et<strong>im</strong>.<br />
Besonders interessant für die Prozessautomation ist<br />
eCl@ss, das auf den Datenmodellen nach ISO 13584 [6]/<br />
IEC 61360 [7] basiert.<br />
eCl@ss ist ein gewerbeübergreifendes System zur Klassifikation<br />
und Beschreibung von Produkten. Es besteht<br />
aus 29 Segmenten, neben Elektro-, Automatisierungsund<br />
Prozessleittechnik auch aus Segmenten der Lebensmittel-<br />
oder Medizintechnik. Die Produkte werden in<br />
Main Groups und Groups unterteilt, zum Beispiel Generator<br />
und Generator > 100 MVA. Bild 3 zeigt ein Schema<br />
der Struktur und Bild 4 liefert dafür ein Beispiel.<br />
Produkte werden in eCl@ss durch Merkmale klassifiziert,<br />
die unter anderem aus einer eindeutigen Identifikation,<br />
einem Typ und einer Beschreibung bestehen. Des Weiteren<br />
können sie in Bezug zu anderen Merkmalen stehen.<br />
Durch das Austauschformat auf XML-Basis sind eCl@ss-<br />
Produktbeschreibungen per Design maschinenlesbar und<br />
daher für die automatische Verarbeitung geeignet.<br />
2. LÖSUNG<br />
Für eine automatische Parametrierung von Geräten ist es<br />
notwendig, Information aus dem gesamten Planungsprozess<br />
einer Anlage zu berücksichtigen. Letztendlich sind<br />
es Geräteintegrationstechnologien, die die Verbindung<br />
zwischen einem Gerät und dem Leitsystem herstellen. Von<br />
daher ist eine Abbildung von Merkmalen auf eine Gerätebeschreibungstechnologie<br />
wie in Bild 5 gezeigt die beste<br />
Möglichkeit, die Geräteparametrierung durch Merkmale<br />
zu ermöglichen. So lassen sich auch ältere Geräte ohne<br />
Änderung der Gerätesoftware mit Merkmalen parametrieren.<br />
Darüber hinaus können gemeinsame Merkmale in<br />
einer Standardbibliothek gehandhabt werden. Ein weiterer<br />
Vorteil ist, dass die oft vorhandenen Abhängigkeiten<br />
zwischen Parametern durch die Beziehungen zwischen<br />
den Merkmalen automatisch erfasst werden.<br />
Prinzipiell lässt sich ein solches Verfahren für alle<br />
verbreiteten Geräteintegrationstechnologien umsetzen.<br />
Nachfolgend wird dies am Beispiel von EDDL dargestellt.<br />
Als Integrationstechnologie wird EDD von der<br />
Hart Communication Foundation, der Fieldbus Foundation<br />
und den Profibus-Nutzerorganisationen (PNO)<br />
unterstützt. So werden für Hart-EDD Grundlagen für die<br />
Universal- und Common-Practice Kommandos, für FF<br />
die Blocktypen und Geräteprofile und seitens der PNO<br />
ebenfalls das PA-Profil als EDD-Bibliothek den Geräteherstellern<br />
bereitgestellt. Durch den quelloffenen Ansatz<br />
ist es für den Gerätehersteller sehr kostengünstig,<br />
EDD auf Basis dieser Bibliotheken zu erstellen. Weiterhin<br />
ist es möglich, die Merkmale auf die standardisierten<br />
Geräteparameter abzubilden und diese Abbildungsregeln<br />
ebenfalls als eine herstellerübergreifende Bibliothek<br />
zur Verfügung zu stellen.<br />
Komponentenbasierte Ansätze wie FDT haben hier den<br />
Nachteil, dass herstellerübergreifende Standardkomponenten<br />
wie die Profibus PA-Parameter für die DTM durch<br />
die Nutzerorganisationen nicht zur Verfügung stehen.<br />
Für die automatische Geräteparametrierung müssen die<br />
verschiedenen Komponenten einer Anlage zusammenwirken:<br />
Leitsystem, Engineeringwerkzeuge und Geräteintegrationswerkzeuge<br />
beziehungsweise Gerätebeschreibungen.<br />
Die Kommunikationssysteme müssen eine zuverlässige<br />
Identifikation der Feldgeräte ermöglichen, zum Beispiel<br />
durch die I&M-Daten bei Profibus und Profinet.<br />
2.1 Überblick<br />
Aus den <strong>im</strong> Engineeringprozess entstandenen Gerätemerkmalen<br />
und Werten wird eine Merkmalsmenge abgeleitet,<br />
auf deren Basis das Gerät zu parametrieren ist.<br />
Dies kann durch ein Engineeringwerkzeug und das Leitsystem<br />
erfolgen. Im Leitsystem ist die Interaktion mit<br />
den Gerätebeschreibungen <strong>im</strong>plementiert. Voraussetzung<br />
ist eine Schnittstelle, um den Austausch von Merkmalen<br />
mit den Gerätebeschreibungen zu ermöglichen.<br />
Die tatsächliche Abbildung auf Parameter erfolgt in der<br />
Gerätebeschreibung in einem zweistufigen Prozess.<br />
Auf Basis allgemeiner, das heißt gerätetypunabhängiger<br />
Abbildungsregeln, werden die Werte der Parameter aus<br />
den Merkmalen best<strong>im</strong>mt. Es ist möglich, dass mehr als<br />
ein Geräteparameter von einem Merkmal abhängt, zum<br />
Beispiel wenn ein Merkmal neben dem Zahlenwert noch<br />
58<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
Removal<br />
Task<br />
Front End<br />
Engineering<br />
Customer<br />
• Customer states<br />
his expectations<br />
Plant<br />
Manufacturer<br />
• Engineering<br />
Customer<br />
• Overviews the<br />
changes<br />
Plant<br />
Manufacturer<br />
• Adapt<br />
Devices<br />
• Parameterize<br />
Lots of documents<br />
Operation /<br />
Opt<strong>im</strong>ization /<br />
Maintenance<br />
Signal<br />
•Properties<br />
• Requirements<br />
Basic Engineering<br />
Customer<br />
• Customer<br />
expectation using<br />
properties<br />
Plant<br />
Manufacturer<br />
• Engineering<br />
• Completes<br />
properties<br />
Customer<br />
• Overviews the<br />
changes<br />
Plant<br />
Manufacturer<br />
• Adapt properties<br />
Devices<br />
• Generate device<br />
parameterization<br />
from properties<br />
BILD 2: Entwicklung einer Anlage<br />
Commissioning<br />
Detail Engineering<br />
Procurement<br />
BILD 1: Planungsschritte und Ergebnisse<br />
für Signale und Parameter<br />
BILD 3:<br />
Strukturschema von<br />
eCl@ss mit Hauptund<br />
Untergruppen<br />
Segments<br />
Main groups<br />
Groups<br />
Commodity classes<br />
Properties for the<br />
description of products<br />
and services – Standard<br />
sets of properties and<br />
keywords<br />
BILD 4: Beispiel<br />
einer Strukturierung<br />
gemäß eCl@ss<br />
DCS<br />
Classification<br />
Properties<br />
DD<br />
Parameter<br />
BILD 5: Parametrierung mit Merkmalen<br />
Communication<br />
System<br />
Device<br />
die physikalische Einheit umfasst. Es muss also geprüft<br />
werden, welche Parameter von dem Merkmal abhängig<br />
sind und ob hier die allgemeine Abbildungsregel gilt.<br />
Merkmale mit gerätetypspezifischen Besonderheiten werden<br />
in Schritt zwei verarbeitet.<br />
Gerätetypspezifische Abbildungen sind beispielsweise<br />
nötig bei speziellen Datentypen, Abhängigkeiten zu anderen<br />
Parametern oder falls Berechnungen und zusätzliche<br />
Gültigkeitsprüfungen durchgeführt werden müssen. Hier<br />
können zudem Anforderungen für weitere Merkmale entstehen,<br />
um eine gültige Parametrierung zu erreichen. In<br />
diesem Fall wird eine Liste dieser Merkmale erstellt, die<br />
vom Leitsystem entsprechend verarbeitet und zur Verfügung<br />
gestellt wird. Wenn die Abbildung erfolgreich verlief<br />
und keine zusätzlichen Anforderungen vorliegen, können<br />
die Parameter zum Gerät übertragen werden.<br />
Die Abbildung von Merkmalen auf Geräteparameter<br />
direkt in der EDD vorzunehmen, statt durch zukünftige<br />
Technologien wie FDI und OPC [6] zu realisieren, bringt<br />
den Vorteil, dass ein Gerätehersteller semantische Information<br />
über das Gerät und dessen Parameter bereitstellen<br />
kann und trotzdem kompatibel mit allen bisherigen<br />
Technologien und Systemen bleibt.<br />
2.2 Vorgehen<br />
Voraussetzung ist, dass in der EDD eine Liste der EDD-<br />
Variablen definiert ist, die für die Abbildung untersucht<br />
werden sollen. Jede dieser EDD-Variablen enthält einen<br />
Tag, der angibt, zu welchen Merkmalen diese Variable<br />
gehört. Im Detail kann die Abbildung von Merkmalen<br />
auf Geräteparametern durch folgende Sequenz von Aktionen<br />
durchgeführt werden:<br />
1 | Das Leitsystem startet den Vorgang. Dafür werden<br />
alle Anforderungen an das Gerät, die als Merkmal<br />
vorliegen, an den EDD-Algorithmus gegeben. Jedes<br />
Merkmal wird durch ein Kennzeichen (identifier,<br />
ID) eindeutig identifiziert.<br />
2 | Die Variablen der EDD werden durchsucht bis eine<br />
Variable gefunden wird, deren Tag zu der ID des<br />
Merkmals passt. Wurde eine Variable gefunden, kann<br />
das Mapping für dieses Merkmal fortgesetzt werden.<br />
3 | Anhand der ID wird die passende Abbildungsmethode<br />
gesucht. Diese kann entweder die Standard-<br />
Abbildungsmethode sein oder eine gerätetypspezifische<br />
Methode.<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
59
HAUPTBEITRAG<br />
BILD 6: Zusammenhang zwischen Merkmalen,<br />
Merkmalskatalog und Mapping<br />
4 | Der Wert des Merkmals wird mit Hilfe der Abbildungsmethode<br />
in einen Wert für die Variable umgewandelt.<br />
Nach erfolgreichem Mapping wird<br />
dieser Wert der entsprechenden Variablen zugewiesen.<br />
5 | Die Schritte 2 bis 5 werden für dasselbe Merkmal<br />
wiederholt, denn es können mehrere Parameter von<br />
einem Merkmal abhängen.<br />
6 | Für alle weiteren Merkmale werden die Schritte 2<br />
bis 5 wiederholt, bis alle Merkmale erfolgreich auf<br />
Gerätevariablen abgebildet wurden oder ein Fehler<br />
auftritt. Im Erfolgsfall wird die Geräteparametrierung<br />
anschließend zum Gerät geschrieben. Im Fehlerfall<br />
werden alle Variablen zu ihren vorherigen,<br />
gültigen Werten zurückgesetzt.<br />
Die Abbildung ist erfolgreich, wenn jedes einzelne Merkmal<br />
mindestens einmal auf eine Gerätevariable abgebildet<br />
wurde und die Abbildung erfolgreich verlief. Es ist<br />
die Aufgabe der Gerätebeschreibung zu garantieren, dass<br />
alle notwendigen Variablen untersucht werden. Die Abbildung<br />
ist fehlerhaft, wenn keine Variable mit dem passenden<br />
Tag gefunden wird, der Katalog keine entsprechende<br />
Regel enthält oder die Abbildungsmethode einen<br />
Fehler signalisiert.<br />
3. EDD-MERKMALSKATALOG<br />
EDD mit Unterstützung für eCl@ss können einen<br />
eCl@ss-Katalog einbinden (Bild 6 zeigt eine Übersicht).<br />
In diesem Katalog sind Variablen und Abbildungsfunktionsprototypen<br />
für die in eCl@ss beschriebenen Merkmale<br />
definiert. Für jedes Merkmal, das für die Automatisierung<br />
relevant ist, stellt der Katalog eine Repräsentation<br />
des Merkmals in EDDL-Syntax und -Semantik<br />
bereit. Zu jeder Variable gibt es zudem einen Funktionsprototypen<br />
(EDDL: #define). Im Normalfall wird eine<br />
Funktion genutzt, die den gleichen Datentyp bei dem<br />
Merkmal und bei der EDD-Variable ann<strong>im</strong>mt, also eine<br />
einfache Kopie. Abhängig vom Gerätetyp kann diese<br />
jedoch überschrieben (EDDL: #undef, #define) und angepasst<br />
werden, falls zum Beispiel andere Datentypen<br />
verwendet werden müssen oder eine komplexere Logik<br />
notwendig ist.<br />
Der Merkmalskatalog ist eine Bibliothek, die ebenfalls<br />
in EDD realisiert ist, ähnlich dem Hart-Katalog oder der<br />
Profibus PA-Bibliothek.<br />
Hart und Profibus PA definieren zudem viele Standardparameter<br />
wie Funktions- oder Transducer-Blöcke.<br />
Diese Standard-Parameter können auch in einen Standard-Merkmalskatalog<br />
abgebildet werden, sodass die<br />
Basisfunktionalität für solche Geräte automatisch abgedeckt<br />
wird.<br />
Die EDD wird lediglich durch die Merkmale und die<br />
entsprechenden Abbildungen ergänzt. Da dies auf Basis<br />
einzelner Merkmale beziehungsweise Parameter<br />
geschieht, können bestehende EDD um die Unterstützung<br />
ausgewählter Merkmale erweitert werden. Hierfür<br />
sind keine neuen Sprachelemente erforderlich,<br />
sodass diese EDD weiter mit allen bisherigen Systemen<br />
funktionieren. Da die Funktionalität des Katalogs<br />
hauptsächlich durch Makros realisiert ist, kann eine<br />
bestehende EDD ohne inkompatible Änderungen um<br />
die Unterstützung einzelner Merkmale erweitert werden<br />
und neue Geräte und Gerätebeschreibungen können<br />
so entworfen werden, dass der Katalog (fast) automatisch<br />
funktioniert. Merkmale für Profilparameter<br />
können so einfach integriert werden.<br />
4. WIE VIELE PARAMETER LASSEN SICH ABBILDEN?<br />
Untersuchungen zeigen, dass sich, abhängig von der<br />
Geräteart, über 75 % des Geräteparametersatzes durch<br />
eCl@ss-Merkmale abbilden lassen.<br />
Aktuell trifft das vor allem für Messgeräte zu. Hier<br />
sind für fast alle Geräteparameter Merkmale definiert,<br />
auch für herstellerspezifische Parameter. Problematisch<br />
ist die Parametrierung von Geräten wie Stellventilen,<br />
zu denen fast gar keine technischen Merkmale<br />
definiert sind.<br />
Gerätehersteller können bei der Neu<strong>im</strong>plementierung<br />
der Gerätebeschreibungen direkt auf Kompatibilität zu<br />
eCl@ss-Merkmalen achten, beispielsweise bei Datentypen,<br />
Bezeichnern, um einen möglichst großen Teil der<br />
Parameter durch die allgemeinen Abbildungsregeln abzudecken.<br />
Ein Gerätehersteller muss prinzipiell drei<br />
Anpassungen an der Geräte-EDD vornehmen:<br />
Einbinden des eCl@ss-Katalogs<br />
Zuweisen der Merkmal-ID zu den entsprechenden<br />
EDD-Variablen<br />
Anpassen der speziellen Abbildungsmethoden,<br />
wo notwendig<br />
Systemhersteller müssen vor allem den Engineeringprozess<br />
auf Basis von Merkmalen unterstützen und diese<br />
Information zum Parametrieren bereitstellen. Entsprechend<br />
müssen Gerätebeschreibungsfunktionen, die die<br />
Parametrierung durch Merkmale durchführen, angebunden<br />
werden. Außerdem ist es notwendig, dass sich Hersteller<br />
von Geräten und Systemen in den Standardisierungsprozess<br />
um eCl@ss einbringen, um möglichst viele<br />
Gerätetypen abzudecken.<br />
60<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
FAZIT<br />
Feldgeräte automatisch zu parametrieren, reduziert den<br />
Aufwand bei Erstinbetriebnahme oder be<strong>im</strong> Gerätetausch<br />
stark und verringert auch die Wahrscheinlichkeit von Fehlern.<br />
Dafür können die aktuell zum E-Commerce und Engineering<br />
eingesetzten Klassifikationssysteme wie eCl@ss<br />
eingesetzt werden, die Produkte auf Basis standardisierter<br />
Merkmale beschreiben. Hierdurch lässt sich Information,<br />
die <strong>im</strong> Engineering als Anforderungen an die Geräte entsteht,<br />
detailliert erfassen und maschinenlesbar speichern.<br />
Auf dieser Basis kann ein Satz von Merkmalen abgeleitet<br />
werden, der die Geräteparametrierung beschreibt. Mit den<br />
aktuellen Integrationstechnologien wie EDD kann dieser<br />
Merkmalssatz in tatsächliche Geräteparameter umgewandelt<br />
und zum Gerät geschrieben werden. Ein genereller<br />
Merkmalskatalog verringert den Aufwand bei der Anpassung<br />
der Gerätebeschreibung erheblich.<br />
Der zentrale Punkt ist, dass die Abbildung der Merkmale<br />
auf Geräteparameter durch die Gerätebeschreibungen<br />
definiert wird. Diese werden direkt vom Gerätehersteller<br />
bereitgestellt und sind daher der ideale Ort für zusätzliche<br />
semantische Information. Im Beitrag wurde ein Ansatz<br />
dafür vorgestellt, der zu bestehenden Geräten und Gerätebeschreibungen<br />
kompatibel ist und eine schrittweise Unterstützung<br />
von Merkmalen erlaubt. Da hierfür die bestehenden<br />
EDDL-Sprachmittel ausreichend sind, arbeiten<br />
diese EDD weiter mit bestehenden Systemen zusammen,<br />
wodurch eine Umstellung Schritt für Schritt erfolgen kann.<br />
Durch die durchgängige Nutzung von Merkmalen lassen<br />
sich das Engineering und die Beschaffung von Feldgeräten<br />
sowie die Inbetriebnahme und Wartung der Anlagen<br />
vereinfachen. Die Interoperabilität zwischen den<br />
Geräten verschiedener Hersteller wird verbessert.<br />
REFERENZEN<br />
[1] IEC2007: International Electrotechnical Committee:<br />
Industrial communication networks – Fieldbus<br />
specifications, IEC 61158, 2007<br />
[2] HCF 2011: HART Device Description Language<br />
Specification, Januar 2011<br />
[3] PNO2009: PROFIBUS PA Profile for Process Control<br />
Devices, V3.02, April 2009<br />
[4] PNO2009a: PNO Profile Guidelines, Part 1: Identification<br />
& Maintenance Function, Version 1.2, Oktober 2009<br />
[5] NE 100: NAMUR Recommendation: Use of Lists of<br />
Properties in Process Control Engineering Workflows,<br />
Version 3.0<br />
[6] PROLIST open 2012 – PROLIST und FDI Lückenlos<br />
von der Bestellung zum Gerätemanagement,<br />
November 2012<br />
[7] ISO 13584: Industrial automation systems and<br />
integration – Parts library, Dezember 2010<br />
[8] IEC 61360: Common Data Dictionary<br />
(CDD - V2.0012.0001), Oktober 2012<br />
MANUSKRIPTEINGANG<br />
31.05.2013<br />
Im Peer-Review-Verfahren begutachtet<br />
AUTOREN<br />
ABB AG Forschungszentrum Deutschland,<br />
Wallstadter Str. 59, D-68526 Ladenburg<br />
Dr.-Ing. DIRK JOHN (geb. 1971) ist seit 2001<br />
Mitarbeiter am ABB Forschungszentrum<br />
Deutschland. Seit 2005 leitet er die Gruppe<br />
„Intelligent Devices“ und beschäftigt sich <strong>im</strong><br />
Rahmen dieser Tätigkeit mit verschiedenen<br />
Aspekten der Software für Automatisierungsgeräte,<br />
unter anderem der Geräteintegration,<br />
vor allem mit FDI.<br />
Dr.-Ing. BENJAMIN DANZER (geb. 1977) ist<br />
derzeit entsandt zu ABB in Norwegen und<br />
arbeitet an der S<strong>im</strong>ulation von Leitsystemen.<br />
Zuvor war er bei ABB <strong>im</strong> Forschungszentrum<br />
Deutschland auf dem Gebiet der intelligenten<br />
Feldgeräte und industriellen Kommunikation<br />
tätig. Seine Arbeitsschwerpunkte sind<br />
Geräteintegration und damit verbundene<br />
Technologien beispielsweise FDI. Er studierte<br />
Maschinenbau an der Technischen Universität München und<br />
promovierte an der Technischen Universität München am<br />
Lehrstuhl für Informationstechnik <strong>im</strong> Maschinenwesen (Prof.<br />
Bender) <strong>im</strong> Bereich Geräteintegration.<br />
ABB AS,<br />
Integrated Operations,<br />
Ole Deviks Vei 10, 0666, Oslo, Norwegen,<br />
Tel: +47 241 653 63,<br />
E-Mail: benjamin.danzer@no.abb.com<br />
Dr.-Ing. MATTHIAS RIEDL (geb. 1967), Studium<br />
der Informatik bis 1994 in der Otto-von-Guericke-Universität<br />
Magdeburg, seitdem wissenschaftlicher<br />
Mitarbeiter und Schwerpunktleiter<br />
am ifak mit Schwerpunkt Fachsprachen<br />
und Inbetriebnahmewerkzeuge, 2005 Promotion<br />
zum Thema verteilter Steuerungssysteme,<br />
seit 2008 Bereichsleiter in verschieden<br />
Geschäftsfeldern.<br />
ifak Magdeburg,<br />
Werner-Heisenberg-Str. 1, D-39106 Magdeburg<br />
HOLGER ZIPPER (geb. 1986) Nach dem<br />
Studium der technischen Kybernetik<br />
und Systemtechnik an der Otto-von-<br />
Guericke-Universität Magdeburg bis 2011<br />
ist er als wissenschaftlicher Mitarbeiter<br />
am ifak tätig. Er beschäftigt sich mit den<br />
Themen Geräte integration und<br />
verteilter Test.<br />
ifak Magdeburg,<br />
Werner-Heisenberg-Str. 1, D-39106 Magdeburg<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013<br />
61
IMPRESSUM / VORSCHAU<br />
IMPRESSUM<br />
VORSCHAU<br />
Verlag:<br />
DIV Deutscher Industrieverlag GmbH<br />
Arnulfstraße 124, D-80636 München<br />
Telefon + 49 (0) 89 203 53 66 0<br />
Telefax + 49 (0) 89 203 53 66 99<br />
www.di-verlag.de<br />
Geschäftsführer:<br />
Carsten Augsburger, Jürgen Franke<br />
Verlagsleiterin:<br />
Kirstin Sommer<br />
Spartenleiterin:<br />
Anne Purschwitz geb. Hütter<br />
Herausgeber:<br />
Dr.rer.nat. Thomas Albers<br />
Dr. Gunther Kegel<br />
Dipl.-Ing. Hans-Georg Kumpfmüller<br />
Dr.-Ing. Wilhelm Otten<br />
Beirat:<br />
Dr.-Ing. Kurt Dirk Bettenhausen<br />
Prof. Dr.-Ing. Christian Diedrich<br />
Prof. Dr.-Ing. Ulrich Epple<br />
Prof. Dr.-Ing. Alexander Fay<br />
Prof. Dr.-Ing. Michael Felleisen<br />
Prof. Dr.-Ing. Georg Frey<br />
Prof. Dr.-Ing. Peter Göhner<br />
Dipl.-Ing. Thomas Grein<br />
Prof. Dr.-Ing. Hartmut Haehnel<br />
Dr.-Ing. Jörg Kiesbauer<br />
Dipl.-Ing. Rolf Marten<br />
Dipl.-Ing. Gerald Mayr<br />
Dr. Jörg Nothdurft<br />
Dr.-Ing. Josef Papenfort<br />
Dr. Andreas Wernsdörfer<br />
Dipl.-Ing. Dieter Westerkamp<br />
Dr.rer.nat. Christian Zeidler<br />
Organschaft:<br />
Organ der GMA<br />
(VDI/VDE-Gesell schaft Messund<br />
Automatisierungs technik)<br />
und der NAMUR (Interessengemeinschaft<br />
Automatisierungstechnik<br />
der Prozessindustrie).<br />
Redaktion:<br />
Anne Purschwitz geb. Hütter (ahü)<br />
(verantwortlich)<br />
Telefon + 49 (0) 89 203 53 66 58<br />
Telefax + 49 (0) 89 203 53 66 99<br />
E-Mail: purschwitz@di-verlag.de<br />
Aljona Hartstock (aha)<br />
Telefon + 49 (0) 89 203 53 66 78<br />
E-Mail: hartstock@di-verlag.de<br />
Gerd Scholz (gz)<br />
Einreichung von Hauptbeiträgen:<br />
Prof. Dr.-Ing. Leon Urbas<br />
(Chefredakteur, verantwortlich<br />
für die Hauptbeiträge)<br />
Technische Universität Dresden<br />
Fakultät Elektrotechnik<br />
und Informationstechnik<br />
Professur für Prozessleittechnik<br />
D-01062 Dresden<br />
Telefon +49 (0) 351 46 33 96 14<br />
E-Mail: urbas@di-verlag.de<br />
Fachredaktion:<br />
Dr.-Ing. Michael Blum<br />
Dipl.-Ing. Heinrich Engelhard<br />
Prof. Dr.-Ing. Jürgen Jasperneite<br />
Dr.-Ing. Bernhard Kausler<br />
Dr.-Ing. Niels Kiupel<br />
Prof. Dr.-Ing. Gerrit Meixner<br />
Dr.-Ing. Jörg Neidig<br />
Dipl.-Ing. Ingo Rolle<br />
Dr.-Ing. Stefan Runde<br />
Prof. Dr.-Ing. Frank Schiller<br />
Bezugsbedingungen:<br />
„<strong>atp</strong> <strong>edition</strong> – Automatisierungstechnische<br />
Praxis“ erscheint<br />
monatlich mit Doppelausgaben <strong>im</strong><br />
Januar/Februar und Juli/August.<br />
Bezugspreise:<br />
Abonnement jährlich: € 468,– + € 30,–/<br />
€ 35,– Versand (Deutschland/Ausland);<br />
Heft-Abonnement + 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 />
für 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 für Abonnementaufträge<br />
beträgt 8 Wochen zum Bezugsjahresende.<br />
Abonnement-/<br />
Einzelheftbestellung:<br />
DataM-Services GmbH, Leserservice <strong>atp</strong><br />
Herr Marcus Zepmeisel<br />
Franz-Horn-Str. 2, 97082 Würzburg<br />
Telefon + 49 (0) 931 417 04 59<br />
Telefax + 49 (0) 931 417 04 94<br />
leserservice@di-verlag.de<br />
Verantwortlich für<br />
den Anzeigenteil:<br />
Inge Matos Feliz<br />
Telefon + 49 (0) 89 203 53 66 22<br />
Telefax + 49 (0) 89 203 53 66 99<br />
E-Mail: matos.feliz@di-verlag.de<br />
Es gelten die Preise der Mediadaten 2013<br />
Anzeigenverwaltung:<br />
Brigitte Krawczyk<br />
Telefon + 49 (0) 89 203 53 66 12<br />
Telefax + 49 (0) 89 203 53 66 99<br />
E-Mail: krawczyk@di-verlag.de<br />
Art Direction / Layout:<br />
deivis aronaitis design | dad |<br />
Druck:<br />
Druckerei Chmielorz GmbH,<br />
Ostring 13,<br />
D-65205 Wiesbaden-Nordenstadt<br />
Gedruckt auf chlor- und<br />
säurefreiem Papier.<br />
Die <strong>atp</strong> wurde 1959 als „Regelungstechnische<br />
Praxis – rtp“ gegründet.<br />
DIV Deutscher Industrieverlag<br />
GmbH München<br />
Die Zeitschrift und alle in ihr enthaltenen<br />
Beiträge und Abbildungen sind urheberrechtlich<br />
geschützt. Mit Ausnahme der<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 />
DIV Deutscher Industrieverlag GmbH,<br />
Arnulfstraße 124, D-80636 München.<br />
Alleiniger Gesellschafter des Verlages<br />
ist die ACM-Unternehmensgruppe,<br />
Ostring 13,<br />
D-65205 Wiesbaden-Nordenstadt.<br />
ISSN 2190-4111<br />
DIE AUSGABE 11 / 2013 DER<br />
ERSCHEINT AM 04.11.2013<br />
MIT DEM SCHWERPUNKT<br />
„PLUG & PRODUCE – TRAUM ODER ALBTRAUM?“<br />
Geräteintegration und<br />
-management – Teil 2:<br />
Integriertes Engineering mit<br />
S<strong>im</strong>atic PDM und FDI<br />
S<strong>im</strong>ulation und modellbasiertes<br />
Testen quasi en passant –<br />
Bausteinbibliothek für<br />
Prozess- und Anlagenmodule<br />
Fähigkeiten adaptiver<br />
Produktionsanlagen<br />
Aus aktuellem Anlass können sich die Themen<br />
kurzfristig verändern.<br />
LESERSERVICE<br />
E-MAIL:<br />
leserservice@di-verlag.de<br />
TELEFON:<br />
+ 49 (0) 931 417 04 59<br />
62<br />
<strong>atp</strong> <strong>edition</strong><br />
10 / 2013
da<br />
steckt mehr<br />
dahinter
4. Explosionsschutz-Sprechstunde<br />
Explosionsschutz<br />
18. + 19.11.2013, Mannhe<strong>im</strong>, Pepperl+Fuchs GmbH<br />
www.explosionsschutz-sprechstunde.de<br />
Veranstaltungskonzept<br />
Haben Sie Fragen zur Umsetzung der Betriebssicherheitsverordnung oder zur<br />
Anwendung der einschlägigen Normen zum Explosionsschutz? Dann sind Sie hier<br />
richtig! Reichen Sie Ihre Fragen rund um den Explosionsschutz ein. Diskutieren Sie mit<br />
Experten Ihre aktuellen Themen am 18. und 19. November 2013 in Mannhe<strong>im</strong>!<br />
Termin<br />
Montag, 18.11.2013<br />
Veranstaltung (11:30 – 17:30 Uhr)<br />
„Get-Together“ mit Abendessen (ab 18:00 Uhr)<br />
Dienstag, 19.11.2013<br />
Veranstaltung (9:00 – 15:00 Uhr)<br />
Ort<br />
Pepperl+Fuchs GmbH<br />
Lilienthalstr. 200<br />
68307 Mannhe<strong>im</strong><br />
Teilnahmegebühren<br />
<strong>atp</strong> <strong>edition</strong>-Abonnenten 540 € zzgl. MwSt.<br />
Firmenempfehlung 590 € zzgl. MwSt.<br />
reguläre Teilnahmegebühr 690 € zzgl. MwSt.<br />
Studenten kostenlos<br />
(Universität, Fachhoch- / Duale Hochschule – Vorlage des Studentenausweises bei der<br />
Anmeldung erforderlich)<br />
Im Preis enthalten sind die Tagungsunterlagen sowie die Verpflegung während der<br />
Veranstaltung (inkl. gemeinsames Abendessen).<br />
Anmeldung<br />
Detaillierte Informationen zur Veranstaltung, das vollständige Programm sowie die<br />
Online-Anmeldung finden Sie <strong>im</strong> Internet unter<br />
www.explosionsschutz-sprechstunde.de
Referenten<br />
Gerhard Jung, Pepperl+Fuchs GmbH<br />
Stefanie Klein, DSM Nutritional Products<br />
Ralf Knitt, Pepperl+Fuchs GmbH<br />
Arnold Staedel, TÜV SÜD Industrie Service GmbH, Niederlassung Nürnberg<br />
Michael Wenglorz, Pepperl+Fuchs GmbH<br />
Thomas Westers, Pepperl+Fuchs GmbH<br />
Dr.-Ing. Michael Wittler, Dekra Exam GmbH<br />
Programm<br />
Moderation: Anne Purschwitz geb. Hütter, <strong>atp</strong> <strong>edition</strong><br />
Montag, 18.11.2013<br />
11:30 Begrüßung und Vorstellung der Referenten und des Programms<br />
Anne Purschwitz<br />
12:15 Mittagessen<br />
13:00 Elektrostatik - Die neue technische Spezifikation IEC 60079-32<br />
Dr. Michael Wittler<br />
14:00 Nachweis der Eigensicherheit und DART<br />
Michael Wenglorz<br />
15:00 Pause<br />
15:30 Zentrifuge als Zündquelle – Anforderungen an die Zuverlässigkeit der<br />
Inertisierung von Zentrifugen.<br />
Stefanie Klein<br />
16:30 Funktionale Sicherheit <strong>im</strong> Explosionsschutz<br />
Arnold Staedel<br />
17:30 Fahrt zum Hotel und Einchecken<br />
18:00 Bustransfer vom Hotel zum „Get-Together“<br />
Dienstag, 19.11.2013<br />
09:00 Parallele Workshops<br />
13:30 Mittagessen<br />
14:15 Zusammenfassung der Ergebnisse<br />
15:00 Ende der Veranstaltung<br />
DIV Deutscher Industrieverlag GmbH<br />
Anne Purschwitz geb. Hütter<br />
Arnulfstraße 124<br />
80636 München<br />
Tel.: +49 (0) 89 203 53 66-58<br />
Fax: +49 (0) 89 203 53 66-99<br />
E-Mail: purschwitz@di-verlag.de<br />
www.sil-sprechstunde.de<br />
Pepperl+Fuchs GmbH<br />
Sandra Achenbach<br />
Lilienthalstraße 200<br />
68307 Mannhe<strong>im</strong><br />
Tel.: +49 (0) 621 776-2176<br />
Fax: +49 (0) 621 776-1108<br />
E-Mail: sachenbach@de.pepperl-fuchs.com<br />
www.pepperl-fuchs.de
Erreichen Sie die Top-Entscheider<br />
der Automatisierungstechnik.<br />
Sprechen Sie uns an wegen Anzeigenbuchungen<br />
und Fragen zu Ihrer Planung.<br />
Inge Matos Feliz: Tel.: +49 89 203 53 66-22<br />
E-Mail: matos.feliz@di-verlag.de