Applikationsplanung und Hinweise zu verteilten Systemen

Planung von verteilten Systemen

Der erste Schritt bei der Planung eines verteilten Systems sollte der zukünftigen Topologie gewidmet werden. Durch die Verbindung von jedem System zu jedem anderen können unterschiedlichste Strukturen realisiert werden. Die Topologie des verteilten Systems wird in der Config-Datei beschrieben (siehe Konfigurationsdatei für verteilte Systeme). Folgende Fragestellungen sollen beitragen, die Anforderungen an das verteilte System zu formulieren:

  • Aus wie vielen Teilsystemen besteht das Gesamtsystem? Als ein Teilsystem wird jeweils ein Server mit Event-Manager gezählt, im redundanten Fall werden die beiden Server des redundanten Paares gemeinsam als ein System gezählt. Abgesetzte Bedienplätze zählen nicht mit.

  • Werden von entfernten Systemen nur Daten angezeigt oder werden an diese Systeme auch Befehle übertragen?

  • Gibt es ein ausgezeichnetes System, welches den anderen Systemen übergeordnet ist. Ist in diesem Fall eine Kommunikation zwischen den Subleitwarten vorgesehen? Was muss alles von der Hauptleitwarte bedient werden können?

  • Gibt es gleichberechtigte Systeme, welche jeweils ein oder mehrere Systeme komplett mitsteuern (bemannte und unbemannte Stationen)?

  • Sollen auf einem System nur Werte von anderen Systemen verfügbar sein (Visualisierung in speziellen Panels, Übersichtspanels) oder sollen auch die Anlagenbilder vom entfernten System dargestellt werden?

  • Soll auf allen Systeme parametriert werden, oder wird dies von einem einzigen System aus getätigt?

  • In welchen Systemen sollen gesammelte Daten ausgewertete werden (Reporting, Archivierung, Weiterverarbeitung)?

  • Welche Systeme werden zu welchen Zeiten von Personen bedient?

  • Muss eine Steuerung der Befehlsgewalt zwischen den einzelnen Systemen vorgesehen werden?

  • Welche Alarme sollen in welchem System angezeigt werden? Wer (welcher Benutzer in welchem System) darf diese auch quittieren?

Anmerkung:

In einem verteilten System können die Alarmklassen in jedem System unterschiedlich parametriert werden.

  • Welche Bandbreiten (Kapazität der Netzwerkverbindung) stehen zur Verbindung der einzelnen Systeme zur Verfügung?

Hinweise und Einschränkungen beim Arbeiten mit verteilten Systemen

Allgemein

Beachten Sie, dass bei einem Betrieb von mehreren verteilten System auf einem Rechner zusätzlich zum Rechnernamen auch der Port konfiguriert werden muss (siehe Config-Eintrag:"distPeer). Es wird empfohlen, nur ein verteiltes System pro Rechner zu betreiben!

Hardware

Für verteilte Systeme werden folgende Hardware-Komponenten empfohlen (siehe auch WinCC OA Voraussetzungen):

  • Netzwerkverbindungen zwischen den Systemen sollen als permanente Verbindungen (Standleitungen) ausgeführt sein. WinCC OA unterstützt Wählleitungen nicht direkt. Wählleitungen sind nur möglich, wenn für WinCC OA nicht sichtbar ist, dass es sich um eine Wählleitung handelt. Der Router muss also selbständig die Verbindung aufbauen, wenn Daten über die Leitung gehen, und sie nach einem Timeout wieder abbauen. Im Falle von Wählleitungen empfiehlt ETM für die Hardware Router von Cisco.

  • Für die Rechnerauslegung in verteilten Systemen sollte nicht nur die Datenpunktanzahl und Dynamik des lokalen Systems, sondern ebenfalls der Anteil an lokal genutzten Datenpunkten anderer Systeme berücksichtigt werden. Hinzu kommt der Aufschlag zur Abdeckung des zusätzlichen Kommunikationsoverheads.

  • Bei größeren Applikationen (Projekte, die je nach Dynamik eine Anzahl von DPEs > 20000 aufweisen) wird der Einsatz von Rechnern mit Doppelprozessoren empfohlen.

Archivierung/Reporting

Auf historische Daten anderer Systeme kann nur zugegriffen werden, solange eine Netzwerkverbindung aufrecht erhalten wird. Die Daten liegen standardmäßig nur auf den jeweiligen Quellsystemen.

  • Sollen Werte auf einem anderen als Ihrem Quellsystem historisch gespeichert werden, so müssen diese Datenpunkte auch in dem System angelegt werden, in dem Sie zusätzlich gespeichert werden sollen. Die Übertragung muss dann über ein Laufzeitskript mit Anmeldung auf diese Datenpunkte erfolgen (wird aber nicht empfohlen, weil sonst Probleme mit Datenhoheit, Korrekturwerten, ... entstehen).

Berechtigungen

Wenn die Bedienung einer Funktion von mehreren Systemen aus erlaubt ist, so ist die Festlegung und Umschaltung der Befehlsgewalt manuell zu implementieren (welches/welcher Userinterface/Benutzer auf welchem System darf zu einem Zeitpunkt die Funktion bedienen; alle anderen sind in dem Fall ohne Rechte).

  • Die Benutzerberechtigungen werden auch im Netzwerk eines verteilten Systems ausgewertet. Aus diesem Grunde ist es notwendig, auf allen Systemen die selben Benutzer mit gleichen Berechtigungen anzulegen.

Funktionen

  • CTRL-Funktionen sollten rechenintensive, systemübergreifende Abfragen aus Performancegründen vermeiden. Auch eine große Anzahl von dpConnect() auf Datenpunkte eines entfernten Systems belastet Rechner und Netzwerk wesentlich.

  • Wenn Sie dpConnect() verwenden um auf mehrere Datenpunkte zuzugreifen, beachten Sie, dass die Datenpunkte auf dem gleichen System liegen müssen.

  • Wenn über die Funktionen dpGet() oder dpSet() mehrere Datenpunkte gleichzeitig abgefragt oder gesetzt werden, müssen diese auf dem gleichen System liegen.

  • dpGet funktioniert immer nur auf ein System. Erfolgt das dpGet in einem Aufruf auf zumindest 2 Systeme funktioniert das nicht und es wird die folgende Fehlermeldung im LogViewer angezeigt:

    WCCOAui (1), 2007.09.26 14:11:19.266, PARAM,SEVERE, 175, this request cannot address more than one system, DP: dist_789:ExampleDP_Arg1.:_original.._value

    WCCOAui (1), 2007.09.26 14:11:19.266, CTRL, WARNING, 76, Invalid argument in function,

    WCCOActrl (2), 2007.09.26 14:24:54.887, PARAM,SEVERE, 175, this request cannot address more than one system, DP: dist_789:ExampleDP_Arg1.:_original.._value

    WCCOActrl (2), 2007.09.26 14:24:54.887, CTRL, WARNING, 76, Invalid argument in function, dpGetAll.txt Line: 14, dpGet

  • Beachten Sie, dass auf allen Knoten eines verteilten Systems die gleiche Anzahl von Sprachen vorhanden sein muss.

  • Alle Teile des "Allgemein" Konfigs, das sind Beschreibung, Format, Einheit und Alias können nicht von einem Remotesystem aus dem UI heraus gesetzt werden. Wird diese Funktionalität gewünscht, so muss dies über einen Steuerdatenpunkt und ein einfaches, den Befehl lokal ausführendes Laufzeitskript, gelöst werden. Die Parametrierung mittels abgesetztem UI (VISION, PARA, GEDI) ist allerdings auf jedem System über das Netzwerk möglich.

  • Die Funktionen dpCreate(), dpDelete(), dpGetAlias(), dpGetAllAliases(), dpGetDescription(), dpGetAllDescriptions(), dpGetFormat() funktionieren auch über Systemgrenzen hinweg. Beachten Sie dabei, dass bei Abfragen mit diesen Funktionen auf Fremdsysteme unbedingt der Systemname beim Datenpunkt angegeben werden muss.

  • Das Anlegen, Ändern oder Löschen von Datenpunkttypen im Modul PARA funktioniert nicht über Systemgrenzen hinweg.

  • Die Konfigurationen (gespeicherte Voreinstellungen) von Ereignisschirm, Meldeschirm, Trends, Gruppendatenpunkten etc. liegt immer lokal auf jenem System auf welchem sie angelegt wurden (siehe auch Melde- und Ereignisschirm).

  • Summenmeldungen (Alarme) können nicht Meldungen von 2 oder mehr verschiedenen Systemen gleichzeitig behandeln.

  • Beim Systemhochlauf kann die Initialisierung des Dist-Managers und dessen Verbindungsaufbau mitunter längere Zeit in Anspruch nehmen als der Start des ersten User Interfaces bzw. Laufzeitskript (CTRL). Sollten diese Verbindungen (dpConnect() mit Hotlinks) zu nicht lokalen Datenpunktelementen aufbauen, so ist darauf zu achten, dass der versuchte Verbindungsaufbau so lange verzögert wird, wie der Verbindungsaufbau des Dist-Managers dauert. Andernfalls werden Datenpunkte von Fremdsystemen als nicht vorhanden erkannt.

  • Wenn in einem verteilten System ein dpGet() auf einem anderen System durchgeführt wird und die Dist-Verbindung nicht existiert, liefert die Funktion dpGet() jedoch den Rückgabewert 0 (OK). Der Fehler muss über die Funktion getLastError() abgefragt werden. getLastError() liefert die folgende Fehlermeldung: "Message could not be sent, DP: System1:ap.:_original.._value, MAN: (SYS: 1 Dist -num 1 CONN: 1), Could not send message DP_MSG_SIMPLE_REQUEST #326" .

SQL Abfragen

  • Es ist nicht möglich, systemübergreifende Abfragen, d.h. also SQL Abfragen auf 2 oder mehr Systeme gleichzeitig, zu tätigen. Solche Aufgabenstellungen müssen über zwei oder mehrere Abfragen auf jeweils nur ein einziges System gelöst werden. Auch der Meldeschirm und der Ereignisschirm teilen solche Abfragen in verteilten Systemen intern auf mehrere Abfragen auf.

  • Abfragen erfolgen mit entsprechenden SQL Schlüsselwort (= REMOTE) systemübergreifend. Siehe auch SQL Panel. Eine Abfrage auf alle Systeme erfolgt mit dem Schlüsselwort REMOTE ALL.

Treiberparametrierung

  • Die Parametrierung von Treiber Datenpunkten in verteilten Systemen ist nur am eigenen System erlaubt!