Sowohl die HTML5- als auch die OPC-UA-basierte Schnittstelle werden über das Rechte-/Rollenkonzept des PLCnext-Controllers abgesichert. Dazu gibt es die eigenen Rollen „DataViewer“ und „DataChanger“, mit denen sich anwenderspezifische Zugriffsrechte nach dem RBAC-Verfahren (Role Based Access Control) kontrollieren lassen. Neben der Authentifizierung über den User respektive das Passwort werden die Erreichbarkeit des OPC-UA-Servers und die Rechte von OPC-UA-Clients durch Zertifikate verwaltet. Zu diesem Zweck stellt der OPC-UA-Server drei verschiedene Möglichkeiten zur Verfügung, wie das lokale Steuerungszertifikat erzeugt oder von außen erhalten werden kann.
Erzeugung und Empfang lokaler Steuerungszertifikate
Als einfachste Alternative erweist sich die Nutzung des Self-signed-Zertifikats. Hier werden nur noch die aktuellen Instanzdaten, wie der Netzwerkname und die IP-Adresse, nachgetragen. Besitzt der Anwender eine eigene Zertifikatshierarchie, kann diese die selbst erstellten Zertifikate anwenderfreundlich über die Engineering-Umgebung PLCnext Engineer in die Steuerung laden. Und schließlich unterstützt der PLCnext-Controller den OPC-UA-Standard „Global Discovery Server“ (GDS), mit dem die SPS Zertifikate durch einen GDS-Pull sicher von einem Server herunterlädt.
Mit dem GDS lassen sich außerdem größere Installationen mit vielen Teilnehmern zentral verwalten und somit aktuell halten. Die Steuerung legt die privaten Schlüssel dieser Zertifikate gesichert in einem lokalen Trusted-Platform-Module (TPM) ab. Beim TPM handelt es sich um einen Chip oder Chip-Bestandteil, der einen Computer oder ähnliche Geräte um grundlegende Sicherheitsfunktionen erweitert. Dieser Tresor wird während der Fertigung der SPS mit einem eindeutigen Zertifikat versehen. So ist sichergestellt, dass sich lediglich von Phoenix Contact signierte Firmware-Komponenten ebenso wie der Bootloader starten lassen. Der Mechanismus schließt eine Manipulation durch Dritte aus, weil diese die veränderten Software-Teile nicht passend signieren können und die Teile daher nicht anlaufen (Bild 3).
Individuelles Anlegen von Alarmen aus dem Applikationsprogramm
Der OPC-UA-Server bietet darüber hinaus einen sicheren Zugriff auf das Dateisystem der Steuerung. Mit den File-Diensten lassen sich beliebige Informationen und die von der Steuerung erzeugten Log-Dateien auslesen. Der OPC-UA-Client kann ferner eigene Ordner erstellen und Dateien – beispielsweise zum Austausch von Parametrierungsdaten oder Rezepten – an die SPS senden. Damit ist eine flexible Anpassung an die lokale Applikation direkt aus der Visualisierung möglich. Dieser Zugriff wird über die Nutzerrollen „FileReader“ und „FileWriter“ abgesichert.
Als weitere wichtige Funktion der PLCnext-Controller erweist sich der eingebaute Alarm-/Event-Server. Er erlaubt, dass der Anwender aus dem Applikationsprogramm Alarme anlegen, aktivieren und quittieren kann. Die Applikation kennt den Status des Alarms in jedem Abarbeitungszyklus und kann darauf reagieren. Dies ist wiederum unabhängig von der gewählten Programmierumgebung – also IEC 61131 oder Hochsprache C++. Sofern der OPC-UA-Client dies beim OPC-UA-Server angemeldet hat, werden die Alarme dann über OPC UA weitergeleitet. Dabei lässt sich sogar der Alarmzeitpunkt durch die Applikation eintragen. Somit kann der Betreiber der Anlage den zyklusgenauen Ablauf einer Alarmkette leicht nachprüfen. Durch diese Flexibilität und den Kommunikationsstandard OPC UA erübrigen sich herstellerspezifische Alarmkonzepte (Bild 4).
OPC UA wird ständig weiterentwickelt. Deshalb ergänzt Phoenix Contact auch die Funktion des OPC-UA-Servers in den PLCnext-Steuerungen kontinuierlich. In den nächsten Schritten ist beispielsweise die Implementierung von OPC UA Pub/Sub, historischen Daten und anwendungsspezifischen Namensräumen vorgesehen, sodass die Anwender stets auf dem neuesten Stand der Technik arbeiten können.