SPS-Programmierung
Das Prinzip der 'Areas of Responsibility'
Automatisierungsprojekte werden zunehmend komplexer und aufwendiger. Der effizienten Zusammenarbeit der Programmierer unterschiedlicher Disziplinen kommt daher künftig eine zentrale Bedeutung zu.
Seit Jahrzehnten wird im Automatisierungsbereich gemäß dem internationalen Standard IEC 61131-3 programmiert. Entsprechende Tools der unterschiedlichen Hersteller, welche die Struktur dieser Norm repräsentieren, erlauben dem Anwender die einfache Entwicklung applikationsspezifischer Automatisierungslösungen. Vergleicht man ältere mit aktuellen Lösungen, ist sofort ersichtlich, dass ihre Komplexität aufgrund der Integration von Technologien wie der funktionalen Sicherheit (Safety), Visualisierungskonzepten oder verschiedenen Programmiersprachen außerhalb der IEC 61131-3 deutlich gestiegen ist. Aus diesem Grund müssen in einem Projektteam immer mehr Disziplinen beherrscht und umgesetzt werden. In der Regel arbeiten deshalb heute unterschiedliche Programmierer parallel am gleichen (Teil-)Projekt und oftmals in verschiedenen Gewerken. Die Teammitglieder führen die einzelnen Ergebnisse dann an festgelegten Zeitpunkten zu einem Gesamtprojekt zusammen. Zu diesem Zweck greifen sie häufig auf marktübliche Versionsverwaltungs-Werkzeuge wie Subversion oder GIT zurück.
Konfliktsituation beim Zusammenführen von Änderungen verschiedener Projektmitarbeiter.
© Phoenix ContactBei herkömmlichen Automatisierungs-Tools werden die Projekte gemäß der in der IEC 61131 beschriebenen Hierarchie in Ordnerstrukturen abgelegt und in dieser Form in die Versionsverwaltungs-Werkzeuge übertragen. Zwar lassen sich auch hier Rechte auf einzelnen Objekten vergeben; Änderungen an einem benutzersichtbaren Objekt ziehen allerdings meist für den Anwender nicht nachvollziehbare Modifikationen in allen Ordnerstrukturen nach sich. Das widerspricht zum einen dem Prinzip der Rechte-Abgrenzung. Zum anderen können dadurch selbst Tools wie GIT keinen verlässlichen Manipulationsschutz bieten. Darüber hinaus ist es möglich, dass konkurrierende Versionen mit unterschiedlichen Änderungen abgespeichert sind.
Um diese grundlegenden Probleme zu lösen, bedienen sich die Entwickler von Phoenix Contact Software eines militärischen Grundsatzes: Die so genannte ‚Area of Responsibility‘ teilt die geografischen Zuständigkeitsbereiche strikt auf definierte Kommandostellen auf. In jedem der Bereiche sorgt die Struktur wegen der festgelegten Befugnisse für kurze Reaktionszeiten. Weniger Kommunikationsschnittstellen erhöhen die Effizienz in der Ausführung, während die Begrenzung der Zuständigkeit auf eine Person Missverständnissen vorbeugt und so zu minimalen Fehlerwahrscheinlichkeiten führt.
Die Aufteilung der Ordnerstruktur nach Zuständigkeiten ermöglicht ein klares Rechtemanagement von der Projekt-Ebene bis in die IT-Ebene.
© Phoenix ContactWie sieht nun die Umsetzung des Ansatzes in der adaptiven Engineering-Software PC Worx Engineer aus, die wesentlicher Bestandteil der neuen, offenen Steuerungsplattform PLCnext Technology von Phoenix Contact ist? Der Projektmanager weist den Entwicklern in gewohnter Weise die Verantwortlichkeiten für die einzelnen Applikationsteile zu. Anschließend legt PC Worx Engineer die Ordnerstruktur des Projekts gemäß den vergebenen Zuständigkeiten an. Nimmt ein Entwickler jetzt Änderungen am Programm vor, werden diese von der Software nur in seinem Bereich der Ordnerstruktur durchgeführt. Die restlichen Teile des Gesamtprojekts bleiben unberührt. Obwohl diese Vorgehensweise für den Anwender nicht wahrnehmbar ist, eröffnet eine solche Ordnerstruktur eine klare Abgrenzbarkeit. Von der Ordnerebene (IT-Administrator) bis zum Entwicklungs-Werkzeug (Projektmanager) lassen sich Rechte auf diese Weise einfach und eindeutig zuweisen.
Möchte das Projektteam ferner zum Beispiel GIT als Versionsverwaltungstool verwenden, kann die Software die nach klaren Zuständigkeiten erzeugte Ordnerstruktur einzeln signieren. Durch das Zusammenspiel dieser Mechanismen können auf jeder Ebene Manipulationen erkannt sowie Zugriffsrechte durchgesetzt werden. Phoenix Contact nutzt die beschriebenen Eigenschaften zum Beispiel für den in der Engineering-Software integrierten Safety-Editor. Deshalb muss der Anwender keine Rechtetrennung über verschiedene Software-Tools sicherstellen. Der Safety-Programmierer kann folglich ebenso einfach vom Safety- in den IEC-61131-Editor springen wie er einen Tab-Wechsel im Browser vollzieht.
Auf der Grundlage der ‚Areas of Responsibility‘ stellt die Engineering-Software zudem intelligente Systemfilter zur Verfügung. Diese Filter erleichtern die Handhabung der Software, indem sie dem Entwickler lediglich die Elemente anbieten, die er für die jeweilige Aufgabe benötigt. Dabei kann es sich entweder nur um die eHMI-Toolbox für den Entwickler der Visualisierungslösung oder die Programm-Organisations-Einheiten (POE) für den Schweißzangen-Spezialisten handeln. Der Verzicht auf die nicht erforderlichen Funktionen reduziert die Komplexität und minimiert so das Fehlerrisiko.
Aktivierung zusätzlicher Funktionen
Die Idee, dem Anwender lediglich die für seine Aufgabenstellung notwendigen Bereiche zugänglich zu machen, hat die Entwickler von Phoenix Contact Software nicht nur zu den ‚Areas of Responsibility‘ inspiriert. Das Lizenzmodell baut auf dem gleichen Konzept auf. In diesem Umfeld war es dem Entwicklungsteam wichtig, ein klares Modell zu kreieren sowie dem Anwender den schnellen Einstieg in das Engineering zu ermöglichen. Das bedeutet konkret: Die Basisversion des Engineering-Tools ist kostenfrei erhältlich und umfasst in dieser Ausprägung bereits die wesentlichen Funktionen, um eine einfache Automatisierungslösung zu erstellen. Dazu gehören neben dem obligatorischen IEC-61131-3-Editor mit den Sprachen Strukturierter Text (ST), Funktionsbausteinsprache (FBS), Kontaktplan (KOP) sowie der Ablaufsprache (AS) unter anderem der integrierte eHMI-Editor, der die grundlegenden Funktionen zur Web-Visualisierung bereitstellt. Außerdem beinhaltet das Lizenzmodell sämtliche erforderlichen Funktionen zur Konfiguration und Diagnose der Peripheriekomponenten. Abhängig von den Anforderungen und eigenen Präferenzen lassen sich darüber hinaus zusätzliche Funktionen über so genannte ‚Funktions-Add-ins‘ aktivieren. Zukünftig werden zum Beispiel Safety-Funktionen, erweiterte eHMI-Features wie Alarming und Trending sowie die Programmiersprachen SFC+ (Sequential Function Charts) und C# verfügbar sein. Als besonders interessant erweist sich für viele Anwender die Möglichkeit, über das Funktions-Add-in C# beispielsweise in Microsoft Visual Studio Programme und Funktionen in der Hochsprache zu erzeugen und sie anschließend in ‚PC Worx Engineer‘ zu importieren. Auf diese Weise lassen sich Kommunikationsaufgaben deutlich eleganter als mit klassischen IEC-61131-Sprachen umsetzen.
Über das ‚Software Development Kit‘ (SDK) haben ambitionierte Anwender ferner die Möglichkeit, eigene Funktions-Add-ins zu generieren. Durch deren Nutzung ergeben sich zahlreiche Vorteile: So kann der Maschinenbauer zum Beispiel eine Konfigurationsmaske für alle wichtigen Projektparameter erstellen. Somit muss der Inbetriebnehmer nicht mehr nach den jeweils notwendigen Funktionsbausteinen suchen oder Konfigurationsdateien modifizieren. Dem Einfallsreichtum sind hier keine Grenzen gesetzt.
Hinter dem geschilderten Konzept steht letztlich folgender Ansatz: Der Anwender muss künftig lediglich für die Leistungen bezahlen, die er tatsächlich zur Realisierung seiner Automatisierungsaufgabe benötigt. Daher kann das Engineer-Tool auch in der Basisversion sämtliche Projekte öffnen, selbst wenn diese mit zusätzlichen Funktions-Add-ins generiert worden sind. Das Projekt lässt sich dann vor Ort auf die Steuerung laden und diagnostizieren. Allerdings sind außerhalb der Standard-Funktionen keine Änderungen durchführbar.
Bei PC Worx Engineer handelt es sich also nicht nur um ein neues IEC-61131-3-Werkzeug. Das Tool passt sich außerdem an die sich ändernden Rahmenbedingungen in der Automatisierungswelt an. Das heißt: Mit seiner Erweiterbarkeit und Flexibilität stellt es die Aufgabe in den Mittelpunkt und nicht länger die Software als solche.
Autor:
Frank Walde ist Mitarbeiter im Competence Center Automationworx bei Phoenix Contact.
Schneller programmieren per Assistenzfunktionen
PC Worx Engineer unterstützt die aus Windows bekannte Drag-&-Drop-Funktion im gesamten System. Durch die neue Role-Picker-Funktionalität wird das Programmieren zusätzlich vereinfacht, denn der Programmierer bekommt stets nur die Objekte angeboten und angezeigt, die auch tatsächlich für die jeweilige Aufgabe nutzbar sind. Die Suche nach passenden Modulen in einem Katalog oder nach Variablen in einer Tabelle ist nicht mehr notwendig. Die Editoren stellen dem Anwender sogenannte ‚Inplace Actions‘ zur Verfügung. Diese Buttons tauchen kontextsensitiv immer dann auf, wenn eine definierte Aktion an einem Objekt möglich ist, und werden grafisch direkt am Objekt platziert. Das Auffinden von Aktionen in Toolbars entfällt damit, und das Editieren von Code oder Grafiken gestaltet sich wesentlich effizienter.













