Eine serviceorientierte Funktionstestarchitektur auf Basis des LabVIEW Actor Framework
Dipl.–Math. Michael Thimm, SEN – SystemEntwicklung Nordhausen GmbH
"Die vorliegende Umsetzung eines Frameworks für individuell angepasste Prüfsoftware vereinfacht deren Erstellung wesentlich und verbessert die Wart-, Test- und Erweiterbarkeit bisheriger Umsetzungen. Das Konzept lässt sich auch auf andere Anwendungsfälle übertragen."
- Dipl.–Math. Michael Thimm, SEN – SystemEntwicklung Nordhausen GmbH
Die Aufgabe:
Vor allem in modularen Hardwareumgebungen ist die kunden-, prüflings- und testspezifische Softwareanpassung ein kritischer Zeit- und Kostenfaktor. Basierend auf dem LabVIEW Actor Framework hat das in diesem Beitrag vorgestellte Framework das Ziel, den Entwicklungsprozess zu vereinfachen.
Die Lösung:
Dies erfolgt durch voneinander unabhängige spezialisierte wiederverwendbare Aktorbäume, die definierte Teilfunktionalitäten kapseln. Diese sind über einen gemeinsamen Root Actor verbunden, der die Kommunikation und den Prüfablauf koordiniert.
Autor(en):
Dipl.–Math. Michael Thimm - SEN – SystemEntwicklung Nordhausen GmbH
Dipl.-Ing. (FH) Matthias Kresel - SEN – SystemEntwicklung Nordhausen GmbH
Diese Kundenlösung wurde im Tagungsband 2016 des Technologie- und Anwenderkongresses „Virtuelle Instrumente in der Praxis“ veröffentlicht.
Eingesetzte Produkte: LabVIEW
Kurzfassung
Vor allem in modularen Hardwareumgebungen ist die kunden-, prüflings- und testspezifische Softwareanpassung ein kritischer Zeit- und Kostenfaktor. Basierend auf dem LabVIEW Actor Framework hat das in diesem Beitrag vorgestellte Framework das Ziel, den Entwicklungsprozess zu vereinfachen. Dies erfolgt durch voneinander unabhängige spezialisierte wiederverwendbare Aktorbäume, die definierte Teilfunktionalitäten kapseln. Diese sind über einen gemeinsamen Root Actor verbunden, der die Kommunikation und den Prüfablauf koordiniert.
Einleitung
Die SEN GmbH ist ein Full-Service-Unternehmen für Funktionstests. Unsere Spezialisten sind deutschlandweit tätig. Wir beraten und entwerfen, entwickeln und vertreiben universelle, modular aufgebaute Funktionstester, diese statten wir nach Kundenwunsch mit individueller Testsoftware basierend auf LabVIEW und TestStand aus. Darüber hinaus entwickeln wir auch Testsequenzen und stellen Lösungen für spezielle Anforderungen (z. B. mechanische Funktionstests) bereit. Da die von der SEN GmbH entwickelten Geräte speziell auf die Kundenbedürfnisse zugeschnitten sind, beinhalten sie nach Bedarf auch selbstentwickelte Hardware. Zur Vereinfachung und Verbesserung der Skalierbarkeit unseres Entwicklungsprozesses bieten wir unsere Testsoftware seit 2015 in einer serviceorientierten Architektur basierend auf dem im Jahr 2011 von Stephen Mercer und Allen Smith vorgestellten LabVIEW Actor Framework an, in der verschiedene, voneinander unabhängige, spezialisierte Aktorenbäume über einen zentralen Root Actor koordiniert werden. So wird eine isolierte Anpassung der Teilfunktionalitäten der Software ermöglicht und die Einbindung fremder Softwaremodule vereinfacht. Des Weiteren ist unsere Software auch als Stand-alone-Produkt einsetzbar, indem sie einzelne Komponenten von Kundensystemen kapselt und deren Koordination und Kommunikation auslagert.
Aufgabenstellung
Ein Funktionstester besteht aus einer Vorrichtung für die Aufnahme von Prüflingen, aus einer Einrichtung zum Setzen und Abfragen von Schalterzuständen, einer Menge von Mess- und Testgeräten und aus einem Steuercomputer mit Benutzerschnittstelle. Beim Steuercomputer handelt es sich um einen Windows-PC, auf dem eine LabVIEW-Runtime-Version und oft auch eine TestStand-Runtime-Version installiert sind. Beispielhaft sind in Bild 1 zwei verschiedene Funktiontester abgebildet.
Im bisherigen Entwicklungsprozess wurde jeweils eine monolithische Software bereitgestellt. Diese wurde spezifisch für den jeweiligen Prüflingstyp, die Prüflingsaufnahmevorrichtung und die jeweilige Gerätekonfiguration entwickelt. Nach Abschluss einer Testserie wurde die Software archiviert, sodass sie für weitere Prüflingschargen genutzt werden konnte. Falls zwischen den Testserien Modifikationen der Prüflinge, des Testequipments oder der Benutzerschnittstelle stattfinden, muss die Software angepasst und als neues Release zur Verfügung gestellt werden. Durch die enge Verzahnung der Funktionalitäten wächst der Wartungsaufwand überproportional und die Softwareversionen weisen über Prüflinge, Gerätekonfigurationen und Benutzerschnittstellen eine große Redundanz aus. Auch kleine Anpassungen, wie z. B. ein anderes Prüfberichtsformat, erfordern unter Umständen tiefgreifende Änderungen der Software.
Konzept eines Frameworks für Funktionstestsoftware
Die grundlegenden und immer wiederkehrenden Funktionen der Testsoftware wurden in ein Framework ausgelagert. Dazu werden die folgenden Teilaufgaben identifiziert:
Grafische Benutzerschnittstelle (GUI)
Das GUI dient zur Steuerung des Prüfprozesses. Die Aufteilung des Bildschirms und das dynamische Einbetten und Entfernen von VIs sind Funktionen dieses Subsystems.
Sequencer
Der Sequencer führt Testsequenzen aus und liefert Testergebnisse zurück. Oft ist ein Wrapper für TestStand implementiert. Es ist aber z. B. auch möglich, statische Abfolgen von Prüf-VIs abzuarbeiten.
Machine
Das Machine-Subsystem steuert und reagiert auf Ereignisse innerhalb des Funktionstesters. In ihm ist das Setzen und Lesen nicht prüfbezogener Digitalein- und -ausgänge implementiert.
Logging
Das Logging-Subsystem dient zur Dokumentation des Betriebs des Funktionstesters.
Report Generator
Der Report Generator ist für die Prüfberichterstellung verantwortlich. Hierbei können sowohl textbasierte Formate wie auch zum Beispiel die direkte Kommunikation mit einer Datenbank implementiert werden. Die Subsysteme kapseln ihre Funktionalität und verbergen jeweils ihre konkrete Implementierung. Die Verteilung erfolgt über eine eigenständige Komponente, die die Koordination und das kooperative Verhalten zentral festlegt. Das individuelle Verhalten der einzelnen Komponenten wird in verschiedenen Abstraktionsebenen durch Vererbung festgelegt.
Umsetzung
Das verwendete Architekturmuster ist eine serviceorientierte Architektur. Um dies zu verwirklichen, übernimmt der Root Actor die Funktion eines intelligenten Nachrichtenbusses und die Services werden als Aktoren der nachgelagerten Ebene der Baumstruktur bereitgestellt.
Der Start eines Services erfolgt über einen Klassenkonstruktor, der als Schablonemethode implementiert ist. Dieser meldet sich über seine implizit aufgerufene Elternmethode beim Root Actor an. Die Elternklasse des Root Actor verwaltet dazu ein mit Servicetypen indiziertes Array von Enqueuern.
Das Framework wurde in zwei Vererbungsebenen realisiert. Zunächst wurde eine abstrakte Basisklasse „Base“ geschaffen, die direkt von der Aktorklasse des LabVIEW Actor Framework abgeleitet wird. Sie hat die Aufgabe, abstrakte Methoden zur Verfügung zu stellen, die von allen abgeleiteten Klassen überschrieben werden können, und zusätzliche Verwaltungsinformationen vorzuhalten, die in eine eigene Klasse, „ActorAdminInfo“, ausgelagert wurden.
Die Zwischenschaltung einer Basisklasse hat zudem den Vorteil, dass bei einem Release-Wechsel des LabVIEW Actor Framework dieses als „Drop-in-Replacement“ ausgetauscht werden kann. Etwaige Änderungen der Schnittstelle können zentral am „Base“ Actor vorgenommen werden.
Von der Klasse „Base“ leiten sich die Klassen „Root“, „GUI“, „Sequencer“, „Machine“, „Log“, und „Report“ ab, die die zur Erfüllung ihrer jeweiligen Aufgabe notwendigen Informationen vorhalten. Bild 2 zeigt dies exemplarisch am Beispiel des Actor Core des GUI-Services, der per Referenz ein VI aufruft, das Unterpanels für nachgelagerte Aktoren bereitstellt.
Zur Entwicklung einer konkreten Funktionstestsoftware lassen sich diese Klassen dann nochmals ableiten, sodass ihre Methoden durch z. B. gerätespezifische Erweiterungen ergänzt werden können.
Die verwendete Klassenhierarchie erlaubte die Verwendung abstrakter Nachrichten, indem zu jeder in der Basisklasse definierten dynamischen Dispatch-Methode eine Nachrichtenklasse bereitgestellt wurde. Wird nun die Methode durch eine Folgeklasse überschrieben und die Nachricht an den Enqueuer der Folgeklasse verschickt, so wird zunächst die abgeleitete Methode ausgeführt, die dann die jeweiligen Vorgängermethoden ausführt. So wird eine lose Kopplung zwischen Sender und Empfänger ermöglicht. Hierbei ist es unerheblich, welcher Aktor eine Aktion ausgelöst hat, sodass auf eine vollständige Entkopplung verzichtet werden konnte.
Um eine nachträgliche Erweiterbarkeit der Nachrichtenparameter zu ermöglichen, wurden diese zum Teil ebenfalls in dedizierte Klassen ausgelagert. Beispielsweise kann eine Nachricht newTestResult sowohl ein Testergebnis der Klasse StringValueTest als auch der Klasse Numerical LimitTest enthalten, weil die Nachricht lediglich ein Objekt der Klasse TestResult erwartet.
Zusammenfassung
Die vorliegende Umsetzung eines Frameworks für individuell angepasste Prüfsoftware vereinfacht deren Erstellung wesentlich und verbessert die Wart-, Test- und Erweiterbarkeit bisheriger Umsetzungen. Das Konzept lässt sich auch auf andere Anwendungsfälle übertragen. Dieses Projekt wird mit der Projektnummer 2015 INP 0067 im Förderprogramm „FuE-Personalrichtlinie“ durch die Thüringer Aufbaubank aus Mitteln des Freistaates Thüringen und des Europäischen Sozialfonds (ESF) gefördert.
Informationen zum Autor:
Dipl.–Math. Michael Thimm
SEN – SystemEntwicklung Nordhausen GmbH
Heringer Weg 1a
Nordhausen 99734
Germany
Tel: +49 (0)3631 658 94 - 0
Fax: +49 (0)3631 658 94 - 10
m.thimm@se-ndh.de