Prinzip und Funktionsweise

Im einfachsten Fall besteht ein verteiltes System aus zwei Projekten auf unterschiedlichen Rechnern mit unterschiedlichem oder gleichem Betriebssystem. Die Kopplung von verteilten WinCC OA Systemen erfolgt über einen eigenen Manager, dem Dist-Manager (WCCILdist). Der Dist-Manager ist in der Lage über ein Netzwerk die logische Verbindung zu mehreren Dist-Managern anderer WinCC OA Systeme aufrecht zu erhalten. Pro System gibt es genau einen Dist-Manager, der für die Verbindung zu allen anderen Systemen zuständig ist. Ausnahme: im Redundanzfall läuft auf jedem Redundanzrechner ein Dist-Manager. Der Zugriff auf Daten von anderen Systemen erfolgt genauso wie der Zugriff auf Daten vom lokalen System. Datenpunkte von Fremdsystemen werden nicht auf das lokale System kopiert, daher ist der Zugriff auf Remote Daten nur bei einer bestehenden Verbindung zum spezifischen System möglich (bei einem Verbindungsausfall zum Teilsystem sind keine Abfragen mehr möglich). Es werden auch nur aktiv abgefragte Informationen übertragen (d.h. Antworten von Abfragen, die mit dpGet(), dpGetPeriod(), dpConnect() auf ein Teilsystem abgesetzt wurden).

Der Dist-Manager übernimmt folgende Aufgaben im Falle eines verteilten Systems:

  • Aufbau und Überwachung der Verbindung zu anderen WinCC OA Systemen

  • Austausch der DP Identification auf allen Systemen

  • Weiterleitung von Telegrammen

Jedes beteiligte System in einem verteilten System muss einen eindeutigen Systemnamen und eine eindeutige Systemnummer besitzen. Die Managernummer des Dist-Managers wird automatisch beim Hochlauf vom Data-Manager vergeben - es handelt sich hierbei auch um die Nummer des jeweiligen Systems, es erfolgt jedoch keine Anzeige innerhalb der WinCC OA Konsole!

Beim Hochlauf eines Teilsystems und Start des Dist-Managers wird automatisch die DP Identification der Systeme ausgetauscht (Ausnahme: One Way Dist). Jeder Zugriff auf einen DP eines Systems erfolgt in WinCC OA intern aus Performancegründen über eine Nummer statt den Namen - diese Nummer ist die DP Identification (= Id). Die Umwandlung von Namen in IDs wird intern in Tabellen gelöst. Folgende Informationen werden für die Umwandlung verwendet:

  • Datenpunkttypen: Pro DPT gibt es intern eine Tabelle, die den Namen der Typen und Elemente enthält.

  • Datenpunkte: Pro DP gibt es intern eine Tabelle mit dem Namen.

  • Datenpunktelemente: Pro DPE gibt es intern eine Tabelle, die Beschreibung, Einheit, Format und Alias enthält.

  • Systemnamen

  • Konfig- und Attributnamen (diese sind fix und im Projekt nicht veränderbar)

Bei größeren Projekten ist natürlich auch die DP Id größer und kann bis zu mehreren MB betragen. Ohne diese Id wäre der Zugriff auf DPs (z.B. mit CTRL) nicht möglich (weitere Informationen zur DP ID können auf der Seite DP Identification nachgelesen werden).

Datenpunkte/Systemname

In WinCC OA beinhaltet jeder Datenpunktbezeichner (Datenpunktname) als ersten Teil den Systemnamen (Default ist das eigene System). Alle Datenpunkte innerhalb eines Systems haben den selben Systemnamen. Daher muss jedes beteiligte System einen eindeutigen Systemnamen und eine eindeutige Systemnummer haben. Datenpunkte von Fremdsystemen werden durch das Einfügen des Systemnamens und eines Doppelpunktes spezifisch adressiert.

Anmerkung: Systeminformationen eines Projekts, wie z.B. Systemnummer oder Systemname, können mit Hilfe des Tools WCCOAtoolNameToId ermittelt werden.

Beispiel

"System3:ExampleDP_Trend1.:_original.._value"

Wird in einem Skript (UI, CTRL) ein Datenpunkt ohne Systemname angesprochen, so wird automatisch der eigene (lokale) Systemname verwendet. Alle Skripts und damit auch alle Panels, welche Daten von anderen Systemen verarbeiten oder darstellen sollen, müssen mit dem vollständigen Datenpunktbezeichner arbeiten.

Beispiel

Folgender Aufruf in einem Skript liefert nur die Datenpunkte (dem Muster entsprechend) von diesem System, wo der Aufruf erfolgt ist:

dpNames("*","ExampleDP_Bit");

Folgender Aufruf in einem Skript liefert die Datenpunkte (dem Muster entsprechend) von allen Systemen:

dpNames("*:*","ExampleDP_Bit");

VORSICHT:

Achten Sie darauf, dass in projektspezifischen Skripts der Systemname nicht hardcodiert verwendet wird! In Datenpunktlisten, die mit dem ASCII-Manager eingespielt werden, müssen Datenpunktelementbezeichner immer ohne Systemname stehen, falls sie auch in andere Systeme eingespielt werden!

Die Datenpunkttypen und Datenpunkte können in den Teilsystemen unterschiedlich sein. Nach dem Verbindungsaufbau zu den anderen Systemen durch den Dist-Manager wird die DP Identification ausgetauscht und somit ist der Zugriff (z.B. mit dpGet(), dpGetPeriod(), dpConnect(), dpSet(), ...) auf alle Remote DPEs möglich. Beachten Sie jedoch, dass die Datenpunkte von Fremdsystemen nicht auf das lokale System kopiert werden, d.h. es gibt keine Vervielfachung von Datenpunkten, und somit ist der Zugriff auf Daten eines Teilsystems nur möglich, wenn die Verbindung zu diesem besteht. Das Arbeiten mit den DPEs auf anderen Systemen erfolgt wie mit lokalen DPEs (im Modul PARA sind die verbundenen Systeme und deren DPTs/DPEs ersichtlich).

Ein eventueller Verbindungsausfall zu einem Teilsystem ist durch das gesetzte Invalid-Bit beim Originalwert für die Attribute _original.._invalid und _original.._bad sowie beim Onlinewert für die Attribute _online.._invalid und _online.._bad (siehe Datenpunktkonfigs _original und _online) der abgefragten Daten ersichtlich. Durch Anmeldung auf diese Attribute in einem Teilsystem wird der Benutzer über einen Verbindungsausfall informiert, d.h. alle dpConnect()-Funktionen mit Antwort (2. Parameter ist TRUE) auf ein Teilsystem liefern einen Hotlink mit einem "Null"-Wert und die Statusbits werden so gesetzt, dass der Wert als ungültig markiert wird. Weiters liefern die dpConnects mit Antwort einen Fehler (kann mit getLastError() abgefragt werden) mit Code 144. Das gilt analog für die Funktionen dpQueryConnectAll() und dpQueryConnectSingle().

Topologie eines verteilten Systems

Verteilte Systeme in WinCC OA können hierarchisch strukturiert sein. Ein System befindet sich in der Hierarchie ganz oben, die weiteren Systeme befinden sich in den darunterliegenden Ebenen. Das System in der obersten Ebene fungiert als "Server" die darunterliegenden Systeme sind die "Clients". Diese Struktur bietet eine wesentliche Erleichterung bei der Parametrierung verteilter Systeme. Folgende Abbildung zeigt eine verteiltes WinCC OA System in hierarchischer Form.

Abbildung 1. Hierarchische Struktur eines verteilten Systems

In obiger Abbildung ist das System 1 "Server" für alle anderen Systeme und akzeptiert Verbindungen von diesen. System 2 verbindet sich zu System 1 und fungiert wiederum als Server für die darunterliegenden Systeme (also für System 4 und 5). Der wesentliche Vorteil solcher Strukturen liegt in der Parametrierung von verteilten Systemen mit dieser Konfiguration. Beim Einstellen der Parameter reicht die Angabe der Verbindung in eine Richtung (d.h. beim Anlegen mit dem Wizard wird zunächst System 1 bei den "Einstellungen des neuen eigenen Projektes" definiert; als nächster Schritt werden die weiteren Teilsysteme mit Parametrierung der Verbindung zu den anderen Systemen angelegt; im Wizard erfolgt dies im Bereich "Verbundene Systeme" - ein Beispiel für das Anlegen eines verteilten Systems finden Sie auch auf der Seite Beispiel für ein redundant verteiltes System). Ist die Verbindung zu einem System einmal aufgebaut, so ist diese bidirektional und die Systeme an den "Enden der Verbindung" sehen einander (z.B. ist die Verbindung von System 4 zu System 2 aufgebaut, können beide miteinander kommunizieren und sind im Systemübersichtspanel zu sehen). Eine solche Struktur eines verteilten Systems bedeutet auch, dass neue untergeordnete Systeme einfach, ohne Neustart des Servers (Dist-Managers) in die Topologie eingebunden werden können. Wie die Parametrierung solcher hierarchischen Strukturen in der Config-Datei aussieht, sehen Sie an einigen Beispielen für verschiedene Strukturen auf der Seite Konfigurationsdatei für verteilte Systeme.

Anmerkung: WinCC OA Systeme, die Nachrichten miteinander austauschen sollen, müssen direkt verbunden sein. Es erfolgt kein Routing von Nachrichten (z.B. wie in der obigen Abbildung dargestellt, kann das System 4 keine Nachrichten mit System 3 austauschen). Ist die Verbindung zu einem System einmal aufgebaut, so ist diese bidirektional, d.h. beide Systeme am "Ende" der Verbindung können einander "sehen", daher ist die Parametrierung der Verbindung in eine Richtung ausreichend!
Anmerkung: Bei der Abfrage, welche verteilten Systeme verfügbar sind, kann das DPE _DistManager(_2).State.SystemNums verwendet werden. Dieses DPE enthält alle Systeme, mit welchen eine Kommunikation aufgebaut werden kann.

Weiterleitung von Messages

In den folgenden Abschnitten finden Sie eine Beschreibung, wie die Weiterleitung von Messages (Abfragen auf Teilsysteme) in einem verteilten System funktioniert. Um das Prinzip von verteilten Systemen ein wenig besser zu veranschaulichen soll folgende Grafik dienen:

Abbildung 2. Verteiltes System in WinCC OA

Die Abbildung zeigt eine detaillierte Darstellung der drei Systeme, wie sie bereits aus der Abbildung auf der Seite Grundlagen verteilte Systeme bekannt sind. System 3 ist ein Einzelplatzsystem, System 2 ein Mehrplatzsystem und System 1 ist redundant konfiguriert. Alle drei Systeme haben eine Verbindung über das lokale Netzwerk. Die Netzwerkanbindung zu den drei Rechnern, die in diesem verteilten System verwendet werden, kann redundant ausgeführt sein. Die drei Systeme können jeweils über einen eigenen Prozessanschluss verfügen. Wie Sie ein verteiltes System mit WinCC OA aufsetzen, wird auf der Seite Anlegen eines verteilten Systems genauer erklärt.

Die Weiterleitung von Messages bei dieser Konfiguration schaut folgendermaßen aus (die Erklärung wird anhand von System 3 und System 2 durchgeführt):

Anmerkung: Achten Sie unbedingt darauf, dass der Dist-Manager auf System 3 und System 2 läuft, damit eine Verbindung besteht und Daten zwischen den Systemen ausgetauscht werden können!

  1. Am System 3 wird ein CTRL-Skript gestartet, dass Werte von DPEs auf System 2 abfragt (z.B. mit dpGet(), dpGetPeriod(), dpConnect()).

  2. Der CTRL-Manager schickt die Nachricht ("ich will einen Wert von DPE... auf System 2 abfragen") an den Event-Manager des eigenen Systems. Der Event-Manager leitet die Nachricht an seinen Dist-Manager weiter. Der Dist-Manager wiederum leitet die Nachricht an den Dist-Manager des richtigen Systems (in unserem Fall System 2). Der Dist-Manager auf System 2 gibt die Nachricht an seinen Event-Manager weiter, der diese auswertet.

  3. In umgekehrter Reihenfolge erfolgt schließlich die Antwort auf die Abfrage. D.h. der Event-Manager am System 2 gibt den angefragten Wert an seinen Dist-Manager weiter. Der Dist-Manager auf System 2 leitet den Wert zum Dist-Manager auf System 3 (von wo die Anfrage gekommen ist) weiter. Der Dist-Manager auf System 3 gibt den Wert an seinen Event-Manager und dieser wiederum an die Quelle, nämlich den CTRL-Manager, der die Antwort auf die Abfrage weiter bearbeitet.

Anmerkung: Erfolgt ein Verbindungsausfall zwischen den Dist-Managern bei bestehenden Anmeldungen (dpConnect()), so bleiben die Anmeldungen bestehen. Ist die Verbindung wieder hergestellt, werden die Werte der bestehenden Anmeldungen bei allen angemeldeten Managern aktualisiert.

Jeder Manager in WinCC OA wird identifiziert durch den Managertyp und Nummer, Systemnummer und Replica. Somit kann jeder Manager in einem verteilten System eindeutig identifiziert werden. Mit diesem "Manager identifier" ist es möglich, Nachrichten an andere Manager in einem Teilsystem zu leiten, ohne direkte Verbindung zwischen Quell- und Zielmanager (d.h. alle Manager, die sich auf dem Weg einer Nachricht zwischen Quell- und Zielmanager befinden, leiten die Nachricht nur weiter und befassen sich nicht weiter mit dem Inhalt).

Im Falle eines redundanten Systems (z.B. wie in der Abbildung System 1) erfolgt die Weiterleitung von Nachrichten im verteilten System wie bereits beschrieben ebenfalls über die Dist-Manager der Teilsysteme. Im Redundanzfall wird jedoch immer der Dist-Manager des aktiven Rechners die Nachricht auch an den aktiven Event-Manager weiterleiten. Eine Ausnahme bildet der Split-Betrieb im Redu-System. Da im Split-Betrieb beide Event-Manager des redundanten Systems aktiv sind, muss im Systemübersichtspanel (bei Redundanz - siehe auch Systemübersicht bei redundanten Systemen) der aktive Dist-Manager bestimmt werden. Weitere Informationen zur Redundanz und Split-Betrieb finden Sie im Kapitel Grundlagen Redundanz bzw. Redundanz im Split-Betrieb.

LAN-Verbindungsstatus

Der Dist-Manager zeigt den LAN-Verbindungsstatus zu einem verteilten System auf einem internen Datenpunkt an. Wenn in einem redundanten Netzwerk z.B. die 1 LAN-Verbindung zu einem verteilen System ausfällt, wird das auf einem internen Datenpunkt abgebildet.

Um den Verbindungsstatus abbilden zu können, müssen Datenpunkte des Typs _ManagerConnections erstellt werden. Legen Sie die Datenpunkte in der Form dist_<sys1num>_<hostnum>_dist_<sys2num>_<hostnum> an.

Zeitunterschiede zwischen Dist-Managern

Durch Verwendung von valueChangeTimeDiff überprüft der Event-Manager die Zeitdifferenz zwischen den Dist-Managern. Das Ergebnis wird auf den verbindungsspezifischen Datenpunkt _ManagerConnections.TimeDiff geschrieben. Bei Überschreiten der Grenze der Zeitdifferenz wird die Verbindung beendet und eine entsprechende Meldung im LogViewer ausgegeben.