Was ist ein PAC – evolutionärer SPS-Nachfolger oder Marketing-Gag?
Werbung
Automatisierungsgeräte Was ist ein PAC – evolutionärer SPS-Nachfolger oder Marketing-Gag? Mario Schwartz und Rainer Drath, ABB Forschungszentrum, Deutschland Dieser Beitrag erläutert die Technologie hinter dem Begriff „Programmable Automation Controller“, kurz PAC. Der PAC wird von der ARC Advisory Group und verschiedenen Anbietern als evolutionärer Nachfolger der SPS propagiert und vermarktet. Was sich tatsächlich dahinter verbirgt, ist in der Industrie jedoch kaum bekannt. Durch diverses Marketingmaterial entsteht der Eindruck, dass ein PAC die SPS mühelos ersetzen und das Automatisierungssystem um wesentliche Funktionen erweitern kann. Dies verunsichert sowohl Hersteller traditioneller SPSn als auch deren Anwender. Dieser Beitrag evaluiert qualitativ und quantitativ am Markt befindliche PAC-Lösungen und stellt eine allgemeine PAC-Definition vor. Weiterhin werden seine Potentiale in Abgrenzung zur klassischen SPS herausgestellt. Programmable Automation Controller (PAC) / Industrielle Steuerung / Industrie-PC (IPC) / Speicherprogrammierbare Steuerung (SPS) 1. Einleitung 1.1 Hintergrund, Gerüchte und Fragen: Was ist ein PAC? Ein neuer Begriff drängt auf den Markt: der „Programmable Automation Controller“-PAC. Er wird als evolutionärer Nachfolger der SPS beworben, doch eine klare und belastbare Definition ist derzeit nicht verfügbar. Sein Ziel: domänenübergreifende Vereinigung von Automatisierungseinrichtungen. Doch was bedeutet das? Zum Hintergrund: die Automatisierung von Maschinen und Anlagen ist unabdingbar mit industriellen Steuerungen verbunden. Allerdings haben sich im Rahmen von Differenzierungsprozessen vielfältige technische Lösungen für Steuerungen herausgebildet, die sich jeweils auf unterschiedliche Aufgabenstellungen und Anforderungen an die Automatisierungstechnik spezialisiert haben. Die wohl bekannteste technische Umsetzung einer Steuerung ist die SPS, die ursprünglich für die logische Verknüpfung binärer Signale entwickelt wurde. Die SPS wird vornehmlich in der Fertigungsindustrie und im Maschinen- 34 What is a PAC – Evolutionary PLC Successor or Just Marketing? This contribution explains the technology that is promoted as “Programmable Automation Controller”, short PAC. The PAC is promoted by the ARC advisory group and several vendors as evolutionary successor of the PLC. s it is quite unknown to many engineers what this really means. Thus the picture of replacing every PLC easily by a PAC and even implementing new functionality by the PAC replacement arises. This contribution evaluates PAC solutions available on the market in a qualitative and quantitative manner and gives a common PAC definition. Furthermore, its potentials regarding classic PLCs are discussed. Programmable Automation Controller (PAC) / Industrial Control System (ICS) / Industry PC (IPC) / Programmable Logic Controller (PLC) bau eingesetzt. Darüber hinaus findet sie in zunehmendem Maße auch in der Prozessindustrie Anwendung, die jedoch nach wie vor überwiegend von Prozesscontrollern beherrscht wird. Sind verteilte Steuerungen erforderlich, werden üblicherweise DCSn (engl. „Distributed Control System“) eingesetzt. Weitere verbreitete Formen von Automatisierungstechniken sind Industrie-PCs (IPCs), SCADA-Systeme oder Embedded-Systems, sowie spezielle Robotersteuerungen und Motion Controller, welche ebenfalls eigenständige Systeme darstellen und häufig mit anderen Automatisierungsgeräten kombiniert werden. Der „Programmable Automation Controller“, kurz PAC, reklamiert die evolutionäre Zusammenführung und somit den Ersatz dieser Systeme. Hierdurch sollen angeblich Kosten und Zeit für Entwicklung, Spezifikation und Inbetriebnahme gesenkt werden. Ist der PAC eine automatisierungstechnische „eierlegenden Wollmilchsau“? Kann ein PAC die Technologien hinter SPSn, IPCs oder DCSn tatsächlich vereinen und sie somit verdrängen? Es ist bekannt, dass die Grenze zwischen den genannten Steuerungstechniken zunehmend verschwimmt: Prozessatp 3.2009 www.atp-online.de Automatisierungsgeräte 1.2 Auswirkungen einer unklaren Definition des PAC Die Verwirrung um den Begriff PAC wirkt bis in die Analyse von Markttrends hinein. Selbst Berichte der ARC Advisory Group verwenden den PAC unterschiedlich: einer Studie von ARC zufolge wird der Markt für SPS und PAC weiter wachsen [1], wobei der SPS-Markt 2011 ein Volumen von ca. 12 Milliarden Dollar umfassen soll, bei einem jährlichen Wachstum von ca. 7,3%. Der PAC-Markt wird demnach lediglich auf ein Gesamtvolumen von mehr als 1 Milliarde Dollar geschätzt, jedoch mit einem jährlichen Wachstum von 15–20 %. Eine andere und aktuellere Studie, ebenfalls von ARC, verwendet den Begriff PAC bereits synonym für High-End SPSn oder Steuerungen mit vergleichsweise großem Funktionsumfang [2]. Dort wird behauptet, dass der PAC bereits 40 % des SPS Marktes beherrscht - auf der Grundlage, dass auch High-End SPSn und Steuerungen als PAC betrachtet werden. Ursache dieser unterschiedlichen Ergebnisse ist ein unzureichendes Verständnis über die Definition eines PAC. Dies verunsichert sowohl Hersteller als auch Anwender traditioneller Steuerungssysteme und erschwert die Vergleichbarkeit sowie die Bewertung der alten und neuen Technik. Bei der Vermarktung des PAC ist weiterhin bemerkenswert, dass dies bisher nur in Amerika und Asien erfolgreich gelingt, während in Europa nur eine sehr geringe Präsenz vorliegt. Unternehmen, welche einen PAC erfolgreich in ihre Produktlinie integriert haben (z. B. Schneider oder Rockwell), bestätigen in Interviews, sie würden ihre Geräte in Amerika www.atp-online.de atp 3.2009 als PAC vermarkten, da dort mit dem Begriff eine erweiterte Funktionalität assoziiert wird. In Europa hingegen würden dieselben Geräte als SPSn vertrieben, da hier nicht zwischen SPS und PAC differenziert wird [1]. Siemens oder B&R beispielsweise verzichten bisher vollständig auf die Vermarktung von PACs. Die Fachliteratur lässt eine klare Abgrenzung zwischen PAC und SPS nur am Rande erkennen. So werden Systeme mit großem Funktionsumfang kurzerhand als PAC bezeichnet, obwohl sie nicht als solche vermarktet werden. Auch dies unterstreicht den Bedarf nach einer klaren Definition. 2. Stand der Technik – Anforderungen an einen PAC Im Folgenden werden unterschiedliche Definitionen und Informationen aus einer Auswahl von Literaturstellen und Internetseiten in Form eines Überblicks zusammengefasst und analysiert. 2.1 Einfache Definition Die einfachste Definition des PAC ist die Kombination aus SPS und IPC [3]. Die SPS als zuverlässiges und robustes Steuerungssystem wird mit ihrem Fokus auf die Verarbeitung binärer Signale vornehmlich in rauen Fabrikumgebungen eingesetzt. Zusätzlich ist die SPS echtzeitfähig und für zeitkritische Anwendungen einsetzbar. Ihr Nachteil liegt in der relativ geringen Flexibilität, zumeist fehlender Redundanz sowie der Begrenzung auf kleine und mittelgroße Automatisierungseinrichtungen. Der IPC hingegen ist wesentlich flexibler als die SPS. Die Software ist üblicherweise modular aufgebaut, zumeist basierend auf MS Windows Systemen. Dadurch kann der IPC leichter erweitert und funktional angepasst werden. Durch die fehlende Echtzeitfähigkeit ist der IPC jedoch für zeitkriti- Flexibilität & Funktionalität Controller und SPSn nähern sich derzeit in Funktionalität und Per formance aneinander an, zugleich rücken prozessnahe und prozessferne Systeme enger zusammen. Ist der PAC die Brücke zwischen beiden Welten? Welche technologische Innovation und welchen Vorteil bringt der PAC tatsächlich mit sich? Ist er der neuartige, evolutionäre Ansatz, wie bereits von ARC und Rockwell propagiert, oder stellt er lediglich eine kleine schrittweise Erweiterung bestehender Systeme um neue Funktionalitäten dar? Anbieter wie Rockwell, SIEMENS, Schneider Electric oder ABB bieten bereits vielfältige und bewährte SPS-Lösungen an, angefangen bei Kleinststeuerungen als Remote Terminal Unit-Ersatz bis hin zum IPC Ersatz. Wozu also braucht der Markt zusätzlich einen PAC? Der PAC soll den Trend der Annäherung fortsetzen und ein hybrides System bilden, welches für Maschinen- und Anlagenautomatisierung in der Fertigungs- und Prozessautomatisierung gleichermaßen verwendet werden kann. Dadurch soll die Automatisierung nicht nur aus einer Hand, sondern auch in einem Gerät realisiert werden. Dennoch bleibt eine klare technische Definition des PACs offen. Dieser Beitrag analysiert die Funktionalität des PAC und ordnet sie den klassischen Steuerungstechniken zu. Dies erfolgt zum einen durch Zusammenstellung von Anforderungen auf der Basis verschiedener Veröffentlichungen in einschlägigen Zeitschriften und Onlineforen, zum anderen auf Basis einer Analyse von am Markt erhältlichen Produkten. Daraus wird eine priorisierte Definition der Anforderungen an einen PAC abgeleitet und vorgestellt. PAC IPC SPS Robustheit & Zuverlässigkeit Bild 1: Einfache PAC Definition. 35 Automatisierungsgeräte sche Applikationen nur beschränkt anwendbar. Da IPCs zudem auf Standard-PC-Hardware basieren, ist ihre Robustheit und Zuverlässigkeit für kritische Systeme nicht ausreichend. Dies begrenzt ihre Einsatzmöglichkeiten. Bild 1 veranschaulicht, wie der PAC beide Systeme gemäß dieser Definition kombiniert und Echtzeitfähigkeit mit flexibler Software und Hardware vereint. Er soll dabei die Vorteile beider Systeme vereinen und gleichzeitig deren Nachteile eliminieren. Diese einfache Definition ist eine gute Grundlage, bleibt aber zu allgemein. Es werden keine Anwendungsbereiche oder Techniken festgelegt. ARC definiert hierzu weitere Anforderungen, welche im folgenden Abschnitt erläutert werden. 2.2 PAC Anforderungen nach ARC Die Erfinder des Begriffes PAC stellen fünf grundlegende Anforderungen an einen PAC [4]: 1. ein PAC besitzt domänenübergreifende Funktionalität, inklusive Logik-, Motion-, Antriebs- und Prozesssteuerung sowie Regelung, 2. ein PAC verfügt über eine interdisziplinäre Entwicklungsumgebung, welche eine Datenbank zum Erfassen globaler Daten beinhaltet, 3. ein PAC unterstützt eine Programmiersprache, welche die Entwicklung eines „Flusses“ zwischen verschiedenen Maschinen oder „Einheiten“ darstellt, 4. ein PAC unterstützt de facto IT Standards, wie z. B. XML, SQL oder HTTP und 5. ein PAC verfügt über integrierte, modulare, skalierbare und flexible Hardware. Diese zum Teil bereits konkreten Anforderungen lassen noch immer hinreichend Spielraum für Interpretationen. Die Mehrzahl der untersuchten Beiträge über den PAC sind von Anbietern auf ihr System zugeschnitten – bzw. die generelle Definition von ARC wird verfeinert, um speziellen Systemen zu genügen. Hierdurch entsteht eine unübersichtliche Verständnisvielfalt, die im Rahmen dieses Artikels konsolidiert wird, um eine allgemeingültige Definition des PAC abzuleiten. Zusätzlich erschwerend wirken sich die unvollständige Darstellung der Automatisierungsdisziplinen und die Mischung aus Netzwerkprotokollen, Kommunikationsprotokollen, Programmiersprachen und Datenaustauschformaten unter dem Oberbegriff „IT-Standards“ aus. Der folgende Absatz gibt beispielhaft die Definition eines Herstellers wieder, welche einige über die Definition von ARC hinausgehenden Automatisierungsdisziplinen und -techniken einführt. 2.3 PAC-Anforderungen von Advantech Definitionen diverser Fachzeitschriften und Onlineforen basieren zumeist auf der ARC-Definition. Aufbauend auf den oben genannten fünf Grundanforderungen werden eigene, spezifische Definitionen erstellt, die auf ein entsprechendes Zielsystem zugeschnitten sind und dessen Merkmale einbeziehen [6]. Advantech beispielsweise erweitert die ARC Definition um: 36 1. einfache Anbindung an das ERP System 2. Verwendung von Standardhardware 3. integrierte Mensch-Maschine Schnittstelle Die genannten Punkte resultieren aus den bereits angebotenen Systemen von Advantech. Der ADAM-5550KW und der AMAX 2050KW basieren auf einem Windows CE Betriebssystem und Standard AMD Hardware. Zusätzlich bieten die Controller VGA Schnittstellen, um kleine Displays direkt an das Gerät anzuschließen. Um eine vollständige Definition der Anforderungen zu generieren, werden im Folgenden verschiedenen Literaturbeiträge zusammengefasst und dadurch um weitere Automatisierungsdisziplinen ergänzt. Zusätzlich werden neue benötigte Technologien beschrieben. Um weitere Anhaltspunkte für eine allgemeine Definition zu erhalten, werden zudem verschiedene Realisierungsmöglichkeiten in Betracht gezogen. 2.4 PAC-Realisierungsvarianten Den Herstellern stehen drei unterschiedliche Ansätze zur Entwicklung eines PACs zur Verfügung: 쐌 Entweder werden vorhandene IPC Lösungen um Funktionalitäten aus der SPS Welt erweitert oder 쐌 vorhandene SPS Lösungen werden um IPC-Funktionalitäten ergänzt und somit flexibler gestaltet oder 쐌 es erfolgt eine Neuentwicklung. Hierdurch lassen sich vorhandene Geräte kategorisieren und auf spezielle Merkmale untersuchen. Bei IPC-basierten PACs wird meist ein nicht echtzeitfähiges Standardbetriebssystem mit einer Standardhardware kombiniert (z. B. Windows CE) und zusätzlich eine SoftSPS installiert. Damit wird SPS Funktionalität und zumindest „weiche“ Echtzeitfähigkeit integriert. Das resultierende System kann zwar keine Antwortzeiten garantieren, aber für „genügend langsame“ Prozesse kann dies ausreichen. Bei SPS-basierten Lösungen werden neben der SPS Standard-IT-Protokolle, z. B. HTTP (Webserver), in Form von Modulen (Hardware oder Software) bereitgestellt. Das SPSübliche Echtzeitbetriebssystem wird beibehalten und somit „harte“ Echtzeitfähigkeit erreicht. Diese Kategorie stellt die Mehrheit der am Markt erhältlichen PACs dar. Die Neuentwicklungen decken meist spezielle Anwendungsgebiete ab, die auf einen definierten Markt abzielen. Ein Beispiel dafür ist der Compact Vision Controller von National Instruments. Das System besitzt Firewire-Ports zur Anbindung von Kameras. Spezielle Software ermöglicht die Bildverarbeitung direkt auf dem Gerät und im Feld. Auch daraus lassen sich wichtige Anforderungen ableiten. Diese fließen in Abschnitt 3 in die hier vorgestellte allgemeine PAC-Definition ein. 2.5 Schlussfolgerung Eine hinreichende Beschreibung zum Stand der Technik eines PAC ist derzeit nicht verfügbar. Unterschiedliche Hersteller definieren ihre Systeme entsprechend der verfügbaren Funkatp 3.2009 www.atp-online.de Automatisierungsgeräte tionen und der verwendeten Technik ihrer Geräte. Die ARCDefinition ist eine gute Basis, muss jedoch weiterentwickelt werden, um einen Anforderungskatalog für PACs zu erhalten. Es bedarf folglich einer klareren Definition. Erst dies erlaubt PACs untereinander sowie mit heutigen Standardsystemen vergleichen zu können. Im folgenden Abschnitt wird eine allgemeine PAC-Definition vorgeschlagen. 3. PAC Anforderungen Im Folgenden wird eine allgemeine PAC-Definition in Form eines Anforderungskatalogs zusammengestellt, der die fünf von ARC vorgegebenen Kategorien konkretisiert. 3.1 Automatisierungsdisziplinen Die erste und wohl wichtigste Kategorie zur Charakterisierung eines PAC sind die unterstützten Automatisierungsdisziplinen. Der PAC als interdisziplinäre Plattform soll mindestens zwei der folgenden Automatisierungsdisziplinen unterstützen. Eine wesentliche Automatisierungsdisziplin ist die binäre und digitale Logik, bekannt und meistens gelöst durch Kleinst-SPSn. Hier wird ein effizientes Einlesen, Verarbeiten und Ausgeben binärer Eingänge realisiert. Außerdem muss für viele Anwendungen in diesem Bereich harte Echtzeitfähigkeit garantiert werden. Zusätzlich sollte eine einfache Programmiersprache wie der Funktions- oder Kontaktplan zum Programmieren verwendet werden. Mittels Motion-Control werden Antriebe bzw. Achsen gesteuert. Eine typische Anwendung ist die digitale, softwarebasierte Regelung einer Achse. Beide bereits genannten Disziplinen kommen hauptsächlich in der Fertigungsautomatisierung und im Maschinenbau vor. Die Prozesssteuerung und -regelung wird zumeist durch verteilte Systeme (DCS) realisiert, welche analoge sowie binäre Ein- und Ausgänge gleichermaßen verarbeiten können. Charakteristisch ist hierbei eine zuverlässige und schnelle Abarbeitung der Signale, was z. B. durch Redundanzkonzepte erreicht wird. Darüber hinaus werden einige Automatisierungsdisziplinen in der ARC Definition nicht genannt. Dazu zählen unter anderem: Messungen, Datenaquirierung und Datenhaltung. Hierfür werden vorwiegend SCADA Systeme eingesetzt und die Steuerung wird lediglich als Brückenkopf zur Datenaufnahme verwendet. Ein PAC hingegen sollte Möglichkeiten zur eigenen Datenauswertung bereitstellen, wie z. B. Integrale oder Filter funktionen, bekannt von Softwaresystemen wie Matlab. Zur Datenhaltung muss der Steuerungsspeicher ausreichend groß sein und zusätzlich die Möglichkeit zur externen Speichererweitung bestehen. Eine weitere Disziplin ist die Visualisierung. Diese sollte auf dem System selbst und PC unabhängig ausgeführt werden. Hierfür kann z. B. eine VGA- oder DVI-Schnittstelle direkt am Gerät verwendet werden. Modulares Engineering und Wiederverwendung mit CoDeSys V3 G Für Automatisierungslösungen mit objektorientiertem Ansatz Für Applikationsingenieure der perfekte Einstieg in die objektorientierte Projektierung mit CoDeSys V3. Das Buch unterstützt Sie beim objektorientierten Herangehen an Automatisierungsaufgaben und vermittelt Ihnen die Konzepte sowie die Vorteile und Grenzen im Vergleich zum funktionalen Ansatz. To UER paktue l SC HE le INU N NE WISSEN für die ZUKUNFT Der besondere Nutzen ist die Kombination von IEC 61131-3 Programmierung und objektorientierten Konzepten, die in der Anwendung das Engineering erleichtern und damit die Wiederverwendbarkeit steigern. Zudem wird die Visualisierung ebenso thematisiert wie die Schnittstelle zum Feldbus und zum Prozess. Alle Themen sind anwendungsnah anhand eines praxisrelevanten, fertigungstechnischen Prozessbeispiels aufbereitet. Diese Darstellungsart des Themas ist völlig neu. Alle Beispiele sind auf der CD-ROM enthalten, so dass die Schritte selbst erstellt und anhand einer Simulation getestet werden können. Gleich anfordern – per Post oder per Fax: +49 / 201 / 820 02-34 Ja, ich bestelle gegen Rechnung 3 Wochen zur Ansicht Firma/Institution Vorname/Name des Empfängers ___ Ex. Modulares Engineering und Wiederverwendung mit CoDeSys V3 1. Auflage 2008 für € 49,- zzgl. Versand Die bequeme und sichere Bezahlung per Bankabbuchung wird mit einer Gutschrift von € 3,- auf die erste Rechnung belohnt Auf CD-ROM + mit allen Beispielen und Codes als Projekt 1. Auflage 2008, 188 Seiten, Broschur ISBN: 978-3-8356-3105-2 Vulkan Verlag GmbH Versandbuchhandlung Postfach 10 39 62 45039 Essen Garantie: Dieser Auftrag kann innerhalb von 14 Tagen bei der Vulkan Verlag GmbH, Versandbuchhandlung, Postfach 10 39 62, 45039 Essen schriftlich widerrufen werden. Die rechtzeitige Absendung der Mitteilung genügt. Für die Auftragsabwicklung und zur Pflege der laufenden Kommunikation werden Ihre persönlichen Daten erfasst und gespeichert. Mit dieser Anforderung erkläre ich mich damit einverstanden, dass ich per Post, Telefon, Telefax oder E-Mail über interessante Verlagsangebote informiert werde. Diese Erklärung kann ich jederzeit widerrufen. Straße/Postfach, Nr. Land, PLZ, Ort Telefon Telefax E-Mail Branche/Tätigkeitsbereich Bevorzugte Zahlungsweise Bankabbuchung Bank, Ort Bankleitzahl Datum, Unterschrift Kontonummer Rechnung Automatisierungsgeräte mat. Ebenso sind abgewandelte Formen einsetzbar, wie z. B. High-Graph oder CFC von SIEMENS oder MSFC, bekannt aus der Automobilindustrie. Generell ist auch eine andere Programmierung möglich, da IEC 61131-3 Konformität beachtlicherweise keine Anforderung für PACs darstellt. 3.4 Unterstützung von „IT-Standards“ Bild 2: Ethernet Protokolle. Mit den genannten Disziplinen können die meisten Automatisierungsaufgaben auf einem Controller gelöst werden – unabhängig von der Domäne und unabhängig von PC Systemen. 3.2 Interdisziplinäre Entwicklungsumgebung Um eine einfache Entwicklung über die Automatisierungsdisziplinen hinweg zu ermöglichen, benötigt der PAC eine einheitliche und interdisziplinäre Engineeringumgebung. Das Engineering des PAC soll auf einer einzigen Entwicklungsplattform geschehen. Dazu muss vom Hersteller eine integrierte, interdisziplinäre und flexible Entwicklungsplattform bereitgestellt werden. Diese Plattform soll aus einer datenbankähnlichen Verzeichnisstruktur [4, 5, 6] bestehen, in der alle globalen Datenpunkte gespeichert sind. Dies erhöht die Übersichtlichkeit und vereinfacht das interdisziplinäre Engineering. Eine PAC-Entwicklungsumgebung soll, wenn die Visualisierung einen globalen Datenpunkt verändert, diesen in allen anderen Bereichen der Entwicklungsumgebung automatisch auf den aktuellen Stand bringen. Neue Datenpunkte müssen ebenfalls über die gesamte Plattform hinweg verteilt und aktualisiert werden können. 3.3 Programmiersprache für das Entwickeln eines Kontrollflusses Zusätzlich zur Entwicklungsumgebung soll ein PAC eine spezielle Programmiersprache verwenden, welche die Entwicklung eines Kontrollflusses der zu steuernden Maschinen oder Fabrikeinheiten ermöglicht. Hierfür bietet die IEC 61131-3 mit der Ablaufsprache bereits ein geeignetes For- 38 Das Engineering eines PAC soll u. a. die Anbindbarkeit an ein übergeordnetes ERP System ermöglichen. Hierfür sollen standardisierte Protokolle verwendet werden. Mittlerweile haben sich einige „IT-Standards“ als hilfreich für die Automatisierung von Anlagen und Maschinen erwiesen. Eine SPS verwendet typischerweise proprietäre Protokolle, welche eine interdisziplinäre Aufgabenbewältigung erschweren. Eine Programmiersprache, die üblicherweise zur Datenbankanbindung verwendet wird, ist SQL. Diese wird zur Manipulation, Erstellung und Auswertung von Datenpunkten verwendet. Dafür wird eine ODBC Schnittstelle zur Datenbank benötigt. Insbesondere für die Datenhaltung ist dieses Feature für PACs interessant. PACs sollten folglich eine ODBC Schnittstelle integrieren, um auf dem Gerät gespeicherte Daten mit Hilfe von SQL auswerten zu können. Eine Technik zum gesicherten und effizienten Datenaustausch bietet XML. Mit Hilfe von XML können Engineeringdaten von Programmiersystem zu Programmiersystem transportiert und portiert werden. Ein zugrundeliegendes XMLSchema stellt die syntaktische Korrektheit der Daten sicher. PAC Entwicklungsplattformen sollten die Möglichkeit zum Austausch von Daten durch XML bieten. Die wichtigste Schnittstelle für den PAC ist Ethernet, das zahlreiche Möglichkeiten zum Datenaustausch bietet, siehe Bild 2. Die meist verwendeten Protokolle in PACs sind TCP/IP und die darauf basierenden HTTP, FTP und SMTP. Durch deren Verwendung wird die Kommunikation mit dem ERP stark vereinfacht. Proprietäre Protokolle werden nicht mehr benötigt und zusätzlich wird in einem gewissen Maße Herstellerunabhängigkeit erreicht. Dies stellt einen Investitionsschutz für den Anwender dar. 3.5 Hardware Neben den bisher genannten Softwareanforderungen lassen sich eine Reihe von Hardwareanforderungen an einen PAC formulieren. Einerseits soll der PAC so robust wie eine SPS sein, andererseits so flexibel und skalierbar wie ein IPC. Um Flexibilität sicherzustellen, soll der PAC zudem modular aufgebaut sein. Dadurch wird dem Nutzer die Möglichkeit gegeben, das System schnell und einfach zu erweitern oder auf neue Bedürfnisse anzupassen. Die Geräte von GE Fanuc bieten beispielsweise Hot-Swappable Module und somit einfache Erweiterbarkeit während des Betriebs. Eine weitere Anforderung ist Echtzeitfähigkeit, welche durch unterschiedliche Maßnahmen erreicht werden kann. Eine Möglichkeit besteht in der Verwendung von Mikrocontrollern mit Echtzeitbetriebssystem. Aber auch andere Ansätze, z. B. spezielle Hardwaremaßnahmen, können in Betracht gezogen werden. Einige Hersteller verwenden Standard MS Windows CE mit SoftSPS, wobei hier die Echtzeitfäatp 3.2009 www.atp-online.de Automatisierungsgeräte higkeit auf bestimmte Problemstellungen begrenzt ist und im Wesentlichen durch „genügend Performance“ erreicht wird. Echtzeitfähigkeit ist nicht nur für das Gerät selbst wichtig, sondern muss für das gesamte System durchgängig realisiert werden. Hierfür werden industrielle Bussysteme benötigt. Standard Ethernet mit CSMA/CD Buszugriffsverfahren kann Echtzeit nicht garantieren. Wenn also Ethernet verwendet werden soll, muss zusätzlich ein echtzeitfähiges Busprotokoll, z.B. ProfiNet, eingesetzt werden. Prozesssteuerung Regelung Antriebe Antriebe Antriebe Ethernet Ethernet Schnittstelle Schnittstelle Ethernet Schnittstelle Bewegungssteuerung OPC, SQL, XML Logik Modulare, Modulare, flexible flexibleund undskalierbare skalierbare Hardware Hardware Modulare, flexible und skalierbare Hardware 4. Ergebnis: eine allgemeine PAC-Definition 4.1 Anforderungen an einen PAC Messauswertung Datenakquise Visualisierung Ausgehend von der ursprünglichen Bild 3: Zusammenfassung der PAC-Funktionalität. PAC-Definition wird die Vielzahl der diskutierten Funktionen im Folgenden anhand eines Anforderungskatalogs zu einer PAC-Definition wichtig? Repräsentative Marktanforderungen liegen in der zusammengefasst. Diese Anforderungen müssen nicht alle Literatur nicht vor. Unter der Annahme, dass die vermarktevollständig umgesetzt werden – eine entsprechende Priori- ten PACs bereits auf Marktanforderungen zugeschnitten sind, verfolgten die Autoren den Ansatz, die bereits umgesetzten sierung erfolgt im nachfolgenden Abschnitt. Anforderungen quantitativ auszuwerten und qualitativ zu priorisieren. Namhafte Hersteller wie Rockwell oder SchneiDefinition eines PAC: 1. Ein PAC unterstützt mindestens 2 der folgenden Automati- der Electric haben PACs bereits erfolgreich in ihre Produktlisierungsdisziplinen: diskrete Logik, Motion/Drive-Control, nien integriert – von den Eigenschaften dieser Geräte ausgeProzesssteuerung bzw. -regelung, Datenakquise, Daten- hend, lassen sich ihre Anwendungsgebiete und -domänen haltung, Messwertverarbeitung und PC-unabhängige ableiten. Zu diesem Zweck wurden 23 verschiedene Geräte von 11 Visualisierung. 2. Ein PAC besitzt eine interdisziplinäre und einheitliche Ent- Herstellern für einen Vergleich ausgewählt und die Integration der definierten Anforderungen untersucht. Dies wicklungsumgebung. 3. Die PAC-Entwicklungsumgebung unterstützt eine Pro- bildet die Grundlage für eine Priorisierung. Die Produktpalette reicht von Micro-PAC bis hin zu High-End Geräten. grammiersprache zur Definition des Kontrollflusses. 4. Ein PAC unterstützt mehrere der folgenden „IT-Standards“: Einige Hersteller bieten lediglich ein oder zwei PAC-Modelle Die Programmiersprache SQL, das Datenaustauschformat an. Außerdem entsteht eine Varianz zwischen bereits häufig XML, OPC als Kommunikationsprotokoll und mehrere verwendeten PACs, bspw. Rockwell ControlLogix, und neuen Netzwerkprotokolle, z.B. UDP/IP, TCP/IP, HTTP, FTP oder Geräten, bspw. Schneider Modicon M340. Hinzu kommen die auf spezielle Anwendungsgebiete ausgerichteten PACs, SMTP. 5. Die Hardware eines PAC sei robust, kompakt, skalierbar, diese werden jedoch zur quantitativen Auswertung der modular, echtzeitfähig und bietet Unterstützung für Definition nicht in Betracht gezogen. Nach Anwendung dieser Auswahlkriterien verbleiben 18 PACs von 8 Herstellern, Ethernet und industrielle Feldbusse. welche der Definition weitestgehend entsprechen. Tabelle 1 zeigt die anonymisierte Auswertung der verschieDie Anforderungen sind zusammenfassend in Bild 3 denen Anforderungen. Da der PAC PC-unabhängig sein soll, dargestellt. werden nur die Funktionen in Betracht gezogen, die direkt auf dem Controller realisiert sind. 4.2 Priorisierung der Anforderungen Tabelle 1 verdeutlicht, dass einige der Anforderungen Die vorgestellte allgemeine Definition der PAC-Anforderun- durchgängig implementiert werden. Hierzu zählt diskrete gen beschreibt verschiedene Techniken, Anwendungsberei- Logik oder TCP/IP. Andere Anforderungen werden nur von che und Eigenschaften. Doch was ist für den Anwender sehr wenigen Geräten direkt auf dem Controller realisiert. www.atp-online.de atp 3.2009 39 Automatisierungsgeräte 4 Industrielle Feldbusse 8 18 17 18 18 Ethernet Robust/kompakt 15 Echtzeitfähigeit Skalierbarkeit 10 8 Modularität 5 Hardware 3 5 HTTP 17 FTP XML 3 5 SMTP OPC 18 18 SQL UDP TCP PAC Programmiersprache IT-Standards und Technologien PAC Entwicklungsumgebung 15 11 10 13 15 5 Visualisierung 8 5 Prozesssteuerung Messauswertung Diskrete Logik Regelungen 16 14 18 Datenakquise/Datenhaltung Direkt auf Controller realisiert Benötigt einen PC Muss von Nutzer implementiert werden Genannt in Werbung, jedoch keine allgemeinen Informationen über Realisierung gefunden Motion-Control Automatisierungsdisziplinen Tabelle 1: Anzahl der Funktionsrealisierungen in PACs. 2 2 1 2 1 2 1 Hierzu zählen SQL und XML, die jeweils auf weniger als 25 % der Geräte integriert sind. Der hier verfolgte Priorisierungsansatz erfolgt durch einen Vergleich der Häufigkeit der Implementierungen auf den Geräten. Bild 4 stellt die Ergebnisse graphisch dar. Die abgebildete Prioritätenhierarchie kann bei vergleichenden Betrachtungen zwischen verschiedenen Gerätetypen sinnvoll genutzt werden. Häufig implementierte Funktionen lassen auf breite Relevanz für den Anwender schließen und besitzen demzufolge eine hohe Priorität. Selten implementierte Features hingegen deuten auf Spezialanwendungen hin und besitzen gemäß der hier vorgeschlagenen PAC-Definition nur eine niedrige Priorität für den breiten Einsatz. Ca. 80 % aller SPS-üblichen Aufgaben können mit weniger als 20 Kontaktplan-Instruktionen gelöst werden [7]. Für solche Aufgaben wird die Micro-SPS weiterhin Anwendung finden. Für zunehmend komplexere Aufgaben werden jedoch leistungsfähigere Systeme benötigt, um neben der performanten Abarbeitung der Automatisierungsaufgaben den Gesamtaufwand in allen Lebenszyklusphasen und über die gesamte Automatisierungspyramide hinweg zu verringern. Moderne SPSn leisten dabei schon heute gute Dienste – es werden Systeme benötigt, die eine einfache Handhabung gewährleisten, einen Großteil der Aufgaben abdecken und eigenständig eine gewisse Datenmenge halten und verarbeiten können. Die SPS wird hinsichtlich dieser Funktionalität gerne unterschätzt. Moderne SPSn bieten bereits häufig Motion-Control-Funktionalität oder haben eine integrierte Fließpunkteinheit, wodurch auch analoge Prozesssignale 4.3 Vergleich zur SPS performant verarbeitet werden können. Das Angebot reicht Da der PAC als evolutionärer Nachfolger der SPS vermarktet von Mikro-SPSn bis hin zu High-End Steuerungen. Im Gegenwird, liegt es nahe, diese Technologie mit heutigen SPSn zu satz zur klassischen Definition einer SPS als Binärverarbeivergleichen. tungssystem bieten moderne SPSn heute bereits nahezu identische Funktionalität wie ein PAC. Ein interessanter Aspekt ist ein Verx < 25% Priorit ät44 Priorität gleich der Leistungsfähigkeit. Die unter(sehr niedrig) suchten PACs verwenden Mikrocontroller mit einer durchschnittlichen Taktfrequenz von 400 MHz. Dies liegt im XML, SQL Bereich von High-End SPSn. Bezüglich der Speicherkapazität besitzt ein PAC typischerweise 100 MB Arbeitsspeicher, 25% < x < 50% Priorit ät33 Priorität Skalierbarkeit, wohingegen der Speicher von HighHTTP (Webserver), (niedrig) SMTP (Mailserver), Datenaquise Datenaquise End SPSn mit ca. 4–16 MB vergleichsweise niedrig ausgestattet ist. Dieser 50% < x < 75% Priorit ät22 Priorität FTP, Visualisierung, FTP, Visualisierung, Aspekt rückt jedoch immer weiter in Prozesssteuerung, (mittel) (mittel) PAC PAC Engineering Umgebung Umgebung den Hintergrund, da viele SPSn und PACs Erweiterungsmöglichkeiten für x > 75% Priorit ät11 Priorität Industrielle IndustrielleFeldbusse, Feldbusse,Ethernet, Ethernet,Echtzeitf Echtzeitfähigkeit, ähigkeit, externen Speicher bieten und Speicherrobuste und kompakte kompakte Struktur, Modularität, Modularit äOPC, t, OPC, UDP, UDP, (hoch) TCP, TCP, PAC PACProgrammiersprache, Programmiersprache,Messwertverarbeitung, Messwertverarbeitung,Logik, Logik, platz günstig verfügbar ist. Regelung, Bewegungssteuerung Bewegungssteuerung Die für SPSn und DCSn relevante IEC 61131-3 stellt für PACs keine generelle Bild 4: Priorisierte Features und Techniken der PAC. 40 atp 3.2009 www.atp-online.de Automatisierungsgeräte Zusammenfassung und Ausblick PAC PAC PAC Die verschiedenen Automatisierungsdisziplinen, Technologien, Geräte und die einzelnen Lebenszyklusphasen werProzessden aufgrund komplexer Automatisierungsaufgaben, steiindustrie gendem Zeitdruck und dem zunehmenden Ingenieurmangel immer weiter zusammenwachsen. Der PAC ist ein Ergebnis dieser Anforderungen und ist somit ein natürlicher Entwicklungsschritt zur Harmonisierung bislang domänenPAC spezifischer Technologien. Der vorliegende Beitrag gibt Fertigungseine allgemeine Definition des Begriffes „PAC“. Hierzu wurBewegungsden die ursprünglichen ARC-Definition, Interpretationen industrie steuerung der Fachliteratur sowie eine Untersuchung verfügbarer PAC-Produkte zugrunde gelegt. Die hier vorgestellte PACDefinition ermöglicht eine bessere Vergleichbarkeit zwischen PAC-Produkten und klassischen Steuerungsgeräten Bild 6: Der PAC als Technologiebrücke. und erleichtert sowohl Anwendern als auch Anbietern die Navigation in einer komplexen Produktlandschaft. Einige vorhandene und gut erprobte Techniken, wie z. B. Zusammenfassend lässt sich feststellen, dass der PAC als industrielle Feldbusse, rücken dabei tendenziell in den Hin„leistungsfähige und kommunikationsfreudige High-End- tergrund. Als Standardkommunikationsbus wird hauptSPS“ charakterisiert werden kann. Die rein technologische sächlich Ethernet verwendet in Kombination mit ProtokolDifferenz zu modernen High-End-SPSn ist inhaltlich nur len wie z.B. ProfiNet oder EtherCat, um zumindest „weiche“ gering. Die zusätzlichen Kommunikationsschnittstellen Echtzeit zu garantieren. Dadurch kann ein Austausch von werden hauptsächlich zur Anbindung an in der Automati- Daten direkt über das normale Netzwerk stattfinden. Bild 7 sierungspyramide höher liegende Systeme verwendet. Des beschreibt den PAC als Kommunikationszentrale zwischen Weiteren ist der PAC bei Kompaktanwendungen mit lokaler prozessnahen und prozessfernen Komponenten. Visualisierung und Ausführung klassischer prozessferner Zusätzlich können aus der IT längst bekannte und verVerarbeitungsfunktionen wie Beobachten, Optimieren und wendete Technologien, Webserver, Mailserver oder Datenbei der Datenauswertung direkt im Gerät vorteilhaft. Pro- bankschnittstellen, auch für die Automatisierungstechnik zessnahe und prozessferne Funktionen rücken somit verwendet werden. Durch Integration von kleinen Datenzusammen. Der Nutzen eines PAC erschließt sich erst aus banken, realisiert durch bspw. MS SQL Mobile Server, köneinem solchen Einsatzgebiet. Im Umkehrschluss ist der nen kleinere Datenmengen direkt auf der Steuerung gespeiEinsatz eines PACs innerhalb eines klassischen Automati- chert und verarbeitet werden. Dadurch nähert sich der PAC sierungssystems nicht immer sinnvoll. dem ERP System an, die Kommunikationslücke beginnt sich Der PAC stellt eine Verbindung verschiedener verfügba- zu schließen. Eine Kommunikation kann über die beschrierer Techniken dar und bezieht seine Innovation aus deren benen Protokolle und Technologien ohne teure Middleware Kombination (siehe Bild 6). Insofern stellt der PAC selbst oder proprietäre Protokolle hergestellt werden. Weitere Technologien wie WLAN werden künftig in den keine neue Technologie dar. Während SPSn, DCSn, Motion Controller und IPCs bisher domänenspezifisch separierte PAC Einzug halten und sowohl Planung als auch Betrieb Lösungen darstellten, kann ein PAC domänenübergreifend von Automatisierungstechnik weiter vereinfachen. Die eingesetzt werden. Er bildet dabei nicht nur die technologi- Zukunft bleibt spannend. sche, sondern auch eine mentale Brücke zwischen den AnwendungsgebieBetriebsebene Betriebsebene Server Server PCs /Datenbank Datenbank PCs Betriebsebene ServerPCs PCs/ /Datenbank PCsPCs PC: ten. Dies trägt der technologischen Ethernet, SQL, XML, flexibel, skalierbar, etc. Weiterentwicklung der SPS Rechnung, deren heutiger Funktionsumfang für Kommunikationsloch -Keine Standards weitergehende Anwendungen durch-Teure Middleware -Langsam aus genügen würde, jedoch aus histo-Hoher Wartungsaufwand rischen Gründen dafür nicht immer wahrgenommen wird. System System bzw. System- --bzw. bzw. SPS SPS DCS //IPC / IPC SPS///DCS DCS IPC Neu ist die Integration von IT-StanZellebene Zellebene SPS: Zellebene Industrielle Feldbusse, dards. Standard- und Micro-SPSn verEchtzeit, IEC 61131 -3, Steuerungs Steuerungs und und wenden zumeist keine IT-Standards Modularitt, robust, kompakt, Steuerungs - und SPS SPS / / RTU RTU / NC / NC / CNC / CNC SPS / RTU / NC / CNC etc. Prozessebene Prozessebene Prozessebene zum Datenaustausch. Bei High-EndSPSn werden allerdings ebenfalls Sensoren Sensoren Aktoren Aktoren immer mehr dieser Standards inteBild 7: Der PAC adres-Temperatursensor -Temperatursensor -Antriebe -Antriebe griert, wodurch sich in diesem Gebiet -Widerstand -Widerstand -Ventile siert die Kommunikati-Etc. -Etc. -Etc. onslücke. SPS und PAC weiter annähern. www.atp-online.de atp 3.2009 41 Automatisierungsgeräte FUP 10 Proprietäre Sprachen KOP 8 ST 6 C# 4 2 C++ AS 0 AWL C Java / Java Script PHP Perl Visual Basic Bild 5: Verteilung der verwendeten Programmiersprachen. Anforderung mehr dar und rückt in den Hintergrund. Die meisten PACs nutzen jedoch nach wie vor diesen Standard und stellen zumindest die drei Sprachen Funktionsplan, Kontaktplan und Strukturierter Text zur Verfügung. Andere lassen sich nur noch in Hochsprachen, z. B. VB.NET, C++ oder C#, programmieren. Hierdurch lassen sich auch auf Entwicklerebene komplexe Aufgaben mit einem Gerät, ohne die zusätzliche Verwendung von PCs, realisieren. Inwiefern sich dieser Ansatz durchsetzen wird, bleibt derzeit offen. Ein ebenfalls vielfach verwendeter Ansatz ist die Verwendung einer proprietären Programmiersprache. Fast die Hälfte der Geräte nutzt eine herstellerspezifische Programmiersprache. Bild 5 zeigt die Verteilung der verwendeten Programmiersprachen über die untersuchten Geräte. Trotz Abkopplung von der IEC61131 ist der Schwerpunkt auf FUP, KOP und ST unübersehbar. Ein vielfach beschriebener Vorteil des PAC liegt in der engen Integration von Hardware und Software. Während bei SPSn zumeist nur Grundfunktionen zur Programmierung der Hardware zur Verfügung stehen, bieten manche PACs die Möglichkeit, Applikationen direkt auf der Hardware unter Verwendung der CPU oder deren Timer zu entwickeln. Damit wird das System offener, der Nutzer kann verschiedene Tasks unabhängig vom zyklischen Verhalten entwickeln. Bekannte Funktionen aus Echtzeitbetriebssystemen, z. B. Semaphoren oder Queues, welche auf SPS-Plattformen nur eingeschränkt zugänglich sind, können zur Lösung komplexer Automatisierungsaufgaben verwendet werden. Der Trend zur Öffnung der Hardware wird jedoch auch bei SPSn ersichtlich. Es gibt bereits SPSn, welche über eine Engineeringumgebung mit eben den beschriebenen Funktionen verfügen. Als tatsächliche Abgrenzung zwischen SPS und PAC verbleibt hauptsächlich die Integration von „IT-Standards“. In der SPS Welt haben sich bislang nur sehr wenige „IT-Standards“ etabliert. Webserver werden meist nicht angeboten, Daten- 42 bankanbindungen werden über proprietäre Protokolle oder OPC realisiert. Das bedeutet, dass die Verbindung zwischen prozessnahen und prozessfernen Komponenten entweder über teure Middleware oder proprietäre Protokolle realisiert werden muss, wodurch die Automatisierungsaufgaben an zusätzlicher Größe und Komplexität gewinnen. Hier bietet der PAC einen entscheidenden Vorteil. Durch die Standardisierung der IT Protokolle ist ein ERP System einfacher an die prozessnahe PAC anbindbar. Dies ist ein natürlicher Schritt, der sich früher oder später auch bei SPSn durchsetzen wird. Ein besonders propagierter Vorteil des PAC gegenüber der SPS liegt in der anwendungsübergreifenden Einsetzbarkeit. Sowohl Anlagen als auch Maschinen können mit PACs automatisiert werden. Dies ermöglicht einen flexiblen Einsatz sowohl in der Prozess- als auch in der Fertigungsindustrie. Während SPSn und DCSn als domänenspezifisch betrachtet werden, wurde der PAC explizit mit domänenübergreifender Intention entwickelt. Diese Untersuchung zeigt jedoch, dass die tatsächliche technologische Differenz zu modernen High-End-SPSn inhaltlich nur gering ist. Literatur [1] Iversen, Wes: PACs gain momentum. Automation World 02/2008. [2] ARC advisory group: Programmable Logic Controller World wide Outlook 2008. 2008. [3] www.elcomgroup.cz; Programmable Automation Controller [4] Humphrey, David W., ARC advisory group: Kleiner Unterschied mit großer Wirkung. Elektro Automation 01/2005. [5] Crump, David; Hill, David, Opto 22: Networked automation: What’s inside a PAC. The Industrial Ethernet Book 10/2007. [6] Piovesan, Billy, Advantech: Programmable Automation Controller find their niche... Everywhere! White paper. [7] Walter, Todd: Welcome PAC - Moving on to the next generation controller. ISA 01/2005. Manuskripteingang: 3.11.08 Dipl.-Ing. (FH) Mario Schwartz (24) ist Mitarbeiter der Gruppe „Automation Engineering“ in der Abteilung „Industrial Software and Applications“ des ABB Forschungszentrums Deutschland. Sein Hauptinteresse gilt der Entwicklung neuer und innovativer Automatisierungskonzepte, unter anderem im Bereich sicherheitsgerichteter Steuerungen. Adresse: ABB AG, Forschungszentrum, Wallstadter Str. 5, D-68526 Ladenburg, Tel. +49 6203 71-6266, Fax -6253, E-Mail: [email protected]. Dr.-Ing. Rainer Drath (37) ist Senior Principal Scientist in der Gruppe „Automation Engineering“ in der Abteilung „Industrial Software and Applications“ des ABB Forschungszentrums Deutschland. Sein Hauptinteresse gilt der Entwicklung neuer Konzepte und Methoden zur Verbesserung des Engineerings von Automatisierungssystemen. Er wirkt maßgeblich an der Entwicklung und Normierung von Datenaustauschformaten wie CAEX und AutomationML mit. Adresse: ABB AG, Forschungszentrum Deutschland, Wallstadter Str. 59, D-68526 Ladenburg, Tel. +49 6203 71-6471, Fax -6253, E-Mail: rainer.drath@de. abb.com. atp 3.2009 www.atp-online.de
