SSV-Konzept

4.1Analyseprojekt

Ein SSV-Analyseprojekt ist eine einzelne Konfigurationsdatei, die alle Informationen zu Hardware-Setup, Kanaleinstellungen, Triggern, Fenstern und Funktionen enthält.

4.2Gerät

Ein „Gerät“ ist definiert als Kombination aus einer National Instruments FlexRio-FPGA-Karte und einem IRS SSV-Modul. Es ermöglicht eine echt parallele Abtastung mit definierten Abtastraten und Kanalzahlen (abhängig von den Fähigkeiten des SSV-Moduls). Die Geräteressource entspricht der Aliasdefinition der FlexRio-Basiskarte in MAX, z. B. „Rio01“

Ein Gerät wird immer aus einer Vorlage erstellt, die die Fähigkeiten und Eigenschaften des Moduls vollständig definiert. Um ein Gerät zu konfigurieren, verwenden Sie den Channel Explorer

4.2.1Geräteeigenschaften

Benutzerdefinierte Einstellungen

Feste Einstellungen (schreibgeschützt)

4.3Kanal

Ein Kanal stellt einen Analogeingang des Geräts dar, zu dem er gehört. Jeder Kanal stellt außerdem eine Triggerquelle dar, die auch von jedem anderen Kanal desselben Geräts verwendet werden kann. Jeder Kanal hat seine eigenen Triggereinstellungen. Ein Window-Set kann mehreren Kanälen zugewiesen werden. Die Fähigkeiten des physischen Kanals hängen vom Modul ab, Einzelheiten finden Sie in der Hardwaredokumentation.

Um einen Kanal zu konfigurieren, verwenden Sie den Channel Explorer

4.3.1Kanaleigenschaften

Benutzerdefinierte Einstellungen

Laufzeiteigenschaften (nicht gespeichert)

Feste Einstellungen (schreibgeschützt)

4.4Trigger

Ein Trigger ist ein Ereignis, das den zugehörigen Kanal veranlasst, die Abtastung zu starten oder den Triggerabstand auf 0 zurückzusetzen (Beginn einer neuen Messperiode). Jeder Trigger kann entweder seinen Kanal (= Selbsttrigger), einen anderen Trigger (= Referenztrigger) oder einen Timer als Quelle verwenden. Einzelheiten finden Sie unter Triggertypen.

Um einen Trigger zu konfigurieren, verwenden Sie das Fenster Trigger Setup.

4.4.1Triggereigenschaften

Benutzerdefinierte Einstellungen

Feste Einstellungen (schreibgeschützt)

4.4.2Triggertypen

Jeder Trigger kann konfiguriert werden als

• Selbsttrigger
• Referenztrigger
• Timer-Trigger

Beispiel-Setup

• Channel1: Selbsttrigger
• Channel2: Referenztrigger (Trg01)
• Channel3: Referenztrigger (Trg01)
• Channel4: Selbsttrigger
• Channel5: Timer-Trigger

Selbsttrigger

Beim Triggertyp Self verwendet der Trigger den Eingang des zugehörigen Kanals als Triggerquelle. Sie müssen Flankenrichtung, Schwellwert, Blackout Time (optional) und Rearming (optional) angeben. Ist in diesem Modus zusätzlich ein Referenztrigger definiert, wird der Referenztrigger nur für zusätzliche Timing-Prüfungen verwendet (siehe Trigger-Testfunktionen).

Referenztrigger

Wird ein Referenztrigger verwendet, wird der physische Kanaleingang ignoriert und stattdessen direkt ein anderes (vorhandenes und konfiguriertes) Triggersignal verwendet. In diesem Fall wird das Triggerereignis einer anderen Triggerquelle verwendet. Auf den Kanal kann eine Startverzögerung angewendet werden, um ähnliche Signale auf verschiedenen Kanälen mit bekanntem Versatz zueinander auszurichten. Jeder Kanal kann eine eigene [Trigger Delay] [ms] festlegen, die zur ursprünglichen Triggerzeit addiert wird. So lässt sich eine Gruppe ähnlicher, aber kanalweise verzögerter Signale bilden, die sich nach dieser Ausrichtung dasselbe Window-Set teilen können. Das ist nützlich für abhängige Signale, die synchron relativ zu einem bestimmten Ereignis erfasst werden sollen.

Beispiel: Ein Motorsteuergerät steuert 6 Zylinder mit nahezu identischen Einspritzsignalen an, die pro Umdrehung um 60° versetzt sind. In diesem Fall können Sie den ersten Kanal als Referenz verwenden und auf die Kanäle 2–6 entsprechende Offsets anwenden. Nun haben Sie auf allen 6 Kanälen ähnlich getriggerte Kurven und können ein einziges Window-Set mit Analysefunktionen verwenden.

Timer-Trigger

Eine weitere Möglichkeit ist ein „Timer-Trigger“, der alle [Trigger Distance] ms periodisch ein Triggerereignis erzeugt. Das ist besonders nützlich bei statischen oder instabilen Signalen, die sich sonst nicht sauber triggern und überwachen ließen.

Blackout Time (Hold-off)

Nach einem Triggerereignis ignoriert der Trigger für diese Zeit (in ms) alle weiteren Ereignisse. Der Wert 0 deaktiviert diese Funktion Es wird empfohlen, mindestens etwa 20 % der erwarteten Zykluszeit anzugeben, um Fehltrigger durch Rauschen usw. zu vermeiden.

Trigger-Rearming

Manche Signale haben keinen charakteristischen Triggerpegel, der ein definiertes Triggern an einem bestimmten Punkt erlaubt. In vielen Fällen hilft hier die Rearming-Funktion. Bleibt das Signal für eine definierte Mindestzeit (Rearming min time) innerhalb eines bestimmten Spannungsbereichs (Rearming LowerBound/UpperBound), wird der Trigger scharf geschaltet und löst bei der nächsten gültigen Schwellwert-/Flankenbedingung aus. Beachten Sie, dass der Trigger nicht sofort auslöst, wenn die Rearming-Bedingung erfüllt ist! Sie ist lediglich eine Vorbedingung, die das Triggern „erlaubt“.

Ist eine Rearming-Zeit definiert, löst der nächste Trigger erst aus, wenn das Signal die Rearming-Bedingungen erfüllt hat.

Referenztrigger-Prüfung

In diesem Fall verwenden zwei Kanäle ihre eigenen Triggerquellen (Selbsttrigger). Ist zusätzlich eine Referenztriggerquelle konfiguriert, kann sie zur Überwachung von Timing-Bedingungen zwischen eigenem Trigger und Referenztrigger verwendet werden: Überschreitet der gemessene Abstand die Grenzwerte, wird ein Fehler „TriggerDelay“ gemeldet.

In diesem Beispiel definieren die Parameter TriggerRefDelayMin und TriggerRefDelayMax einen zusätzlichen Test.

Prüfung des Triggerabstands

Sind die Triggerparameter „Trigger Distance Min“ und „Trigger Distance Max“ ungleich 0 gesetzt, wird zusätzlich die Periode des Selbsttriggers geprüft, um Jitter oder fehlende Trigger zu erkennen. Überschreitet die gemessene Periode die Grenzwerte, wird ein Fehler „TriggerDistance“ gemeldet.

Triggerzähler

Ist der Triggerparameter „Show Trigger Counter“ auf „true“ gesetzt, wird jedes Triggerereignis gezählt. Diese Funktion wird häufig verwendet, um ein „Einzelereignis“ zu prüfen.

4.5Window-Sets

Ein Window-Set ist eine benannte Sammlung von Analysefenstern (AnalysisWindows). Window-Sets können beliebig vielen Kanälen zugewiesen werden, alle zugewiesenen Kanäle müssen jedoch denselben Gerätetyp verwenden. Die Anzahl der Fenster pro Window-Set und der Analysefunktionen pro Fenster ist durch die Geräteeigenschaften begrenzt.

4.6Analysefenster

Ein Analysefenster definiert einen bestimmten Zeitraum relativ zu einem Triggerereignis. Ein Analysefenster selbst hat keinerlei Funktionalität, es dient als Container für die Analysefunktionen, die es aufnehmen kann. Im WindowSet Editor wird es als rechteckiger Bereich dargestellt (siehe Beispiel unten), der obere und der untere Rand sind jedoch nur für die Funktionen UpperLimit und LowerLimit relevant. Alle anderen Funktionen verwenden nur den Zeitraum (linker und rechter Rand) und bieten eigene zusätzliche Parameter.

Analysefenster sind in Window-Sets organisiert.

4.7Analysefunktionen

Definition

Analysefunktionen führen Echtzeittests innerhalb eines bestimmten Analysefensters durch.

Eigenschaften

Jedes Analysefenster verfügt über einen festen Satz (physisch fest verdrahteter) anwendbarer Analysefunktionen.

Jedes Fenster kann alle verfügbaren Funktionen gleichzeitig aktivieren, ohne die Gesamtleistung zu beeinträchtigen. Nur aktivierte Funktionen werden zur Laufzeit ausgewertet und gemeldet.

Jede Funktion verwaltet ihren eigenen Fehlerzähler (pro Kanal und Fenster). Dieser Zähler wird um 1 erhöht, wenn die Testbedingungen innerhalb des Fensters nicht erfüllt sind (auch bei mehreren Fehlschlägen). Die maximale Anzahl an Fehlschlägen ist auf 255 begrenzt. Werden weitere Fehler erkannt, bleibt der Wert bei 255 (kein Überlauf).

Außerdem hat jede Funktion einen Rückgabewert, der üblicherweise als Messwert verwendet wird, auch wenn kein Fehler aufgetreten ist. Um einen gültigen Wert zurückzugeben, muss das gesamte Fenster mindestens einmal ausgeführt worden sein. Mit anderen Worten: Es kann kein gültiger Messwert zurückgegeben werden, wenn kein Trigger aufgetreten ist oder nicht mindestens eine Periode des Signals gelesen wurde. Zur Unterstützung der Auswertung hat jeder Wert außerdem ein Gültigkeitsflag.

Um alle Fehlerzähler zurückzusetzen, lesen Sie die SSV-Ergebnisse aus dem Modul aus (ein einzelner Fehlerzähler kann nicht zurückgesetzt werden)

Funktionsübersicht

• Average
• Area Check
• Duty Cycle
• Edge Counter
• Lower Limit
• Upper Limit

4.7.1Average

Average berechnet den arithmetischen Mittelwert aller Abtastwerte innerhalb der (linken und rechten) Fenstergrenzen. Die Grenzwerte werden angewendet, wenn der rechte Rand des Fensters erreicht ist. Werden die Grenzwerte überschritten, wird der Fehlerzähler „Average“ um 1 erhöht (bis 255, danach bleibt er bei 255)

Ausgabewert

Arithmetischer Mittelwert, ausgewertet 1 Abtastwert nach Abschluss des Fensters

Parameter

Minimum

Niedrigster zulässiger Wert des berechneten Mittelwerts

Maximum

Höchster zulässiger Wert des berechneten Mittelwerts

Beispiel

4.7.2Area Check

Prüft die minimale/maximale Zeit aufeinanderfolgender Abtastwerte zwischen oberer und unterer Schwelle.

Testergebnis

Die Funktion ist PASSED, wenn die gemessene Zeit innerhalb des Zeitlimits Min/Max liegt

Parameter

Time Limit Max

Maximale Zeit (in Millisekunden) aufeinanderfolgender(!) Abtastwerte im Bereich

Time Limit Min

Minimale Zeit (in Millisekunden) aufeinanderfolgender (!) Abtastwerte im Bereich

Upper Bound

Legt den oberen Pegel des Erkennungsbereichs fest.

Lower Bound

Legt den unteren Pegel des Erkennungsbereichs fest.

Entry Check Mode: Legt fest, ob jeder Abschnitt des Signals, der zwischen Upper und Lower Bound liegt, innerhalb von Time Limit Min und Max liegen muss oder nur der größte Abschnitt aufeinanderfolgender Abtastwerte.

• 1 = strict: Jeder Abschnitt muss innerhalb der Zeitgrenzen liegen.
• 0 = tolerant: Nur der größte Abschnitt muss innerhalb der Zeitgrenzen liegen.

Area-Check-Szenarien

a) Kein Puls zulässig

Dieser Modus dient zur Überprüfung, dass im definierten Zeitraum kein Signal auftritt. Tritt ein Puls auf, ist dies ein Fehler. Daher werden die Min/Max-Grenzen auf 0 gesetzt.

b) 100 % Puls

Das Signal liegt im definierten Zeitraum vollständig von Anfang bis Ende an. Time Limit muss genau so lang sein wie das Fenster.

c) Jeder Puls innerhalb der Grenzen

1 = strict: Jeder Abschnitt muss innerhalb der Grenzen liegen.

d) Maximaler Puls innerhalb der Grenzen

0 = tolerant: Nur der größte Abschnitt muss innerhalb der Zeitgrenzen liegen.

4.7.3Duty Cycle

Duty Cycle berechnet das Verhältnis der High-Zeit des Signals (Zeit zwischen den Übergängen an der oberen und der unteren Schwelle) zur Gesamtzeit des Fensters.

Die „High“-Phase beginnt, wenn das Signal mit steigender Flanke die obere Schwelle durchläuft, und dauert an, bis das Signal die untere Schwelle in fallender Richtung durchläuft. Die Summe der High-Phasen geteilt durch die Gesamtzeit des Fensters wird als Tastverhältnis ausgewertet und ergibt einen Ausgabebereich von 0...100 %

Ausgabewert

Tastverhältnis (0...1)

Parameter

Minimum

Niedrigstes zulässiges Tastverhältnis (>= 0 %)

Maximum

Höchstes zulässiges Tastverhältnis (<= 100 %)

Testergebnis

Die Funktion ist PASSED, wenn das Tastverhältnis zwischen Minimal- und Maximalwert liegt (oder ihnen gleich ist). Andernfalls wird der Fehlerzähler um 1 erhöht (bis 255)

Beispiel

4.7.4Edge Counter

Duty Cycle zählt die Übergänge zwischen der Erkennung der oberen und der unteren Schwelle innerhalb der Zeitspanne des Fensters.

Die „High“-Phase beginnt, wenn das Signal mit steigender Flanke die obere Schwelle durchläuft, und dauert an, bis das Signal die untere Schwelle in fallender Richtung durchläuft. Die Summe der Wechsel innerhalb der Gesamtzeit des Fensters wird als Flankenzahl ausgewertet.

Ausgabewert

Flankenzahl (max. 65.536)

Parameter

Minimum

Minimale Anzahl erwarteter Flanken (>= 0)

Maximum

Höchste Anzahl erwarteter Flanken (<= 65.536)

Testergebnis

Die Funktion ist PASSED, wenn die Flankenzahl zwischen Minimal- und Maximalwert liegt. Andernfalls wird der Fehlerzähler um 1 erhöht (bis 255)

Beispiel

4.7.5Upper/Lower Limit

Upper Limit und Lower Limit erkennen Verletzungen des jeweiligen Fensterrands. Im Gegensatz zu den meisten anderen Funktionen werden die Fehler unmittelbar nach der ersten Grenzwertverletzung erkannt.

UpperLimit und LowerLimit sind unabhängige Funktionen, beide können optional und unabhängig voneinander auf jedes Fenster angewendet werden. Jede Funktion hat ihren eigenen Fehlerzähler und Rückgabewert. Werden die Grenzwerte überschritten, wird der Fehlerzähler „Average“ um 1 erhöht (bis 255, danach bleibt er bei 255).

Ausgabewert

Der Minimal-/Maximalwert innerhalb der zeitlichen Fenstergrenzen.

Parameter

Check max (/min) value in window

Wenn ausgewählt, prüft die Funktion zusätzlich, ob der erkannte Messwert (niedrigster/höchster Wert) innerhalb der Fenstergrenzen liegt. Andernfalls schlägt die Funktion fehl, auch wenn der angegebene Grenzwert nicht verletzt wurde.

Minimum

Niedrigster zulässiger Wert innerhalb der zeitlichen Fenstergrenzen.

Maximum

Höchster zulässiger Wert innerhalb der zeitlichen Fenstergrenzen.

Beispiel

4.8Quellen

Jedes einzelne Ergebnis hat im Bericht einen eindeutigen Quell-String. Die Projekteinstellungen legen fest, wie der Quell-String im Bericht und in der Auswertung gebildet wird

Signalquellen

Signalquellen werden als Kombination aus <Device>/<Channel>/<WindowName>/<FunctionName> gebildet (wobei der Inhalt von <Device> und <Channel> von ProjectSettings/Resource Lookup Mode abhängt)

z. B.

RIO0/INJ_0_Current/I_Hold0/Average
RIO0/INJ_0_Current/I_Peak/UpperLimit

Virtuelle Quellen

Die meisten Messungen beziehen sich auf eine eindeutige Kombination aus Gerät/Signal/Fenster/Funktion. In einigen Situationen muss ein Fehler oder eine Warnung gemeldet werden, die sich nicht auf eine Fensterfunktion beziehen kann:

• Device/Signal/TriggerCounter
• Device/Signal/TriggerDelay
• Device/Signal/TriggerDistance

z. B.

RIO0/INJ_0_Current/TriggerDistance

4.9Testergebnisse

Nach dem Start überwachen alle SSV-Module die Analogeingänge permanent gemäß den Projekteinstellungen. Um den aktuellen Überwachungsstatus zu erhalten, ist ein Aufruf von „read results“ erforderlich (API-Funktion).

Dieser Aufruf

• gibt jeden Messwert zurück
• gibt alle Fehlerzähler zurück
• setzt alle Fehlerzähler zurück

Eine Vorschau dieser Aktion ist auch im Projekteditor verfügbar, siehe Log-Fenster

4.10API

Übersicht der SSV-Softwarearchitektur

4.10.1LabVIEW

Siehe SSV API.LabVIEW.chm

4.10.2.NET

Siehe SSV API.NET.chm

4.10.3Verwendung der API

Um die Projektkonfigurationsdatei in Ihrer Testumgebung zu verwenden, wählen Sie eine der verfügbaren APIs (Application Programmer Interface):

Die =>.NET API ist für den Einsatz in nicht LabVIEW-basierten Umgebungen vorgesehen, die .NET unterstützen. Da FlexRIO stark von LabVIEW abhängt, verwendet der Kerntreiber intern weiterhin LabVIEW und stellt seine Funktionalität einem .NET-Wrapper und, darauf aufbauend, auch COM (ActiveX) zur Verfügung. Mit anderen Worten: Wenn Ihre Testumgebung die direkte Verwendung von LabVIEW-VIs unterstützt (z. B. LabVIEW-Programm, NI TestStand), sollten Sie die =>LabVIEW API bevorzugen. Die Funktionalität ist nahezu gleich, im Detail gibt es jedoch kleine Unterschiede.

Die Installationsvoraussetzungen sind für beide Architekturen identisch, da auch der LabVIEW-Treiber intern einige .NET-Assemblies benötigt. Voraussetzungen für LV und .NET siehe Systemvoraussetzungen

Übersicht

Unabhängig von der gewählten API ist die grundsätzliche Handhabung gleich. Das folgende Diagramm zeigt die grundlegende Funktionsweise von SSV (ohne optionale Funktionen wie Baselining, digitale E/A usw.) Das folgende Bild beschreibt den häufigsten Anwendungsfall von SSV-Modulen in einer Überwachungsschleife. Weiterführende Funktionen finden Sie in der API-Dokumentation.

Ergebnisauswertung

Read Results / Evaluate Results / Get Results / Get All Values?!

Get Results

Liest die Daten aus dem FPGA, wertet die Rohdaten gemäß den Benutzereinstellungen aus und gibt alle Daten in einem Schritt zurück. Diese Funktion ist der Kombination ReadResults + Evaluate + GetAllValues vorzuziehen, wenn Sie die Daten nicht erneut auswerten müssen. Der Aufruf dieser Funktion setzt außerdem die SSV-Fehlerzähler aller Geräte zurück. Empfohlene Methode für die meisten Anwendungsfälle. Eine Beschreibung des Datenformats finden Sie unter „Evaluate Results“.

Read Results

Liest einen neuen Ergebnissatz aus dem SSV-FPGA und wertet die Ergebnisse (optional) in eine interne Sammlung aus, gibt die Auswerteergebnisse aber nicht zurück! Diese Werte können Sie mit GetAllValues oder GetValue lesen. Außerdem werden alle Fehlerzähler zurückgesetzt Beachten Sie, dass diese ältere Methode die Option „Include Warnings“ für die Auswertung nicht bietet. Warnungen sind enthalten, wenn „Errors Only“ false ist. Um einen Ergebnissatz nur mit Fehlern, aber auch mit Warnungen zu erhalten, verwenden Sie stattdessen Get Results!

Evaluate Results

Wertet die Rohmesswerte eines vorherigen Aufrufs von „Read Results“ pro aktiviertem Gerät und aktivierten Kanälen (erneut) aus. Es werden KEINE Daten von der Hardware gelesen und keine Fehler zurückgesetzt! Evaluate Results gibt einen menschenlesbaren Satz von Ergebniselementen mit folgenden Bestandteilen zurück:

• Name (Signalname)
• Errors (Anzahl der seit dem letzten Lesevorgang erkannten Fehler)
• Source (eindeutige Datenkennung, z. B. device/signal/window/function)
• Infotext (üblicherweise die angewendeten Grenzwerte)
• Value (Messwert, Bedeutung abhängig von der Funktion)
• Upper Limit (maximaler inklusiver Grenzwert für den Wert)
• Lower Limit (minimaler inklusiver Grenzwert für den Wert)

Get All Values

Gibt alle ausgewerteten Ergebnisse zurück oder wertet sie aus, falls das noch nicht geschehen ist. Es erfolgt kein Hardwarezugriff! Diese Funktion wurde eingeführt, um die Methode Read Results um den zusätzlichen Parameter „Include Warnings“ zu erweitern und gleichzeitig die Kompatibilität mit älterem Testcode zu wahren. Wird normalerweise nur intern oder zur erneuten Auswertung der Ergebnisse mit „Include Warnings“ aufgerufen. => Verwenden Sie entweder „Read Results“ oder „Get All Values“, nicht beides

Get Value

Gibt ein einzelnes Ergebniselement zurück, indem dessen Quell-String abgefragt wird. Beachten Sie, dass diese Funktion nicht auf den SSV-Treiber zugreift, sondern den Wert aus der intern zwischengespeicherten Sammlung „Results“ abruft!

Include Warnings

Ist diese Option ausgewählt, erhalten Sie auch Ergebnisse, die nicht als Fehler gewertet werden konnten, aber möglicherweise ein Problem darstellen. Eine Warnung meldet eine Fehleranzahl von „-1“ Mögliche Warnungen:

• Fehlender Trigger
• Fensterergebnisse als ungültig gemeldet (z. B. wenn das Fenster die Zykluszeit überschreitet und nie vollständig ausgewertet werden konnte)

Verwendung mehrerer Konfigurationsdateien

Der Treiber unterstützt das Laden mehrerer Konfigurationsdateien. Da das Laden einer Konfiguration relativ langsam ist, werden alle Konfigurationsdaten intern zwischengespeichert. Sie müssen jede Konfiguration in Ihrer Testumgebung nur einmal laden.

Ablauf bei mehreren Projektkonfigurationsdateien

1. Systemeinrichtung
2. Konfigurationsdatei A laden
3. Konfigurationsdatei B laden
4. Konfigurationsdatei C laden
5. Konfigurationsdatei D laden
6. Open Devices
7. Konfigurationsdatei A aktivieren
8. Clear Errors (?)
9. Tests durchführen / warten
10. Read Results
11. Konfigurationsdatei B aktivieren
12. Tests durchführen / warten
13. Read Results
14. Dasselbe für die Dateien C und D …
15. Bei Bedarf ab 7. wiederholen
16. Close Devices
17. Systembereinigung

4.11Baselining

Baselining ist ein Verfahren, um großzügig definierte allgemeine Grenzwerte während der Messung auf prüflingsspezifische Grenzwerte einzuengen. Dazu wird eine sogenannte Baseline erstellt, die während eines Kalibrierlaufs für jede Messung durchschnittliche Erwartungswerte sammelt. Diese Baseline ist projekt- und prüflingsspezifisch und kann nur als Ergänzung zur ursprünglichen Projektdatei angewendet werden.

Auf Basis dieser Durchschnittswerte kann (optional) für jeden Messwert eine Baseline-Toleranz definiert werden. Während des Testlaufs werden diese neuen Toleranzen mit den Grenzwerten der Fensterfunktionen kombiniert und ergeben in der Regel ein engeres Toleranzband. Die resultierenden dynamischen Grenzwerte können die ursprünglichen Grenzwerte jedoch nicht überschreiten.

Der Testbericht enthält die verwendeten Gesamtgrenzwerte (Projektgrenzwerte + dynamische Toleranz).

Baselining verwenden

• SSV-Projektkonfigurationsdatei laden
• Neue Baseline erstellen
• Mehrere Messungen in der gewünschten Umgebung durchführen
• Baseline aktivieren (berechnet die Durchschnittswerte, ändert die ursprünglichen Grenzwerte und schreibt sie in das FPGA)
• (optional) Baseline bereinigen (entfernt die Messwerte und behält die Durchschnittswerte)
• Baseline in einer Datei speichern (ssv_api:baseline_Save)