Testen in der Industrieautomatisierung ist oft eine manuelle Aufgabe. Zunehmende Komplexität und veränderte Betriebsbedingungen verlangen allerdings neue Testansätze. Hier könnte die Methodik und Technologie aus dem regulären Software-Engineering mit seinen automatisierten Tests hilfreich sein, um robustere und ausgereiftere Testprozesse zu schaffen. Diesen Ansatz verfolgen das Institut für Automation und Kommunikation Ifak und das Software-Unternehmen Parasoft in einem gemeinsamen Projekt: Sie kombinieren ihre existierenden Tools, um das Testen im Kontext industrierelevanter Anwendungsfälle auf Basis der Kommunikation per Modbus und OPC UA zu ermöglichen.

Das Testkonzept – Testadapter, SOAtest und Workflow

Der Testadapter

Die generierten Testfälle werden mittels eines Verfahrens ausgeführt, das eine protokollunabhängige Schnittstelle zum Verbinden des Testwerkzeugs mit dem zu prüfenden System (System Under Test, SUT) bereitstellt (Bild 3). Da die Palette der verfügbaren Protokolle besonders im Bereich der Industrieautomation überaus heterogen ist, ist ein generalisierter ‚Agent‘ zum Anschließen der Test Suite notwendig. Der zu diesem Zweck entwickelte generalisierte Testadapter verleiht dem Testsystem eine einheitliche Schnittstelle, welche die Kommunikationsstruktur vom Testsystem entkoppelt. Die Kommunikation mit dem SUT wird in beiden Richtungen mithilfe verschiedener Kommunikationsprotokolle, z.B. OPC UA oder Modbus, realisiert. Aus Sicht des SUT unterscheidet sich das Test-Szenario somit nicht von der Integration in eine reale Einsatzumgebung. Der Ansatz zur automatisierten Testausführung wird als Prototyp anhand einer Demo-Anwendung vorgestellt.

Der Testadapter nutzt MQTT als Medium für die Kommunikation mit MBTCreator. Er wurde so angelegt, dass sich die wesentlichen Bestandteile einer Testausführung in eine gemeinsame Reihe von Aktionen mit einer gemeinsamen Sprache zerlegen lassen. In Verbindung mit einer Konfiguration, welche die spezifischen Merkmale des Systems abbildet, lässt sich die Kommunikation mit den verschiedenen SUTs über das vom jeweiligen SUT benutzte Protokoll abwickeln.

Um eine einheitliche Sprache für die Testausführung zu schaffen, muss im Prinzip jeder einzelne Teilschritt der Testausführung auf ein gemeinsames Sprachelement abgebildet werden. Diese Teilschritte setzen damit eine nicht weiter unterteilbare Aktion des SUT um. Derartige Teilschritte wären beispielsweise die Anweisungen ‚Lese Sensorwert X ein‘ oder ‚Stop‘. Untersucht man Testschritte dieser Art genauer, so stellt man fest, dass sich eine vom System auszuführende Aktion im Rahmen der Testausführung auf drei Arten von Aktionen abbilden lässt, nämlich auf das Ausführen einer Funktion, das Einlesen von Werten oder das Schreiben von Werten. Auch wenn die hierfür erforderlichen Schritte heterogen und bezüglich der Kommunikation mit dem System komplexer sind, ist dieser Teil der Ausführung für die ausführende Toolchain dennoch transparent. Auf jeden Fall vereinfacht das Reduzieren der Kette auf diese drei Grundfunktionen die Kommunikation auf Seiten der Testgenerierung erheblich, da die Toolchain nur diese drei Operationen kennen muss.

Der Testadapter verwendet MQTT genau für die eben beschriebene Reduktion der Aktionen. Diese elementaren Nachrichten, die für diese grundlegenden Aktionen stehen, werden als verschiedene Nachrichten vom und zum SUT implementiert. Anschließend werden diese Meldungen in das vom SUT benutzte Protokoll umgewandelt und transparent als Kommunikationselement zwischen Test Suite und SUT verwendet.

Testlösung SOAtest

Parasoft SOAtest ist eine generische Testlösung für Funktionstests. Es umfasst API-Tests für mehrere Schnittstellen (UI, REST & SOAP APIs, Web-Services, Microservices) und vereinfacht das automatisierte End-to-End-Testen (einschl. Datenbanken, MQ, JMS, EDI, Kafka). Die Palette der unterstützten Features und Protokolle lässt sich mit Plug-ins erweitern. Über das MQTT-Interface ist die Kommunikation mit dem vom ifak entwickelten Testadapter möglich, sodass SOAtest über Industrieprotokolle wie Modbus und OPC UA kommunizieren kann.

Der Workflow

Das vom ifak entwickelte modellbasierte Konzept für die Testgenerierung erzeugt eine abstrakte Test Suite, in der neben den Testdaten auch ein Testorakel und die nötigen Prüfschritte definiert sind. Letztere werden aus einem genau definierten Satz von Aktionen (Read, Write, Assert) aufgebaut und lassen sich zum Zweck der Testausführung in eine äquivalente Testfall-Darstellung in SOAtest umwandeln. Diese Umwandlung kann entweder manuell erfolgen oder von einem Algorithmus durchgeführt werden.

In der ersten Phase der Zusammenarbeit wurde eine manuelle Umwandlung der abstrakten Testfälle gewählt (Bild 4). Links ist ein abstrakter Testfall als Ablaufdiagramm dargestellt. Nachrichten werden zwischen Prüfsystem und SUT übertragen. Rechts im Bild ist der entsprechende Testfall in SOAtest zu sehen. In einem realen Testausführungs-Szenario ist eine direkte Kommunikation zwischen Prüfsystem und SUT oftmals nicht möglich, weil beispielsweise das Prüfsystem das nötige Kommunikationsprotokoll nicht unterstützt, oder die Kommunikation an ein sehr spezifisches, SUT-abhängiges Verhalten angepasst werden muss.

SOAtest unterstützt verschiedene Schnittstellen und Protokolle einschließlich MQTT, wodurch es mit dem Testadapter kommunizieren kann. Mithilfe des Testadapters sind Tests für verschiedene Kommunikationsprotokolle mit SOAtest möglich. Sämtliche relevanten Testschritte lassen sich implementieren, indem die nativen MQTT-Befehle „publish” (zum Senden) und „subscribe” (zum Empfangen) sowie die SOAtest-spezifische Funktion „assert” zum Auswerten des Inhalts einer Nachricht benutzt werden. Ein weiterer Vorteil dieses Konzepts ist, dass sich die Test Suites für verschiedene Kommunikationsprotokolle einsetzen lassen, wenn das zugrundeliegende Verhalten des SUT unverändert bleibt, z.B. dann, wenn ein SUT mehrere verschiedene Schnittstellen unterstützt.

Die Kommunikationsprotokolle und ihre Anwendung

Es folgt eine kurze Übersicht über die verschiedenen, vom Testadapter unterstützten Kommunikationsprotokolle und ihre Anwendung. Auf der Basis des im vorigen Abschnitt umrissenen Workflows finden sich hier Beispiele für die Integration in SOAtest für Modbus und OPC UA.

MQTT

MQTT ist ein schlank konzipiertes Machine-to-Machine-Kommunikationsprotokoll, das sich eines Publish-Subscribe-Mechanismus bedient. Obwohl eigentlich für TCP gedacht, kann es auch mit anderen verlustlosen bidirektionalen Protokollen eingesetzt werden. MQTT unterstützt die Verschlüsselung und Authentisierung ebenso wie unterschiedliche Quality-of-Service-Optionen. Es garantiert die Nachrichten-Reihenfolge innerhalb eines Subscription-Topics und unterstützt die Nachrichten-Persistenz. Notwendig ist auch ein Broker als zentralisierter, für die Verteilung der Nachrichten zuständiger Verbindungs-Endpunkt.

MQTT kommt in großem Umfang als Protokoll für IoT-Geräte, im Home-Automation-Bereich sowie in weiteren Szenarien mit kleinen Geräten mit kleinem Footprint zum Einsatz. Im Testausführungs-Workflow erfolgt die gesamte Kommunikation zwischen dem Testsystem (MBTCreator) und dem Testadapter per MQTT. Alle relevanten Informationen für einen Testschritt werden in eine JSON-Nachricht codiert, über den Testadapter interpretiert und in das benötigte Protokoll umgewandelt. Die vom SUT gelesenen und/oder empfangenen Daten werden wiederum vom Testadapter als JSON-Nachrichten codiert und an das Testsystem zurückgeschickt.

Modbus

Modbus ist ein serielles Kommunikationsprotokoll zum Verbinden elektronischer Geräte im industriellen Bereich. Das eigens für industrielle Anwendungen entwickelte Protokoll ist verglichen mit anderen Standards relativ einfach einzurichten und zu pflegen und gibt – abgesehen vom Format der zu übertragenden Daten – nur wenige Restriktionen vor. Modbus nutzt RS-485 als Bit-Übertragungsschicht.

• Mit MQTT-Befehlen können einem Modbus-Gerät folgende Anweisungen erfolgen:
• Den Wert in einem seiner Register ändern, der in coil- und holding-Register geschrieben wird.
• Lesen eines I/O-Ports: Lesen von Daten von einem discrete- oder coil-Ports.
• Dem Gerät befehlen, einen oder mehrere Werte zurückzusenden, die in seinen coil- und holding-Registern enthalten sind.

Ein Modbus-Befehl enthält die Modbus-Adresse des Geräts, für das er bestimmt ist (1 bis 247). Nur das derart adressierte Gerät reagiert auf den Befehl und führt ihn aus, selbst wenn andere Geräte den Befehl empfangen. (Eine Ausnahme hiervon bilden spezielle broadcastfähige Befehle, die an den Knoten 0 geschickt werden. Diese werden zwar ausgeführt, aber nicht bestätigt.) Sämtliche Modbus-Befehle enthalten Prüfsummen-Informationen, an denen der Empfänger etwaige Übertragungsfehler erkennen kann.

Modbus wird derzeit als Protokoll für die Kommunikation zwischen einem SUT und dem präsentierten Testadapter unterstützt.

OPC UA

Bei OPC UA (OPC Unified Architecture) handelt es sich um ein Machine-to-Machine-Kommunikationsprotokoll für industrielle Bussysteme - ein offenes, plattformübergreifendes Protokoll nach dem Prinzip der serviceorientierten Architektur. Es gliedert sich in zwei Hauptbestandteile, nämlich den Informationstransport und das Metamodell, das die Information einschließlich der Semantik beschreibt. Für den Transport werden verschiedene Protokoll-Implementierungen unterstützt unter Einbeziehung von Security-Aspekten.

Das Informationsmodell ist ein so genanntes Full-Mesh-Netzwerk aus Knoten (Nodes), mit dem neben den Nutzerdaten eines Knotens auch Meta- und Diagnoseinformationen dargestellt werden. Ein Knoten ähnelt einem Objekt, wie es aus der objektorientierten Programmierung bekannt ist. So kann ein Knoten verschiedene Attribute aufweisen, die gelesen und geschrieben werden und Historical Data Access bieten können. Es besteht die Möglichkeit zur Definition und Ausführung von Methoden mit Argumenten und Rückgabewerten. Darüber unterstützt OPC UA Events, die versendet werden können, um bestimmte Informationen zwischen Geräten auszutauschen. Durch die Kombination von Knoten und hierarchischen Daten kann dieses Protokoll unterschiedliche reale Objekte  repräsentieren – vom kleinen Sensor bis zur großen Industrieanlage.