Aktoren-basiertes Zellen-Testsystem

In einer modularen Hardwareumgebung sind sowohl ein Hardware Abstraction Layer (HAL) als auch ein Measurement Abstraction Layer (MAL) unverzichtbar, um ein großes Maß an Wiederverwendbarkeit von Software-Komponenten zu erreichen. Das in diesem Beitrag vorgestellte Batterie-Zelltestsystem basiert auf dem Labview Actor Framework und beinhaltet verschiedene Entwurfsmuster (Design Patterns) wie Composite, Factory Method und Abstract Factory, um Software-Komponenten zur Laufzeit zu erstellen, welche in einer State Machine im scxml-Format beschrieben sind. Ebenso sind Observer zur besseren Entkopplung implementiert. Design Patterns wie Command, Strategy und Remote Proxy werden verwendet, um das System in einer modularen Hardwareumgebung besser integrieren zu können. Es wird gezeigt, wie einfach sich manche dieser Design Patterns in einem Aktor-basierten System realisieren lassen.

Die Escad Group bringt mit ihren 550 Ingenieuren und Technikern ihre Erfahrung im Bereich End of Line (EoL) Prüfstandsautomatisierung/industrieller Messtechnik und insbesondere ihrer hohen Softwarekompentenz ein bewährtes System auf eine belastbare zukunftsträchtige Evolutionsstufe auf dem Stand modernster Software- und Messtechnik.

Das mPAC-Zelltestsystem ermöglicht die Definition von Testsequenzen unabhängig davon, auf welcher Hardware die einzelnen Sequenzen ausgeführt werden sollen. Dies ermöglicht zum Beispiel das Validieren von Messsequenzen im Labor, um deren Deployment auf EoL-Systemen besser zu planen.

Im Betriebsmodus Emulation simuliert das Testgerät eine Batterie. Somit ist beispielsweise die Validierung eines Battery-Management-Systems (BMS) möglich, um Algorithmen zur Bestimmung des State of Charge (SoC) oder des State of Health (SoH) anhand von vorermittelten oder definierten Verbrauchsprofilen testen zu können. Das BMS-Verhalten kann in einer frühen Entwicklungsphase besser an die Gegebenheiten der Applikation angepasst werden. Die einzelnen Hardwarekomponenten werden über Proxies angesprochen, sodass die Befehle an die einzelnen Komponenten sicherer und flexibler übertragen werden.

Bild 1: Typischer Systemaufbau. Die mit mn* markierten Verbindungen sind bei einer autarken Anwendung des Testers nicht vorhanden. Escad Automation

Aufbau des Testsystems

Der Aufbau lässt sich sowohl zur Entwicklung als auch zur Anwendungzeit beliebig neu definieren, wobei man drei Anwendungsfälle unterscheidet:

• Die Anwendung als Daten-Server: Der Server dient als Adapter zu Datenbanken, in denen Prüfsequenzen, Prüfparameter und Beschreibungen von Devices vorliegen.
• Die Anwendung als Interpreter und Editor von Sequenzen.
• Die Anwendung als autarkes Messsystem mit vorinterpretierten Sequenzen und Beschreibungen von Devices.

Der Process Engineer hat somit die Möglichkeit, Prüfsequenzen zu definieren, die er im Labor mit Standard-Labormessgeräten ausführen und testen kann. Später werden die Sequenzen in der Produktion auf den dafür vorgesehenen Geräten ausgeführt. Die Autarkie des Messsystems ist durch den Einsatz des NI System On Module (SOM) gewährleistet.

Der Server ist hauptsächlich für das zentrale Management von Mess- und Prozessdaten zuständig. Er kommuniziert mit den übrigen Systemkomponenten über TCP/IP.

Zusätzlich verwaltet der Server auch Plug-ins, welche vom Server an die Clients verteilt werden. Die zentrale Verwaltung dieser Plug-ins vereinfacht die Versionierung.

ClientOnDesktop ermöglicht die Erstellung und das Editieren von Hardwarekonfigurationen, die Eingabe von Sequenzen (Messungen und Berechnungen) sowie deren Management und die Anzeige von Messdaten.

Eine Hardwarekonfiguration wird in einer Network Devices Information gespeichert, kompiliert und einem vorhandenen SOM zur Verfügung gestellt.

Der ClientOnDesktop benötigt von jeder vorhandenen Hardware-Komponente eine Device-Information. Er speichert eine Sequenzbeschreibung in einer State Chart Description (SCD). Bei der Synchronisierung mit einem Server werden alle vorhandenen Sequenzbeschreibungen an den Server übergeben.

Die SCD enthält Bezeichnungen für logische Kanäle als Zuweisungen zu den tatsächlichen Kanälen auf der Hardware.

Bild 2: Auszug aus der Essential Perspective. Escad Automation

Die Zuweisung zwischen den logischen und den tatsächlichen Bezeichnern wird in die Datei Target Device channel Assignation (TDA) gespeichert, mit der Measurement-ID versehen und an den Server übermittelt.

ClientOnSOM ist eine Ausführungseinheit. Sie besteht hauptsächlich aus einem Interpreter und kommuniziert einerseits mit der Messhardware und andererseits mit dem Server, um Messdaten zu liefern oder Prozessdaten abzurufen.

Aspekte der Realisierung des Testsystems

Der Einsatz von Aktoren vereinfacht das Erstellen von voneinander unabhängigen, spezialisierten, wiederverwendbaren Aktorbäumen, die Nachrichten untereinander austauschen können. Zudem motiviert dieser Einsatz den Programmierer, eine eigene Semantik zu entwickeln und gute Architekturen anzuwenden im Sinne von bewährten Prinzipien des Designs, wie Single Responsability (Vererben von Verhalten), Open-Closed und Dependency Inversion (Abstract Messages) oder Liskov Substitution (Substitute Actor).

Bild 3: Auszug aus dem Projekt CellCycler und die Registrierung einer Engine. Escad Automation

Anhand von zwei Beispielen werden im folgenden Anwendungsfälle von Observer und Abstract Factory des Testsystems erörtert.

Aktoren-basierte Implementierung vom Observer Pattern

In Bild 2 ist zwischen dem Interface EngController und der Klasse DataOnBus ein Beobachter realisiert. Zusätzlich möchte man die zu beobachtende Komponente unabhängig vom EngController codieren. Letzterer ruft also die öffentliche Funktion registerEngine() des Modells auf, um einen Eintrag in die Liste der Beobachter dieses Modells hinzuzufügen.

GetBusData Msg ist eine abstrakte Nachricht, die bei jedem konkreten Controller (eine Implementierung von EngController) als Notified_n_Msg vererbt wird. Die konkrete Klasse der Nachricht sowie der Enqueuer der Engine werden bei der Registrierung übermittelt.

Die Engine wird beim Eintreten der gegebenen Bedingungen darüber informiert, indem die zugehörige Nachricht zum geeigneten Enqueuer gesendet wird.

Aktoren-basierte Implementierung von Abstract Factory

Bild 4: Abstract Factory ist im Fall von CellCycler ein generischer Controller. Ein Produkt ist die zu dem entsprechenden Controller zugehörige Konfiguration. Escad Automation

In Bild 2 wird die Beziehung u1 zwischen zwei generischen Klassen definiert. Zur Entwicklungszeit ist der Typ des Controllers nicht bekannt. Erst das Interpretieren der Sequenz ermittelt, ob der Controller ein State, ein Event oder ein Device ist. Unabhängig davon instanziert jeder Controller eine eigene Konfiguration (Product).

Die Realisierung einer solchen Struktur in einem Aktor-basierten System erfolgt, indem der Controller bei deren Konstruktion (Pre-Launch Actor) eine Konfigurationsklasse erhält, die wiederum die generische Konfiguration als Vaterklasse besitzt.

Somit wird dem Programmierer ermöglicht, die gesamte Verhaltensstruktur (Erscheinungsbild, Datenbankzugriff, User Interaktivität…) des Konfigurationstools einmalig implementieren und sie bei jeder weiteren Software-Komponente wiederverwenden zu können.

Andere Patterns lassen sich im Actor Framework sehr einfach realisieren. Das NI-Forum verweist auf viele Beispiele hervorragender Implementierungen, die beim Entwurf der eigenen Anwendung hilfreich sind.

(jj)