SW-Beschreibung

Im folgenden Kapitel wird das Softwarekonzept vorgestellt: zunächst ein allgemeiner Überblick, dann Blockschaltbilder der SW-Subsysteme, eine Beschreibung der Kommunikation zwischen den SW-Subsystemen und schließlich eine kurze Funktionsbeschreibung der Funktionsblöcke.

Für Lebensdauertests wird Software zur Testkonfiguration, Datenaufzeichnung und Testausführung benötigt. Diese Softwareteile werden in diesem Dokument nicht beschrieben. IRS bietet eine vollständige SW-Lösung für Lebensdauertests an, die zusätzlich zu der im folgenden Kapitel beschriebenen Software Folgendes enthält:

• PC-Host-Software
  • Benutzeroberfläche (GUI)
  • TestStand Controller (TSC)
  • TestStand einschließlich Prüfablauf, der auf die API-Funktionen des Messsystems zugreift

Für eine Beschreibung dieser Softwareteile wenden Sie sich an IRS.

Für das Messsystem werden im folgenden Kapitel diese Subsysteme vorgestellt:

• PC-Host-Software
  • Basiskommunikation zum Messsystem (Kommunikation PC zu RT)
  • SW zum Steuern und Abfragen der einzelnen Funktionsblöcke
  • Signalzuordnung für den Zugriff auf Analog-, Digital- und Kommunikationskanäle über den DUT-spezifischen Signalnamen
• Messsystem-Software:
  • LabVIEW-RT-Software, die auf dem RT-Controller des sbRIO läuft
  • LabVIEW-FPGA-Software, die auf dem FPGA des sbRIO läuft
  • Mikrocontroller-Software, die auf dem Mikrocontroller der Kommunikationsplatine läuft

4.1SW-Schichten im Lebensdauertest

Das folgende Blockschaltbild zeigt die verschiedenen Softwareschichten eines typischen Lebensdauerprüfstands mit Schwerpunkt auf der Messsystem-Software (gelb). Die blau markierten SW-Teile sind die generische IRS-Benutzeroberfläche und TestStand von National Instruments.

4.2Embedded Software des Messsystems

4.2.1Übersicht FPGA-SW

Das nächste Blockschaltbild zeigt das gesamte FPGA-Design mit seinen Funktionsblöcken, das auf dem FPGA des sbRIO läuft:

Das Blockschaltbild enthält mehrere Sub-VIs, die die gesamte FPGA-Datenverarbeitung gemäß der folgenden VI-Hierarchie übernehmen:

Die Sub-VIs werden nicht im Detail beschrieben, da dies den Rahmen dieses Dokuments sprengen würde. Um die Funktionsweise der Blöcke zu verstehen, sollte der Quellcode untersucht werden.

4.2.2Übersicht RT-SW

Das folgende Blockschaltbild zeigt das Top-Level-RT-Design, das auf dem RT-Controller des sbRIO läuft:

Nach dem Einschalten initialisiert die RT-SW die FPGA-Referenz und nimmt alle DMA-Kanaleinstellungen für die Kommunikation mit dem FPGA vor.

Anschließend wartet die RT-SW auf eine Verbindungsanfrage vom Host-PC. Nachdem die Verbindung aufgebaut ist, wartet die RT-SW stets auf einen auszuführenden Befehl vom Host-PC.

Bei jedem Befehl (z. B. Digitalausgänge setzen, Analogwerte anfordern, CAN-Befehl senden, …) werden die folgenden Schritte ausgeführt:

• Command-Handler aufrufen
• Parameter lesen
• Befehl ausführen
• Antwort zurückgeben

Nachdem der Host-PC die Verbindung geschlossen hat, wird die Schleife, die auf einen Befehl wartet, abgebrochen, die Ethernet-Verbindung geschlossen, und die RT-SW wartet erneut auf eine neue Verbindung zum PC-Host.

Derzeit sind für die RT-SW keine weiteren Tasks erforderlich. Es gibt mehrere Möglichkeiten, diese Software zu erweitern, unter anderem durch parallele Tasks für Berechnungen, die Ausführung von Modellen, …

Das Blockschaltbild enthält mehrere Sub-VIs, die die gesamte RT-Datenverarbeitung gemäß der folgenden VI-Hierarchie übernehmen:

Die Sub-VIs werden nicht im Detail beschrieben, da dies den Rahmen dieses Dokuments sprengen würde. Um die Funktionsweise der Blöcke zu verstehen, sollte der Quellcode untersucht werden.

4.2.3Kommunikation RT zu FPGA

Kommunikation über Read/Write-Controls

Befehle, die keine größeren Datenblöcke von RT an das FPGA oder umgekehrt übergeben müssen, verwenden einfache Read/Write-Controls, um Daten an das FPGA zu senden oder vom FPGA zu lesen. Als Beispiel sehen Sie hier den Case des Command-Handlers zum Setzen der Digitalausgänge aus RT-Sicht:

Alle verfügbaren Read/Write-Controls (Temperatur, Digitalausgänge, Zeitstempel, Reset, CMM, …) zeigt auch das FPGA-Blockschaltbild in Kapitel 5.2.1.

Kommunikation über DMA aus FPGA-Sicht

Zur Übergabe größerer Datenblöcke von RT an das FPGA oder umgekehrt können DMA-Kanäle verwendet werden. Die folgende Struktur, die sich in der Abbildung in Kapitel 5.2.1 findet, übernimmt die DMA-Kommunikation:

Kommunikation über DMA aus RT-Sicht

Für die Kommunikation von RT zum FPGA werden die folgenden Schritte ausgeführt:

4.3Kommunikation PC zu RT

4.3.1STM-Bibliothek

Die Kommunikation zwischen der PC-Host-Schnittstelle und dem RT-Controller des Messsystems erfolgt über eine Ethernet-Verbindung. Implementiert ist ein Protokoll auf Basis der STM-Bibliothek von National Instruments, das das TCP/IP-Protokoll verwendet.

Jedes von der STM-Bibliothek verarbeitete Befehls- oder Antwortpaket enthält den folgenden Datenstring:

Das Befehlsfeld „Metadata“ ist eine ID, die ein Element des Arrays gültiger Befehle darstellt. Die folgende Abbildung zeigt ein Beispiel der verwendeten Befehle des Messsystems.

Die Metadaten werden einmalig vom PC-Host an das RT-Target übertragen, nachdem der Host-PC die Verbindung aufgebaut hat. So ist sichergestellt, dass PC und RT dieselben gültigen Befehle mit denselben IDs kennen.

4.3.2Normale Befehlsausführung aus PC-Sicht

Normale Befehlsausführung bedeutet, dass der PC einen Befehl sendet. RT führt den Befehl aus und sendet sofort eine Antwort. Aus Sicht des PC werden die folgenden Schritte ausgeführt:

1. Parameter in den Befehlsstring packen:
   • Dieser Schritt ist befehlsspezifisch und bedeutet, alle Befehlsparameter in einen String zu packen
2. Befehlsstring an RT senden:
   • Dieser Schritt ist in der generischen Kommunikationsroutine enthalten, die den Befehlsstring an das RT-Target sendet
3. Antwortstring von RT empfangen:
   • Dieser Schritt ist in der generischen Kommunikationsroutine enthalten, die auf den Antwortstring vom RT-Target wartet
4. Parameter aus dem Antwortstring entpacken:
   • Dieser Schritt ist befehlsspezifisch und bedeutet, alle Antwortparameter aus dem String zu extrahieren

4.3.3Slot-Adressierung

Beachten Sie, dass bei jedem Befehl ein Slot-Parameter übergeben wird. Dieser Parameter dient dazu, mehrere Prüflinge an einem Messsystem zu unterscheiden. Bei Prüflingen mit nur wenigen Pins und Funktionen kann ein Messsystem bis zu 6 Prüflinge parallel bedienen. Wenn in diesem Fall mehr als eine Testausführung mit dem Messsystem verbunden ist, muss die Kommunikationsroutine die Verbindungen für die Testausführung jedes Prüflings prüfen. Sie darf die Verbindung erst schließen, wenn alle Testausführungen aller Prüflinge die Verbindung geschlossen haben. Der Slot repräsentiert also den Prüfling am Messsystem.

4.3.4Generische Kommunikationsroutine

Die generische Kommunikationsroutine wird für jeden vom PC gesendeten Befehl verwendet. Die folgende Abbildung zeigt die Schritte dieser Routine.

4.3.5Normale Befehlsausführung aus RT-Sicht

Die folgende Abbildung zeigt die Schleife für den Befehlsempfang, die kontinuierlich auf RT läuft:

Der Command-Handler wählt den Befehl aus und führt ihn aus:

4.4Befehlsablauf

4.4.1Normale Befehlsausführung

Die folgende Abbildung zeigt einen typischen Befehlsablauf aus PC-Sicht. In diesem Fall werden die Funktionen des Messsystems in einer LabVIEW-Anwendung verwendet:

Dieselben Schritte sind erforderlich, wenn aus TestStand oder anderen Anwendungen auf das Messsystem zugegriffen wird. Die folgende Abbildung zeigt einen typischen Ausführungsablauf in TestStand

Schritt 1:

Öffnen Sie die Verbindung, um die TCP-IP-Verbindung aufzubauen und die Metadaten zwischen PC und RT auszutauschen.

Schritt 2:

Rufen Sie „PC_SYS_SetSbRioCmdWaitTimeout.vi“ auf, um den „Safe-State“-Timeout auf eine geeignete Größe zu setzen. Dieser Timeout bedeutet Folgendes: Wenn das Messsystem (RT-SW) innerhalb dieser Timeout-Zeit keinen gültigen Befehl empfangen hat, schaltet die RT-SW alle Ausgänge ab, setzt die CAN-Controller zurück, trennt die TCP-IP-Verbindung und wartet auf eine neue Öffnungsanfrage. Dieser Timeout soll sicherstellen, dass das Messsystem in einen Ruhezustand zurückkehrt und den Prüfling abschaltet, wenn der PC abgestürzt ist.

Der Standardwert dieses Timeouts beträgt 2 Sekunden. Der PC muss also alle 2 Sekunden einen Befehl senden. Das lässt sich nicht in allen Anwendungen erreichen. Insbesondere wenn der Benutzer Befehle durch Betätigen von Schaltflächen senden möchte, muss der Timeout auf höhere Werte gesetzt werden. Ein typischer Wert für ein unempfindliches Gerät wären 60 Sekunden. Geräte wie Fensterheber, die in einem unkontrollierten, aktiven Zustand beschädigt werden könnten, erfordern kürzere Timeouts, deutlich unter 5 Sekunden. Der Benutzer legt den geeigneten Timeout für seine Anwendung selbst fest.

Schritt 3: (beliebig oft wiederholbar)

Befehle gemäß der API-Beschreibung in Messsystem-API (CORE_API) oder in Lebensdauertest-API mit benannten Kanälen (TS_API) können anwendungsspezifisch in beliebiger Weise gesendet werden.

Schritt 4:

Vor dem Beenden der Anwendung sollte die Verbindung geschlossen werden. Andernfalls würde das Messsystem weiterhin auf einen Befehl warten und nach der eingestellten Zeit in den „Safe-State“-Timeout laufen. Versucht der Benutzer, die Verbindung zum Messsystem erneut zu öffnen, während es noch läuft, würde ein Fehler gemeldet. Schließen Sie daher die Verbindung, bevor Sie die Anwendung beenden.

4.4.2Sub-Sequencer-Ausführung

Der Sub-Sequencer ist dafür ausgelegt, Befehle schnell mit einem genau definierten Timing im Bereich weniger Millisekunden auszuführen. Beim Senden von Befehlen über die normale Befehlsausführung hängt das Timing zwischen den Befehlen vom Timing des Windows-Betriebssystems auf dem PC ab. Bei einem solchen Nicht-Echtzeit-Betriebssystem kann das Timing zwischen wenigen Millisekunden und mehreren Sekunden schwanken.

Sub-Sequencer-Ausführung bedeutet, mehrere Befehle auf RT zu laden, sie ohne vom PC verursachte Verzögerungen auszuführen und mehrere Antworten an den PC zurückzugeben. Die Antworten können in der PC-SW mit unkritischem, schwankendem Timing ausgewertet werden.

Befehlsablauf des Sub-Sequencers

Um eine Subsequenz zu verwenden, muss der folgende Befehlsablauf implementiert werden

Befehlsausführung des Sub-Sequencers aus RT-Sicht

Aus RT-Sicht bedeutet Sub-Sequencer-Ausführung einfach, ein Array von Befehlsstrings vom PC zu empfangen. Das Array mit den einzelnen auszuführenden Befehlsstrings wird Element für Element abgearbeitet. Die Antworten der einzelnen Befehle werden in einem String-Array gesammelt und an den PC zurückgegeben.

Befehlsausführung des Sub-Sequencers aus PC-Sicht

Aus PC-Sicht bedeutet Sub-Sequencer-Ausführung, die Einheit für die Befehls-/Antwortverarbeitung in drei Teile aufzuteilen:

• Befehl zur Subsequenz hinzufügen (für mehrere Befehle wiederholt)
• Gesamte Subsequenz ausführen
• Antwort der Subsequenz abrufen (für mehrere Befehle wiederholt)

Die Trennung zwischen normaler Befehlsausführung, Sub-Sequencer-„Load“ und Sub-Sequencer-„Get Result“ ist mit polymorphen VIs implementiert. Die Sub-Sequencer-Ausführung wird im Folgenden am Beispiel-VI „CAN_EOL_SendReceive.vi“ erläutert:

Zunächst wird die normale Befehlsausführung von CAN_EOL_SendReceive.vi dargestellt, um den Unterschied zur Sub-Sequencer-Ausführung zu zeigen

CAN_EOL_SendReceive, normale Ausführung:

Can_SendMultipleMsgs:

Für die Sub-Sequencer-Ausführung müssen die drei farbig markierten Teile auf mehrere VIs aufgeteilt werden. Der Teil „Execute Subsequence“ ist generisch und kann von jedem Befehl verwendet werden. Für jeden Befehl müssen jedoch die folgenden Teile separat mit polymorphen VIs implementiert werden:

• COMMAND_XXX_AddToSubsequence
  • enthält die Formatierung des Befehlsstrings und speichert den Befehlsstring im angegebenen Befehlscontainer der Subsequenz
• COMMAND_XXX_GetResult
  • enthält das Lesen des Antwortstrings der angegebenen Sequenz und des angegebenen Schritts. Der formatierte Antwortstring wird entpackt und in die entsprechenden Antwortparameter umgewandelt.

Add to Subsequence (befehlsspezifisch)

Execute Subsequence (ein generisches VI für alle Befehle)

GetResult (befehlsspezifisch)

4.5Fehlerbehandlung

4.5.1Allgemeine Fehlerbehandlung

Jedes implementierte VI hat einen Fehlereingang und einen Fehlerausgang.

Alle VIs geben Fehlercodes im Cluster „error out“ zurück.

Wird dem VI an „error in“ ein Fehler mit einem Fehlercode ungleich null übergeben,

• wird der Code des VI nicht ausgeführt
• wird der Fehlercode an „error out“ durchgereicht

Es wird empfohlen, Fehlereingang und Fehlerausgang mit einem benutzerdefinierten Fehlerhandler in der Anwendung zu verbinden. So ist sichergestellt, dass die Kommunikation mit dem MesSy und alle Parameter geprüft werden und der Benutzer der Anwendung Informationen über den Status von MesSy und Software erhält.

4.5.2Fehlercodes

Im Feld „code“ von „error out“ wird ein Fehlercode zurückgegeben, der entweder von einem VI der Standard-LabVIEW-Bibliothek oder von der MesSy-Software erzeugt wird. Werte unter 5000 einschließlich negativer Werte sind Standard-LabVIEW-Fehlercodes. Werte darüber sind MesSy-Fehlercodes.

Die MesSy-Fehlercodes sind wie folgt gegliedert:

Die Klassifizierung legt die Kritikalität des Fehlers fest, wobei ein Systemfehler als schwerer Fehler gilt.

Ein DUT-Fehler bedeutet, dass das MesSy-System noch arbeitet, aber beispielsweise eine CAN-Nachricht vom Prüfling nicht beantwortet wurde.

Eine Warnung dient lediglich zur Information.

Die Quelle ist der Softwareblock, der einen Fehler erkannt hat.

Der Typ klassifiziert einige typische Fehlerarten.

Die folgenden Tabellen zeigen die implementierten Fehlercodes und den zugehörigen Fehlertext, der im Cluster „error out“ unter „source“ ausgegeben wird:

• DUT-Fehler:

• Systemfehler:

4.6Messsystem-API (CORE_API)

Für den Zugriff einer Benutzeranwendung, typischerweise in LabVIEW erstellt, auf das MesSy steht eine VI-Bibliothek (API) zur Verfügung. Der Funktionsumfang der Bibliothek wird künftig erweitert. Die Dokumentation der Bibliothek ist deshalb elektronisch verfügbar.

Der normale Befehlsablauf der CORE API ist identisch mit dem in Kapitel 5.4.1 beschriebenen Ablauf.

4.6.1Adressierungsarten der CORE_API

Zur Adressierung eines bestimmten MesSy wird dessen IP-Adresse verwendet. Jedes VI der Bibliothek hat dazu einen String-Eingangsparameter namens „IP Address“, der die IP-Adresse als String enthält (z. B. 192.168.101.2 – ohne Anführungszeichen eingeben)

Beachten Sie, dass bei jedem Befehl ein Slot-Parameter übergeben wird. Dieser Parameter dient dazu, mehrere Prüflinge an einem Messsystem zu unterscheiden. Bei Prüflingen mit nur wenigen Pins und Funktionen kann ein Messsystem bis zu 6 Prüflinge parallel bedienen. Wenn in diesem Fall mehr als eine Testausführung mit dem Messsystem verbunden ist, muss die Kommunikationsroutine die Verbindungen für die Testausführung jedes Prüflings prüfen. Sie darf die Verbindung erst schließen, wenn alle Testausführungen aller Prüflinge die Verbindung geschlossen haben. Der Slot repräsentiert also den Prüfling am Messsystem.

4.6.2Funktionsblöcke

In der API stehen verschiedene Funktionsblöcke zur Verfügung. Jedes VI hat ein Präfix PC_xxx, wobei xxx der Block gemäß der folgenden Tabelle ist:

4.7Lebensdauertest-API mit benannten Kanälen (TS_API)

Für den Zugriff aus TestStand auf das MesSy steht eine VI-Bibliothek (API) zur Verfügung, die komfortabler ist als die CORE_API. Diese Bibliothek heißt TS_API. Diese zusätzliche Softwareschicht über der CORE_API erleichtert dem Benutzer die Gestaltung des Prüfablaufs, insbesondere wenn mehrere Prüflinge entweder mit einem MesSy oder mit mehreren MesSys geprüft werden müssen.

Der normale Befehlsablauf der TS_API entspricht im Wesentlichen dem in Kapitel 5.4.1. Unterschiede sind die Adressierung des MesSy über die Nummern „Bus“ und „Slot“ sowie die Signalzuordnung zur Adressierung des physischen Analog-, Digital- oder Kommunikationskanals.

Der Funktionsumfang der Bibliothek wird künftig ebenso wie die CORE_API erweitert. Die Dokumentation der Bibliothek ist deshalb elektronisch verfügbar.

4.7.1Adressierung über Bus, Slot und Signalname

Die TS_API unterscheidet sich von der CORE_API in der Adressierung der physischen Kanäle des MesSy. Während in der CORE_API jeder physische Kanal über die IP-Adresse des MesSy und die physische Kanalnummer adressiert wird (z. B. 1…96 für die Single-Ended-Analogeingänge SE_1to96, Serial_01 … SERIAL_10, 1…24 für FET, ...), erfolgt die Adressierung in der TS_API über „Bus“, „Slot“ und „Signalname“:

• Bus:
  • Bereich = [0…255]
  • Ist die letzte Zahl der IP-Adresse.
  • Der Rest der IP-Adresse – der IP-Adressbereich – wird in der Signalzuordnungsdatei festgelegt (siehe Signalzuordnung).
  • Z. B.: Bei Bus = 12 und dem IP-Adressbereich „192.168.100.“ lautet die IP-Adresse des adressierten MesSy „192.168.100.012“,
• Slot:
  • Bereich = [1…6]
  • Die MesSy-Software ist so ausgelegt, dass ein MesSy bis zu 6 Prüflinge bedienen kann.
  • Die Slot-Nummer steht für die Nummer des Prüflings.
  • Der Slot wählt gemäß der Signalzuordnungsdatei den passenden physischen Kanal eines MesSy aus (siehe Signalzuordnung).
• Signalname
  • Der Signalname ist ein frei wählbarer Name, der einem Signal entspricht (typischerweise dem Signalnamen des Prüflings), das entweder an einen Analogeingang, einen Digitalausgang oder eine Kommunikationsleitung angeschlossen ist.
  • Die Zuordnung der physischen Kanäle zu Signalnamen erfolgt in der Signalzuordnungsdatei (siehe Signalzuordnung).

Bedient ein MesSy beispielsweise drei Prüflinge, ist derselbe Signalname an einem MesSy dreimal vorhanden. Der richtige physische MesSy-Kanal wird über die jeweilige Slot-Nummer ausgewählt.

4.7.2Signalzuordnung

Die Signalzuordnungsdatei enthält zunächst den IP-Adressbereich aller angeschlossenen MesSys. Der IP-Adressbereich umfasst die ersten drei Zahlen der IP-Adressen (z. B. 192.168.101.).

Außerdem enthält diese Datei die Anzahl der Slots, d. h. die Anzahl der angeschlossenen Prüflinge und der zugehörigen Ausführungen. Und schließlich ist in dieser Datei für jeden Slot die Zuordnung der Signalnamen zu Analogeingängen, Digitalausgängen, Relais und Kommunikationsleitungen festgelegt.

Die Signalzuordnungsdatei wird als XML-Datei gespeichert. Das folgende XML-Beispiel zeigt den IP-Adressbereich (common_ip=192.168.101.), die Anzahl der Slots = 2 (count=2) und alle möglichen Signalgruppen.

Wird ein „name“ mehrfach verwendet, entweder für denselben Typ (Relais, Single-Ended-Eingang, …) oder für verschiedene Typen, fügen Sie die folgende Eigenschaft hinzu (wie im Beispiel für den Analogeingang gezeigt)

resourcesharing = "1"

Andernfalls wird beim Laden der Signalzuordnungsdatei ein Fehler gemeldet. Diese Funktion hilft, unerwünschte Mehrdeutigkeiten zu vermeiden.

<?xml version="1.0" encoding="utf-8"?>
<ldsa name="LDSA" count="2" common_ip="192.168.101.">
<modules>
<module name="ANALOG">
   <item name="Example_Signal_Name_Analog_1">
    <connector slot="1" name="SingIn_11" resourcesharing="1"/>
    <connector slot="2" name="SingIn_59" />
   </item>
   <item name="Example_Signal_Name_Analog_2">
    <connector slot="1" name="SingIn_12" />
    <connector slot="2" name="SingIn_60" />
   </item>

   <item name="Example_Signal_Name_Analog_Differential">
    <connector slot="1" name="DiffIn_01a" />
    <connector slot="2" name="DiffIn_09a" />
   </item>
</module>

<module name="RELAY">
   <item name="Relay_VBatt">
    <connector slot="1" name="REL_15" />
    <connector slot="2" name="REL_47" />
   </item>
</module>

<module name="TRIGGER">
   <item name="TRIG1">
    <connector slot="1" name="TRIG_01" />
    <connector slot="2" name="TRIG_04" />
   </item>
</module>

<module name="OPENCOLLECTOR">
   <item name="GREEN">
    <connector slot="1" name="OPEN_COLL_16" />
    <connector slot="2" name="OPEN_COLL_14" />
   </item>
</module>

<module name="FET">
   <item name="PWM_Out">
    <connector slot="1" name="FET_1" />
    <connector slot="2" name="FET_13" />
   </item>
</module>

<module name = "CMM">
  <item name ="CMM">
    <connector slot = "1" name = "CMM_1"/>
    <connector slot = "2" name = "CMM_2"/>
  </item>
</module>

<module name="CAN">
   <item name="COMM_CAN">
     <connector slot="1" name="CAN_1A" />
     <connector slot="2" name="CAN_2A" />
   </item>
   <item name="CAN_Second">
     <connector slot="1" name="CAN_1B" />
     <connector slot="2" name="CAN_2B" />
   </item>
</module>

<module name="SERIAL">
   <item name="K-Line">
     <connector slot="1" name="SERIAL_01" />
     <connector slot="2" name="SERIAL_06" />
   </item>
</module>

<module name="I2C"
  <item name="I2CName">
     <connector slot="1" name="0x42" /> <!-- name is the I2C address without the R/W bit -->
     <connector slot="2" name="0x13" />
  </item>
</module>
</modules>
<itemgroupslist />
</ldsa>