DE19838469B4

DE19838469B4 - Prozeßsteuer- und Regelsystem mit verteilter Verarbeitung

Info

Publication number: DE19838469B4
Application number: DE19838469A
Authority: DE
Inventors: Stephan Dipl.-Ing. Merker; Matthias Dr.rer.nat. Schumann
Original assignee: ABB Research Ltd Switzerland; ABB Research Ltd Sweden
Current assignee: ABB Research Ltd Switzerland; ABB Research Ltd Sweden
Priority date: 1998-08-25
Filing date: 1998-08-25
Publication date: 2007-10-18
Anticipated expiration: 2018-08-26
Also published as: DE19838469A1

Abstract

Prozeßsteuer- und Regelsystem mit verteilter Verarbeitung, das zumindest mehrere Controller (C) zur Prozeßsteuerung, eine Konfigurationsstation (E), eine Bedienstation (O) und einen Komponentenserver (S) als Teilsysteme, 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 Teilplattformen (CP, EP, OP, XP) gebildet ist, wovon zumindest eine ausgewählte Teilplattform (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.

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.
Aus der WO 95/30937 A1 ist ein Leitsystem für eine technische Anlage bekannt, bei dem die hierarchisch zwischen der Betriebsführungsebene und der Automatisierungsebene angeordnete Leitebene modular aufgebaut ist. In dieser Leitebene sind Funktionsbausteine mit standardisierten Schnittstellen vorgesehen, die entsprechend der zu lösenden technischen Aufgabe miteinander verknüpft werden. Die Verdrahtung und/oder Programmierung erfolgt durch Strukturieren in abgeschlossenen Funktionsbausteinen und ist statisch hinterlegt.
Aus dem Aufsatz „Das Prozessleitsystem Advant OCS von ABB" von Ulrich Epple, veröffentlicht in der atp – Automatisierungstechnische Praxis 38, 1996, 12, S. 37–45, ist bekannt, an einen Systembus sowohl Controller als auch Bedien- und Beobachtungseinrichtungen, Engeneeringstationen oder Informationsmanagementstationen anzuschließen.
Hierzu zeigt 5 zur Verdeutlichung 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 -regelung über ein Kommunikationsnetzwerk N verbunden. An die Controller C sind Feldgerä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 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 benutzer-definierte Funktionsblöcke, die sich aus Basis-Funktionsblöcken zusammensetzen (beispielsweise eine Pumpensteuerung bestehend aus AI, PID und AO), unterschieden. 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 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 System-Software im jeweiligen Teilsystem verfügbar sein muß, bevor auch nur ein einziger Basis-Funktionsblock verwendet werden kann. Bei Systemerweiterungen, z.B. weil neue Basis-Funktionsblöcke hinzugefügt werden sollen, muß in den Teilsystemen die gesamte Software ausgetauscht werden.
7 zeigt am Beispiel von Controllern C, wie beispielsweise die vollständige Systemsoftware SS, die auch die Basis-Funktionsblöcke enthält, mittels eines download 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 Konfiguration vorgenommen werden. Die Konfigurationsdaten CD werden zu den Controllern 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 Regelsystems.
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 Regelsystem mit verteilter Verarbeitung und mit einer System-Architektur anzugeben, die mit geringem Aufwand flexibel an die konkrete automatisierungstechnische Aufgabe anpassbar ist.
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:
1 eine System-Architektur eines Prozeßsteuer- und -Regelsystems,
2 die zugehörige Software-Architektur,
3 eine Programmlade- und -Konfigurationsprozedur,
4 einen möglichen Einsatz eines Standard-Softwarewerkzeugs zur Konfiguration,
5 eine bekannte System-Architektur,
6 die zugehörige bekannte Software-Architektur und
7 eine bekannte Programmlade- und Konfigurationsprozedur.
1 zeigt eine Struktur eines Prozeßsteuer- und -Regelsystems mit verteilter Verarbeitung, die bereits weitgehend anhand der 5 erläutert wurde. Die Struktur gemäß 1 enthält zusätzlich einen Komponentenserver S, auf dem erfindungsgemäß vorgeschlagene DCS (Distributed Control System)-Komponenten installiert sind.
2 zeigt die zugehörige Software-Architektur, wobei dargestellt ist, daß die generische 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 5 dargestellten System-Architektur. Diese 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 Softwarekomponenten, also Steuer- und Regelkomponenten CC, Konfigurationskomponenten EC, Bedienerkomponenten OC, sowie Komponenten XC zu Zusatzfunktionen Y abholen. Beobachtungs- und Überwachungsfunktionen können z.B. zu den Bedienerkomponenten OC gehören. Zu den Zusatzfunktionskomponenten XC können beispielsweise Inbetriebssetzungsroutinen, Diagnosefunktionen und Historienspeicherung zählen. Die Teilsystem-spezifischen Komponenten sind ebenfalls hardware-unabhängig ausgeführt.
In 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 verteilt 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 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 (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 spezifischen Komponenten CC aus den funktionellen Komponenten AI, AO, PID vom Server 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 gespeichert werden. Wenn eine Funktion, wie beispielsweise die Analogeingabe AI geändert 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 Komponenten vom Server S zu laden. So ist es zum Beispiel nicht notwendig, einen Controller C anzuhalten, um einen neuen Basis-Funktionsbaustein zur Teilplattform CP hinzuzufügen.
Es ist zwar möglich, aber nicht erforderlich, eine spezielle Software für die Konfigurationstation E zu entwickeln. Als Konfigurationssoftware kann ein standard component 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 beispielsweise zur Konfiguration eines Controllers ist in 4 dargestellt. Ein Anwender wählt mittels seiner Konfigurationsdaten erforderliche Teilsystem-spezifische Komponenten EC (vgl. 2) aus. Das Tool bewirkt, daß die benötigten Komponenten EC aus dem Server S abgerufen werden. Jede Konfigurationskomponente EC korrespondiert 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 Datenbank geschrieben, die vom Controller während der Inbetriebnahme ausgelesen wird.
Der eigentliche Konfigurationsvorgang des Controllers C wurde bereits beschrieben (3).

Claims

Prozeßsteuer- und Regelsystem mit verteilter Verarbeitung, das zumindest mehrere Controller (C) zur Prozeßsteuerung, eine Konfigurationsstation (E), eine Bedienstation (O) und einen Komponentenserver (S) als Teilsysteme, 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 Teilplattformen (CP, EP, OP, XP) gebildet ist, wovon zumindest eine ausgewählte Teilplattform (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.
Prozeßsteuer- und Regelsystem nach Anspruch 1, dadurch gekennzeichnet, daß als generische Teilplattformen (CP, EP, OP, XP) eine Steuer- und Regelplattform (CP), eine Konfigurationsplattform (EP), eine Bedienerplattform (OP) sowie Plattformen für Zusatzfunktionen (XP) vorhanden sind.
Prozeßsteuer- und Regelsystem nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß als Teilsystem-spezifische Komponenten (CC, EC, OC, XC) Steuer- und Regelkomponenten (CC), Konfigurationskomponenten (EC), Bedienerkomponenten (OC), sowie Komponenten zu Zusatzfunktionen (XC) vorhanden sind.
Prozeßsteuer- und Regelsystem nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, daß als Konfigurations-Teilplattform (EP) ein standard component builder tool verwendet wird.