Heartbeat Connection Monitoring

Zur Überwachung der Verbindung zwischen LabVIEWTM und TwinCAT können Heartbeat-Signale periodisch zwischen den beiden Systemen ausgetauscht werden. Dafür sind auf beiden Seiten entsprechende Funktionen notwendig.

Heartbeat Connection Monitoring 1:

SPS-Projekt erforderlich

Für die Verwendung des Heartbeat Connection Monitorings sind in dem TwinCAT-Projekt eine SPS und eine SPS-Lizenz erforderlich.

Nachfolgend ist dargestellt, wie die Heartbeat-Signale eingesetzt werden, um eine Verbindungsunterbrechung zu detektieren.

Heartbeat Connection Monitoring 2:

Für jedes Heartbeat-Signal wird in LabVIEW™ der maximal zu erwartende Roundtrip-Delay (RTD) geschätzt. Dabei handelt es sich um die Zeit, die das ausgesendete Signal benötigt, um von TwinCAT empfangen und wieder zurückgesendet zu werden. Die Schätzung wird als RTD Estimate bezeichnet. Trifft das Heartbeat-Signal innerhalb des RTD Estimate wieder in LabVIEW™ ein (wie in der Abbildung auf der linken Seite gezeigt), ist die Verbindung in Ordnung. Ist dies nicht der Fall, könnte die Verbindung unterbrochen sein (wie in der Abbildung auf der rechten Seite gezeigt). Um dies zu überprüfen, wird ein weiteres Heartbeat-Signal zur Validierung ausgesendet. Hierbei wird der RTD Estimate erhöht. Schlägt auch dieses Heartbeat-Signal fehl, wird eine Unterbrechung detektiert (Timeout detected).

Die Heartbeat-Signale werden periodisch mit der Polling-Zeit T gesendet. Diese wird seitens TwinCAT 3 genutzt, um zu bestimmen, bis zu welchem Zeitpunkt das nächste Heartbeat-Signal erwartet wird. Trifft das Heartbeat-Signal vor diesem Zeitpunkt in TwinCAT ein, ist die Verbindung in Ordnung. Bleibt das Heartbeat-Signal zweimal in Folge aus, wird auch TwinCAT-seitig eine Unterbrechung detektiert (Timeout detected).

Roundtrip Delay (RTD) Estimation

Die Schätzung des nächsten maximal zu erwartenden RTDs ist zentral für die Verbindungsüberwachung. Die Schätzung findet sowohl in LabVIEW™ als auch in TwinCAT Anwendung. Der zu Grunde liegende Algorithmus ist in beiden Systemen identisch. Es gibt zwei Möglichkeiten der Schätzung: dynamisch oder statisch.

Dynamische RTD Estimation: Bei der dynamischen Schätzung wird auf Basis von aufgezeichneten RTDs der nächste zu erwartenden RTD (RTD Estimate) errechnet. Hierbei kommt eine Kombination aus verschiedenen Algorithmen zum Einsatz. Über einen Offset-Parameter (siehe unten) kann Einfluss auf die Schätzung genommen werden. Der konfigurierte Offset wird zum Ergebnis der dynamischen RTD-Schätzung hinzuaddiert. Hierdurch können das Risiko einer fälschlicherweise detektierten Unterbrechung und die Reaktionszeit individuell an den Anwendungsfall angepasst werden. Ein größerer Offset führt zu einer geringeren Wahrscheinlichkeit, dass eine Unterbrechung fälschlicherweise detektiert wird und erhöht gleichzeitig die Reaktionszeit der Überwachung.

Statische RTD Estimation: Bei der statischen Schätzung wird als maximaler RTD ein konstanter Wert festgelegt. Dieser Wert wird vom Nutzer über den Offset-Parameter eingestellt.

Maximale Verzögerung bis zur Erkennung einer Unterbrechung

Die maximale Verzögerung bis zur Erkennung einer Unterbrechung ist abhängig vom Schätzungsverfahren für den RTD.

Für die dynamische Schätzung gilt näherungsweise:

Reaktionszeit ≈ Polling-Zeit + 3*RTD Estimate + Offset

Für die statische Schätzung gilt näherungsweise:

Reaktionszeit ≈ Polling-Zeit + 3* Offset

Parametrierung

Über die Parameter kann Einfluss auf das Verhalten der Verbindungsüberwachung genommen werden. Folgende Parameter stehen hierzu zur Verfügung:

Name

Bezeichnung

Polling-Time

Zeitspanne in ms, die zwischen zwei Heartbeat-Signalen vergeht.

UseRtdEstimation?

Auswahl des Verfahrens zur Schätzung des RTD
(TRUE: dynamische Schätzung; FALSE: statische Schätzung)

Offset

Dynamische Schätzung: Zusätzliche Wartezeit in ms

Statische Schätzung: Konstanter RTD Estimate in ms

Heartbeat Connection Monitoring 3:

Parametrierung nur in LabVIEWTM

Die Parameter werden in LabVIEWTM konfiguriert und automatisch von TwinCAT übernommen. Eine Parametrierung in TwinCAT ist nicht erforderlich.

Es ist sinnvoll, über die Parameter das Verhalten der Überwachung auf Ihren individuellen Anwendungsfall abzustimmen. Hierbei sollen folgende Überlegungen eine Unterstützung darstellen:

Polling-Zeit: Je größer die Polling-Zeit, desto länger ist die Reaktionszeit. Gleichzeitig führt eine geringere Polling-Zeit zu mehr versendeten Heartbeat-Signalen, wodurch unter Umständen die Netzwerkauslastung steigt. Über die Polling-Zeit kann die Reaktionszeit der Verbindungsüberwachung gut eingestellt werden (berücksichtigen Sie hierbei, dass Polling-Zeit != Reaktionszeit gilt).

Heartbeat Connection Monitoring 4:

Die Polling-Zeit hat keinen Einfluss auf das Risiko einer fälschlicherweise detektierten Unterbrechung.

Offset: Über den Offset kann das Risiko einer fälschlicherweise detektierten Unterbrechung zu Lasten der Reaktionszeit reduziert werden.

Funktionsblock in TwinCAT anlegen

Für das Heartbeat Connection Monitoring muss für jeden Port im TwinCAT-Projekt, zu dem eine Überwachung stattfinden soll, eine Instanz des Funktionsblocks FB_Heartbeat angelegt werden. Dazu muss in TwinCAT die „Tc3_InterfaceForLabVIEW“ PLC Library hinzugefügt werden und anschließend eine Instanz vom Funktionsblock FB_Heartbeat angelegt und aufgerufen werden.

PROGRAM MAIN
VAR
   fbHeartbeat  :  FB_Heartbeat;
END_VAR
fbHeartbeat();

Der Funktionsbaustein verfügt über Ausgänge, die den Zustand der Verbindung anzeigen.

Name

Bedeutung

bConnected

Zeigt an, ob eine Verbindung zum LabVIEWTM-System besteht.

bTimeoutDetected

Zeigt an, ob eine Verbindungsunterbrechung vorliegt.

bStopped

Zeigt an, ob die Verbindungsüberwachung von LabVIEWTM aus gestoppt wurde.

AmsAddr

Gibt das Zielsystem an, zu dem die Heartbeat-Verbindung besteht.

Verbindungsüberwachungen zu mehreren Zielsystemen

Zu jeder Instanz des FB_Heartbeat kann ein Heartbeat-Signal von einem LabVIEWTM-Projekt eingehen, jedoch kann ein LabVIEWTM-Projekt eine Verbindungsüberwachung zu mehreren TwinCAT-Systemen realisieren.