DE19838469A1 - Prozeßsteuer- und Regelsystem mit verteilter Verarbeitung - Google Patents

Abstract

Die Erfindung bezieht sich auf ein Prozeßsteuer- und Regelsystem mit verteilter Verarbeitung, das Teilsysteme, wie mehrere Controller (C) zur Prozeßsteuerung, eine Konfigurationsstation (E) und gegebenenfalls weitere Teilsysteme (O, X), einen Komponentenserver (S) sowie eine Systemsoftware (DCS) enthält. DOLLAR A Zur Erleichterung der Erweiter- und Änderbarkeit sowie zur Verminderung des Speicherplatzbedarfs wird eine Software-Architektur vorgeschlagen, bei der die Systemsoftware (DCS) eine generische Systemsoftware-Plattform (DCS-Plattform) enthält, die durch generische Teilplattformen (DC, EP; OP, XP) jeweils in den entsprechenden Teilsystemen (C, E; O, X) installiert ist. DOLLAR A Im Komponentenserver (S) sind funktionelle Systemsoftware-Komponenten, wie beispielsweise Analogeingabe-Funktionen (AI), Analogausgabe-Funktionen (AO) und Regelalgorithmen (PID), gespeichert, die jeweils Teilsystem-spezifische Komponenten (CC, EC, OC, XC) enthalten. DOLLAR A Die generischen Teilplattformen (CP, EP, OP, XP) sind in der Lage, die benötigten Teilsystem-spezifischen Komponenten (CC, EC, OC, XC) zur Laufzeit bei Bedarf automatisch vom Server (S) zu laden. DOLLAR A Als generische Teilplattform (EP) der Konfigurationsstation (E) kann ein standard component builder tool verwendet werden, das aus der Softwareentwicklung bekannt ist, wie z. B. Visual Basic oder Java Studio.

Description

Die Erfindung bezieht sich auf ein Prozeßsteuer- und Regelsystem mit verteilter Verarbeitung. Solche Systeme sind beispielsweise in leittechnischen Systemen für Kraftwerke oder sonstige Industrieanlagen anwendbar.

Fig. 5 zeigt eine typische hierarchische Struktur eines üblichen Prozeßsteuer- und Regelsystems. In einer oberen hierarchischen Ebene sind als Sub- oder Teilsysteme eine Bedien(Operator)-Station O, eine Konfigurations(Engineering)-Station E, und sonstige Stationen X sowie mehrere Controller C zur Prozeßsteuerung und -rege­ lung über ein Kommunikationsnetzwerk N verbunden. An die Controller C sind Feld­ geräte F jeweils über einen Feldbus B angeschlossen.

Die verteilte Informationsverarbeitung erfolgt in einem solchen System auf der Basis von Software-Funktionsblöcken, wie in Fig. 6 als zugehörige Software-Architektur dargestellt ist. Funktionsblöcke werden in Basis-Funktionsblöcke (beispielsweise für Analogeingaben AI, Analogausgaben AO oder Regelalgorithmen PID) und in benut­ zerdefinierte Funktionsblöcke, die sich aus Basis-Funktionsblöcken zusammenset­ zen (beispielsweise eine Pumpensteuerung bestehend aus AI, PID und AO), unter­ schieden. In den Teilsystemen O, E, C, X sind derartige Basis-Funktionsblöcke AI, AO, PID jeweils monolithisch in der Systemsoftware gepackt. Beispielsweise enthält die Software der Konfigurationsstation E die erforderliche Konfigurationssoftware für die Funktionsblöcke AI, AO, PID und die Controller C enthalten die Software zur Ausführung der jeweiligen Funktion AI, AO, PID.

Die Funktionsblöcke AI, AO, PID und die Controller C enthalten die Software zur Ausführung der jeweiligen Funktion AI, AO, PID.

Nachteilig ist, daß eine solche Software-Architektur erfordert, daß die gesamte Sy­ stem-Software im jeweiligen Teilsystem verfügbar sein muß, bevor auch nur ein ein­ ziger Basis-Funktionsblock verwendet werden kann. Bei Systemerweiterungen, z. B. weil neue Basis-Funktionsblöcke hinzugefügt werden sollen, muß in den Teilsyste­ men die gesamte Software ausgetauscht werden.

Fig. 7 zeigt am Beispiel von Controllern C, wie beispielsweise die vollständige Sy­ stemsoftware SS, die auch die Basis-Funktionsblöcke enthält, mittels eines down­ load tools D in einem ersten Schritt über das Netzwerk in die Controller C gebracht wird. In einem zweiten Schritt kann mittels der Konfigurationsstation E eine Konfigu­ ration vorgenommen werden. Die Konfigurationsdaten CD werden zu den Control­ lern C übertragen.

Anstelle eines solchen downloads kann auch ein Austausch von PROMs (programmierbaren Speicherbausteinen) erfolgen.

Nachteilig ist aber in jedem Fall, daß jeweils die gesamte Systemsoftware in das Teilsystem installiert werden muß, auch wenn nur einer der Funktionsblöcke benö­ tigt wird. Damit ist verbunden, daß jeweils ein entsprechend großer Hauptspeicher vorhanden sein muß. Weiterhin ist es notwendig, die komplette System-Software auszutauschen, wenn ein oder mehrere Basis-Funktionsbausteine einem Teilsystem hinzugefügt werden sollen. Insbesondere bei Controllern bedeutet das Installieren von System-Software manuelle Arbeit und ein Ausfall des Prozeßsteuer- und Regel­ systems.

Soweit ein textuelles oder graphisches Interface verwendet werden soll, muß für die Konfigurationsstation bzw. die Bedienstation eine anwenderspezifische Software entwickelt werden.

Der Erfindung liegt daher die Aufgabe zugrunde, ein Prozeßsteuer- und Regelsy­ stem mit verteilter Verarbeitung und mit einer System-Architektur anzugeben, mit der sich die genannten Nachteile vermeiden lassen.

Diese Aufgabe wird durch ein Prozeßsteuer- und Regelsystem mit den im Anspruch 1 angegebenen Merkmalen gelöst. Vorteilhafte Ausgestaltungen sind in weiteren Ansprüchen angegeben und der nachstehenden Erläuterung der Erfindung anhand eines in Zeichnungsfiguren dargestellten Ausführungsbeispiels zu entnehmen.

Es zeigen:

Fig. 1 eine System-Architektur eines Prozeßsteuer- und -Regelsystems,

Fig. 2 die zugehörige Software-Architektur,

Fig. 3 eine Programmlade- und -Konfigurationsprozedur,

Fig. 4 einen möglichen Einsatz eines Standard-Softwarewerkzeugs zur Konfi­ guration,

Fig. 5 eine bekannte System-Architektur,

Fig. 6 die zugehörige bekannte Software-Architektur und

Fig. 7 eine bekannte Programmlade- und Konfigurationsprozedur.

Fig. 1 zeigt eine Struktur eines Prozeßsteuer- und -Regelsystems mit verteilter Ver­ arbeitung, die bereits weitgehend anhand der Fig. 5 erläutert wurde. Die Struktur gemäß Fig. 1 enthält zusätzlich einen Komponentenserver S. auf dem erfindungs­ gemäß vorgeschlagene DCS (Distributed Control System)-Komponenten installiert sind.

Fig. 2 zeigt die zugehörige Software-Architektur, wobei dargestellt ist, daß die gene­ rische System-Software-Plattform (DCS-Platform) gebildet ist durch generische Teilplattformen, wie Steuer- und Regelplattform CP, Konfigurationsplattform EP, Bedienerplattform OP sowie gegebenenfalls weitere, mit XP bezeichnete Plattformen für Zusatzfunktionen Y. Die Teilplattformen korrespondieren zu den funktionellen Teilsystemen der traditionellen, z. B. in Fig. 5 dargestellten System-Architektur. Die­ se Software-Plattformen CP, EP, OP, XP sind unabhängig von einer bestimmten Hardware konzipiert. Sie sind jeweils in den zugehörigen Teilsystemen C, E, O, X gespeichert. Die Teilplattformen sind in der Lage, mit dem Komponentenserver S zu kommunizieren. Sie beinhalten insbesondere keine Basis-Funktionsbausteine.

Eine jeweils in den Teilsystemen benötigte Funktionalität wird dadurch geschaffen, daß sie vom Komponentenserver S entsprechende Teilsystem-spezifische Software­ komponenten, also Steuer- und Regelkomponenten CC, Konfigurationskomponenten EC, Bedienerkomponenten OC, sowie Komponenten XC zu Zusatzfunktionen Y ab­ holen. Beobachtungs- und Überwachungsfunktionen können z. B. zu den Bediener­ komponenten OC gehören. Zu den Zusatzfunkfionskomponenten XC können bei­ spielsweise Inbetriebssetzungsroutinen, Diagnosefunktionen und Historienspeiche­ rung zählen. Die Teilsystem-spezifischen Komponenten sind ebenfalls hard­ wareunabhängig ausgeführt.

In Fig. 2 ist dargestellt, daß die funktionellen Systemsoftwarekomponenten AI, AO, PID, also die Basisfunktionen, die im Komponentenserver S gespeichert sind, jeweils Teilsystem-spezifische Komponenten CC, EC, OC, XC enthalten, die abrufbar sind zur Ergänzung der Teilplattformen CP, EP, OP, XP.

Anstelle monolithischer System-Softwareblöcke, die über das gesamte System ver­ teilt sind, ist somit erfindungsgemäß eine zentrale Speicherung der Systemsoftware im Server S vorgesehen, mit der Möglichkeit, daraus spezifische Komponenten zur Ergänzung generischer Plattformen abzurufen. Das bedeutet, daß zu Beginn der Installationsphase die Teilsysteme E, O, C, X außer den Teilplattformen CP, EP, OP, XP noch keine Systemsoftware enthalten. Diese wird erst durch den Abhol- und Konfigurationsvorgang in die Teilsysteme E, O, C, X geladen.

In Fig. 3 ist eine solche Konfiguration von Controllern C dargestellt. Nachdem ein Anwender Konfigurationsdaten CD in die Konfigurationsstation E eingegeben hat und diese über das Netzwerk N (Fig. 1) im Schritt 1 zum jeweiligen Controller C übertragen sind, fordert dessen Plattform CP im Schritt 2 benötigte spezifische Komponenten CC beim Server S an. Im Schritt 3 werden die entsprechenden spezi­ fischen Komponenten CC aus den funktionellen Komponenten AI, AO, PID vom Ser­ ver S in die Controller C übertragen.

Daraus wird deutlich, daß das System aufgrund der in Komponenten unterteilten System-Software feinstufig erweitert werden kann. In den Teilsystemen bzw. deren Plattformen muß in den Hauptspeichern nur eine ausgewählte Konfiguration gespei­ chert werden. Wenn eine Funktion, wie beispielsweise die Analogeingabe AI geän­ dert werden soll, bedarf dies lediglich einer Änderung der im Server S gespeicherten Software und mittels eines Software-Werkzeugs einer Anweisung an die betroffenen Teilsysteme, die neue spezifische Softwarekomponente abzurufen und damit die alte Komponente zu ersetzen. Die Teilsysteme sind in der Lage, zur Laufzeit Komponen­ ten vom Server S zu laden. So ist es zum Beispiel nicht notwendig, einen Controller C anzuhalten, um einen neuen Basis-Funktionsbaustein zur Teilplattform CP hinzu­ zufügen.

Es ist zwar möglich, aber nicht erforderlich, eine spezielle Software für die Konfigu­ rationstation E zu entwickeln. Als Konfigurationssoftware kann ein standard compo­ nent builder tool verwendet werden, wie sie aus der Softwareentwicklung bekannt sind, z. B. Visual Basic von Fa. Microsoft oder Java Studio von Fa. Sun. Es versteht sich, daß in diesem Fall die entsprechenden Teilsystem-spezifischen Komponenten EC abgestimmt sein müssen auf die Architektur, die vom Tool unterstützt wird, wie z. B. ActiveX für Visual Basic oder JavaBeans für Java Studio.

Die Vorgehensweise mit Hilfe eines standard component builder tools beispielswei­ se zur Konfiguration eines Controllers ist in Fig. 4 dargestellt. Ein Anwender wählt mittels seiner Konfigurationsdaten erforderliche Teilsystem-spezifische Komponen­ ten EC (vgl. Fig. 2) aus. Das Tool bewirkt, daß die benötigten Komponenten EC aus dem Server S abgerufen werden. Jede Konfigurationskomponente EC korrespon­ diert dabei zu einer Steuer- und Regelkomponente CC. Der Anwender kann somit das Steuer- bzw. Regelprogramm aus den Konfigurationskomponenten EC erstellen. Die Konfigurationskomponente EC enthält die Information, in welchen Controllern C die korrespondierende Steuer- und Regelkomponente CC ausgeführt werden soll, sowie weitere Konfigurationsinformationen, damit die benötigten Funktionen AI, AO, PID im Controller C ausführbar werden. Im Fall eines Online-Engineerings können die Komponenten EC die Konfigurationsinformation direkt zum Controller C senden. Im Fall eines Offline-Engineerings wird die Konfigurationsinformation in eine Daten­ bank geschrieben, die vom Controller während der Inbetriebnahme ausgelesen wird.

Der eigentliche Konfigurationsvorgang des Controllers C wurde bereits beschrieben (Fig. 3)

Claims (4)

1. Prozeßsteuer- und Regelsystem mit verteilter Verarbeitung, das Teilsysteme, wie mehrere Controller (C) zur Prozeßsteuerung, eine Konfigurati­ onsstation (E) und gegebenenfalls weitere Teilsysteme (O, X), einen Komponenten­ server (S), sowie eine Systemsoftware (DCS) enthält, wobei

• a) die Systemsoftware (DCS) eine generische Systemsoftware-Plattform (DCS- Platform) und funktionelle Systemsoftware-Komponenten (DCS- Komponenten) enthält,
• b) die Systemsoftware-Plattform (DCS-Platform) durch generische Teilplattfor­ men (CP, EP, OP, XP) gebildet ist, wovon zumindest eine ausgewählte Teil­ plattform (CP, EP, OP, XP) jeweils in den entsprechenden Teilsystemen (C, E, O, X) installiert ist,
• c) im Komponentenserver (S) die funktionellen Systemsoftware-Komponenten, wie beispielsweise Analogeingabe-Funktionen (AI), Analogausgabe- Funktionen (AO), und Regelalgorithmen (PID) gespeichert sind, die jeweils Teilsystem-spezifische Komponenten (CC, EC, OC, XC) enthalten, und
• d) die generischen Teilplattformen (CP, EP, OP, XP) dafür eingerichtet sind, die benötigten Teilsystem-spezifischen Komponenten (CC, EC, OC, XC) zur Laufzeit bei Bedarf automatisch vom Server S zu laden.

2. Prozeßsteuer- und Regelsystem nach Anspruch 1, dadurch gekennzeich­ net, daß als generische Teilplattformen (CP, EP, OP, XP) eine Steuer- und Regelplatt­ form (CP), eine Konfigurationsplattform (EP), eine Bedienerplattform (OP) sowie Plattformen für Zusatzfunktionen (XP) vorhanden sind.

3. Prozeßsteuer- und Regelsystem nach Anspruch 1 oder 2, dadurch ge­ kennzeichnet, daß als Teilsystem-spezifische Komponenten (CC, EC, OC, XC) Steu­ er- und Regelkomponenten (CC), Konfigurationskomponenten (EC), Bedienerkom­ ponenten (OC), sowie Komponenten zu Zusatzfunktionen (XC) vorhanden sind.

4. Prozeßsteuer- und Regelsystem nach Anspruch 1, 2 oder 3, dadurch ge­ kennzeichnet, daß als Konfigurations-Teilplattform (EP) ein standard component builder tool verwendet wird.