Analysen mit Triggern und Berechnungen¶

Berechnungsschritt¶

Ein Berechnungsschritt innerhalb einer Traceanalyse dient dazu, flexibel und schnell Signale anhand von Ausdrücken zu berechnen und zu bewerten. Hierfür steht ein Dialog zur Verfügung, welcher mithilfe der Schaltfläche Berechnungsschritt ( Calc_Symbol ) geöffnet werden kann.

Der Dialog zur Erzeugung eines Berechnungsschritts bietet folgende Einstellmöglichkeiten:

Allgemein

Im Feld Name kann ein aussagekräftiger Bezeichner für den Berechnungsschritt festgelegt werden, welcher dann auch in der Übersicht des Traceanalyse-Editors und im Report erscheint. Packagevariablen können innerhalb des Bezeichners mit der Syntax {Variablenname} verwendet werden. Im Report wird an dieser Stelle des Bezeichners dann der Wert der betreffenden Variablen eingesetzt.

Eine kurze Beschreibung des Berechnungsschritts kann im Feld Beschreibung eingetragen werden. Die Beschreibung kann ebenfalls Packagevariablen enthalten, die dann im Report durch ihren Wert ersetzt werden.

Ausdruck

In dem Eingabefeld muss der zu berechnende Ausdruck eingeben werden. Hierbei können Signale, Packagevariablen, Funktionsaufrufe sowie arithmetische Operationen verwendet werden. Die Auswahl der Signal-, Variablennamen und Funktionsbezeichner wird durch die integrierte Autovervollständigung unterstützt.

Info

Eine Übersicht verfügbarer Funktionen ist im Abschnitt Zusätzliche Funktionen für Ausdrücke zu sehen.

Beispiel: Es soll überprüft werden, ob Signalwerte eines Signals unter dem Wert 0.5 liegen.

Folgender Ausdruck wäre hierfür zu verwenden:

SignalToCheck < 0.5

Als Ergebnis liefert dieser Ausdruck ein diskretes Signal mit booleschen Signalwerten (also True oder False). In den Standard-Einstellungen des Berechnungs-Schrittes wird geprüft, dass dieses Ergebnis immer True ist.

Info

Die eigentliche Bewertung wird in der Dialogeinstellung Bewertung vorgenommen. Für Details dazu siehe weiter unten.

Speichern in

Sofern aktiviert, erfordert diese Einstellung die Angabe eines Signals in dem das Ergebnis des interpretierten Ausdrucks gespeichert werden soll. Die Eingabe eines unbekannten Signalnamens führt dazu, dass ein neues Signal mit diesem Namen automatisch angelegt wird.

Bewertung

Diese Einstellung erlaubt es, für das Ergebnis des Ausdrucks, eine testfallspezifische Bewertung zu erzeugen. Ist die Bewertung aktiviert, stehen die zwei Reiter Erwartung und Optionen zur Verfügung.

Erwartung

Im ersten Teil des Abschnitts Bewertung ist die Erwartungshaltung hinsichtlich der Zeitstempel anzugeben. Mögliche Werte sind der folgenden Tabelle zu entnehmen, in der jede Zeile für einen Modus steht; das heißt alle Einträge in einer Zeile können synonym verwendet werden.

Erwartungshaltung	Deutscher Alias	Englischer Alias
‚always‘	‚Überall erfüllt‘	‚Fulfilled everywhere‘
‚once‘	‚Mindestens einmal erfüllt‘	‚Fulfilled at least once‘
‚duration‘	‚Erfüllt für mindestens‘	‚Fulfilled for at least‘

‚Überall erfüllt‘

Wahr, wenn die Erwartung zu allen Zeitstempeln der verwendeten Signale erfüllt wird.
‚Mindestens einmal erfüllt‘

Wahr, wenn die Erwartung (in jedem Triggerbereich) zu mindestens einem Zeitstempel der verwendeten Signale erfüllt ist.
‚Erfüllt für mindestens‘

Wahr, wenn die Erwartung (in jedem Triggerbereich) zu einem Zeitstempel der verwendeten Signale erfüllt wird und ab diesem Zeitstempel für eine als Parameter zu übergebende Zeitspanne Mindestdauer gilt. Hierbei wird zugelassen, dass innerhalb der angegebenen Zeitspanne keine weiteren Samples vorhanden sind. Ist die Länge des überprüften Bereichs kleiner als „Mindestdauer“, wird der Bereich mit FAILED bewertet.

Das Verhalten für die Auswertung der „Mindestdauer“ kann mit zwei Schaltflächen beeinflusst werden. Die Schaltfläche legt fest, ob die Mindestdauer für einen Teilbereich oder summiert über alle erfolgreichen Teilbereiche gilt. Mit der Schaltfläche wird eingestellt, dass der Wert für die „Mindestdauer“ relativ in Prozent (%) angegeben wird.

Vorsicht

Wird eine relative Mindestdauer verwendet, kann der Berechnungsschritt nur innerhalb eines Triggerblocks verwendet werden!

Aufgrund des Sample-und-Hold-Prinzip, ist diese Einstellung nur geeignet wenn Samples der verwendeten Signale im gesamten Triggerbereich existieren.

Die Gesamtdauer wird von den tatsächlich bewerteten Teilbereichen bestimmt. Für den Übergang zweier Teilbereiche gilt ebenfalls das Sample-und-Hold-Prinzip.

Beispiel:
```
0.0 - 8.0       Trigger range
  1.0 - 2.0     subrange SUCCESS
  4.0 - 6.0     subrange FAILED
```
Resultiert in einem Teilbereich mit einer Dauer von 3.0 (1.0 bis 4.0) mit Ergebnis SUCCESS and einem Teilbereich mit einer Dauer von 4.0 (4.0 bis 8.0) mit Ergebnis FAILED. Dies entspricht 42.86% SUCCESS und 57,14% FAILED.

Im nächsten Teil ist die Erwartungshaltung an den Ausdruck genauer zu spezifizieren. Neben der einfachen Bewertung True kann dort auch eine numerische Prüfung statt finden. Damit ist es zum Beispiel möglich, auf einfache Weise Toleranzen zu definieren. Der Berechnungsschritt wird anhand der Erwartung mit SUCCESS oder FAILED bewertet, je nachdem ob der Ausdruck wahr (Erwartungshaltung erfüllt) oder falsch (Erwartungshaltung nicht erfüllt) ist.

Stellt man die Auswahlbox von unterstützt auf manuell oder wählt man als Datentyp Unspecific, kann die Erwartungshaltung in einem Textfeld als Python-Ausdruck beschrieben werden. Der resultierende Wert des Ausdrucks wird dabei durch das Schlüsselwort value referenziert.

Optionen

Im Unterpunkt Optionen können zusätzliche Einstellungen Bewertung gesetzt werden.
- Vektor/Matrix-Behandlung
  
  Ermöglicht es, vektor- oder matrixwertige Signale auf eine Erwartungsart wie beispielsweise „Numeric“ zu überprüfen. Je nach Einstellung muss die Erwartung in allen beziehungsweise in mindestens einer Komponente des Signals erfüllt werden, damit das Ergebnis der Bewertung SUCCESS ist.
- Ergebnis … setzen, falls der Bereich leer ist
  
  Falls der Ausdruck nicht an mindestens einem Zeitstempel berechnet werden kann wird das entprechende Ergebnis gesetzt.
- SUCCESS-Kommentar
  
  Alternativer Ergebnistext, welcher verwendet wird, wenn der Berechnungsschritt mit SUCCESS bewertet wird.
- FAILED-Kommentar
  
  Alternativer Ergebnistext, welcher verwendet wird, wenn der Berechnungsschritt mit FAILED bewertet wird.

Fundstellen im Report dokumentieren

Konfiguration der maximal angezeigten Fundstellen im Report. Der Mindestabstand gibt an, wie nah die angezeigten Fundstellen zueinander liegen dürfen. Fundstellen, die innerhalb dieses Mindestabstands liegen, werden dennoch im Report angezeigt, falls sie eine schlechtere Bewertung haben als die bisher am schlechtesten bewertete, im Report angezeigte Fundstelle.

Triggerblöcke¶

Triggerblöcke dienen dazu, gezielt bestimmte Bereiche im Signalverlauf zu finden und für diese eine Analyse anhand der im Triggerblock enthaltenen Traceschritte durchzuführen. Ein neuer Triggerblock kann durch das Symbol Trigger_Symbol (“Neuer Triggerblock“) im Traceschritt-Fenster hinzugefügt werden. Durch einen Mausklick auf dieses Symbol öffnet sich ein Dialog zur Konfiguration des Triggerblocks.

Der Dialog für den Triggerblock bietet folgende Einstellmöglichkeiten:

Allgemein

Im Feld Name kann ein aussagekräftiger Bezeichner für den Triggerblock festgelegt werden, welcher dann im Traceschritt-Fenster angezeigt wird. Der Bezeichner kann auch Packagevariablen enthalten. Diese werden während der Ausführung durch ihren Wert ersetzt.

Eine kurze Beschreibung des Triggerblocks kann im Feld Beschreibung eingetragen werden. Die Beschreibung kann ebenfalls Packagevariablen enthalten.

Parameter

Die Parametrierung von Triggerblöcken ist in drei Tabs Bedingungen, Erweiterte Optionen und Report untergliedert, die nachfolgend beschrieben werden.

Bedingungen

Auf dem Tab Bedingungen kann die grundlegende Funktionalität eines Triggerblocks mit folgenden Einstellungen parametriert werden:

Modus:

Der (Trigger-)Modus spezifiziert, wie Triggerbereiche durch die Bedingungen in Start- (und eventuell Stoptrigger) erzeugt werden sollen. Mögliche Werte sind der folgenden Tabelle zu entnehmen, in der jede Zeile für einen Modus steht; das heißt die ersten drei Einträge einer Zeile können synonym verwendet werden.

Modus	Deutscher Alias	Englischer Alias	Benötigt Stoptrigger
‚while start trigger‘	‚solange Starttrigger erfüllt‘	‚as long as start trigger is fulfilled‘	nein
‚start trigger while not stop trigger‘	‚ab Starttrigger solange nicht Stoptrigger erfüllt‘	‚from start trigger as long as stop trigger is not fulfilled‘	ja
‚start trigger to next stop trigger‘	‚ab Starttrigger bis zum nächsten Mal Stoptrigger erfüllt‘	‚from start trigger until next time stop trigger is fulfilled‘	ja
‚start trigger with time offsets‘	‚mit Zeitversatz wenn Starttrigger erfüllt‘	‚with time offset if start trigger is fulfilled‘	nein

Triggerbereiche werden standardmäßig als linksgeschlossene, rechtsoffene Intervalle angelegt. Der Startzeitpunkt des Triggerbereichs gehört zum Triggerbereich, wohingegen der Stopzeitpunkt in der Regel nicht zum Triggerbereich gehört.

Info

Per Definition kann ein neuer Triggerbereich (außer im letzten Modus) erst mit dem nächsten Zeitschritt nach dem Ende des vorherigen Triggerbereichs beginnen.

‚solange Starttrigger erfüllt‘

In diesem Modus wird ein Triggerbereich dadurch definiert, dass die Starttrigger-Bedingung in diesem Bereich ununterbrochen erfüllt ist. Der Triggerbereich beginnt, wenn die Starttrigger-Bedingung erfüllt ist und endet, sobald die Starttrigger-Bedingung nicht mehr erfüllt ist.

Hat ein Signal beispielsweise Zeitstempel im Intervall [0, 5) und gilt die Starttrigger-Bedingung an dieses Signal überall, außer im Bereich mit Zeitstempeln von 2 bis 4 (genauer im Intervall [2, 4)), so werden die zwei Triggerbereiche [0, 2) und [4, 5) erzeugt.

Info

Dieser Modus verhält sich wie eine Bedingung (If-Statement) in Programmiersprachen.
‚ab Starttrigger solange nicht Stoptrigger erfüllt‘

In diesem Modus wird der Anfang eines Triggerbereichs durch Starttrigger- und Stoptrigger-Bedingung festgelegt. Hierzu wird zunächst die Stoptrigger-Bedingung ausgewertet. Ist diese erfüllt, wird unabhängig von der Starttrigger-Bedingung kein Triggerbereich geöffnet. In diesem Modus ist es also möglich, einen erfüllten Starttrigger zu unterdrücken (siehe auch Option Unterdrückte Starttrigger reporten auf dem Tab Report). Ist die Stoptrigger-Bedingung hingegen nicht erfüllt (oder nicht auswertbar) und die Starttrigger-Bedingung erfüllt, so wird ein neuer Triggerbereich erzeugt. Das Bereichsende wird durch die Stoptrigger-Bedingung definiert (siehe Parameter Stoptrigger).

Beispielhaft werde wieder ein Signal mit Zeitstempeln im Intervall [0, 5) betrachtet. Die Starttrigger-Bedingung gelte überall, ausgenommen im Bereich mit Zeitstempeln von 1 bis 3 (genauer im Intervall [1, 3)). Die Stoptrigger-Bedingung gelte lediglich ab dem Zeitstempel 2 bis zum Zeitstempel 4 (genauer im Intervall [2, 4)). Dann werden erneut die zwei Triggerbereiche [0, 2) und [4, 5) erzeugt.
‚ab Starttrigger bis zum nächsten Mal Stoptrigger erfüllt‘

Im Gegensatz zum vorangegangenen Modus führt dieser Modus dazu, dass ein Triggerbereich immer dann gestartet wird, wenn die Starttrigger-Bedingung erfüllt ist. Der Bereichsanfang hängt also nur von der Starttrigger-Bedingung ab. Das Bereichsende wird erneut durch die Stoptrigger-Bedingung definiert (siehe Parameter Stoptrigger).

Wird dieser Modus auf das vorangegangene Beispiel angewandt, so werden neben den Triggerbereichen [0, 2) und [4, 5) zusätzliche Triggerbereiche ab dem Zeitstempel 3 (inklusiv) bis zum Zeitstempel 4 (exklusiv) erzeugt, die jeweils lediglich aus den Intervallen zwischen zwei aufeinanderfolgenden Messpunkten bestehen.
‚mit Zeitversatz wenn Starttrigger erfüllt‘

In diesem Modus wird für jeden Zeitpunkt, zu dem die Starttrigger-Bedingung erfüllt ist, ein Triggerbereich erzeugt, indem zum Zeitpunkt des Starttriggers ein Start-Offset und ein Stop-Offset addiert werden. Wenn ein Bereich, um den Starttrigger aufgespannt werden soll, müssen ein negativer Start-Offset und ein positiver Stop-Offset gewählt werden. Falls Start-Offset und Stop-Offset das gleiche Vorzeichen haben, liegt der Zeitpunkt des Starttriggers außerhalb des resultierenden Triggerbereichs.

Info

In diesem Modus können überlappende Triggerbereiche entstehen!

Info

Der Triggermodus lässt sich auch über Packagevariablen oder globale Konstanten parametrieren.

Starttrigger:

Der Starttrigger definiert, ab welchem Moment ein neuer Triggerbereich erzeugt werden soll. Der Ausdruck im Eingabefeld kann hierbei generische Signale, arithmetische und logische Operatoren, Packagevariablen und Funktionen enthalten. Gültige Ausdrücke sind zum Beispiel:
- SignalToAnalyze == 5
- Edge(SignalToCheck, 0, 1)

Die Auswahl der Signal- und Variablennamen sowie Funktionsbezeichner wird durch die integrierte Autovervollständigung unterstützt.

Start-Offset:

Mithilfe eines Start-Offset kann der Anfang eines Triggerbereichs sowohl in die Vergangenheit (negativer Start-Offset) als auch in die Zukunft (positiver Start-Offset) verschoben werden.
Stop-Offset:

Mithilfe eines Stop-Offset kann das Ende eines Triggerbereichs sowohl in die Vergangenheit (negativer Stop-Offset) als auch in die Zukunft (positiver Stop-Offset) verschoben werden.
Stoptrigger:

Wurde ein Modus ausgewählt, der einen Stoptrigger benötigt, muss eine Bedingung in Form eines Ausdrucks im Eingabefeld des Stoptriggers definiert werden, welche das Ende des Triggerbereiches beschreibt. Das Ende des Triggerbereichs entspricht dann dem Moment in dem der Ausdruck für den Stoptrigger gültig ist, unabhängig davon ob der Starttrigger weiterhin gültig ist oder nicht. Allerdings ist der auslösende Zeitschritt selbst nicht mehr Teil der Triggerbereichs (rechtsoffenes Intervall).

Oftmals wird der letzte Triggerbereich nicht durch die Bedingungen in Start- oder Stoptrigger beendet, sondern durch das Erreichen des Traceendes. Ist die Option Traceende als Stoptrigger behandeln ausgewählt, so wird dieses Ereignis wie ein normaler Stoptrigger behandelt. Im Gegensatz zu dem regulären Ende eines Triggerbereiches werden Traceschritte innerhalb des Triggerblocks auch zum letzten Sample ausgewertet (geschlossenes Intervall). Falls diese Option nicht ausgewählt ist, wird ein Triggerbereich, der durch das Traceende beendet wird, mit INCONCLUSIVE bewertet.

Info

Der Abschnitt Zusätzliche Funktionen für Ausdrücke enthält eine Übersicht über die Funktionen, die in den Ausdrücken für Start- und Stopptrigger verwendet werden können.

Erweiterte Optionen

Auf dem Tab Erweiterte Optionen können zusätzliche Einstellungen für den Triggerblock getroffen werden.
- Einmalige Triggerung
  
  Nur der erste gefundene Triggerbereich wird betrachtet, alle weiteren werden ignoriert.
- Ergebnis … setzen, falls kein Bereich gefunden wird
  
  Durch diese Einstellung kann der Fall, dass kein Triggerbereich gefunden wird, individuell bewertet werden. Standardmäßig werden Triggerblöcke, die keine Bereiche finden, mit INCONCLUSIVE bewertet.
- Ergebnis … setzen, falls Bereich kürzer ist
  
  Wenn diese Einstellung gesetzt ist, wird ein gekürzter Bereich pauschal mit dem angegebenen Ergebnis bewertet. Wenn diese Einstellung nicht gesetzt ist, wird ein gekürzter Bereich normal ausgewertet.
  
  Info
  
  Bei der Verwendung von Start-Offset und Stop-Offset kann es vorkommen, dass der Bereich vor dem Anfang des übergeordneten Triggerbereichs (bzw. Anfang des Traces) beginnen oder nach dem Ende des übergeordneten Triggerbereichs (bzw. Ende des Traces) enden würde. Da dies nicht möglich ist, werden Anfangs- bzw. Endzeit eines solchen Triggerbereichs auf die Anfangs- bzw. Endzeit des übergeordneten Triggerbereichs gesetzt. Der Bereich ist also kürzer als spezifiziert.
- Zeit nach Starttrigger ignorieren
  
  Möchte man zu Beginn eines jeden Triggerbereichs jeweils das erste Sample des Triggerbereichs von Prüfungen ausschließen, so wählt man hier die Einstellung Erstes Sample. An alle in diesem Triggerblock enthaltenen Traceschritte wird dann das erste Sample nicht weitergegeben.
  
  Möchte man allgemeiner eine bestimmte Zeitspanne nach dem Starttrigger ignorieren, so wählt man Manuell und kann darauf einen positiven Parameter, die Länge des zu ignorierenden Bereichs, angeben. Liegt ein Sample genau auf dem Rand des zu ignorierenden Bereichs, so wird dieses ebenfalls ignoriert.
  
  Info
  
  In diesem Feld kann auch eine Variable stehen. Mögliche Werte sind dann positive Zahlen, „firstsample“, 0 oder None. Der String „firstsample“ repräsentiert hierbei das Ignorieren des ersten Samples, während 0 oder None dazu führen, dass keine Samples ignoriert werden.
- Zeit vor Stoptrigger ignorieren
  
  Wählt man hier die Einstellung Manuell, so kann man eine Zeitspanne vor dem Stoptrigger angeben, die ignoriert werden soll. Liegt ein Sample genau auf dem Rand des zu ignorierenden Bereichs, so wird dieses ebenfalls ignoriert. Wenn sich in diesem Triggerblock weitere Triggerblöcke befinden, werden die aus letzteren resultierenden Triggerbereiche spätestens zum Zeitpunkt „Stoptrigger-Zeit des übergeordneten Triggerbereiches minus ignorierter Zeit vor dem Stoptrigger des übergeordneten Triggerbereiches“ automatisch gestoppt, selbst wenn zu diesem Zeitpunkt kein Signal einen Zeitstempel besitzt.
Report

Der Tab Report enthält Optionen, mit denen das Reporting von Triggerbereichen angepasst werden kann.
- Bedingung
  
  Hier kann eine Bedingung an das Ergebnis eingestellt werden, die erfüllt sein muss, damit betroffene Triggerbereiche explizit in den Report aufgenommen werden.
- Maximale Anzahl pro Ergebnis und untergeordnetem Traceschritt
  
  Hier kann eine maximale Anzahl von im Report anzuzeigenden Triggerbereichen festgelegt werden. Die eingegebene Obergrenze versteht sich pro Ergebnis. Ist also beispielsweise eine Obergrenze von fünf eingestellt, dann werden maximal fünf Triggerbereiche mit dem Ergebnis SUCCESS, maximal fünf Bereiche mit dem Ergebnis FAILED, maximal fünf mit dem Ergebnis ERROR, etc. angezeigt.
  
  Ferner versteht sich die Obergrenze pro untergeordnetem Traceschritt, sodass nicht der erste untergeordnete Traceschritt relevante Einträge weiterer Traceschritte verdrängen kann. Sind einem Triggerblock beispielsweise zwei Berechnungen untergeordnet, die in disjunkten Triggerbereichen eine Bewertung FAILED liefern, dann werden bei einer Obergrenze von fünf jeweils fünf Triggerbereiche pro Berechnung, also insgesamt zehn Bereiche mit dem Ergebnis FAILED in der Ergebnistabelle des Triggerblocks aufgeführt.
  
  Weiterhin ist insbesondere bei verschachtelten Triggerblöcken hervorzuheben, dass untergeordnete Triggerblöcke nur die eigenen Einstellungen und andere untergeordnete Traceschritte nur die Einstellungen des direkt übergeordneten Triggerblockes berücksichtigen. Bereiche des übergeordneten Triggerblockes werden immer dann angezeigt, wenn mindestens ein untergeordneter Bereich angezeigt wird (unabhängig von den eigenen Einstellungen). In einer zukünftigen Version von trace.check wird dieses Verhalten eventuell verbessert, sodass die Einstellungen aller Triggerblöcke berücksichtigt und ausmultipliziert werden.
  
  Info
  
  Die zuvor aufgeführten Filter-Optionen betreffen ausdrücklich nur das Reporting, also die Anzahl von Triggerbereichen, die im Report-Baum links und in der detaillierten Ergebnistabelle rechts angezeigt werden. Sie haben keinen Einfluss auf das Ergebnis einzelner Traceschritte, geschweige denn der gesamten Traceanalyse. Ferner ist im Ergebnistext des jeweiligen Traceschritts unabhängig von den Filter-Optionen immer die gesamte Anzahl von Triggerbereichen pro Ergebnis dargestellt.
- Unterdrückte Starttrigger reporten
  
  Ist diese Option gesetzt, so wird für jeden unterdrückten Starttrigger ein Spot mit einer entsprechenden Meldung zur Ursache der Unterdrückung ausgegeben. Ein unterdrückter Starttrigger kann zum einen im Modus ‚ab Starttrigger solange nicht Stoptrigger erfüllt‘ vorkommen, wenn gleichzeitig zur Starttrigger-Bedingung die Stoptrigger-Bedingung erfüllt ist. Zum anderen kann ein Starttrigger im Modus ‚mit Zeitversatz wenn Starttrigger erfüllt‘ unterdrückt werden, wenn der komplette Triggerbereich außerhalb des übergeordneten Triggerbereichs liegen würde.
- Ignorierte Bereiche im Testreport erwähnen
  
  Ist die Summe der ignorierten Zeiten (also ignorierte Zeit nach Starttrigger + ignorierte Zeit vor Stoptrigger) größer oder gleich der Länge eines Triggerbereichs, so wird dieser ignoriert. Ein ignorierter Bereich wird stets mit NONE bewertet. Möchte man, dass ignorierte Bereiche nicht detailliert im Report stehen, so kann man die Option Ignorierte Bereiche im Testreport erwähnen abwählen. Im Report ist dann nur noch die Anzahl der ignorierten Bereiche im Ergebnistext des Triggerblocks zu sehen.
  
  Info
  
  Die Nummerierung der Triggerbereiche bezieht die ignorierten Triggerbereiche stets mit ein. Folglich wird ein Triggerbereich 2 unabhängig von dieser Option stets als Triggerbereich 2 gekennzeichnet auch wenn Triggerbereich 1 ignoriert und nicht im Testreport erwähnt wird, d.h. die Liste der Triggerbereiche beginnt in diesem Fall mit Triggerbereich 2.

Beispiel:

Im folgenden Abschnitt ist ein kleines Beispiel aufgeführt, welches die Funktionsweise der Triggerblöcke besser verdeutlichen soll. Als Signalverlauf ist die Aufnahme der Geschwindigkeit eines Autos vorhanden:

In der Traceanalyse ist der Signalverlauf der Geschwindigkeit an das generische Signal Geschwindigkeit gebunden. Der Triggerblock unterhalb der Traceschritt-Episode Episode erzeugt Triggerbereiche mit dem definierten Starttrigger Geschwindigkeit > 10. Als Ende der Triggerbereiche sollen jeweils die Momente gewählt werden, an denen die Geschwindigkeit den Wert 0 besitzt (bzw. das Ende des Signalverlaufs erreicht wurde).

Um die Triggerbereiche zu analysieren ist ein Berechnungsschritt (Analysen mit Triggern und Berechnungen) unterhalb des Triggerblocks eingefügt. Dieser prüft ob der Signalwert größer als zehn ist. Damit die Auswertung der Traceanalyse grafisch unterstützt wird, soll zusätzlich noch ein Plot (Diagrammerstellung (Plot)) erzeugt werden.

../../_images/Triggerbereich_Beispiel1.png

Nach Ausführen der Traceanalyse wird automatisch ein Report erstellt. Im Abschnitt Neuer Triggerblock ist zu erkennen, dass zwei Triggerbereiche (Triggerbereich 1 und Triggerbereich 2) gefunden wurden. Die Bewertung der Bereiche ist durch den Berechnungsschritt erfolgt. Im Abschnitt Berechnung ist eine detailliertere Ansicht zu sehen. Hier ist unter anderem zu erkennen , dass im Triggerbereich 1 ein Teilbschnitt gültig (SUCCESS), aber ein anderer ungültig (FAILED) war.

../../_images/Triggerbereich_Beispiel2.png

Die Triggerbereiche sowie die Bewertungen durch den Berechnungsschritt sind anhand eines Plots grafisch dargestellt:

../../_images/Triggerbereich_Beispiel3.png

Report¶

Im Report eines Berechnungsschritts werden aufeinanderfolgende Zeitstempel, in denen sich das Ergebnis der Bewertung nicht geändert hat, zu Bereichen zusammengefasst. Ein einzelner Bereich wird durch Anfangs- und Endzeitpunkt, das Ergebnis und eine Nachricht gekennzeichnet. Die Bereiche eines Berechnungsschitts können z.B. wie folgt aussehen:

../../_images/Ranges.png — Bereiche eines ungetriggerten (links) und getriggerten (rechts) Berechnungsschritts¶

Bei Berechnungsschitten in Triggerblöcken werden die Bereiche eingerückt unterhalb des übergeordneten Triggerbereichs dargestellt.

Unter gewissen Umständen ist eine Aus- bzw. Bewertung des Ausdrucks eines Berechnungsschritts nicht überall möglich. Beispielsweise steht der Ausdruck Value(Sig1, 1.0), der zu jedem Zeitpunkt den Wert des Signals Sig1 in einer Sekunde liefert (vgl. Abschnitt Zusätzliche Funktionen für Ausdrücke), ab einer Sekunde vor Signalende nicht mehr zur Verfügung. Dies kann auch passieren, falls Sig1 ein Signal ist, dass in einem getriggerten Berechnungsschritt berechnet wird und daher nur in Triggerbereichen zur Verfügung steht. Derartige Bereiche werden standardmäßig mit INCONCLUSIVE bewertet.

Um die Prüfung auf einen geeigneten Teilbereich einzuschränken, kann man (Sub-)Triggerblöcke mit ignorierten Bereichen verwenden.

Info

Da in ungetriggerten Berechnungsschritten Abhängigkeiten von Signalwerten, die in der Zukunft (oder Vergangenheit) liegen, stets zu INCONCLUSIVE-Bereichen am Signalende (Signalanfang) führen würden, werden derartige Bereiche bei ungetriggerten Berechnungsschritten abweichend mit NONE bewertet.

Ausdrücke¶

Ausdrücke für die Formeln von Berechnungsschritten müssen mindestens den Namen eines generischen Signals enthalten. Zusätzlich können Packagevariablen, Funktionsaufrufe sowie arithmetische Operationen verwendet werden. In Start- bzw. Stoptriggerbedingungen eines Triggerblocks sind dagegen auch Ausdrücke ohne generische Signale erlaubt.

In einem Berechnungsschritt wird der hinterlegte Ausdruck zu allen Zeitstempeln ausgewertet, an denen mindestens ein enthaltenes generisches Signal einen Messpunkt hat. Im Falle eines Triggerblocks findet die Auswertung zu allen Zeitstempeln statt, an denen mindestens ein generisches Signal aller verwendeten Ausdrücke einen Messwert hat. Falls in keinem der Ausdrücke ein generisches Signal verwendet wird, werden die Zeitstempel der Signale aus den Ausdrücken des übergeordneten Triggerblocks oder - falls kein solcher existiert - aller in der Episode referenzierten Signale verwendet.

Andere generische Signale, die zum betrachteten Zeitstempel keinen Messwert besitzen, erhalten bei der Auswertung den letzten verarbeiteten Wert bzw. None falls kein solcher Wert existiert. Die Auswertung des Ausdrucks eines Berechnungsschritts oder Triggerblocks kann durch Einfügen in einen übergeordneten Triggerblock (weiter) eingeschränkt werden. Hierbei ist zu beachten, dass die Funktionen CheckResponse, Derivative, HoseAbsolute, HoseRelative, Integral, MovingAverage, StartTriggerValue, StopTriggerValue und Value (sowie zusätzlich mit restricted=False die Funktionen Always, AtLeastOnce und Static) auf Signalwerte zugreifen können, die außerhalb des (äußersten) Triggerbereichs liegen. Beispielsweise verarbeitet der Ausdruck Value(Signal, 2) Signalwerte, die das Triggerbereichsende um bis zu zwei Sekunden überschreiten. Ein derartiger Ausdruck wird mit INCONCLUSIVE bewertet, wenn nicht alle erforderlichen Werte bestimmt werden können.

Zusätzliche Funktionen für Ausdrücke¶

Always(signal, duration, restricted=False)¶

Prüft, ob der Wahrheitswert für ein Signal oder eine Bedingung innerhalb der angegebenen Zeit duration immer True ist.

Betrachtet werden alle Signalwerte im rechts offenen Zeitbereich [t, t + duration) für duration > 0 bzw. im geschlossenen Zeitbereich [t + duration, t] für duration < 0. Liegt an der linken Intervallgrenze kein Sample vor, wird der gehaltene Signalwert verwendet. Triggerbereiche schränken abhängig von Parameter restricted den Bereich weiter ein.

Wird der Parameter restricted als False übergeben (Standard), kann der durch duration definierte Zeitbereich auch über den durch eine Triggerung begrenzten Bereich hinaus reichen. Falls für diesen Parameter True übergeben wird, muss die Erwartung lediglich innerhalb des nicht ignorierten Bereichs erfüllt sein.

Info

Im Unterschied zur Funktion Static werden auch Bereiche ausgewertet, welche kürzer als die mittels duration angegebene Dauer sind (beispielsweise am Anfang/Ende eines Signalverlaufs).

Beispiele:

# Wahr, wenn das Signal innerhalb der nächsten 2 Sekunden immer zu True ausgewertet
# werden kann
Always(Sig0, 2.0)

# Wahr, wenn die Bedingung 'Sig0 > 5' innerhalb der letzten 2 Sekunden immer erfüllt wurde
Always(Sig0 > 5, -2.0)

# Wahr, wenn das Signal innerhalb der nächsten Sekunde, jedoch höchstens bis zum Ende des
# aktuellen Triggerbereichs immer zu True ausgewertet werden kann
Always(Sig0, 1.0, True)

# Wahr, wenn innerhalb der nächsten 1.5 Sekunden keine steigende Flanke von 0 auf 1 existiert
Always(not Edge(Sig0, 0, 1), 1.5)

AtLeastOnce(signal, duration, restricted=False)¶

Prüft, ob der Wahrheitswert für ein Signal oder eine Bedingung innerhalb der angegebenen Zeit duration mindestens einmal True ist.

Wird der Parameter restricted als False übergeben (Standard), kann der durch duration definierte Zeitbereich auch über den durch eine Triggerung begrenzten Bereich gehen.

Falls für diesen Parameter True übergeben wird, muss die Erwartung nur innerhalb des nicht ignorierten Bereichs erfüllt sein.

Info

Im Unterschied zur Funktion Static werden auch Bereiche ausgewertet, welche kürzer als die mittels duration angegebene Dauer sind (beispielsweise am Anfang/Ende eines Signalverlaufs).

Beispiele:

# Wahr, wenn das Signal innerhalb der nächsten 2 Sekunden mindestens einmal zu True
# ausgewertet werden kann
AtLeastOnce(Sig0, 2.0)

# Wahr, wenn die Bedingung 'Sig0 > 5' innerhalb der letzten 2 Sekunden mindestens einmal
# erfüllt wurde
AtLeastOnce(Sig0 > 5, -2.0)

# Wahr, wenn das Signal innerhalb der nächsten Sekunde, jedoch höchstens bis zum Ende des
# aktuellen Triggerbereichs mindestens einmal zu True ausgewertet werden kann
AtLeastOnce(Sig0, 1.0, True)

# Wahr, wenn innerhalb der nächsten 1.5 Sekunden eine steigende Flanke von 0 auf 1 existiert
AtLeastOnce(Edge(Sig0, 0, 1), 1.5)

Average(signal)¶

Liefert den Mittelwert des angegebenen Signals für den getriggerten Bereich.

Bei Verwendung dieser Funktion in einem Berechnungsschritt, der nicht unter einem Triggerblock liegt, wird der Mittelwert über den Definitionsbereich des Argumentsignals zurückgegeben. Die Speicherung des Mittelwerts innerhalb eines Berechnungsschritts erfolgt stets als konstantes Signal mit Samplezeitpunkten, die dem Argumentsignal entsprechen.

Example

Info

Diese Funktion kann nicht in den Ausdrücken Starttrigger und Stopptrigger verwendet werden.

Average(Sig0) # Mittelwert des Signals Sig0

BoundControl(signal, minVal, maxVal)¶

Prüft für jeden Zeitstempel, ob der Wert eines Signals innerhalb des angegebenen Wertebereichs liegt.

Die Parameter minVal und maxVal können jeweils Namen generischer Signale oder Zahlen sein. Werden mehrere Signale übergeben, so erfolgt eine Bestimmung des Rückgabewerts nur, wenn Werte für alle benutzten Signale (gegebenenfalls auch zu zurückliegenden Zeitstempeln) vorhanden sind.

Der Rückgabewert zum aktuellen Zeitstempel ist:

True, wenn der Signalwert zwischen oder auf den Wertgrenzen liegt
False, wenn der Signalwert den angegebenen Wertebereich verlässt

Beispiele:

# True zum Zeitstempel t, wenn 0 <= Sig0(t) <= 100
BoundControl(Sig0, 0, 100)

# True zum Zeitstempel t, wenn Sig1(t) <= Sig0(t) <= Sig2(t)
BoundControl(Sig0, Sig1, Sig2)

CheckAlive(signal, cycleLimit)¶

Prüft, ob ein Signal zählenden Charakter hat: Die Signalwertfolge beginnt bei 0, steigt streng monoton mit der festgelegten Schrittweite von 1 (Eins) bis zum Maximalwert (angegeben durch den Parameter cycleLimit) und beginnt wieder bei 0 zu zählen.

Die Funktion liefert False, wenn der gleiche Signalwert sich unmittelbar wiederholt, die Schrittweite von 1 nicht eingehalten wird, der Maximalwert überschritten wird oder wenn das Signal (auch nach Erreichen des Maximalwerts) nicht mit Null beginnt.

Beispiel:

# True, wenn die Wertfolge von Sig0 die Form (0, 1, 2, 3, 0...) hat
CheckAlive(Sig0, 3)

CheckResponse(signal1, signal2, timeout=None, useHoldValue=False)¶

Prüft zeitliche Zusammenhänge zwischen zwei Signalen. Für jeden Wahrheitswert in signal1, der zu True ausgewertet wird, muss der Wahrheitswert in signal2 innerhalb der angegebenen Zeit timeout ebenfalls zu True führen.

Die Signalwerte werden boolesch interpretiert, damit die Funktion einfach mit logischen Ausdrücken verkettet werden kann. Somit können intuitive Ausdrucke wie z.B: CheckResponse(RisingEdge(ignition), engineSpeed > 0, 0.5) verwendet werden.

Der Parameter timeout ist optional. Wird er nicht angegeben, prüft CheckResponse, dass signal2 zeitlich nach signal1 mindestens einmal zu True ausgewertet werden kann. Negative Werte sind nicht erlaubt und führen zu einer Fehlermeldung.

Der Parameter useHoldValue ist nur relevant, wenn signal1 und signal2 unterschiedliche Zeitachsen haben oder signal2 Lücken aufweist. Wird useHoldValue auf True gesetzt, dann wird zu Zeitpunkten, wo signal1 True ist und signal2 keinen Wert liefert, der letzte gültige Wert von signal2 (Haltewert) verwendet.

Bei Verwendung in getriggerten Berechnungsschritten wird die Bedingung von signal2 auch über den Triggerbereich hinaus geprüft. In den ignorierten Bereichen des Triggerblocks wird die Bedingung ebenfalls geprüft. Die auszulösende Bedingung aus signal1 wird hingegen in den ignorierten Bereichen nicht ausgewertet.

Info

Es ist vorteilhaft, in der auszulösenden Bedingung aus signal1 Funktionen wie Edge zu verwenden, um mehrfache Auslösungen bei aufeinanderfolgenden Samples zu vermeiden. Ein Ausdruck wie ignition == 1 löst aus wenn der Wert z.B. von 0 auf 1 wechselt, aber auch an jedem Sample darauf, an dem ignition den Wert 1 hat.

Beispiele:

# Verwendung von logischen Ausdrücken zur besseren Lesbarkeit
CheckResponse(RisingEdge(ignition), engineSpeed > 0, 0.5)

# Verwendung des Haltewerts von Sig2 zu Beginn eines Triggerbereichs
CheckResponse(RisingEdge(Sig1), Sig2, 1.5, useHoldValue=True)

# Verwendung ohne Angabe von timeout
CheckResponse(FallingEdge(Sig1), RisingEdge(Sig2))

CheckTiming(signal, period, tolerance)¶

Prüft, ob zwischen den beiden letzten Zeitstempeln des vorliegenden Signals die Zeit period vergangen ist.

Möchte man eine Zeitspanne zulassen, so kann man mit dem Parameter tolerance die relative Toleranz in Prozent (%) für ein symmetrisches Zeitintervall um period definieren.

Beispiele:

# True, wenn seit dem letzten Zeitstempel zwischen 0.9 und 1.1 Sekunden vergangen sind
CheckTiming(Sig0, 1, 10)

# True, wenn seit dem letzten Zeitstempel genau 0.01 Sekunden vergangen sind
CheckTiming(Sig1, 0.01, 0)

Derivative(signal)¶

Liefert den Wert der ersten Ableitung eines Signals.

Für das erste Sample (n=0) bestimmt sich die Ableitung y‘(n) wie folgt:

Für alle weiteren Samples als Mittelwert der Anstiege:

Im Falle äquidistanter Zeitstempel vereinfacht sich dies zum zentralen Differenzenquotienten:

Beispiel:

Derivative(Sig0) # Ableitung des Signals Sig0

Edge(signal, valFrom='*', valTo='*')¶

Prüft, ob sich ein Signalwert vom Wert valFrom zum Wert valTo ändert.

Mit den Default-Parametern wird jede Wertänderung detektiert (Änderung von einem beliebigen Wert auf einen beliebigen Wert).

Für je einen der Parameter valFrom und valTo können anstelle von numerischen Werten auch die Zeichenketten (String) ‚<‘ (kleiner als der andere Parameter) oder ‚>‘ (größer als der andere Parameter) als Argument übergeben werden. So kann auch auf steigende/fallende Flanken von/zu beliebigen Werten geprüft werden.

Info

Die Parameter valFrom und valTo dürfen nicht gleich sein (es sei denn beide haben den Default-Wert ‚*‘)!

Beispiele:

Edge(Sig0)            # Beliebige Flanke (beliebige Wertänderung)
Edge(Sig0, 0, 1)      # Steigende Flanke von 0 auf 1
Edge(Sig0, '>', 1)    # Fallende Flanke von einem beliebigen Wert auf 1
Edge(Sig0, 1, '<')    # Fallende Flanke von 1 auf einen beliebigen Wert kleiner 1
Edge(Sig2, '<', '>')  # entspricht Edge(Sig2, '*', '>') bzw. Edge(Sig2, '<', '*') bzw. RisingEdge(Sig2)

Evaluate(expression)¶

Wertet einen als String gegebenen Ausdruck aus.

Beispiele:

Evaluate('Sig0 > 0')  # Äquivalent zu Sig0 > 0
Evaluate(var)         # Wertet den in der Variable 'var' gespeicherten Ausdruck aus

FallingEdge(signal, threshold='*')¶

Prüft, ob sich der Signalwert von einem Wert größer gleich threshold zu einem Wert kleiner als threshold ändert.

Beispiel:

FallingEdge(Sig0)      # True, wenn Sig0(n-1) > Sig0(n)
FallingEdge(Sig0, 0.5) # True, wenn Sig0(n-1) >= 0.5 und Sig0(n) < 0.5

Hose(signalA, signalB, deltaT, deltaY)¶: Veraltet ab Version 6.4: Stattdessen HoseAbsolute() benutzen.

HasSample(signal)¶

Überprüft, ob das angegebene Signal genau zum aktuellen Zeitpunkt abgetastet wurde.

Liegt zu diesem Zeitpunkt lediglich ein Haltewert vor, der sich aus dem Sample-und-Hold-Prinzip ergibt, dann liefert die Funktion False zurück.

Beispiel:

# Prüft, ob 'signal' einen Abtastwert zu jedem
# Zeitpunkt hat, der Teil der gemeinsamen Zeitachse
# von 'signal' und 'clock' ist.
HasSample(signal) and clock >= 0

Die nachfolgende Abbildung zeigt neben den Signalverläufen von signal und clock das Ergebnis result des Beispielausdruckes:

Die Abbildung zeigt darüber hinaus das Ergebnis einer getriggerten Analyse, mit der überprüft wurde, ob spätestens eine Sekunde nach jeder steigenden Flanke in clock ein neuer Abtastwert von signal ermittelt wurde. Dazu mussten im Triggermodus ‚ab Starttrigger bis zum nächsten Mal Stoptrigger erfüllt‘ folgende Triggerbedingungen formuliert werden:

Starttrigger:

clock == 1

Stoptrigger:

HasSample(signal)

Innerhalb des Triggerblocks musste dann folgender Berechnungsschritt ausgeführt werden:

StopTriggerTime() - Time(signal or clock) <= 1.0

HasValue(signal, restricted=False)¶

Ermittelt, ob ein Signal zum aktuellen Zeitpunkt einen Wert hat oder ein gehaltener Wert existiert.

Gibt diese Funktion True zurück, wird ein anschließender Zugriff auf das Signal einen gültigen Signalwert zurückgeben, beispielsweise mittels Value(signal, 0.0).

Wird für den Parameter restricted True übergeben (Standard: False) werden nur Signalwerte innerhalb des Triggerbereichs berücksichtigt. Gehaltene Werte von außerhalb des Triggerbereichs werden ignoriert.

Beispiel:

HasValue(Sig0) # True, wenn Sig0 bereits einen Wert hat
HasValue(Sig0, True) # True, wenn Sig0 bereits einen Wert (innerhalb des Triggerbereichs) hat

HoseAbsolute(signalA, signalB, deltaT, deltaY)¶

Berechnet einen Schlauch für das Signal signalA und prüft ob die Signalwerte des Signals signalB darin liegen. Hierbei sind deltaT die zeitliche Toleranz und deltaY die absolute Toleranz der Signalwerte.

deltaT:: Der zeitliche Mindestabstand zwischen signalA und der Schlauchgrenze. Damit entspricht die Minimalbreite des Schlauchs 2 * deltaT. Dieser nichtnegative Parameter geht wie unten beschrieben in die Bestimmung der Schlauchgrenzen ein.

Info

Wenn deltaT auf 0 gesetzt wird, dann bezieht sich deltaY jeweils auf den aktuellen Wert (bzw. den Haltewert) von signalA.
deltaY:: Kann ein Tupel der Form (minusDeltaY, plusDeltaY) sein. Diese nichtnegativen Parameter gehen in die Bestimmung der Schlauchgrenzen als absolute Toleranz wie unten beschrieben ein. Wird ein einzelner Zahlenwert angegeben, so entspricht dies dem Tupel (deltaY, deltaY).

Die Berechnung der Ober- und Untergrenze des Schlauchs zu einem Zeitpunkt t geschieht in zwei Schritten. Zunächst werden das Maximum und das Minimum des Signals signalA über dem Zeitintervall [t - deltaT, t + deltaT] bestimmt. Wenn für den Zeitpunkt t - deltaT kein Sample vorliegt, wird der dort gültige Haltewert von ‚signalA‘ einbezogen. Im zweiten Schritt wird vom ermittelten Minimum die erste Komponente von deltaY subtrahiert. Dies liefert die untere Grenze des Schlauchs zum Zeitpunkt t. Analog wird die obere Grenze des Schlauchs bestimmt, indem zum ermittelten Maximum die zweite Komponente von deltaY addiert wird.

Insbesondere bei Signalen mit betragsgroßer Ableitung kann die Schlauchhöhe erheblich größer als minusDeltaY + plusDeltaY sein.

Beispiele:

# True, wenn Sig1 innerhalb eines gleitenden Bereichs anhand von Sig0 mit 0.2 Dauer,
# gleitendes Minimum und Maximum um jeweils 123.4 aufgeweitet, liegt.
HoseAbsolute(Sig0, Sig1, 0.2, 123.4)

# True, wenn Sig1 innerhalb eines gleitenden Bereichs anhand von Sig0 mit 0.1 Dauer,
# nur gleitendes Maximum um 1.33 aufgeweitet, liegt.
HoseAbsolute(Sig0, Sig1, 0.1, (0, 1.33))

Plotten oder Weiterverarbeiten der Grenzwertverläufe:

Das Ergebnis der Funktion HoseAbsolute() ist ein sogenanntes strukturiertes Signal. Neben dem binären Ergebnissignal stehen die Strukturelemente .lower und .upper mit den Grenzwertverläufen zur Verfügung und können in Ausdrücken verwendet werden. Speichert (Option Speichern in von Berechnungsschritten) man das Ergebis von HoseAbsolute() beispielsweise in einem Signal namens ‚HoseResult‘, dann kann man im Anschluss mit den Ausdrücken

HoseResult.lower
HoseResult.upper

auf den Verlauf des unteren/oberen Grenzwertes zugreifen. In arraybasierten NumPy-Traceschrittvorlagen funktioniert der Zugriff auf strukturierte Signale analog:

signals['HoseResult'].GetValues().lower
signals['HoseResult'].GetValues().upper

Plottet man ‚HoseResult‘, dann werden im Plot neben dem binären Ergebnis auch die Grenzwertverläufe dargestellt:

HoseRelative(signalA, signalB, deltaT, toleranceY)¶

Berechnet einen Schlauch für das Signal signalA und prüft ob die Signalwerte des Signals signalB darin liegen. Hierbei sind deltaT die zeitliche Toleranz und toleranceY die relative Toleranz der Signalwerte in Prozent (%).

deltaT:: Der zeitliche Mindestabstand zwischen signalA und der Schlauchgrenze. Damit entspricht die Minimalbreite des Schlauchs 2 * deltaT. Dieser nichtnegative Parameter geht wie unten beschrieben in die Bestimmung der Schlauchgrenzen ein.

Info

Wenn deltaT auf 0 gesetzt wird, dann bezieht sich toleranceY jeweils auf den aktuellen Wert (bzw. den Haltewert) von signalA.
toleranceY:: Kann ein Tupel der Form (minusToleranceY, plusToleranceY) sein. Diese nichtnegativen Parameter gehen in die Bestimmung der Schlauchgrenzen als relative Toleranz wie unten beschrieben ein. Wird ein einzelner Zahlenwert angegeben, so entspricht dies dem Tupel (toleranceY, toleranceY).

Die Berechnung der Ober- und Untergrenze des Schlauchs zu einem Zeitpunkt t geschieht in zwei Schritten. Zunächst werden das Maximum und das Minimum des Signals signalA über dem Zeitintervall [t - deltaT, t + deltaT] bestimmt. Wenn für den Zeitpunkt t - deltaT kein Sample vorliegt, wird der dort gültige Haltewert von signalA einbezogen. Im zweiten Schritt wird das ermittelte Minimum um minusToleranceY Prozent verringert. Dies liefert die untere Grenze des Schlauchs zum Zeitpunkt t. Analog wird die obere Grenze des Schlauchs bestimmt, indem das ermittelte Maximum um plusToleranceY Prozent vergrößert wird.

Beispiele:

# True, wenn Sig1 innerhalb eines gleitenden Bereichs anhand von Sig0 mit 0.2 Dauer,
# gleitendes Minimum und Maximum um jeweils 40% aufgeweitet, liegt.
HoseRelative(Sig0, Sig1, 0.2, 40)

# True, wenn Sig1 innerhalb eines gleitenden Bereichs anhand von Sig0 mit 0.1 Dauer,
# nur gleitendes Maximum um 10% aufgeweitet, liegt.
HoseRelative(Sig0, Sig1, 0.1, (0, 10))

Plotten oder Weiterverarbeiten der Grenzwertverläufe:

Das Ergebnis der Funktion HoseRelative() ist ein sogenanntes strukturiertes Signal. Neben dem binären Ergebnissignal stehen die Strukturelemente .lower und .upper mit den Grenzwertverläufen zur Verfügung und können in Ausdrücken verwendet werden. Speichert (Option Speichern in von Berechnungsschritten) man das Ergebis von HoseRelative() beispielsweise in einem Signal namens ‚HoseResult‘, dann kann man im Anschluss mit dem Ausdruck

HoseResult.lower

auf den Verlauf des unteren Grenzwertes zugegreifen. In arraybasierten NumPy-Traceschrittvorlagen funktioniert der Zugriff auf strukturierte Signale analog:

signals['HoseResult'].GetValues().lower

Plottet man ‚HoseResult‘, dann werden im Plot neben dem binären Ergebnis auch die Grenzwertverläufe dargestellt:

Integral(signal)¶

Liefert den Wert des bestimmten Integrals zwischen dem ersten und dem aktuellen Zeitstempel eines Signals.

Für das erste Sample (n=0) ist der resultierende Wert gleich 0. Für alle weiteren Samples gilt:

Beispiel:

Integral(Sig0) # Integral des Signals Sig0 bis zum aktuellen Zeitstempel

Monotony(signal, type)¶

Prüft, ob ein Signal monoton steigend oder monoton fallend ist.

Dazu wird der Definitionsbereich des Signals signal gegebenenfalls eingeschränkt und nur das betrachtete getriggerte Intervall untersucht. In der Regel wird das Signal anhand seines derzeitigen und letzten Werts auf Monotonie geprüft. In Spezialfällen, in denen nur der aktuelle Wert verwendet werden kann (z.B. am Signalanfang), wird zum aktuellen Zeitstempel zusätzlich der nächste zukünftige Signalwert verarbeitet.

Das Argument type bestimmt welche Art der Monotonie überprüft wird:

‚inc‘, um auf monotones Steigen zu prüfen
‚dec‘, um auf monotones Fallen zu prüfen
‚inc_strict‘, um auf streng monotones Steigen zu prüfen
‚dec_strict‘, um auf streng monotones Fallen zu prüfen

Beispiele:

# Prüfung, ob Sig1 aktuell monoton steigend verläuft
Monotony(Sig1, 'inc')
# Prüfung, ob Sig1 aktuell streng monoton fallend verläuft
Monotony(Sig1, 'dec_strict')

MovingAverage(signal, duration, durationKind='sample')¶

Liefert den gleitenden Durchschnittswert des Signals signal über den angegebenen Zeitbereich.

duration:

Muss entweder als positiver numerischer Wert oder als Tupel zweier positiver numerischer Werte angegeben werden. Ein einzelner Wert spezifiziert einen ausschließlich in die Vergangenheit reichenden Zeitbereich. Ein Tupel legt fest, wie weit der Zeitbereich in Vergangenheit und Zukunft reichen soll.

durationKind:

Legt fest, wie duration zu interpretieren ist:

Der Wert ‚sample‘ gibt an, dass duration als Sample-Anzahl zu interpretieren ist. duration darf in diesem Fall nur ganzzahlige Werte enthalten.
Der Wert ‚time‘ gibt an, dass duration als Zeitspanne zu interpretieren ist. Der Zeitbereich ist ein geschlossenes Intervall [t - duration, t] falls duration ein numerischer Wert ist bzw. ein geschlossenes Intervall [t - duration[0], t + duration[1]] falls duration ein Tupel ist.

Info

Wenn für duration ein einzelner Wert und für durationKind der Wert ‚sample‘ angegeben wird, dann umfasst duration auch das aktuelle Sample, d.h. ein Wert von 3 beschreibt ein gleitendes Intervall, dass den aktuellen Wert und 2 Werte aus der Vergangenheit enthält. Wenn für duration ein Tupel und für durationKind der Wert ‚sample‘ angegeben wird, dann beschreibt das Tupel, wie viele Werte aus Vergangenheit und Zukunft zusätzlich zum aktuellen Wert Teil des gleitenden Intervalls sind.

Beispiele:

# Gleitender Durchschnittswert der letzten 5 Sekunden
MovingAverage(Sig0, 5.0, 'time')

# Gleitender Durchschnittswert der letzten 3 und nächsten 2 Sekunden
MovingAverage(Sig1, (3.0, 2.0), 'time')

# Gleitender Durchschnittswert der letzten 10 Samples (aktuelles Sample und 9 Vorgänger)
MovingAverage(Sig1, 10, durationKind='sample')

# Gleitender Durchschnittswert über 5 Samples (aktuelles Sample, 2 Vorgänger, 2 Nachfolger)
MovingAverage(Sig2, (2, 2))

MovingMax(signal, duration, durationKind='time')¶

Liefert das gleitende Maximum des Signals signal über den angegebenen Zeitbereich.

duration:

durationKind:

Legt fest, wie duration zu interpretieren ist:

Der Wert ‚sample‘ gibt an, dass duration als Sample-Anzahl zu interpretieren ist. duration darf in diesem Fall nur ganzzahlige Werte enthalten.
Der Wert ‚time‘ gibt an, dass duration als Zeitspanne zu interpretieren ist. Der Zeitbereich ist ein geschlossenes Intervall [t - duration, t] falls duration ein numerischer Wert ist bzw. ein geschlossenes Intervall [t - duration[0], t + duration[1]] falls duration ein Tupel ist. Der gehaltene Wert zum Zeitpunkt t - duration wird berücksichtigt, falls dort kein Sample vorliegt.

Info

Beispiele:

# Gleitendes Maximum der letzten 5 Sekunden
MovingMax(Sig0, 5.0, 'time')

# Gleitendes Maximum der letzten 3 und nächsten 2 Sekunden
MovingMax(Sig1, (3.0, 2.0), 'time')

# Gleitendes Maximum der letzten 10 Samples (aktuelles Sample und 9 Vorgänger)
MovingMax(Sig1, 10, durationKind='sample')

# Gleitendes Maximum über 5 Samples (aktuelles Sample, 2 Vorgänger, 2 Nachfolger)
MovingMax(Sig2, (2, 2))

MovingMin(signal, duration, durationKind='time')¶

Liefert das gleitende Minimum des Signals signal über den angegebenen Zeitbereich.

duration:

durationKind:

Legt fest, wie duration zu interpretieren ist:

Der Wert ‚sample‘ gibt an, dass duration als Sample-Anzahl zu interpretieren ist. duration darf in diesem Fall nur ganzzahlige Werte enthalten.
Der Wert ‚time‘ gibt an, dass duration als Zeitspanne zu interpretieren ist. Der Zeitbereich ist ein geschlossenes Intervall [t - duration, t] falls duration ein numerischer Wert ist bzw. ein geschlossenes Intervall [t - duration[0], t + duration[1]] falls duration ein Tupel ist. Der gehaltene Wert zum Zeitpunkt t - duration wird berücksichtigt, falls dort kein Sample vorliegt.

Info

Beispiele:

# gleitendes Minimum der letzten 5 Sekunden
MovingMin(Sig0, 5.0, 'time')

# gleitendes Minimum der letzten 3 und nächsten 2 Sekunden
MovingMinSig1, (3.0, 2.0), 'time')

# gleitendes Minimum der letzten 10 Samples (aktuelles Sample und 9 Vorgänger)
MovingMin(Sig1, 10, durationKind='sample')

# gleitendes Minimum über 5 Samples (aktuelles Sample, 2 Vorgänger, 2 Nachfolger)
MovingMin(Sig2, (2, 2))

RisingEdge(signal, threshold='*')¶

Prüft, ob sich der Signalwert von einem Wert kleiner gleich threshold zu einem Wert größer als threshold ändert.

Beispiel:

RisingEdge(Sig0)      # True, wenn Sig0(n-1) < Sig0(n)
RisingEdge(Sig0, 0.5) # True, wenn Sig0(n-1) <= 0.5 und Sig0(n) > 0.5

StartTriggerTime()¶

Gibt den Zeitstempel des Starttriggers zurück.

In einem Berechnungsschritt, der nicht unterhalb eines Triggerblocks liegt, definiert der erste Signalzeitstempel aller Signale der Episode den Starttriggerzeitpunkt.

Wenn diese Funktion im Ausdruck Stopptrigger verwendet wird, bezieht sie sich auf den Triggerblock selbst (und nicht auf den übergeordneten Triggerblock).

Info

Diese Funktion kann nicht im Ausdruck Starttrigger verwendet werden.

Beispiel:

# True, wenn - zum aktuellen Zeitstempel von Sig0 - bereits mindestens eine Sekunde seit dem Starttrigger vergangen ist
Time(Sig0) - StartTriggerTime() >= 1

StartTriggerValue(signal, deltaT=0.0)¶

Liefert den Wert des Signals signal zum Zeitpunkt des Starttriggers plus deltaT.

In einem Berechnungsschritt, der nicht unterhalb eines Triggerblocks liegt, definiert der erste Signalzeitstempel des Signals signal (nicht der erste Zeitstempel aller Signale!) den Referenzzeitpunkt (deltaT=0.0).

Wenn diese Funktion im Ausdruck Stopptrigger verwendet wird, bezieht sie sich auf den Triggerblock selbst (und nicht auf den übergeordneten Triggerblock).

Info

Diese Funktion kann nicht im Ausdruck Starttrigger verwendet werden.

Beispiel:

# Signalwert von Sig0 zum Zeitpunkt des Starttriggers
StartTriggerValue(Sig0)

Static(signal, duration, restricted=True, constValue=True)¶

Prüft, ob die Signalwerte für signal über die angegebene Zeitspanne duration konstant gleich constValue waren (duration < 0) bzw. sein werden (duration > 0).

Um das Ergebnis der Funktion für einen Zeitpunkt t zu bestimmen, werden die folgenden Signalwerte betrachtet:

Bei positiver duration die Signalwerte im rechts offenen Zeitbereich [t, t + duration). Liegt bei oder nach der rechten Intervallgrenze kein Signalwert mehr vor, beispielsweise am Ende von signal, wird nicht der gehaltene Signalwert verwendet. Stattdessen liefert die Funktion für diesen Zeitpunt t False zurück, da die Konstanz über das gesamte Intervall nicht nachgewiesen werden kann.
Bei negativer duration die Signalwerte im geschlossenen Zeitbereich [t + duration, t]. Liegt bei der linken Intervallgrenze t + duration kein Signalwert vor, wird der gehaltene Signalwert verwendet. Liegt kein Haltewert vor, liefert die Funktion für diesen Zeitpunkt t False zurück.

Wird die Static-Funktion mit restricted gleich True (Standard) in Berechnungsschritten innerhalb eines Triggerblocks ausgewertet, stehen der Funktion nur die Signalwerte von signal innerhalb des nicht ignorierten Bereichs des Triggerblocks zur Verfügung. Folglich liefert die Funktion bei restricted gleich True in einem Triggerbereich nie durchweg True.

Der Parameter constValue ist optional und standardmäßig auf True gesetzt. So kann die Funktion einfach mit logischen Ausdrücken verkettet werden, sodass z.B. Static(Drehzahl == 1000, 1) statt Static(Drehzahl, 1, constValue=1000) genutzt werden kann. Wird der Parameter constValue auf None gesetzt, so wird der aktuelle Signalwert für den Vergleich herangezogen.

Beispiele:

Static(Sig0, 2)                   # True, wenn Sig0 == True für die nächsten 2 Sekunden
Static(Sig1, -0.5, True, 0)       # True, wenn Sig1 == 0 für die letzten 0.5 Sekunden
Static(Sig1, -0.5, constValue=0)  # Entspricht dem vorherigem Beispiel
Static(Sig1 == 0, -0.5)           # Entspricht dem vorherigem Beispiel
Static(Sig2, 1, True, None)       # True, wenn Sig2 konstant für die nächste Sekunde
Static(Sig3 > 1000, 1)            # True, wenn Sig3 > 1000 für die nächste Sekunde

Info

Soll geprüft werden, ob signal innerhalb eines Triggerbereichs variabler Dauer konstant ist, eignen sich eher folgende Ausdrücke:

signal == StartTriggerValue(signal)
Derivative(signal) == 0

StopTriggerTime()¶

Gibt den Zeitstempel des Stoptriggers zurück. Triggerbereiche sind rechtsoffene Intervalle, d.h. der Stoptriggerzeitpunkt selbst gehört nicht zum Triggerbereich.

In einem Berechnungsschritt, der nicht unterhalb eines Triggerblocks liegt, definiert der letzte Signalzeitstempel aller Signale der Episode den Stoptriggerzeitpunkt.

Info

Diese Funktion kann nicht in den Ausdrücken Starttrigger und Stoptrigger verwendet werden.

Beispiel:

# True, wenn ab dem aktuellen Zeitstempel von Sig0 der Stoptrigger nach mehr als einer Sekunde auftritt
StopTriggerTime() - Time(Sig0) > 1

StopTriggerValue(signal, deltaT=0.0)¶

Liefert den Wert des Signals signal zum Zeitpunkt des Stoptriggers plus deltaT. Triggerbereiche sind rechtsoffene Intervalle, d.h. der Stoptriggerzeitpunkt selbst und mithin der Wert bei deltaT=0.0 gehören nicht zum Triggerbereich.

In einem Berechnungsschritt, der nicht unterhalb eines Triggerblocks liegt, definiert der letzte Signalzeitstempel aller Signale der Episode den Referenzzeitpunkt (deltaT=0.0).

Beispiel:

# Signalwert von Sig0 zum Zeitpunkt des Stoptriggers
StopTriggerValue(Sig0)

Info

Diese Funktion kann nicht in den Ausdrücken Starttrigger und Stoptrigger verwendet werden.

Time(refSignal=None)¶

Gibt den aktuellen Zeitstempel zurück.

Es kann ein Signal refSignal angegeben werden, welches als Zeitstempelquelle verwendet wird, falls keine weiteren Signale im Ausdruck vorkommen.

Beispiele:

Time(Sig0)           # Ermittle den aktuellen Zeitstempel von Sig0
Time(Sig0) + Sig0    # Addiere den aktuellen Zeitstempel mit dem zugehörigen Wert von Sig0
Time() + Sig0        # Gleichbedeutend mit Time(Sig0) + Sig0

Time(Sig0) + Sig1    # Zu beachten: Dieser Ausdruck wird immer ausgewertet, wenn Sig0 oder
                     # Sig1 ein Sample besitzen. Der Aufruf Time(Sig0) liefert dabei den
                     # tatsächlichen aktuellen Zeitstempel, auch wenn Sig0 gerade keinen
                     # Wert besitzt. Außerdem wird der letzte gültige Wert von Sig1 verwendet,
                     # falls Sig1 kein Sample zum Zeitpunkt der Auswertung hatte.

Time(Sig0) - StartTriggerTime() >= 1  # True, wenn zum aktuellen Zeitstempel von Sig0 mindestens
                                      # eine Sekunde seit dem Starttrigger-Zeitpunkt vergangen ist.

TriggerRangeStartTime()¶

Gibt den Startzeitpunkt des Triggerbereichs zurück. Diese Funktion berücksichtigt den im Triggermodus ‚mit Zeitversatz wenn Starttrigger erfüllt‘ angegebenen Start-Offset, durch den der Startzeitpunkt des Triggerbereichs vom Starttriggerzeitpunkt (StartTriggerTime()) abweichen kann.

In einem Berechnungsschritt, der nicht unterhalb eines Triggerblocks liegt, definiert der erste Signalzeitstempel aller Signale der Episode den Startzeitpunkt des Triggerbereichs.

Wenn diese Funktion im Ausdruck Stopptrigger verwendet wird, bezieht sie sich auf den Triggerblock selbst (und nicht auf den übergeordneten Triggerblock).

Info

Diese Funktion kann nicht im Ausdruck Starttrigger verwendet werden.

Beispiel:

# True, wenn - zum aktuellen Zeitstempel von Sig0 - bereits mindestens eine Sekunde seit dem Start des Triggerbereichs vergangen ist
Time(Sig0) - TriggerRangeStartTime() >= 1

TriggerRangeStartValue(signal, deltaT=0.0)¶

Liefert den Wert des Signals signal zum Startzeitpunkt des Triggerbereichs plus deltaT. Diese Funktion berücksichtigt den im Triggermodus ‚mit Zeitversatz wenn Starttrigger erfüllt‘ angegebenen Start-Offset, durch den der Startzeitpunkt des Triggerbereichs vom Starttriggerzeitpunkt (StartTriggerTime()) abweichen kann.

Wenn diese Funktion im Ausdruck Stopptrigger verwendet wird, bezieht sie sich auf den Triggerblock selbst (und nicht auf den übergeordneten Triggerblock).

Info

Diese Funktion kann nicht im Ausdruck Starttrigger verwendet werden.

Beispiel:

# Signalwert von Sig0 zum Startzeitpunkt des Triggerbereichs
TriggerRangeStartValue(Sig0)

TriggerRangeStopTime()¶

Gibt den Endzeitpunkt des Triggerbereichs zurück. Diese Funktion berücksichtigt den im Triggermodus ‚mit Zeitversatz wenn Starttrigger erfüllt‘ angegebenen Stop-Offset, durch den der Endzeitpunkt des Triggerbereichs vom Ende der Triggerung (StopTriggerTime()) abweichen kann.

In einem Berechnungsschritt, der nicht unterhalb eines Triggerblocks liegt, definiert der letzte Signalzeitstempel aller Signale der Episode den Endzeitpunkt des Triggerbereichs.

Info

Diese Funktion kann nicht in den Ausdrücken Starttrigger und Stoptrigger verwendet werden.

Beispiel:

# True, wenn der Triggerbereich ab dem aktuellen Zeitstempel von Sig0 noch für mehr als eine Sekunde fortgesetzt wird
TriggerRangeStopTime() - Time(Sig0) > 1

TriggerRangeStopValue(signal, deltaT=0.0)¶

Liefert den Wert des Signals signal zum Endzeitpunkt des Triggerbereichs plus deltaT. Diese Funktion berücksichtigt den im Triggermodus ‚mit Zeitversatz wenn Starttrigger erfüllt‘ angegebenen Stop-Offset, durch den der Endzeitpunkt des Triggerbereichs vom Ende der Triggerung (StopTriggerTime()) abweichen kann.

In einem Berechnungsschritt, der nicht unterhalb eines Triggerblocks liegt, definiert der letzte Signalzeitstempel aller Signale der Episode den Referenzzeitpunkt (deltaT=0.0).

Info

Diese Funktion kann nicht in den Ausdrücken Starttrigger und Stoptrigger verwendet werden.

Beispiel:

# Signalwert von Sig0 zum Endzeitpunkt des Triggerbereichs
TriggerRangeStopValue(Sig0)

Value(signal, deltaT)¶

Liefert den Signalwert von signal unter Beachtung des angegebenen Offsets deltaT in Sekunden.

Beispiele:

Value(Sig0, 1)    # Wert des Signals Sig0 in 1 Sekunde
Value(Sig1, -0.5) # Wert des Signals Sig1 vor 0.5 Sekunden