-
Technisches
Gebiet der Erfindung
-
Die vorliegende Erfindung betrifft
allgemein Rechner- und
Datenverarbeitungssysteme und insbesondere ein System und ein Verfahren
zum Ausgleichen und Verteilen der Steueralgorithmus-Verarbeitungslast und
ein Echtzeit-Anlagensteuersystem, das das System oder das Verfahren
verwendet.
-
Allgemeiner Stand der
Technik
-
Automatisierte Prozeßsteuersysteme
enthalten eine umfassende Menge von Steueralgorithmen oder softwaredefinierbaren
Prozeßsteuerroutinen
zur Steuerung und Überwachung
verschiedener Prozeße
zum Beispiel in einer Herstellungseinrichtung. Die Steuersysteme
können
angepaßt
werden, um vielfältige
Prozeßanforderungen
global oder innerhalb spezifizierter Teile der Einrichtung zu erfüllen. Die
Steuersysteme enthalten gewöhnlich
vielfältige
Module jeweils mit ihrem eigenen Prozeßor oder ihrer eigenen Firmware,
die durch Kommunikationsbusse miteinander verbunden sind, so daß sich ein
verteiltes Prozeßsteuersystem
ergibt. Die verteilte Beschaffenheit des Systems bietet eine hohe
Leistungsfähigkeit
mit der Möglichkeit,
das System in Schritten zu erweitern, um einem Wachstum oder Modifikationen
in der Einrichtung zu genügen.
-
Um es einem Benutzer zu erlauben,
ein Prozeßsteuersystem
an eine bestimmte Verarbeitungsumgebung anzupassen, ist es wichtig,
solche Systeme mit hochgradig konfigurierbaren und anpaßbaren Steuersystemen
auszustatten. Prozeßsteuersysteme
liefern im allgemeinen ein Mittel, durch das Benutzer kundenspezifische
Steuerstrategien, z. B. softwaredefinierbare Prozeßsteuerroutinen,
erzeugen können.
In objektorientierten Programmierumgebungen kann aus kleineren Komponenten
wie zum Beispiel Blöcken
und Parametern eine vollständige
Steuerstrategie aufgebaut werden. Ein Block ist ein Softwarekonstrukt
oder ein Objekt, mit dem die Daten und die Algorithmen elementarer
Steuerberechnungen eingekapselt werden; Parameter definieren die
Schnittstelle zu einzelnen Datenelementen in einem Block.
-
Digitale Prozeßsteuerungen (DPCs) müssen im
allgemeinen eine Reihe von Anforderungen bezüglich der Art und Weise, auf
die sie Steueralgorithmen verarbeiten, erfüllen. Zum Beispiel müssen sie
die Steueralgorithmen auf periodische Weise ausführen. Die Steueralgorithmen
müssen
mit einer Abtastrate ausgeführt werden,
wobei das Abtastraten-Jitter im Vergleich zu der Toleranz der Prozeßdynamik
klein genug ist. DPCs müssen
möglicherweise
zusätzliche
Algorithmen ausführen,
deren Funktionen für
die gesamte Prozeßsteuermission
wesentlich sind, die aber nicht periodisch und vorhersehbar sind,
z. B. Kommunikation mit Überwachungsanzeige-
und -steuerstationen, Kommunikation mit Peer-Steuerungen, Ereignisverteilung
und Verwaltungsaufgaben. DPCs müssen
nichtperiodische Algorithmen auf eine Weise ausführen, die die deterministische
Ausführung
periodischer Steueralgorithmen nicht stört, solange die DPCs in einem
definierten Betriebsbereich konfiguriert sind.
-
Um diese oben beschriebenen Anforderungen
zu erfüllen,
müssen
DPCs die Steueralgorithmus-Verarbeitungslast ausgleichen und sie über das
Zeitintervall der Grundwiederholungsrate der DPCs verteilen. Herkömmliche
DPCs, wie zum Beispiel die Steuerungen TDC3000 von Honeywell Inc.,
die als Process Manager, Advanced Process Manager und High Performance
Process Manager bekannt sind, stufen eine Konfiguration im voraus
ein und entscheiden auf der Grundlage des vorhergesehenen Potentials
für Überlastung,
ob die Konfiguration angenommen oder zurückgewiesen wird. Diese DPCs
unterstützen
jedoch keinen manuellen Ausgleich, den Ausgleich einer Teilmenge
von Algorithmen, während andere
Algorithmen die Steuerung behalten, Benutzermessung der Ausführungszeit
für einen
bestimmten Algorithmus oder das Zuordnen von Ausführungszeit
zu einem Algorithmus als ein charakteristisches Attribut.
-
Andererseits ermöglichen andere herkömmliche
DPCs, wie zum Beispiel der Alcont Process Manager von Honeywell
nur einen manuellen Ausgleich der Algorithmusverarbeitungslast.
Diese DPCs unterstützen
jedoch keine Einstufung einer Algorithmuslast auf der Grundlage
einer Modellberechnung oder ein Zurückweisen einer Last, die zu
hoch ist. Noch andere DPCs, wie zum Beispiel der TPS Networks Safety
Manager von Honeywell gewährleisten
die Rechenausführungszeit
aus Kenngrößen einer
bestimmten Algorithmuskonfiguration, unterstützen aber keinen Ausgleich
von Teilmengenalgorithmen, während
andere Algorithmen die Steuerung behalten.
-
Deshalb wird in der Technik ein verbessertes
Verfahren zur Verwaltung der Algorithmusverarbeitungslast in einer
Prozeßsteuerung
benötigt,
das alle oben erwähnten
Merkmale in eine Steuerung integriert. Genauer gesagt wird in der
Technik ein Verfahren benötigt,
das ein flexibles Management der Algorithmusverarbeitungslast gewährleistet.
-
Kurze Darstellung
der Erfindung
-
Die vorliegende Erfindung liefert
ein System gemäß dem folgenden
Anspruch 1.
-
Das System kann die Merkmale eines
beliebigen oder mehrerer der abhängigen
Ansprüche
2 bis 6 enthalten.
-
Die vorliegende Erfindung liefert
außerdem
ein Verfahren gemäß dem folgenden
Anspruch 7.
-
Das Verfahren kann das Merkmal eines
beliebigen oder mehrerer der abhängigen
Ansprüche
8 bis 11 enthalten.
-
Die vorliegende Erfindung kann eine
wesentlich flexiblere und leistungsstärkere Methode zum Ausgleichen
und Verteilen von Steueralgorithmus-Verarbeitungslasten liefern.
-
Deshalb stellt die vorliegende Erfindung
ein modellgestütztes
Steueralgorithmusausgleich- und -verteilungssystem bereit, bei dem
jeden auszugleichenden Steueralgorithmus betreffende Daten zur Ableitung
einer abgeschätzten
Ausführungszeit
verwendet werden, wobei der Benutzer jedoch wahlweise übersteuernde, empirisch
bestimmte (möglicherweise
tatsächlich
gemessene, vielleicht formelmäßig analysierte,
vielleicht intuitiv geschätzte)
Ausführungszeiten
eingeben kann.
-
Das System kann das Modell zum Zeitpunkt
der Konfiguration dieser bestimmten Steueralgorithmen ablaufen lassen,
um ein iteratives und interaktives Stattfinden des Ausgleichens
und Verteilens zu ermöglichen,
falls dies gewünscht
ist. Als Alternative ermöglicht
bei einer Ausführungsform
der vorliegenden Erfindung der Dateneingabeprozeß dem Benutzer, die Last unter
der Steuerung des Benutzers selbst auszugleichen und zu verteilen.
-
Bei einer Ausführungsform der vorliegenden
Erfindung kann bei dem Modell mindestens ein Steueralgorithmus konfiguriert
und die Last ausgeglichen und verteilt werden, ohne daß der Betrieb
anderer Steueralgorithmen unterbrochen wird. Alternativ dazu kann
das System die Ausführung
der anderen Steueralgorithmen unterbrechen, um zu pausieren oder
anzuhalten, während
das Ausgleichen und Verteilen stattfindet.
-
Bei einer Ausführungsform der vorliegenden
Erfindung werden entweder die Daten oder die Zeit in dem Modell für jede Instanz
mindestens eines Steueralgorithmus repliziert. Vorzugsweise muß der Benutzer nicht
die Daten oder die Zeit mit jedem Auftreten eines gegebenen Steueralgorithmus
assoziieren. Bei bestimmten Ausführungsformen
kann der Benutzer jedoch eine solche manuelle Assoziation durchführen.
-
Bei einer Ausführungsform der vorliegenden
Erfindung enthalten die Konfigurationsdaten einen Algorithmustyp,
eine Algorithmusausführungszeit,
einen Algorithmusblockzählwert
und einen Datenflußverbindungszählwert.
Für Fachleute
ist erkennbar, daß auch
andere Konfigurationsdatentypen vorteilhaft mit der vorliegenden
Erfindung verwendet werden können.
-
Bei einer Ausführungsform der vorliegenden
Erfindung bildet mindestens ein Steueralgorithmus einen Teil eines
Steuermoduls mit Konfigurationsparametern, die aus der folgenden
Gruppe ausgewählt
werden: (1) Periode, (2) geschätztes
Gewicht und (3) Phase. Das Modell verwendet die Konfigurationsparameter
zum Ausgleichen und Verteilen der Verarbeitungslast. Natürlich können bei
einer gegebenen Anwendung zusätzliche oder
andere Parameter erwünscht
sein.
-
Bei einer Ausführungsform der vorliegenden
Erfindung kann das Modell einem Benutzer eine tatsächliche
Ausführungszeit
mindestens eines Steueralgorithmus angeben. Dadurch kann der Benutzer
die Leistungsfähigkeit
mindestens eines Steueralgorithmus bewerten und darauf basierend
Entscheidungen treffen.
-
Es wurden oben relativ allgemein
die Merkmale und technischen Vorteile der vorliegenden Erfindung skizziert,
so daß Fachleute
die folgende ausführliche
Beschreibung der Erfindung besser verstehen können. Zusätzliche Merkmale und Vorteile
der Erfindung werden nachfolgend beschrieben und bilden den Gegenstand
der Ansprüche
der Erfindung.
-
Kurze Beschreibung
der Zeichnungen
-
Für
ein besseres Verständnis
der vorliegenden Erfindung und ihrer Vorteile wird nun auf die folgenden Beschreibungen
in Verbindung mit den beigefügten
Zeichnungen Bezug genommen. Es zeigen:
-
1 ein
Funktionsschaltbild eines beispielhaften verteilten Echtzeit-Prozeßsteuersystems,
mit dem die vorliegende Erfindung geeigneterweise verwendet werden
kann;
-
2 ein
Blockschaltbild auf hoher Ebene eines beispielhaften digitalen Verarbeitungssystems,
das verwendet werden kann, um softwaredefinierbare Prozeßsteuerroutinen
auszuführen,
die die Prinzipien der vorliegenden Erfindung realisieren;
-
3 eine
Ausführungsform
eines Echtzeit-Prozeßsteuersystems,
das eine Ausführungsform
einer Steuerung verwendet, die unter Verwendung der Prinzipien der
vorliegenden Erfindung in einer objektorientierten Programmierumgebung
konstruiert wurde;
-
4 ein
beispielhaftes Interaktionsdiagramm, das zusammenfaßt, wie
verschiedene Subsysteme innerhalb der vorliegenden Erfindung miteinander
in Wechselwirkung treten.
-
Ausführliche
Beschreibung
-
Vor einer Beschreibung der Ausführungsbeispiele
der Systeme und Verfahren der vorliegenden Erfindung wird es hilfreich
sein, eine Rechner- oder Datenverarbeitungssystemumgebung zu beschreiben,
in der die vorliegende Erfindung geeigneterweise verwendet oder
implementiert werden kann. Unter anfänglicher Bezugnahme auf 1 ist ein Funktionsschaltbild
eines beispielhaften verteilten Echtzeit- Prozeßsteuersystems (mit der allgemeinen
Kennzeichnung 100) gezeigt, mit dem die vorliegende Erfindung
geeigneterweise verwendet werden kann.
-
Das Prozeßsteuersystem 100 enthält beispielsweise
ein Computernetzwerk mit einem Server 110 und einem Steuerungsnetzwerk 111.
Das Steuerungsnetzwerk 111 liefert eine Schnittstelle zwischen
dem Server 110 und DPCs (mit der allgemeinen Kennzeichnung 121);
das Steuerungsnetzwerk 111 kann zum Beispiel Überwachungsnachrichten
zwischen dem Server 110 und DPCs 121 und Peer-to-Peer-Nachrichten
zwischen den DPCs 121 führen.
Die DPCs 121 kommunizieren über ein E/A-Netzwerk 112 mit Eingabe-/Ausgabegeräten (E/A-Geräten) 122.
Die DPCs 121 sind so ausgelegt, daß sie softwaredefinierbare
Prozeßsteuerroutinen zur
Steuerung von Prozeßsensoren
und Stellgliedern 130 und zum Empfangen von Daten von diesen über E/A-Geräte 122 und
das E/A-Netzwerk 112 ausführen. Fachleute werden mit
verschiedenen Arten von Prozeßsensoren
und Stellgliedern 130 vertraut sein, wie zum Beispiel elektrisch
steuerbaren Motoren, Ventilen oder Pumpen, die bei der Herstellung
verschiedener Produkte verwendet werden können; die Prinzipien der vorliegenden
Erfindung sind jedoch nicht auf einen spezifischen Prozeß oder ein
spezifisches Verarbeitungssystem beschränkt, sondern können in
jedem beliebigen solchen System ohne weiteres vorteilhaft verwendet werden.
-
Bei einer Ausführungsform enthält das Prozeßsteuersystem 100 weiterhin
ein lokales Netzwerk (LAN) 113, das eine Schnittstelle
zwischen dem Server 110 und abgesetzten Workstations (mit
der allgemeinen Kennzeichnung 140) bereitstellt. Systembediener
können
die abgesetzten Workstations 140 zur Steuerung und Überwachung
des Betriebs des Prozeßsteuersystems 100 benutzen.
Obwohl sie als ein separates Netzwerk dargestellt sind, können das
LAN 112 und das Steuerungsnetzwerk 111 ein und
dasselbe sein, d. h. die abgesetzten Workstations 140 und
die DPCs 120 können
sich dasselbe Netzwerkübertragungsmedium
teilen. Für
Fachleute ist jedoch erkennbar, daß die Bereitstellung separater
Netzwerke für
Steuersysteme und Bedienerworkstations die Zuverlässigkeit
eines verteilten Echtzeit-Prozeßsteuersystems
verbessern kann, z. B. stört Netzwerkverkehr
auf dem LAN 112 in Verbindung mit dem Verteilen prozeßbezogener
Daten von dem Server 110 zu den Bedienerworkstations 140 nicht
die Prozeßsteuerinformationen,
die über
das Steuernetzwerk 111 zwischen dem Server 110 und
den abgesetzten DPCs 120 übertragen werden.
-
Softwaredefinierbare Prozeßsteuerroutinen
können
von jedem beliebigen digitalen Verarbeitungssystem ausgeführt werden,
wie zum Beispiel durch den Server 110, Workstations 140 oder
DPCs 121. 2 zeigt ein
Blockschaltbild auf hoher Ebene eines beispielhaften digitalen Verarbeitungssystems 200,
das verwendet werden kann, um softwaredefinierbare Prozeßsteuerroutinen
auszuführen,
die die Prinzipien der vorliegenden Erfindung realisieren. Das beispielhafte
digitale Verarbeitungssystem 200 enthält einen MikroProzeßor 210,
einen nichtflüchtigen
Speicher 220 und Direktzugriffsspeicher (RAM) 230.
Der nichtflüchtige
Speicher 220, der zum Speichern softwaredefinierbarer Prozeßsteuerroutinen
verwendet wird, kann zum Beispiel einen programmierbaren Nurlesespeicher
(PROM), einen Flash-ROM oder ein magnetisches Speichermedium umfassen.
Die in dem nichtflüchtigen
Speicher 220 gespeicherten softwaredefinierbaren Prozeßsteuerroutinen
werden durch den MikroProzeßor 210 ausgeführt. Der
MikroProzeßor
verwendet den RAM 230 zum Speichern aller Prozeßsteuerroutinen
oder eines Teils dieser, während
die Routinen ausgeführt
werden, und auch als Speicherung für Prozeßsteuerdaten, die den Prozeßsensoren
und Stellgliedern 130 zugeordnet sind. Die Beschreibung
des beispielhaften digitalen Verarbeitungssystems 200 dient
lediglich zur Veranschaulichung; für Fachleute ist erkennbar,
daß softwaredefinierbare
Prozeßsteuerroutinen,
die die Prinzipien der vorliegenden Erfindung verwenden, nicht auf
eine spezifische Hardwareimplementierung für das digitale Verarbeitungssystem 200 beschränkt sind,
und daß alle
solche Systeme in den Schutzumfang der angefügten Ansprüche fallen.
-
Um die Prinzipien der vorliegenden
Erfindung zu verstehen, ist es notwendig, die zur Unterstützung der
vorliegenden Erfindung notwendigen Umgebungen zu definieren. Die
erste ist eine Anwendungs-Builder-Umgebung. Die Anwendungs-Builder-Umgebung
liefert Dienste, die es dem Endbenutzer erlauben, Steuerstrategien
zu konfigurieren und sie in die Steuerung zu laden. Die zweite Umgebung
ist die Steuerung selbst. Die Steuerung empfängt Konfigurationen zum Zeitpunkt
des Ladens, registriert sie bei internen Unterstützungsdiensten und führt sie
zur Laufzeit aus. Für
Fachleute sollte ohne weiteres erkennbar sein, daß der Anwendungs-Builder
nicht unbedingt an irgendeinem bestimmten Ort verankert sein muß. Die Anwendungs-Builder-Umgebung
kann in vielfältigen Überwachungsplattformen
verankert sein.
-
In einer DPC, die objektorientierte
Programmierung verwendet, d. h. in einer objektorientierten Steuerung,
können
Algorithmen und ihre zugeordneten Daten als Objekte implementiert
werden, die als Blöcke
bezeichnet werden. Daten in einem Block können aus benannten Attributen
von Blöcken,
die als Parameter bezeichnet werden, gelesen oder in diese geschrieben
werden. Der Datenfluß zwischen
verschiedenen Blöcken kann
durch Herstellen einer Verbindung von einem Ausgangsparameter eines
Blocks zu einem Eingangsparameter eines zweiten Blocks erreicht
werden.
-
Steuerstrategien werden als eine
Menge von Blöcken
erzeugt, die jeweils einen notwendigen Bestandteil der Gesamtsteuerstrategie
verkapseln. Ein Block, der als ein Steuermodul bezeichnet wird,
dient als Behälter
für elementarere
Algorithmusblöcke
und für
die Verbindungen, die einen Datenfluß zwischen diesen bewirken.
Der Gesamtprozeß des
Erzeugens eines Steuermoduls besteht aus der Verwendung des Anwendungs-Builders zum Einfügen von
Algorithmusblöcken,
dem Herstellen von Verbindungen zwischen Blockparametern und dem
Zuweisen von Werten zu Konfigurationsparametern. Nachdem ein Steuermodul
erzeugt wurde, verwendet man Dienste des Anwendungs-Builders zum
Laden dieses Steuermoduls in die Steuerung.
-
In dem Kontext der Anwendungs-Builder-
und Steuerungsumgebungen wird die Aufgabe der Verwaltung der Algorithmusverarbeitungslast
gleichbedeutend mit der Aufgabe des Verwaltens der Verarbeitungslast für das Steuermodul.
Durch Verwendung der Prinzipien der vorliegenden Erfindung können bei
vorteilhaften Ausführungsformen
die Steuermodule die folgenden Konfigurationsparameter unterstützen: z.
B. PERIOD; ESTWEIGHT und PHASE, wobei:
-
PERIOD die sich wiederholende Zykluszeit
des Steuermoduls und aller seiner Komponentenalgorithmusblöcke festlegt.
PERIOD ist auf Werte beschränkt,
die Vielfache der kleinsten von der Steuerung unterstützten PERIOD
sind, die zum Beispiel BASEPERIOD genannt wird.
-
ESTWEIGHT hält einen geschätzten Wert
für die
Ausführungszeit
des Steuermoduls. Dieser Wert kann explizit durch den Endbenutzer
auf der Grundlage direkter Messungen konfiguriert werden, oder,
wenn er unkonfiguriert (Null) gelassen wird, wird er von dem Anwendungs-Builder
auf der Grundlage eines Modells geschätzt. Die Beschaffenheit des
zur Berechnung von ESTWEIGHT verwendeten Modells ist zur Beschreibung
der Ausübung
der vorliegenden Erfindung nicht notwendig.
-
PHASE hält einen Wert, der die Steuerung
anweist, das Steuermodul in einer bestimmten Phase der gewählten PERIOD
ablaufen zu lassen. Mögliche
Werte von PHASE liegen z. B. zwischen 0 und (PERIOD modulo BASEPERIOD).
Wenn der Endbenutzer die Last manuell ausgleichen möchte, weist
der Endbenutzer dem Parameter PHASE einen spezifischen Wert zu,
der in seinem zulässigen
Bereich liegt. Bei einer vorteilhaften Ausführungsform läßt der Benutzer
den Wert PHASE unzugewiesen (Null), wenn er wünscht, daß die Steuerung die Last automatisch
ausgleichen soll.
-
Wenn ein Steuermodul in die Steuerung
geladen wird, enthalten die geladenen Daten die Werte der Parameter
PERIOD, ESTWEIGHT und PHASE. Die Steuerung verwendet diese Parameter
als Eingaben für den
Gesamtprozeß des
Lastausgleichs und der Lasteinstufung. Der Parameter PHASE ist jedoch
ein Schlüsselparameter
dabei, wie er diese Operationen auslöst.
-
Das Konzept von PHASE hängt eng
mit dem Konzept von Steuerungsausführungszyklen zusammen. Jeder
Zyklus ist ein Zeitintervall der Länge BASEPERIOD, der so konfiguriert
ist, daß er
eine spezifische Menge von Steuermodulen ausführt. Um die Einplanung in Zyklen
darzustellen, nehme man an, daß eine
Steuerung eine einfache Konfiguration von Steuermodulen unterstützen soll,
die durch die folgende Tabelle beschrieben wird; man nehme an, daß BASEPERIOD
50 ms beträgt.
-
-
Die in TABELLE 1 beschriebene Konfiguration
weist jedem Steuermodul einen Wert von PERIOD und PHASE zu. Durch
diese beiden Werte wird die Art und Weise, auf die jedes Steuermodul
in dem Steuerungszyklusschema ausgeführt wird, vollständig eingeschränkt. Das
resultierende Ausführungsmuster
ist nachfolgend in TABELLE 2 dargestellt.
-
-
Aus den Mustern in der obigen TABELLE
2 ist ersichtlich, daß die
Werte von PERIOD und PHASE zusammen vollständig bestimmen, wie ein Steuermodul
in der Steuerung ausgeführt
wird. PERIOD bestimmt die Wiederholungsrate und PHASE bestimmt,
in welchem einer endlichen Menge verfügbarer Zyklen ein Steuermodul
ausgeführt
wird. Zum Beispiel hat in einer PERIOD von 200 ms CMd eine mögliche PHASE-Auswahl von
0, 1, 2 und 3. Da die gewählte
PHASE 1 war, wird CMd in den Zyklen 1, 5, 9, 13 usw. ausgeführt. Steuermodule,
deren Perioden der Wert BASEPERIOD zugewiesen wird, haben nur eine
Möglichkeit
für PHASE:
0. Da die größte Ausführungsperiode,
die in dem obigen Beispiel verwendet wird, 200 ms beträgt, sind
die Zyklen 0–3
den Zyklen 4–7 äquivalent.
Dieses Muster wiederholt sich unendlich.
-
Die Gesamtzahl von Zyklen, die in
einer Steuerung unterstützt
werden kann, ist endlich. Die Gesamtzahl, die unterstützt werden
kann, basiert auf dem Verhältnis
der größten unterstützten Periode
zu BASEPERIOD. Wenn die größe Periode
eine Sekunde ist und BASEPERIOD 50 ms beträgt, gäbe es deshalb insgesamt 20
Zyklen. Die Ausübung
der vorliegenden Erfindung ist mit einer beliebigen Anzahl von Verfahren
zur Anordnung der Steuermodulausführung in einem Zyklus vereinbar.
Zum Beispiel hätte
die im Zyklus 0 gezeigte Reihenfolge (CMe, CMc, CMb und CMa) anders
gewählt
werden können.
Die Art und Weise der Auswahl der Ausführungsreihenfolge ist für das Verständnis der
vorliegenden Erfindung nicht notwendig und wird im folgenden nicht
beschrieben. Obwohl sie in Zyklen angeordnet ist, sollte beachtet
werden, daß die
Ausführung
von Steuermodulen zeitlich sequentiell stattfindet, wie in der nachfolgenden
Zeitlinie dargestellt, wobei die Steuermodule einfach durch ihren
Buchstabenindex angegeben sind. Die Zeit zwischen angrenzenden Zyklen
dient zur Ausführung
nichtperiodischer Algorithmen.
-
-
Nunmehr mit Bezug auf 3 ist eine Ausführungsform
eines Echtzeitprozeßsteuersystems 300 gezeigt,
die eine Ausführungsform
einer unter Verwendung der Prinzipien der vorliegenden Erfindung
in einer objektorientierten Programmierumgebung konstruierten Steuerung 330 verwendet.
Das Prozeßsteuersystem 300 enthält eine
Steuerung 330 mit mehreren Steuermodulen (wovon eine gezeigt
und mit 340 gekennzeichnet ist). Das Steuermodul 340 enthält außerdem mehrere
Algorithmusblöcke;
es sind 3 Algorithmusblöcke
gezeigt und als erster, zweiter und dritter Block 345, 355, 365 bezeichnet.
Bei der dargestellten Ausführungsform
sind der erste und der zweite Block 345, 355 an
mehrere Wandler (mit der allgemeinen Kennzeichnung 370)
angekoppelt oder diesen zugeordnet, wie zum Beispiel Temperatur-
oder Drucksensoren, die zur Überwachung
der Prozeßumgebung
dienen, während
der dritte Block 365 an ein Stellglied 380 angekoppelt
oder diesem zugeordnet ist. Die Steuerung 330 ist außerdem an
einen Anwendungs-Builder 310 angekoppelt, der eine Menge von
Softwarediensten sein kann, die in einer Überwachungsworkstation ausgeführt werden.
Der Anwendungs-Builder 310 ist außerdem an ein Dateneingabe-
und Anzeigegerät 320,
wie zum Beispiel einen herkömmlichen
Computer und Monitor, der einem Endbenutzer als Mittel zur Eingabe
und Überwachung
von Prozeßdaten
dient, angekoppelt gezeigt. Bei der dargestellten Ausführungsform
enthält
der Anwendungs-Builder 310 außerdem eine erste, eine zweite
und eine dritte Modellkomponente 312, 314, 316,
entsprechend dem ersten, zweiten bzw. dritten Block 345, 355, 365.
Das Modell enthält
bei einer vorteilhaften Ausführungsform Konfigurationsdaten,
die den Algorithmusblocktyp, den Zählwert für jeden Blocktyp, die Algorithmusausführungszeit,
den Datenflußverbindungszählwert (Eingangsparameter)
und die Datenflußausführungszeit
des Blocks enthalten.
-
Wie bereits beschrieben, konstruiert
der Anwendungs-Builder 310 das
Steuermodul 340 (das zur Durchführung der Algorithmusverarbeitung
verwendet wird) unter Verwendung des ersten, des zweiten und des
dritten Blocks 345, 355, 365. Der Anwendungs-Builder 310 erzeugt
außerdem
in dem Steuermodul 340 Verbindungen zwischen Blockparametern
und weist den Prozeßkonfigurationsparametern,
darunter die bereits besprochenen Parameter PERIOD, ESTWEIGHT und
PHASE, Werte zu.
-
Die Aufgabe des Ausgleichens der
Verarbeitungslast umfaßt
das Zuweisen eines Werts von PHASE zu jedem Steuermodul 340.
Die PHASE-Werte müssen
so zugewiesen werden, daß jeder
Zyklus ungefähr
dieselbe Zeit mit der Ausführung
der Steuermodule 340 verbringt. Um die Verarbeitungslast
auszugleichen, sind durch den Parameter ESTWEIGHT übermittelte
Informationen wesentlich. Der Parameter ESTWEIGHT bildet ein Element
der Konfigurationsdaten der Steuermodule 340 und wird in
der Regel in die Steuerung 330 geladen, wenn das Steuermodul 340 zuerst
konfiguriert wird. Durch Summieren von ESTWEIGHT für jedes
Steuermodul 340 in einem Zyklus kann die Steuerung 330 bestimmen,
wieviel Ausführungszeit
für diesen
Zyklus erforderlich sein wird. Das relative Laden von Zyklen kann
dann je nach Bedarf verglichen oder modifiziert werden.
-
Die Steuerung 330 verwendet
zwar ESTWEIGHT, berechnet es aber nicht. Es kann durch eines von zwei
Verfahren bestimmt werden, die beide außerhalb des Rahmens der Steuerung 330 liegen.
Das erste Verfahren besteht darin, daß ESTWEIGHT von einem Endbenutzer
berechnet wird. Dies kann auf der Grundlage statistischer Zeitsteuerungsdaten
geschehen, die von der Steuerung 330 selbst geliefert werden.
Zum Beispiel kann die Steuerung 330 Meßwerte der Zyklusausführungszeit
oder der Ausführungszeit
des Steuermoduls 340 angeben, aus denen ein Endbenutzer
einen Wert für
ESTWEIGHT formulieren könnte.
Sobald er erhalten wurde, kann der Wert ESTWEIGHT dann mit einer
Builder-Konfigurationsschnittstelle (Dateneingabe- und Anzeigegerät 320)
an das Steuermodul 340 angeknüpft werden.
-
Die Entwicklung eines Werts für ESTWEIGHT
kann relativ aufwendig sein. Dieser Aufwand ist jedoch nur so oft
erforderlich, wie einzigartige Konfigurationen des Steuermoduls 340 erzeugt
werden. Für
Fachleute ist erkennbar, daß bei
Prozeßsteuerkonfigurationen
häufig
mehrere Kopien identisch konfigurierter Steuermodule 340 auftreten.
In diesen Fällen
kann für
alle Kopien identisch konfigurierter Steuermodule 340 derselbe Wert
von ESTWEIGHT verwendet werden.
-
Das zweite Verfahren zur Berechnung
von ESTWEIGHT besteht darin, daß der
Builder 310 ein mathematisches Modell der Ausführungszeiten
des Steuermoduls 340 verwendet. Die Beschaffenheit des
verwendeten mathematischen Modells ist für ein Verständnis der vorliegenden Erfindung
nicht notwendig. Es muß nur
die Anforderung erfüllen,
daß das
mathematische Modell auf der Grundlage der Konfigurationseigenschaften
des Steuermoduls 340 eine relativ genaue Schätzung der
Ausführungszeit
berechnet. Ein ausreichendes Modell könnte zum Beispiel ein System
linearer Gleichungen sein, das ESTWEIGHT berechnet, indem die typische
Ausführungszeit
für jede
Art von Komponentenalgorithmusblock, die typische Verbindungsausführungszeit
für einen
Eingangsparameter jedes Komponentenalgorithmusblocks und die Overhead-Ausführungszeit
für das
Steuermodul 340 selbst bekannt sind.
-
Die vorliegende Erfindung zieht Mittel
in Betracht, durch die der Endbenutzer angeben kann, ob der Endbenutzer
einen Wert für
ESTWEIGHT eingeben möchte,
oder ob der Builder 310 automatisch eine Schätzung berechnen
soll. Der Endbenutzer kann dies zum Beispiel dadurch erreichen,
daß er
ESTWEIGHT auf einem Nullwert läßt, um anzugeben,
daß die
automatische Berechnung erforderlich ist, oder daß er es
auf einen von Null verschiedenen Wert einstellt, wenn automatische
Berechnung gesperrt werden soll.
-
Nach der Erzeugung des Steuermoduls 340 lädt der Anwendungs-Builder 310 unter
Verwendung herkömmlicher,
in der Technik wohlbekannter Techniken Konfigurationsdaten für das Steuermodul 340 in
die Steuerung 330.
-
Wenn eine Konfiguration des Steuermoduls 340 in
die Steuerung 330 geladen wird, richtet sich der Lastausgleichsalgorithmus
nach dem Wert von PHASE; PHASE ist entweder Null oder von Null verschieden (nicht
zu verwechseln mit den Null- und Nicht-Null-Werten von ESTWEIGHT). Ein von Null
verschiedener Wert von PHASE gibt an, daß der Endbenutzer den automatischen
Ausgleichsprozeß,
der ansonsten von der Steuerung 330 durchgeführt würde, übersteuern
will. Wenn der Endbenutzer direkt steuern will, auf welcher Menge von
Zyklen ein Steuermodul 340 ausgeführt werden wird, kann der Endbenutzer
direkt den gewünschten
PHASE-Wert zuweisen. Zum Beispiel könnte der Endbenutzer zugewiesen
haben, daß das
in der obigen TABELLE 2 referenzierte CMd in Phase 1 ausgeführt wird.
-
Wenn der empfangene PHASE-Wert Null
ist, interpretiert die Steuerung 330 dies als Anzeige,
daß ein automatischer
Lastausgleich gewünscht
ist und setzt die Operationen fort, die im folgenden beschrieben
werden. Es wird angemerkt, daß,
gleichgültig,
welches Verfahren zur Bestimmung des PHASE-Werts verwendet wird,
der PHASE-Wert weiteren Validierungsprüfungen unterzogen werden kann,
bevor er von der Steuerung 330 angenommen wird (was ebenfalls
später
beschrieben werden wird).
-
Außerdem ist zu beachten, daß die Verwendung
von Null- und Nicht-Null-Werten
für PHASE,
um anzugeben, wann automatischer Lastausgleich angefordert wird,
lediglich eine Kovention ist. Andere Verfahren zur Anzeige dieser
Unterscheidung können
verwendet werden und liegen in dem allgemeinen Schutzumfang der
vorliegenden Erfindung.
-
Wenn die Steuerung 330 bestimmt,
daß der
geladene Wert von PHASE Null ist, d. h. daß der Endbenutzer keinen Wert
vorgewählt
hat, weist die Steuerung 330 PHASE einen Kandidatenwert
zu. Ein beispielhafter Algorithmus zum Zuweisen eines Werts zu PHASE
ist in Tabelle 3 dargelegt. Der Nettoeffekt dieses Algorithmus ist
die Auswahl eines PHASE-Werts, der die Last zu einer bestimmten
Menge von Zyklen mit der kleinsten Maximallast hinzufügt. Bei
einer vorteilhaften Ausführungsform
können
die einzelnen Steueralgorithmen in dem Steuermodul 340 konfiguriert,
geladen und ausgeglichen werden, ohne den Betrieb anderer Steueralgorithmen
zu unterbrechen.
-
-
Nachdem der Parameter PHASE bestimmt
wurde, entweder als das Ergebnis der Lastausgleichsauswahl, d. h.
des in Tabelle 3 beschriebenen Prozeßes, oder als explizite Konfiguration
durch den Endbenutzer, kann die Steuerung 330 bei einer
vorteilhaften Ausführungsform
eine Einstufungsprüfung
durchführen.
Ein beispielhafter Einstufungsprüfalgorithmus
ist in Tabelle 4 dargestellt.
-
-
Es sollte beachtet werden, daß die Einstufungsprüfung für die Ausübung der
vorliegenden Erfindung nicht notwendig ist und weggelassen werden
kann. Wenn die Einstufungsprüfung
verwendet wird, kann die entsprechende Maßnahme („appropriate action") in Tabelle 4 im
Fall einer vorhergesagten Zyklusüberlastung abhängig von
der Entwurfsphilosophie der Steuerung 330 unterschiedlich
sein. Mögliche
Maßnahmen
sind zum Beispiel ein Zurückweisen
der Last des Steuermoduls 340 oder eine Annahme der Last
des Steuermoduls 340, wobei dem Endbenutzer unter Verwendung
des Dateneingabe- und Anzeigegeräts 320 eine
Warnung angezeigt wird.
-
Nachdem das Steuermodul 340 akzeptiert
und in die Steuerung 330 geladen wurde, weist die Steuerung 330 PHASE
einen Wert zu und aktualisiert ihren Datensatz des Gesamtgewichts
für jeden
Zyklus unter Verwendung eines in Tabelle 5 dargelegten beispielhaften
Prozeßes.
Der Prozeß in
Tabelle 5 führt
diesen Datensatz in einem Array mit dem Namen CycleWeight.
-
-
Nunmehr mit Bezug auf 4 ist ein beispielhaftes
Interaktionsdiagramm 400 gezeigt, das zusammenfaßt, wie
verschiedene Subsysteme in der vorliegenden Erfindung in Wechselwirkung
treten. Das Interaktionsdiagramm 400 enthält die folgenden
Objekte: einen Benutzer 410, eine Builder-Bedienerschnittstelle 420, ein
Steuermodulausführungszeitmodell 430,
eine Steuerungskommunikationsschnittstelle 440 und einen
Lastmanager 450.
-
Der Benutzer 410 entspricht
einem Endbenutzer, der ein Steuermodul mit dem Namen CMa konfiguriert.
Die Builder-Bedienerschnittstelle 420 entspricht einem
Computer (analog dem in 3 dargestellten
Dateneingabe- und Anzeigegerät 320),
durch den der Benutzer 410 seine Konfigurationsspezifikationen
in den Builder eingibt. Das Steuermodulausführungszeitmodell 430 entspricht
der Intelligenz in dem Builder, die ein Modell davon hält, wie
Steuermodulausführungszeiten
aus bekannten Konfigurationsdaten berechnet werden können. Die
Builder-Bedienerschnittstelle 420 und das Steuermodulausführungszeitmodell 430 können beide als
Teil des Builders angesehen werden. Die Steuerungskommunikationsschnittstelle 440 entspricht
dem Subsystem in der Steuerung, das mit dem Anwendungs-Builder kommuniziert,
und der Lastmanager 450 kann als das Subsystem in der Steuerung
angesehen werden, das die Steuermodulverarbeitungslast verwaltet.
-
Das Interaktionsdiagramm 400 zeigt
eine Nachrichtensequenz zwischen Subsystemen zum Zeitpunkt des Konfigurierens
und Ladens eines Steuermoduls. Der Prozeß beginnt mit einer Menge von
Interaktionen zwischen dem Benutzer 410 und dem Builder 420,
bei der der Benutzer 410 Konfigurationsdaten eingibt und nach
Abschluß der
Eingabe ein Laden befiehlt. Der Ladebefehl des Benutzers 410 bewirkt,
daß der
Builder 420 auf das Modell 430 zugreift und dann
das Laden in die Steuerungskommunikationsschnittstelle 440 einleitet.
Der Lastmanager 450 in der Steuerung empfängt die
Lastdaten aus der Steuerungskommunikationsschnittstelle 440 und
verarbeitet die empfangenen Daten. Der Lastmanager 450 löst dann
die Ausführung
des zuvor beschriebenen Pseudocodes aus. Weitere Informationen darüber, wie
Diagramme des in 4 dargestellten
Typs zu lesen sind, findet man in „Object Oriented Analysis
and Design with Applications" von
Grady Booch, Benjamin/Cummings (1994), worauf hiermit ausdrücklich Bezug
genommen wird.
-
Aus dem Obigen ist ersichtlich, daß es durch
die vorliegende Erfindung möglich
wird, daß der
Lastausgleich durch Verwendung einer modellberechneten Ausführungszeit
oder durch Verwendung einer direkt durch den Endbenutzer gemessenen
Ausführungszeit
stattfindet. Die Modellberechnung verwendet Daten, die sich mit
dem Typ und Zählwert
von Algorithmusblöcken
und mit dem Zählwert
von Datenflußverbindungen ändern können. Außerdem ist
es durch die vorliegende Erfindung möglich, daß eine vom Benutzer gemessene
Ausführungszeit
in dem Steueralgorithmus erfaßt
und repliziert wird, wenn neue Kopien dieses Algorithmus erzeugt
werden. Zusätzlich
wird es durch die vorliegende Erfindung möglich, daß der Ausgleich automatisch
bei der Konfiguration des Steueralgorithmus oder manuell bei der
Auswahl des Endbenutzers stattfindet. Außerdem ermöglicht die vorliegende Erfindung
die Konfiguration neuer Steueralgorithmen, die auf potentielle Überlastung
geprüft
und ausgeglichen werden, ohne daß es notwendig ist, andere
in der Steuerung ablaufende Algorithmen herunterzufahren.
-
Die vorliegende Erfindung gibt dem
Endbenutzer die Vorteile der Flexibilität, der Bestimmtheit und der Benutzbarkeit
in derselben Steuerung. Flexibilität wird durch mehrere Period-Wahlmöglichkeiten
und die Möglichkeit
zum Wählen
eines manuellen oder automatischen Ausgleichs bereitgestellt. Bestimmtheit
wird durch die Zyklus- und Phasenstruktur des Entwurfs bereitgestellt.
Bei einer Ausführungsform
der vorliegenden Erfindung werden, sobald eine Phase in einer Steuerung
zugewiesen wurde, die Algorithmen in einem schmalen periodischen
Zeitband ausgeführt.
Benutzbarkeit wird dadurch bereitgestellt, daß es möglich ist, daß Konfigurationen
für eine
Last eingestuft und ausgeglichen werden, ohne daß die gesamte Steuerung heruntergefahren werden
muß; durch
die Möglichkeit,
gegebenenfalls einen manuellen Lastausgleich zu vermeiden; und durch die
Möglichkeit,
einer bestimmten Steuerkonfiguration eine gemessene Ausführungszeit
zuzuordnen.
