LabView Actor Framework

Serviceorientierter Funktionstest

18. Dezember 2017, 16:17 Uhr | Michael Thimm und Matthias Kresel von der SEN – Systementwicklung
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Umsetzung

Es wird eine serviceorientierte Architektur [4] verwendet. Dazu übernimmt der RootActor die Funktion eines intelligenten Nachrichtenbusses und die Services werden als Aktoren der nachfolgenden Ebene in der Baumstruktur bereitgestellt.

Der Service wird über einen Klassenkonstruktor gestartet, der als Schablonenmethode implementiert ist. Dieser meldet sich über seine implizit aufgerufene Elternmethode beim Root-Actor an. Die Elternklasse des Root-Actors verwaltet dazu ein mit Servicetypen indiziertes Array von Enqueuern.

Das Framework wurde auf zwei Vererbungsebenen realisiert. Zunächst ist eine abstrakte Basisklasse Base erzeugt, die direkt von der Aktorklasse des LabVIEW Actor Frameworks abgeleitet wird. Sie soll abstrakte Methoden zur Verfügung stellen, die von allen abgeleiteten Klassen überschrieben werden können. Diese hält zusätzliche, in eine eigene Klasse ausgelagerte, Verwaltungsinformationen vor.

Mit der Basisklasse kann ein Releasewechsel des LabVIEW-Actor Frameworks als Drop-in-Replacement erfolgen. Etwaige Änderungen der Schnittstelle werden zentral am Base-Actor vorgenommen. Von der Base-Klasse leiten sich die Klassen Root, GUI, Sequencer, Machine, Log und Report ab. Diese halten die notwendigen Informationen zur Erfüllung der Aufgaben vor.

Actor Core des GUI-Services. Implementiert ist ein synchroner Aufruf eines VIs, das Unterpanels enthält. Die Referenzen dieser Unterpanels werden durch Unteraktoren mit für Teilaufgaben spezialisierten VIs gefüllt.
Bild 2: Actor Core des GUI-Services. Implementiert ist ein synchroner Aufruf eines VIs, das Unterpanels enthält. Die Referenzen dieser Unterpanels werden durch Unteraktoren mit für Teilaufgaben spezialisierten VIs gefüllt.
© SEN - Systementwicklung

Bild 2 zeigt den 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 zum Beispiel durch gerätespezifische Erweiterungen ergänzt werden können.
Die verwendete Klassenhierarchie handelt abstrakte Nachrichten, indem zu jeder in der Basisklasse definierten dynamischen Dispatch-Methode, eine Nachrichtenklasse bereitgestellt wird. Bei Überschreibung der Methode durch eine Folgeklasse und senden der Nachricht an ihren Enqueuer, wird zunächst die abgeleitete Methode ausgeführt, die damit die jeweiligen Vorgängermethoden ausführt. Dies realisiert eine lose Kopplung zwischen Sender und Empfänger [3]. Hierbei ist es unerheblich, welcher Aktor eine Aktion ausgelöst hat, sodass auf eine vollständige Entkopplung verzichtet werden konnte.

Zur nachträglichen Erweiterung der Nachrichtenparameter, 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, da die Nachricht lediglich ein Objekt der Klasse TestResult erwartet.


  1. Serviceorientierter Funktionstest
  2. Testsoftware
  3. Umsetzung
  4. Fazit

Lesen Sie mehr zum Thema


Das könnte Sie auch interessieren

Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu National Instruments Germany GmbH

Weitere Artikel zu Halbleitertestsysteme