DE20121551U1 - Steuerungssystem-Simulation, -Testen und -Bediener-Training - Google Patents

Description

Steuerungssystem-Simulation, -Testen und -Bediener-Training

Diese Anmeldung beansprucht die Vorteile der provisorischen US-Anmeldung Nr. 60/177991, der provisorischen US-Anmeldung Nr. 60/177899 und der internationalen Anmeldung Nr. PCT/USOO/07962, wobei jede von ihnen an dieser Stelle durch Bezugnahme in ihrer Gesamtheit einbezogen ist.

Das Gebiet der Erfindung sind Steuerungssystem-Simulations-, Steuerungssystem-Test- sowie Steuerungssystem-Trainings-Systeme.

Steuerungssysteme, die PLC (Programmierbare Logik-Steuerungen) und DCS (Verteilte Steuerungssysteme) vereinigen, werden häufig verwendet, um Prozesse der wirklichen Welt mittels Akzeptierens von Eingaben zu steuern, die typischerweise von Sensoren erzeugt worden sind, wie unter anderem solche, die verwendet werden, um die Temperatur, den Fluss, den Pegel, die Strahlung, das Licht, die Bewegung und den Druck zu erfassen, und solche, die zum 0 Erzeugen von Ausgaben verwendet werden, die verwendet werden, um Aktoren zu betreiben, wie hydraulische Geräte, Ventile, Lampen und Motoren. Steuerungssysteme können oft als Systeme angesehen werden, die eine Steuerungs-Komponente und eine Schnittstellen-Komponente aufweisen, wobei eine oder beide Komponenten sowohl Hardware- als auch Software-Teil-Komponenten aufweisen. Somit könnte eine PLC-basierte Vorrichtung eine digitale PLC, die als Steuerungs-Komponente eingebettete Software (die' "Steuerung") aufweist, mit einer Schnittstellen-Komponente (die "I/O-Schnittstelle") verwenden, die (a) Signale von Sensoren akzeptiert und diese in eine für die PLC akzeptable Form umwandelt, und die (b) Ausgaben von der PLC akzeptiert und diese in Signale umwandelt, die als Eingaben für die Aktoren geeignet sind.

• »

Bei solchen Systemen sind die Steuerung und die 1/0-Schnittstelle oft mittels eines oder mehrerer Pfade (dem "Steuerungs-I/O-Kommunikationskanal") gekoppelt, so dass es Kommunikations- und Steuerungssignalen ermöglicht wird, zwischen der Steuerung und der I/O-Schnittstelle übertragen zu werden. In gleicher Weise ist die I/O-Schnittstelle, nachdem das Steuerungssystem in seiner Betriebsumgebung installiert ist, mittels eines oder mehrerer elektrischer Pfade (der "Feld-Verdrahtung") mit den Komponenten gekoppelt, von denen das Steuerungssystem seine Eingaben empfängt, und mit den Komponenten gekoppelt, an die das Steuerungssystem seine Ausgaben richtet, wobei die I/O-Schnittstelle mit einer Mehrzahl von Verbindern ("Feld-I/O-Verbindern") versehen ist, die das Koppeln der I/O-Schnittstelle mit der FeId-Verdrahtung ermöglichen. Viele Steuerungssysteme enthalten ferner eine Mensch-Maschine (HMI)-Schnittstellen-Komponente, die Hardware oder Software zum Ermöglichen der Interaktion des Bedieners mit dem Steuerungssystem aufweist. Fig. 1 stellt solch ein Steuerungssystem 900 gemäß dem Stand der Technik mit einer HMI 910, einer Steuerung 920, einer I/O-Schnittstelle 930, einem HMI-Steuerungs-Kommunikationskanal 940, einem Steuerungs-I/O-Kommunikationskanal 950, einer Feld-Verdrahtung 960 und Sensor / Aktor-Komponenten 970 dar. Bei einigen Beispielen ist die HMI 910 ein Allgemein-Zweck-Computer, der ein Windows-basiertes Betriebssystem und eine Anwendung ausführt, die derart gestaltet ist, dass dem Bediener eine Interaktion mit dem Steuerungssystem 900 ermöglicht wird, und sowohl der HMI-Steuerungs-Kommunikationskanal 940 als auch der Steuerungs-I/O-0 Kommunikationskanal 950 werden unter Verwendung eines lokalen Netzwerkes implementiert, das die HMI 910, die Steuerung 920 und die I/O-Schnittstelle 930 miteinander koppelt. Solch ein Aufbau ist in Fig. 2 gernäß dem Stand der Technik mit der HMI 910, der Steuerung 920 und der I/O-Schnittstelle 930 gezeigt, wobei jede mit einem Netzwerk-Knoten 980 gekoppelt ist.

Bei Entwicklungsprojekten ist es oft typisch, dass einem Entwickler, der durch einen Kunden beauftragt worden ist, eine Anlage (inklusive irgendeines darin verwendeten

• t ·

• · f

Steuerungssystems) zu bauen, ein Satz von Anforderungen mitgegeben wird, die die Anlage erfüllen muss, bevor der Entwickler fertig. Dies trifft insbesondere auf das Anlagen-Steuerungssystem zu, das eine kritische Rolle beim Betrieb der Anlage spielt. Bei verschiedenen Entwicklungsstufen wird ein Abnahmetest durchgeführt, um zu ermitteln, ob das Anlagen-Steuerungssystem bei dem aktuellen Stand die Anforderungen erfüllt, die an den Entwickler gestellt worden sind. Während des Abnahmetests ist es im Allgemeinen wünschenswert, die Aktionen, die während des Tests durchgeführt werden, und die Ergebnisse solcher anforderungsspezifischer Aktionen zusammenzufassen, um so zu zeigen, ob die erstellten Anforderungen erfüllt sind oder nicht.

Das Erzeugen von Testplänen, das Implementieren solcher Pläne und das Korrelieren von Testergebnissen mit den Anforderungen, um die Anforderungserfüllung zu verifizieren, kann ermüdend, zeitaufwendig und fehleranfällig sein. Obwohl Verfahren und Vorrichtungen zum Testen von Steuerungssystemen bekannt sind, haben alle jeweils individuelle Stärken und Schwächen, wodurch sie in einigen Situationen geeigneter und in anderen Situationen weniger geeignet sind. Eine hauptsächliche Schwäche der meisten Verfahren und Vorrichtungen zum Testen von Steuerungssystemen ist die Unfähigkeit, die Erfüllung der Anforderungen korrekt zu verifizieren. Diese Unfähigkeit kann zumindest teilweise aus der Tatsache resultieren, dass die Steuerung, wenn einmal in einer Anlage installiert, nicht einem kompletten oder strengen Testen unterworfen werden kann, wie es in einer Laborumgebung möglich wäre. Ein anderer möglicher Faktor ist die Schwierigkeit, große Mengen von Testergebnissen mit Anforderungen zu korrelieren. Daher gibt es ein ständiges Bedürfnis, den Test-Erzeugungs- und Anforderungs-Verifikations-Prozess zu verbessern.

Zusätzlich zu den Schwierigkeiten, die mit dem Testen und der Verifikation verbunden sind, kann es manchmal schwierig sein, das Trainieren von Bedienern, den HMI-Abschnitt 910 eines Steuerungssystems zu bedienen, in einer kosteneffizienten

* ItIt

Weise zu erreichen. Das Trainieren von Bedienern an einem realen („Life"-) System (d. h. bereits in einer bereits in Betrieb befindlichen Anlage installiert) ist kein bevorzugtes Verfahren, da ein Schaden an der Anlage sowie Material-Verschwendung riskiert werden und es im Allgemeinen erforderlich ist, die Anlage herunterzufahren oder während des Trainings mit weniger als Volllast zu betreiben.

Das Training an realen („Life"-) Systemen kann durch die Verwendung von Simulatoren vermieden werden. Solche Simulatoren existieren bereits, aber sie werden typischerweise auf großen Modellen (d. h. ein physikalisches Modell / eine Wieder-Erzeugung von zumindest Abschnitten der Anlage) durchgeführt, die typischerweise hohe Investitionen bei den Modell-Umgebungen und bestimmte Plätze erfordern, an denen sie zusammengefügt werden können. Es ist ferner oft schwierig und teuer, das Modell synchron mit den Änderungen an der Anlage zu halten. Ferner gibt es die Tendenz, dass sich die Kosten wesentlich erhöhen, wenn Bediener an einen externen Ort reisen müssen, um trainiert zu werden. Solch eine Reise ist oft notwendig, da es häufig kosteneffizienter ist (soweit die Verwendung eines großen Modells kosteneffizient sein kann), ein einziges großes Modell und einen Trainerstab zum Trainieren der Bediener von gleichen Anlagen zu nutzen, als ein großes Modell und einen Trainerstab an jeder Anlage zu 5 haben.

Daher gibt es ein ständiges Bedürfnis für verbesserte Trainingssysteme, die es Bedienern ermöglichen, trainiert zu werden, um ein Anlagen-Steuerungssystem zu bedienen, ohne dass große Modelle verwendet werden, und/oder dass es 0 notwendig ist, von der Anlage wegzufahren.

Verfahren und eine Vorrichtung sind vorgesehen, die es ermöglichen, Steuerungssysteme zu testen, und die es vereinfachen, Bediener zu trainieren, um solche Steuerungs-5 systeme zu bedienen.

Zum Zwecke des Testens ist ein Testsystem mit einem Steuerungssystem in einer Weise gekoppelt, durch die es ermöglicht wird, dass das Testsystem mit dem Steuerungssystem kommuniziert und dieses mittels Sendens und Empfangens von Signalen mittels sowohl des Steuerungs-I/O-Kommunikationskanals als auch der Feld-I/O-Verbinder steuert. Das Testsystem wird im Wesentlichen genutzt, um sowohl eine zu steuernde Anlage zu simulieren als auch diese zu überwachen, zu validieren und/oder den internen Zustand der Steuerungssystem-Steuerung und möglicherweise die Steuerungssystem-I/O-Schnittstelle zu modifizieren. Die Simulation der Anlage wird mittels Simulierens der I/O-Geräte erreicht, mit denen das Steuerungssystem gekoppelt ist (und daher die Anlagenprozesse) , wenn es in seiner Betriebsumgebung installiert ist. Zusätzlich zu der Simulation von I/O-Geräten hat das Testsystem den Vorteil, dass viele allgemein verwendete Steuerungs- und I/O-Schnittstellen befähigt sind, mit anderen Geräten unter Verwendung solch einer Kommunikationsfähigkeit zu kommunizieren, so dass Befehle an oder Informationen von Steuerungssystem-Steuerung(en) und I/O-Schnittstelle(n) bereitgestellt werden oder erlangt werden.

Als eine Hilfe bei der Validierung werden von den an dieser Stelle offenbarten Systemen und Verfahren eine Anforderungs-Datenbank und ein Test-Generator („RDTG") verwendet, der aus einem Satz von Softwaredaten-Tabellen und Nutzerbildschirmen besteht, um die Eingabe von Funktions-Anforderungen für programmierbare Logik-Steuerungen (PLC) / Mensch-Maschine (HMI) -Schnittstellen oder verteilte Steuerungssysteme (DCS) zu ermöglichen. Der RDTG kann ferner Tests zum Funktions- und zum Feld-Testen erzeugen.

Zum Trainieren von Bedienern werden die visuellen Abschnitte einer Steuerungssystem-HMI dupliziert und mit einem Software- und/oder Hardware-Simulator gekoppelt, um so zu ermöglichen, dass simulierte Anlagen-Bedienungen durchgeführt werden. Bei bevorzugten Ausführungsformen werden die visuellen Abschnitte der HMI um audiovisuelle Trainingshilfen ergänzt, wie Audio- und Videoclips. Verschiedene Ausführungsformen können ferner

&phgr;&phgr;&phgr;&phgr; ΦΦ··

&phgr;&phgr;&phgr;&phgr; ··

III* ΦΦΦ

die Fähigkeit aufweisen, die Leistungsfähigkeit des Bedieners in Bezug auf gewünschte Ziele und/oder andere Anforderungen zu vergleichen.

Es ist vorgesehen, dass die an dieser Stelle offenbarten Verfahren und die Vorrichtung einen wirksamen Ansatz zum Koppeln eines zu testenden Steuerungssystems mit simulierten I/O-Geräten sowie zum Steuern und Überwachen der simulierten I/O-Geräte bereitstellen, um so Eingaben für das Steuerungssystem zu erzeugen, um Ausgaben von dem Steuerungssystem aufzuzeichnen und die aufgezeichneten Ausgaben mit einem erwarteten Wert zu vergleichen und das Ergebnis des Vergleiches zu Berichtzwecken aufzuzeichnen.

Es ist ferner vorgesehen, dass die an dieser Stelle offenbarten Verfahren und die Vorrichtung einen wirksamen Ansatz zum Einstufen und Testen von PLC / HMIs (programmierbare Logik-Steuerungen / Mensch-Maschine-Schnittstellen) und DCS (verteilte Steuerungssysteme) vor der Auslieferung in das Feld bereitstellen.

Es ist ferner vorgesehen, dass die an dieser Stelle offenbarten Verfahren und die Vorrichtung einen wirksamen Mechanismus zum Validieren des Betriebs eines Steuerungssystems bereitstellen, sobald es einmal in einer zu steuernden Anlage installiert ist. Es ist vorgesehen, dass solch eine Validierung die Verwendung von automatisch erzeugten Berichten aufweist, die die Beziehung zwischen den Anforderungen, den Tests, die verwendet worden sind, um die Erfüllung dieser Anforderungen zu validieren, und der Ergebnisse der Validierungs-Tests zeigen.

Es ist ferner vorgesehen, dass die an dieser Stelle offenbarten Verfahren und die Vorrichtung ein Vor-Ort- / Anlagen-Training von Bedienern ohne das Bedürfnis des Erzeugens eines großen Modells ermöglichen.

Verschiedene Ziele, Merkmale, Aspekte und Vorteile der Erfindung werden aus der folgenden ausführlichen Beschreibung

der bevorzugten Ausführungsbeispiele der Erfindung im Zusammenhang mit den beigefügten Figuren offenbar, bei denen sich gleiche Bezugszeichen auf gleiche Komponenten beziehen.

Bevorzugte Ausführungsbeispiele der Erfindung werden nachstehend, mit Bezug auf die Zeichnung, ausführlich beschrieben.

Fig. 1 ist eine schematische Ansicht eines Steuerungssystems gemäß dem Stand der Technik.

Fig. 2 ist eine schematische Ansicht eines zweiten Steuerungssystems gemäß dem Stand der Technik.

Fig. 3 ist eine schematische Ansicht eines Testsystems.

Fig. 4 ist eine schematische Ansicht des Testsystems von Fig. 3, das gekoppelt ist mit dem Steuerungssystem von Fig. 2 gemäß dem Stand der Technik.

Testsystem - Übersicht

Bezugnehmend auf Fig. 3 weist ein Testsystem 100 einen Konfigurator 110, einen I/O-Simulator 120 und möglicherweise einen Netzwerkknoten 180 auf. Bezugnehmend auf Fig. 4 kann ein Testsystem 100 mit einem Steuerungssystem ("CS") 900 mittels Koppeins eines I/O-Simulators 120 mit einer I/O-Schnittstelle 930 mittels eines Kabelbaums 150 und/oder mittels Koppeins des I/O-Simulators 120 und des Konfigurators 110 mit dem Steuerungs-I/O-Netzwerk des CS 900 gekoppelt sein.

Bei dem Testsystem 100 werden Kabelbäume 15 0 verwendet, um I/O-Signale zu und von der I/O-Schnittstelle 930 zu senden und zu empfangen, um so die Eingabegeräte / Sensoren 971 und 973 sowie die Ausgabegeräte / Aktoren 974 und 976 zu

simulieren, die mittels der Feld-Verdrahtung 960 mit dem Ziel-CS 900 gekoppelt sein können, wenn das Ziel-CS 900 installiert ist. Das Testsystem 100 nutzt die Netzwerkverbindung zu dem CS, um Register- und Statusinformationen von der I/O-Schnittstelle 930, der HMI 910 und der PLC 920 zu erlangen. Durch das Überwachen des internen Zustands und des Datenflusses zwischen der I/O-Schnittstelle 930, der HMI und der PLC 920 ist das Testsystem 100 besser befähigt, irgendwelche Probleme zu isolieren, die in dem Ziel-CS während des Testens auftreten können, wenn sie in einem bestimmten Teilsystem des Ziel-CS 900 auftreten. Wenn notwendig, können die I/O-Schnittstelle 930, die HMI 910 und die PLC 920 unabhängig voneinander anstatt in Kombination, da dies voraussichtlich ein typischeres Szenario ist, getestet und/oder überwacht werden. Durch die Weise, in der das Testsystem 100 mit dem Ziel-CS 900 gekoppelt ist, ist es ferner möglich, dass das Testsystem 100 die Mehrfach-I/O-Kanäle und/oder Teilsysteme des Ziel-CS 900 gleichzeitig testet.

Das Testsystem wird bevorzugt automatisch mittels Verwendens seiner Verbindungen zu dem Steuerungs-I/O-Netzwerk initialisiert, um das Ziel-CS 900 anzufragen, um Informationen zu erlangen, die es dem Testsystem 100 ermöglichen, eine automatische Initialisierung und eine Abbildung seiner Eingänge und Ausgänge auf die des Ziel-CS 900 durchzuführen. Das Testsystem 100 enthält eine Wissensbasis, die Merkmale der bekannten Steuerungssystem-Hardware- und -Software-Komponenten beim Durchführen solch einer automatischen Initialisierung aufweist. Es ist vorgesehen, dass die Wissensbasis erweitert werden kann, so dass sie mathematische Modelle der Standard-Komponenten, wie von Sensoren und Aktoren, aufweist, sodass dem Testsystem ermöglicht wird, solche Komponenten besser zu simulieren und eine automatische Test-Erzeugung für Ziel-Systeme zu ermöglichen, die mit solchen Komponenten gekoppelt sind.

Testsystem - Lokales Testen

Das Testsystem 100 ist als bei der Entwicklung und beim lokalen Testen des Ziel-CS 900 mittels Simulierens der Anlage profitierend angesehen, deren Ziel-CS 900 dazu bestimmt ist zu steuern. Wenn die Kapazität eines einzelnen Testsystems 100 nicht ausreicht, um eine gesamte Anlage zu simulieren, können mehrere Testsysteme 100 verwendet werden, um die Simulation zu erreichen. Solch eine Kombination von Testsystemen 100 kann Mehrfach-HMI-Einrichtungen 110 nutzen oder eine einzelne HMI 110 gemeinsam nutzen. Das Testsystem 100 wird ferner als nützlich für das lokale Training des Personals beim Bedienen des Ziel-CS 900 angesehen, wenn das Testsystem 100 in Verbindung mit dem Ziel-CS 900 genutzt wird. Solch eine lokale Nutzung des Testsystems 100 wird unter anderem als komplettes Testen aller Ziel-CS 900-Eingaben und der resultierenden Ausgaben vor der Feldinstallation angesehen.

Testsystem - Vor-Ort-Testen

Das Vor-Ort-Testen wird ebenfalls als von der Nutzung des Testsystems 100 entweder in dessen Gesamtheit oder lediglich dessen Konfigurator- / HMI-Abschnitt profitierend angesehen. Ist das Ziel-CS 900 einmal in dessen Betriebsumgebung installiert, kann der Konfigurator 110 als Test- und Validierungs-Werkzeug verwendet werden. Der Konfigurator 110 kann Schritt-für-Schritt einem Feld-Tester Befehle bereitstellen, was, wenn befolgt, zu einer gewünschten Teststufe des Ziel-CS 900 führt. Auf diese Weise steuert der Konfigurator 110 im Wesentlichen den Testprozess mittels des Feld-Testers. Mittels Anforderns einer Rückmeldung von dem Feld-Tester auf das Abschließen der verschiedenen Testabschnitte hin kann ein Testbericht erstellt werden, der die durchgeführten Testschritte aufweist sowie die Tester-Antworten, so dass gewährleistet wird, dass die erforderliche Teststufe abgeschlossen ist. Durch solch ein „gesteuertes" Testen ist somit ein Verfahren eines wiederholten,

validierten und verifizierten Testens bereitgestellt. Der Konfigurator 110 kann ferner genutzt werden, um die Ergebnisse solch eines Tests aufzuzeichnen und Imfeld-Berichte zu erzeugen, die eine Rückmeldung bezüglich des aktuellen Zustands des Ziel-CS 900 und der Feld-Verdrahtung, mit der das Ziel-CS 900 gekoppelt ist, bereitstellen.

Wenn das gesamte Testsystem 100 vor Ort genutzt wird, kann das Testsystem 100 mit ausgewählten Eingaben und Ausgaben des Ziel-CS 900 ausgetauscht werden, so dass es ermöglicht wird, dass die realen („Life"-) Eingaben das Ziel-CS 900 dazu bringen, die simulierten Aktor-Komponenten zu steuern oder simulierte Eingaben zu verwenden, um das Ziel-CS 900 dazu zu bringen, die realen Aktor-Komponenten zu steuern oder die simulierten Eingaben und Ausgaben, wie gewünscht, zur Laufzeit zu mischen und anzupassen. Wenn der Konfigurator immer noch an den Rest des Testsystems 110 während des Testens angeschlossen ist, und wenn das Testsystem 110 mit dem Ziel-CS 900 während des Testens gekoppelt ist, kann der Konfigurator 110 den Testprozess sowohl mittels der direkten Interaktion mit dem Ziel-CS 900 als auch durch einen Test-Bediener, wie bereits diskutiert, steuern.

Konfigurator

Die HMI / der Konfigurator 110 des Testsystems 100 ist als ein Allgemein-Zweck-Computer, wie ein Laptop-PC („PC") 5 vorgesehen. Die Portabilität ist insbesondere wünschenswert, da dadurch das Transportieren der HMI 110 in das Feld zur Unterstützung des Vor-Ort-Testens eines installierten Ziel-CS 900 ermöglicht wird. Die HMI 110 ist zum Einbeziehen von Software vorgesehen, die es erlaubt, Alarm-Antworten (inklusive Totbänder), Schleifen und Logik zu testen und über die HMI-Auslesevorgänge, Trend-Graphen, Alarme, Berichte, System-Anforderungen usw. zu berichten. Testergebnisse werden in der Form von textuellen Daten und Zeitstempel-Daten, Graphen und Tester-Antworten auf abgefragte Fragen gespeichert.

Bei einem bevorzugten Ausführungsbeispiel weist die HMI 110 ein Multitasking-Betriebssystem auf, bevorzugt Windows NT™, das befähigt ist, eine graphische Nutzerschnittstelle („GUI") und ein relationales Datenbanksystem (bevorzugt Microsoft Access™) ebenso wie Software zum Steuern von I/O-Simulator-Modulen 120 zu unterstützen und das Ziel-CS 900 zu testen. Für die HMI 100 ist ferner bevorzugt, dass sie eine Ethernet-Netzwerk-Schnittstellenkarte zum Koppeln mit dem Steuerungs-I/O-Netzwerk aufweist, das häufig ein TCP/IP-basiertes Ethernet-Netzwerk ist. Es ist ferner bevorzugt, dass die HMI 110 des Testsystems 100 entfernbar von dem Rest des Testsystems 100 ist, um zu ermöglichen, es unabhängig als ein Vor-Ort-Verifikations-Werkzeug zu nutzen.

Wie bereits diskutiert, ist der HMI- / Konfigurator-Abschnitt 110 des Testsystems 100 sowohl beim Betrieb des Testsystems 100 als auch als ein entfernbares Validierungs- und/oder Trainingswerkzeug verwendbar. Es ist vorgesehen, dass die HMI / der Konfigurator 110 die Software sowie eine oder mehrere Datenbanken aufweist, die erforderlich sind, um es zu ermöglichen, diese Trainings- und/oder Validierungs-Funktionen durchzuführen. Solche Funktionen können unter anderem aufweisen die Fähigkeit, den Zugriff mittels Anforderns einer Anmeldung durch den Bediener zu steuern, die Fähigkeit, eine bestimmte Funktion zu simulieren und die Fähigkeiten des Ziel-CS zu testen, um auf den gesamten Bereich der Eingabe eines Sensors zu antworten, die Fähigkeit, den Bediener aufzufordern, Operationen unter Verwendung der Ziel-CS-HMI durchzuführen, und Tests gegen das Ziel-CS automatisch durchzuführen, wenn solche Tests keine manuelle 0 Bedienung durch einen Bediener erfordern.

Konfigurator - Interaktives Testen

Bei einem besonderen Konfigurator-Ausführungsbeispiel ist es günstig, wenn dieser die Fähigkeit aufweist, Mehrfach-Tests zu speichern und zu starten, wobei jeder Test einen oder mehrere Schritte aufweist. Beim Ausführen eines bestimmten

Tests oder einer Sequenz von Test-Schritten wird der Konfigurator den Bediener auffordern, eine Funktion auf dem Ziel-CS durchzuführen, wann immer ein manueller Eingriff durch den Bediener erforderlich ist, allerdings wird er einige Test-Schritte automatisch (d. h. ohne Aktionen des Bedieners) durchlaufen, die keinen derartigen manuellen Eingriff erfordern. Daher kann der Konfigurator, um eine Pumpe zu testen, einen Bediener auffordern, die Pumpe einzuschalten, dann, nachdem der Bediener dem Konfigurator angegeben hat, dass er die Pumpe eingeschaltet hat, wird der Konfigurator eine Frage stellen, um den korrekten Betrieb der Pumpe zu verifizieren, wie: „Wurde die Pumpen-Kennzeichen-Lampe eingeschaltet?", auf die der Bediener entweder bejahend oder negativ antworten kann. Wenn negativ beantwortet, wird der Konfigurator den Bediener auffordern, einen Kommentar einzugeben, in dem angegeben wird, welche Antwort des Ziel-CS tatsächlich zu sehen war. Während eines anderen Schrittes kann der Konfigurator simulierte Ereignisse erzeugen, auf die das Ziel-CS automatische Antworten hat, die mittels des Konfigurators erfasst werden können, und in dem Fall wird der Simulator einfach die Ereignisse simulieren und die Antwort des Ziel-CS überwachen. Als ein Beispiel, wenn ein Energie-Spannungspegel einen Schwellenwert-Betrag überschreitet, kann es für das Ziel-CS erforderlich sein, die Energiequelle abzuschalten. Solch ein Test würde mittels des Simulators an dem geeigneten Punkt in einer Testsequenz mittels Sendens eines Überspannungs-Signals an das Ziel-CS und mittels Überwachens der Antwort des Ziel-CS durchgeführt, um zu sehen, ob ein Abschalt-Signal gesendet wird. Die Test-0 ergebnisse, entweder Antworten des Bedieners oder automatisch überwachte Ereignisse/Werte, werden ebenfalls in einer oder mehreren Datenbanken gespeichert, so dass ein Ausnahme-Bericht, in dem die tatsächlichen Ziel-CS-Antworten mit erwarteten Ergebnissen verglichen werden, erzeugt werden 5 kann.

¹ · 1

13

Konfigurator - Test-Datenbanken

Es ist vorgesehen, dass der Konfigurator eine skalierbare Bibliothek von Test-Datenbanken und Test-Funktionen aufweist, bei denen die Test-Datenbanken verwendet werden, um die Test-Schritte durchzuführen. Unter Verwendung der Datenbank-Tabellen, um die Tests und Testparameter zu speichern, wird einem Tester ermöglicht, neue Tests und/oder Test-Szenarien hinzuzufügen und ferner Parameter für bestehende Tests zu ändern. Solche skalierbaren Bibliotheken und dynamischen Aktualisierungen führen zu einem robusteren und flexibleren System.

Die HMI / der Konfigurator 110 stellt zum Herunterladen eines Tests relationale Datenbanken zum Initiieren von Tests, zum Erfassen von Tester-Antworten und Kommentaren und zum Erzeugen von Berichten auf. Die Test-Datenbanken weisen Testfälle, erwartete Ergebnisse für Testvergleiche und eine Ausnahme-Erzeugung auf. Mittels einer Gesamttest-Planer-Datenbank wird die Sequenz von Testereignissen organisiert. Werden die Test-Datenbanken von der Anforderungs-Datenbank abgeleitet, wird dem Systemeigentümer eine Sperrschritt („Lock-Step")-Konfigurationssteuerung und ein verfolgbarer Anforderungs-Test gewährleistet.

Konfigurator - Anforderungs-Datenbank und Testgenerator

Eine Anforderungs-Datenbank und ein Testgenerator („RDTG") besteht aus einem Satz von Softwaredaten-Tabellen und Nutzerbildschirmen, um die Eingabe zu ermöglichen und die Verwaltung der gesamten Funktions-Anforderungen im Datenbankformat für programmierbare Logik-Steuerungs- (PLC) Mensch-Maschine-Schnittstellen- (HMI) oder verteilte Steuerungssystem (DCS)-Systeme zu ermöglichen. Der RDTG erzeugt ferner Tests zum Funktions- und Feld-Testen zur Verwendung mittels des Simulator-Systems, welches in der provisorischen US-Anmeldung 60/126060 („Testsystem")

]4 ·♦ ··

beschrieben ist, die an dieser Stelle mittels Bezugnahme in ihrer Gesamtheit einbezogen ist.

Die RDTG-Daten-Tabellen enthalten Informationen, die beim Implementieren und Testen eines Ziel-Steuerungssystems verwendet werden. Die Information in den Daten-Tabellen wird während der Anforderungs-Definition gesammelt, ferner referenziert als die Beschreibung der Systemanforderungen (DSR), und enthält Informationen über alle Aspekte des Systems, inklusive der Architektur, der Tags, der Netzwerkkopplung, der Schleifen (beispielsweise PID usw.), Alarme, Instrument-Kennzeichnungen, Trend-Vorhersagen, allgemeiner Anforderungen usw. Diese Information wird in einem Tag-Basis-Bereich (numerische Daten), einem Test-Basis-Bereich (Beschreibungsdaten für QTP und ATP) und einem Bereich für erwartete Ergebnisse gespeichert. Die Anforderungen können in irgendeinem Multimedia-Format, inklusive Text, Graphik und Klang gespeichert und/oder dargestellt sein. Die Implementierung des Systems wird durch Entwickler mittels des erforderlichen Satzes an Systemfunktionen erreicht.

Nach der Implementierung (komplett oder teilweise) erzeugt der RDTG automatisch eine Folge von anforderungsbezogenen vordefinierten Test- und Testfall-Daten-Tabellen für das Testsystem zum Vorfeld- / lokalen und zum Imfeid- / Vor-Ort-Testen (beispielsweise PLC, HMI, Verdrahtung, FeId-Verbindungen, Schleifen, Logik, Instrumente, Steuerungselemente usw.). Dadurch wird gewährleistet, dass alle Anforderungen sowie das Testen dieser Anforderungen und irgendwelche Änderungen an dem System in einem Sperrschritt gehalten werden, sodass ein zuverlässiges Produkt gewährleistet wird mittels eines elektronischen Tests, Dokumentation und Ergebnissen. Der RDTG kann ferner für eine schnelle Aktualisierung der Anforderungen und eine erneute Validierung irgendwelcher Änderungen mittels des Testsystems genutzt werden. Das Testsystem-Testgerät verwendet diese vordefinierten RDTG-Test- und -Testfall-Daten-Tabellen, um die Tests pro korrekter Sequenz zu starten, und zeigt automatisch das Durchlaufen und Fehlschlagen von Ergebnissen

an. Dadurch werden die Anordnung und die Programmierung eines Ziel-Steuerungssystems verifiziert.

Daher werden drei Teststufen mit diesen RDTG-Daten-Tabellen durchlaufen. Die erste Stufe ist ein Abmelden des Systems während der Entwicklung, wenn erforderlich. Die zweite Stufe ist ein Funktionstest, oder eine Qualifikations-Testprozedur (Qualification Test Procedure - QTP). Bei der QTP werden die Systemfunktionen mittels des Testsystems gründlich gegen die Anforderungen geprüft, die mittels des Clients in der DSR (eingekapselt in den RDTG-Daten-Tabellen) bekannt gemacht worden sind. Die dritte mittels des Testsystems durchlaufene Teststufe erfolgt mittels der Akzeptanz-Testprozedur (Acceptance Test Procedure - ATP), die stattfindet, wenn das QTP-getestete System im Feld installiert ist und auf einen zweiten Satz von RDTG-konfigurierten Daten-Tabellen getestet wird. Durch irgendeine Test-Ausnahme wird ein erneuter Test auf den fehlgeschlagenen Test hin angestoßen inklusive irgendeines aufgelisteten, voreingestellten Tests.

Durch den RDTG werden viele Vorteile bereitgestellt, inklusive aber nicht beschränkt auf die folgenden: (1) Er stellt eine/mehrere komplette Funktions-Anforderungs-Datenbank(en) für ein Ziel-PLC-/HMIs-System (möglicherweise in der Form von Boolean-ausdrucksbezogenen Tags und Datenwerten) bereit; (2) Er erzeugt von der/den Funktions-Anforderungs-Datenbank(en) automatisch Test-Datenbanken für das Testsystem zum Vorfeld- und Imfeld-Testen (beispielsweise PLC, HMI, Verdrahtung, Feld-Verbindungen, Schleifen). Durch Aufweisen des RDTGs, der die Test-Datenbanken erzeugt, ist ein höherer Gewährleistungsgrad dieser Anforderungen gegeben, wobei das Testen dieser Anforderungen und irgendwelche Änderungen an dem System im Sperrschritt mittels eines elektronischen Tests, Dokumentationen und Ergebnissen gehalten werden, um ein zuverlässiges Produkt zu gewährleisten; (3) Er stellt eine automatische Dokumentenerzeugung inklusive der Anforderungsdokumentation, Handbücher, Bedien-Prozeduren, Instrumenten-Datenblätter, Instrumenten-Indizes, Instrumenten-Schleifendiagramme, Validierungsberichte und

Testberichte inklusive der Ausnahme- und Übergabeberichte bereit. Das System kann für eine schnelle Aktualisierung der Anforderungen, eine erneute Validierung irgendwelcher Änderungen und für eine unmittelbare Aktualisierung verwandter Systemdokumentationen genutzt werden, wodurch eine automatische Konfigurationskontrolle bereitgestellt ist.

Kabelbaum

Der Kabelbaum 150 kann fast jede Form annehmen, solange durch ihn die I/O-Signale zwischen dem Testsystem 100 und dem Ziel-CS 9 00 korrekt übertragen werden. Jedoch ist bevorzugt, dass der Kabelbaum 150 derart ausgewählt wird, dass die Kopplung des Ziel-CS 900 an das Testsystem 100 und die Simulation der Feld-Verdrahtung, mit der das Ziel-CS 900 in seiner Betriebsumgebung gekoppelt sein wird, ermöglicht wird. Es ist vorgesehen, dass verschiedene Kabelbäume in dem Testsystem 100 enthalten sein können, wobei jeder Kabelbaum derart eingerichtet ist, dass die Kopplung des Testsystems 100 mit einem bestimmten Typ des Ziel-CS 900 ermöglicht wird. Das Einbeziehen solcher vorkonfigurierter Kabelbäume wird als Ermöglichen der Verwendung des Testsystems 100 angesehen, eine Vielzahl von Standard-Steuerungssystemen zu testen, wie Allen-Bradley-PLC-5-Steuerungen oder Siemens S7-Steuerungen.

Beispielanwendung

Das Testsystem 100 wird als besonders geeignet für eine 5 Anzahl von Anwendungen angesehen, wenn es zu einer betreibbaren Anlage genommen wird und anstelle der gesamten oder eines Teils der Feld-Verdrahtung gekoppelt ist, aufweisend aber nicht notwendigerweise beschränkt auf: (1) das Testen der bestehenden Logik auf die Reaktion auf neue Szenarien; (2) das Testen neuer Logik auf Operationen; (3) das Trainieren von Prozess-Bedienern vor einer Bedienaktion, um a) die Bereitschaft des Bedieners zu bewerten und zu validieren, b) unzureichende Trainingsbereiche zu identifizieren und c) die Betriebsbereitschaft als Team-

&ggr;&eegr; ** ♦· ·

gesamtheit zu gewährleisten; (4) das Trainieren von Prozess-Bedienern an der Bedieneinrichtung unter Verwendung des Anschließens des Testsystems 100 anstelle der eigentlichen Sensoren und Auslöser der Anlage; (5) die Fehlerbehebung der Verdrahtung und anderer feldbezogener Probleme.

Beispiel - Lokales Testen

Eine Beispielanwendung des Testsystems 100 liegt in dem erneuten Validieren eines PLC-Programms, das verwendet wird, um ein Arzneimittel herzustellen, wobei die PLC dies mittels Steuerns des Gewichts der Ingredienzien, der Heizung, der Kühlung, der Pegelsteuerung im Behälter, der Pumpensteuerung und anderer Bereiche des Herstellungsprozesses durchführt. Dieses Beispiel betrifft ein Ziel-CS 900, so als ob es das erneut zu validierende System wäre. Die erneute Validierung des PLC-Programms des Ziel-CS 900 würde zunächst das Verwenden des Testsystems 100 einbeziehen, um das lokale Testen des Ziel-CS 900 durchzuführen, und dann das Entfernen der HMI / des Konfigurators von dem Rest des Testsystems 100 und das In-Das-Feld-Nehmen des Ziel-CS 900, wenn das Ziel-CS 900 an der Arzneimittel-Produktions-Einrichtung installiert ist.

Während des lokalen Testens / Labortestens werden die I/O-Simulationsmodule 12 0 dazu verwendet, eine Eingabe an jeden der PLC-I/O-Kanäle mittels der Feld-I/O-Verbinder 225 bereitzustellen. Durch die automatischen Initialisierungs-Routinen des Testsystems wird eine Abbildung zwischen den Ziel-PLC- und den Testsystem-I/O-Kanälen erzeugt. Ein Tester würde sich an dem Testsystem-Konfigurator-Computer / der HMI 110 anmelden (erfordert, dass die Bediener sich zum 0 zukünftigen Prüfen/Audi ting der Einrichtungen anmelden) . Nach dem Anmelden werden Test-Datenbanken von einer Anforderungs-Datenbank heruntergeladen, die für das Ziel-CS 900 zum Projektstart aufgebaut worden ist. Die Test-Datenbanken werden dann verwendet, um alle Funktionen der PLC, der HMI und des Netzwerkes inklusive der Alarme, Schleifen und der

Feld-Verdrahtung zu testen, sodass die Testanforderung erfüllt wird, die in den Test-Datenbanken enthalten ist. Solch ein Testen wird mittels einer Folge automatischer Tests erreicht ebenso wie mittels Tests, die den Bediener auffordern, bestimmte Aktionen durchzuführen und die Antworten/Eingaben an die HMI nach dem Durchführen solcher Aktionen bereitzustellen. Das Testen von Alarmen weist das Testen von Totbändern und geeigneter Low-Low-, Low-, High- und High-High-Alarmbereiche ebenso wie anderer Typen von Daten-Veränderungen auf. Alle Daten können elektronisch mit >' einem Datum und einem Zeitstempel ebenso wie mit anderer Prüfinformation, wenn notwendig, gespeichert werden.

Ist das lokale / Labor-Testen einmal abgeschlossen, wird der Testsystem-Konfigurator / die HMI 110 von dem Testsystem und dem Ziel-CS 900 entfernt und im Feld eingesetzt, um vor Ort genutzt zu werden, das Test-Ziel-CS 900 zu testen, wenn es einmal in der Arzneimittel-Produktions-Einrichtung installiert ist. Im Feld weist der Testsystem-Konfigurator einen Feld-Tester mit einer Folge von Tests auf, die auf die 0 Feld-I/O- und die Verdrahtungsverbindungen bezogen sind. Für einige Tests wird der Feld-Tester mittels des Testsystem-Konf igurators aufgefordert, einen Techniker zu benachrichtigen, möglicherweise über ein Telefon, um Signale an das System einzugeben, die von dem Ziel-CS 900 mittels der 5 Feld-Verdrahtung übertragen worden sind. Der Testsystem-Konf igurator 110 fordert dann den Feld-Tester auf, Antworten einzugeben, die auf Fragen antworten, die auf die Rückantwort der HMI 910 des Ziel-CS 900 bezogen sind, die dem Tester als Antwort auf die Eingaben des Technikers bereitgestellt werden. Alle Testfragen und -ergebnisse werden gespeichert, um so zu ermöglichen, dass ein Bericht der Testergebnisse erzeugt wird.

Beispiel - Vor-Ort-Testen

Ist das Test-Ziel-CS 900 einmal in der Arzneimittel-Produktions-Einrichtung installiert, kann das Testsystem 100

periodisch genutzt werden, um die Bediener der Prozesse zu trainieren. Solch ein Training kann vor Ort unter Verwenden der Ziel-CS 900-HMI mittels einfachen Trennens des Ziel-CS 900 von den Sensoren und Aktoren der Anlage und möglicherweise mittels Trennens von der Feld-Verdrahtung und des Koppeins des Testsystems 100 mit dem Ziel-CS 900 anstelle der Sensoren und Aktoren durchgeführt werden. Wird das Ziel-CS 900 einmal eher mit der simulierten I/O als mit den realen Sensoren und Aktoren betrieben, sind die Bediener darin frei, mit dem Ziel-CS 900 ohne irgendeine Angst bezüglich der Konsequenzen für die Anlage zu interagieren. Wenn in solch einer Weise genutzt, können die Prozeduren, die verwendet werden, um das Ziel-CS 900 zu validieren, zum Trainieren der Bediener genutzt werden, oder ansonsten kann das Testsystem 100 die spezifische Software und/oder Daten zum Training der Bediener einbeziehen. Solche eine Software und/oder Daten können Multimedia-Präsentationen enthalten, wie Trainings-Videos. Das Testsystem 100 kann ferner teilweise oder komplett unabhängig von dem Bediener wirken, um so Ereignisse zu simulieren, wobei der verfolgende Bediener auf die simulierten Ereignisse antwortet und/oder dass auf die Qualität der Antworten des Bedieners angezeigt wird, ohne dass der Bediener mit dem Testsystem 100 während des Trainings interagieren muss.

Softwarebasiertes Training

Es ist vorgesehen, dass das Bediener-Training durch die Verwendung des Testsystems, wie vorher beschrieben, oder durch eine unabhängige, lediglich softwarebasierte Lösung verbessert werden kann, die auf einem computerlesbaren, entfernbaren Medium gespeichert ist, wie einer DVD oder einer CD-ROM.

Ein Verfahren zum Trainieren eines Bedieners, um ein Anlagen-Steuerungssystem zu bedienen, kann aufweisen: (a) Simulieren des HMI-Abschnitts des Anlagen-Steuerungssystems; (b) Simulieren des Steuerungs-Abschnitts des Anlagen-

t · i	•	•	• t	t ·	► · t ··	I ·	t
				* ·	' ·· ···
• · · t	•	•

Steuerungssystems; (c) Simulieren der Anlage selbst; (d) Koppeln der simulierten HMI des Steuerungssystems und der Anlage-Komponenten miteinander, so dass die Bediener-Interaktion mit der simulierten HMI dazu führt, dass die HMI aktualisiert wird, als ob der Bediener mit dem HMI-Abschnitt eines realen („Life"-} Steuerungssystems interagieren würde; und (e) Verursachen, dass der Bediener mit der simulierten HMI interagiert.

Für Steuerungssysteme, die Hardware-I/O nutzen, wie Steuerungs-Paneele, die Knöpfe, Schalter und Zifferblätter aufweisen, enthält die Simulation der HMI das Erzeugen von Graphik-Darstellungen des Steuerungspaneels und der Steuerungen, die darauf angebracht sind. Bei softwarebasierten Systemen enthält sie das Reproduzieren der HMI entweder mittels Duplizierens der HMI-Software oder mittels Aufnehmens der Bilder der Schnittstelle (über Bildschirm-Erfassungs-Techniken) und des Koppeins der Bilder mit Software, mittels derer Nutzereingaben akzeptiert und überwacht werden können, sowie des Aktualisierens der visuellen Bilder, 0 die der Bediener sehen kann. Das Duplizieren der HMI-Software und das Koppeln von ihr mit einem Steuerungs-Simulator und/oder Anlagen-Simulator kann dazu führen, dass es zu einer sehr realistischen Simulation kommt. Jedoch erfordert ein häufiges Vorgehen in dieser Weise, dass die HMI-Software modifiziert wird. Die Modifikation der HMI-Software ist nicht immer wünschenswert, da durch sie Fehler in die Simulation eingeführt werden können. Ferner ist typischerweise eine Lizenz und ein Zugriff auf den Quellcode der HMI erforderlich, um diese zu duplizieren und/oder zu modifizieren. Sowohl der Quellcode als auch eine Lizenz, um ihn zu kopieren und zu modifizieren, kann für einen Entwickler von Trainingsmaterialien schwierig zu beschaffen sein, wenn dieser nicht mit einem HMI-Software-Entwickler verbunden ist. In solchen Fällen können Screen Shots der visuellen Aspekte der HMI verwendet werden, um die HMI zu simulieren.

Der Steuerungs-Simulator wird bevorzugt mittels Software modelliert. Der Anlagen-Simulator kann hardware- und/oder softwarebasiert sein. Die hardwarebasierte Anlagen-Simulation kann mittels des vorher beschriebenen Testsystems erreicht werden. Bei der softwarebasierten Anlagen-Simulation können einfache Modelle, wie einfach zu verwendende Prozess-Testdaten, komplexe Modelle, bei denen komplizierte mathematische Modelle verwendet werden, oder eine hybride (Misch-) Form von beiden verwendet werden. Typischerweise ist eine Kombination dieser beiden notwendig, um eine effektive Simulation des Prozesses zu erzeugen.

Das Simulator-System kann mittels Hinzufügens von Prüfmodulen und gewünschten Start-Bedingungen an das Training angepasst werden. Heuristiken können ebenfalls hinzugefügt werden, um den Trainingsinhalt und das Szenario zur Laufzeit einzustellen.

Durch die Simulation ist es möglich zu trainieren und Sequenzen, d. h. Notfallsituationen, zu testen, was ansonsten nicht möglich wäre. Sowohl Simulations- als auch Trainingssysteme können auf einer CD-ROM, einer DVD usw. platziert sein und unabhängig von dem Steuerungssystem ausgeführt werden.

Eine beispielhafte Ausführungsform ist ein Simulator-System zum Simulieren eines Überwachungssystems für Spüloperationen.

Die eigentliche Bedien-HMI des Spül-Überwachungssystems wird als „Front-End" verwendet, und ein Simulationsgerät mit programmierten Szenarien ist als Code zur Ausübung des Bedienertrainings vorhanden. Alle Bildschirme der HMI, der Code und die Daten-Dateien befinden sich auf einer CD-ROM.

Wird sie in einem Gerät vom Typ eines Personalcomputers mit einem CD-ROM-Laufwerk platziert, startet das Installationsprogramm automatisch die Anwendung, und der Nutzer wird mit einem der verschiedenen Szenarien dargestellt, aus denen auszuwählen ist. Die Simulation beginnt dann, unterschiedliehe Bedienszenarien anzugeben, die basierend auf Kriterien gespeichert sind. Wenn die Person entscheidet, ein Gerät zu

überwachen, werden zu diesem Szenario Heuristiken eingefügt und Einstellungen getätigt, um die Qualifikation der Person zu testen. Es sind Videodateien verfügbar, wie auch Klang-Dateien, wie auch Prozeduren für das ausführliche Training verfügbar sind.

Es ist vorgesehen, dass es bei einigen Beispielen nützlich sein kann, das Testen und das Training zu kombinieren, sodass ein Bediener lernt, wie ein Steuerungssystem zu verwenden ist, wenn es gleichzeitig getestet wird.

Zusammenfassend wurden auf diese Weise spezifische Ausführungsbeispiele und Anwendungen von Geräten und Verfahren für eine Anlagen-Simulation, das Testen eines Anlagen-Steuerungssystems und das Trainieren eines Bedieners der Anlage offenbart.

Im Fazit erzeugt eine Anforderungs-Datenbank und Test-Generator Tests für das Funktions- und Feld-Testen und erzeugt Anforderungsdokumentationen, Handbücher, Bedien-Prozeduren, Instrumenten-Datenblätter, Instrumenten-Indizes, Instrumenten-Schleifendiagramme, Validierungs-Berichte und 0 Testberichte, inklusive eines Ausnahme- und Übergangsberichtes. Ein tragbares Prozess-Steuerungs-Simulator (120)-System, das Nutzern ein Steuerungssystem (900) mit Szenarien bereitstellt, die den Feldbetrieb, wie definiert, widerspiegeln .

Claims (13)

1. Testsystem zum Testen eines Steuerungssystems (900), aufweisend:
einen Konfigurator (110) mit einem Satz von Tags, wobei jedes Tag ein Bezeichner ist, der einer Komponente des zu testenden Steuerungssystems entspricht; und
wobei der Konfigurator (110) einen Satz von Anforderungen aufweist, wobei jede Anforderung zumindest ein Tag und zumindest einen Booleschen Operator aufweist.

2. Testsystem gemäß Anspruch 1, ferner aufweisend einen I/O- Simulator (120), einen Mechanismus zum automatischen Erzeugen von zumindest einem Satz von Befehlen für den I/O-Simulator (120) von jeder Anforderung und einen Mechanismus zum Übertragen des zumindest einen Satzes von Befehlen für den I/O-Simulator (120) an den I/O-Simulator (120).

3. Testsystem gemäß Anspruch 2, wobei jedes Tag einen entsprechenden Komponenten-Typ aufweist, und wobei der Konfigurator (110) einen Satz von Parameterwerten aufweist, wobei jeder Parameterwert einem Komponenten-Typ entspricht, und wobei zumindest einige der Parameterwerte zum Erzeugen des zumindest einen Satzes von Befehlen für den I/O-Simulator (120) verwendet werden.

4. Testsystem gemäß Anspruch 3, ferner aufweisend einen Satz von Fragen, mit denen das Testsystem (100) einen Bediener zum Antworten auf die Fragen und zum Aufzeichnen irgendeiner Antwort des Bedieners auf die Fragen auffordert.

5. Testsystem gemäß Anspruch 4, ferner aufweisend eine graphische Nutzerschnittstelle (GUI), die einen Mechanismus für einen autorisierten Bediener aufweist, um den Satz von Tags, den Satz von Anforderungen, den Satz von Untersätzen von Parameterwerten und/oder den Satz von Fragen zu warten.

6. Simulator-System zum Trainieren eines Bedieners, um ein Anlagen-Steuerungssystem (900) zu bedienen, unter Verwendung einer Prozessoreinheit, die derart eingerichtet ist, dass folgende Verfahrensschritte durchführbar sind:
Simulieren des HMI-Abschnitts (910) des Anlagen-Steuerungssystems (900)
Simulieren des Steuerungsabschnitts des Anlagen-Steuerungssystems (900)
Simulieren der Anlagen-Sensoren (971, 973) und -Aktoren (974, 976)
miteinander Koppeln der simulierten HMI, des simulierten Steuerungssystems und der simulierten Anlagen-Sensoren (971, 973) und -Aktoren (974, 976) derart, dass die Bediener-Interaktion mit der simulierten HMI dazu führt, dass die HMI (910) aktualisiert wird, als ob der Bediener mit dem HMI-Abschnitt eines realen ("Life"-) Steuerungssystems (900) interagiert hätte; und
Bringen des Bedieners dazu, mit der simulierten HMI zu interagieren.

7. Simulator-System gemäß Anspruch 6, wobei der HMI-Abschnitt (910) des Anlagen-Steuerungssystems (900) einen Computer- Anzeigebildschirm aufweist, und wobei das Simulieren des HMI-Abschnitts (910) des Anlagen-Steuerungssystems (900) das Erlangen von Bildern des Anzeigebildschirms während des Betriebs der HMI (910) sowie das Verwenden der erlangten Bilder beim Simulieren des HMI-Abschnitts (910) des Anlagen-Steuerungssystems (900) aufweist.

8. Simulator-System gemäß Anspruch 7, wobei die simulierte HMI, das simulierte Steuerungssystem und die simulierte Anlage jeweils softwarebasiert sind und auf einem entfernbaren Speichermedium gespeichert sind.

9. Simulator-System gemäß Anspruch 8, wobei das Speichermedium eine CD-ROM oder eine DVD-Platte ist.

10. Simulator-System gemäß Anspruch 9, wobei der Schritt des Simulierens der Anlage mittels eines Hardware-Simulators erreicht wird.

11. Testsystem gemäß einem der Ansprüche 1 bis 6, ferner eingerichtet, einen Bediener zu trainieren, wobei
das Testsystem (100) mit dem Steuerungssystem (900) gekoppelt ist, Prozeduren aufweist und eingerichtet ist, diese Prozeduren auszuführen, mit den Schritten:
Bringen des Bedieners dazu, mit dem Steuerungssystem (900) zu interagieren;
Bringen des Test- und Trainingssystems (100) dazu, die Qualität der Leistungsfähigkeit des Bedieners und die Qualität der Leistungsfähigkeit des Steuerungssystems (900) während der Zeitdauer anzuzeigen, in der der Bediener mit dem Steuerungssystem (900) interagierte.

12. System zum Testen eines Steuerungssystems (900) mit einer HMI (910), einer PLC (920) und einer I/O- Schnittstelle (930), wobei das System jede der HMI (910), der PLC (920) und der I/O-Schnittstelle (930) entweder individuell oder in Kombination miteinander testen kann.

13. System gemäß Anspruch 12, wobei das Testen jeder der HMI (910), der PLC (920) und der I/O-Schnittstelle (930) mittels direkten Manipulierens der Eingaben und Überwachens der Ausgaben der HMI (910), der PLC (920) und der I/O-Schnittstelle (930) erreicht wird.