-
Die Erfindung betrifft ein Simulationssystem insbesondere für ein Leitsystem, welches einen in einer technischen Anlage ablaufenden Prozess steuert, wobei das Leitsystem zumindest eine als Container ausgebildete erste Ablaufumgebung umfasst, welche dazu ausgebildet ist, den der Anlage zugrunde liegenden Automatisierungsprozess nachzubilden und entsprechende Schnittstellen zum Leitsystem aufweist. Die Erfindung betrifft ferner ein Verfahren zur Durchführung einer Simulation mittels des erfindungsgemäßen Simulationssystems. Angegeben ist auch ein entsprechendes Leitsystem und Computerprogrammprodukt.
-
Bei technischen Großanlagen wie beispielsweise Kraftwerken werden Trainingssimulatoren zunehmend eingesetzt, um Wartenpersonal für den Betrieb des Kraftwerks zu schulen und um Ausnahmesituationen und kritische Betriebszustände zu trainieren, welche beim tatsächlichen Betrieb des Kraftwerks auftreten können. Simulatoren werden aber auch für Testzwecke im Rahmen des Engineering einer technischen Anlage angewendet, um einem Projekteur die Möglichkeit zu geben, optimale Lösungen für die Verschaltung von Funktionen innerhalb der technischen Anlage zu finden oder Fehler vor der Realisierung der Anlage zu erkennen und damit die Inbetriebnahme zu verkürzen.
-
Bei einem Simulator handelt es sich in der Regel um eine Rechneranlage, in der Abläufe einer technischen Anlage unter realitätsnahen Bedingungen geübt oder veranschaulicht werden können.
-
Im Kraftwerksbereich beispielsweise ist im Simulator im Prinzip ein Kraftwerk als Software nachgebildet. Um den Betrieb einer Kraftwerksanlage möglichst realistisch auf einem Rechner nachzubilden, ist es erforderlich, sowohl den verfahrenstechnischen Prozess, welcher in einem realen Kraftwerk abläuft und das Betriebsverhalten und Zusammenwirken der Kraftwerkskomponenten betrifft, als auch den automatisierungstechnischen Prozess, welcher das zur Bedienung und Steuerung eingesetzte Prozessleitsystem mit seinen Automatisierungs- und Bedien- und Beobachtungskomponenten umfasst, mit Hilfe von komplexer Software zu simulieren. Dementsprechend verhält sich der Simulator identisch zum realen Kraftwerk. Wird das Kraftwerk mit einem bestimmten Leitsystem, wie beispielsweise dem Siemens Leitsystem SPPA-T3000 gefahren, so entsprechen alle Details am Simulatorbildschirm denen aus dem Leitstand der realen Anlage.
-
Üblicherweise werden zur Simulation von Kraftwerksanlagen Simulationsrechner eingesetzt, welche vom Leitsystem unabhängig sind, d. h. ein eigenes separates Rechnersystem darstellen. Der dafür nötige Aufwand erfordert meist eine gigantische Rechnerleistung des eingesetzten Simulationsrechners. Die Hardware für den Simulationsrechner muss an jedem Einsatzort aufgebaut, installiert und gewartet werden.
-
Heutzutage gibt es zwei verschiedene Simulatoransätze (vgl. auch Beschreibung von 1A): Simulatoren, bei denen das Bedien- und Beobachtungssystem des originalen Leitsystems verwendet wird, und Simulatoren, die auch das Bedien- und Beobachtungssystem des Leitsystems, d. h. die gesamte Benutzeroberfläche mit simulieren – dies ist aber sehr aufwendig und die Ergebnisse sind im Allgemeinen auch unbefriedigend. Diese Lösung wird meistens nur noch bei älteren Leitsystemen angewendet, beispielsweise wenn das Bedien- und Beobachtungssystem nicht simulationsfähig ist weil z. B. keine Simulatorzeitunterstützung vorhanden ist.
-
Häufig gibt es Simulatoren, welche getrennte Rechner für die Hardware, wobei es sich um die Automatisierungsserver des Leitsystems und die an das Leitsystem angebundene Hardware wie I/O-Baugruppen, Motoren, Ventile usw. handelt, und für den der technischen Anlage zu Grunde liegenden physikalischen Prozess aufweisen. (vgl. auch Beschreibung von 1A)
-
In beiden Fällen ist die Software genauso wie die Hardware der Simulatoren vom Leitsystem entkoppelt. Oft werden Teile der originalen Software-Engineering-Daten betreffend die Automatisierung des Leitsystems verwendet, d. h. die Eingänge für die Simulationssoftware erhalten Werte aus dem Leitsystem, die aber in eine vom Leitsystem separate Software geschrieben werden. Weiterhin ist die Konfiguration dieser Simulatoren sehr komplex (teilweise bei den Prozesssimulatoren für den Benutzer gar nicht zugänglich) und erfolgt mit völlig anders gearteten Konfigurationswerkzeugen als die des Leitsystems. Ein Konsistenzcheck zwischen Simulatoren und Leitsystem findet nicht statt. Darüber hinaus berücksichtigt die Konfiguration von Simulatoren im Allgemeinen nicht die Engineeringdaten zur Verkabelung oder Verdrahtung von angebundener Hardware (Sensoren, Aktoren).
-
Aus der
DE 10 2009 055 810 A1 ist ein Verfahren zur Simulation eines Betriebsführungsprozesses bekannt. Dabei kommunizieren eine (Infrastruktur-)Simulation des Betriebsführungsprozesses und eine installierte Leittechnik des Betriebsführungsprozesses über eine auf standardisierte Industrieprotokolle basierende Kommunikationsverbindung.
-
Aus der
EP 1 906 377 A1 ist ein Simulationssystem, ein so genannter virtuellen PC, für ein (Prozess-)Leitsystem einer technischen Anlage bekannt.
-
Dieses Simulationssystem weist verschiedene Softwarekomponenten auf, die die Teile eines bzw. des Leitsystems nachbilden/simulieren und über einen virtuellen Bus in das Simulationssystem integriert sind.
-
Daher ist es Aufgabe der vorliegenden Erfindung, ein Simulationssystem anzugeben, durch welche die Simulation integraler Bestandteil eines Leitsystems wird. Es ist ferner Aufgabe der vorliegenden Erfindung, ein Leitsystem mit integriertem Simulationssystem anzugeben. Eine weitere Aufgabe der Erfindung besteht darin, ein verbessertes Verfahren zur Simulation anzugeben. Außerdem soll ein entsprechendes Computerprogrammprodukt angegeben werden.
-
Diese Aufgaben werden durch die Merkmale der unabhängigen Patentansprüche gelöst. Vorteilhafte Ausgestaltungen sind jeweils in den abhängigen Patentansprüchen wiedergegeben.
-
Das erfindungsgemäße Simulationssystem umfasst in dieser Variante Ablaufumgebungen für die Automatisierung und für die Simulation der Hardware der Peripherie des Leitsystems. Beide Ablaufumgebungen weisen die gleichen Schnittstellen auf, und sind über diese an das Bussystem angebunden. Die Ablaufumgebungen können auch zu einer einzigen Ablaufumgebung verschmelzen. Außerdem kann jede Ablaufumgebung selbst eine Softwarekomponente darstellen. Innerhalb der Ablaufumgebungen und Softwarekomponenten existieren eingebettete Softwarekomponenten als Repräsentanten von Funktionen, Baugruppen und Geräten.
-
Durch das erfindungsgemäße Simulationssystem werden die Automatisierungsfunktion selbst und die Simulation der Hardware der Peripherie des Leitsystems in die Software des Leitsystems eingebunden. In einem Leitsystem, welches eine universell einsetzbare Ablaufumgebung für Softwarekomponenten besitzt, kann diese Ablaufumgebung nun sowohl im normalen Leitsystem in Echtzeit für die Automatisierung beispielsweise eines Kraftwerks benutzt werden, als auch in weiteren Instanzen, um die Hardware zu simulieren. Die Simulation der gesamten Automatisierung und der Hardware der Peripherie des Leitsystems laufen hier vorteilhaft in einer Instanz ab. Dazu werden nur Erweiterungen in der Bausteinbibliothek um Simulationsbausteine für die Hardware der Peripherie des Leitsystems benötigt.
-
Leitsystem und Hardwaresimulator verschmelzen auf diese Weise softwaremäßig und damit auch rechnertechnisch zu einer Einheit, was zahlreiche Vorteile mit sich bringt:
- – Die Konfiguration des Simulationssystems erfolgt mit den gleichen Engineering- oder Projektierungswerkzeugen wie die Konfiguration des Leitsystems.
- – Die Projektierung des Simulationssystems erfolgt mit graphischen Werkzeugen in Bausteintechnik genauso wie die Projektierung der realen Anlage innerhalb des Leitsystems.
- – Aufgrund der Verwendung gleicher Werkzeuge für Konfiguration und Projektierung ist erstmals eine Konsistenzprüfung zwischen der Automatisierung und Simulation möglich. Damit können mit größter Sicherheit alle Funktionen des Leitsystems gewährleistet werden.
-
Durch die Erfindung wird ein vereinfachtes Simulationssystem für Training und Testzwecke bereit gestellt. Daraus resultieren geringere Ausfallzeiten beim Betrieb einer technischen Anlage, Verkürzung und Verbesserungen bei der Inbetriebnahme und verbesserte Qualität der Simulation, da Konsistenz innerhalb der gesamten Simulatorlösung vorhanden ist und alles auf einer Plattform abläuft.
-
Im Folgenden werden einige der verwendeten Begriffe dieser Anmeldung erläutert, um gleiches Verständnis sicherzustellen:
Im Allgemeinen wird als Softwarekomponente ein Programm bezeichnet, das aus direkt auf einem Betriebssystem ausführbarem Softwarecode besteht, und nach außen hin abgeschlossen ist, so dass Kommunikation zu anderen Softwarekomponenten nur über exakt definierte Schnittstellen zu anderen Softwarekomponenten erfolgt. Eine eingebettete (engl. „embedded”) Softwarekomponente ist eine Softwarekomponente, die in eine andere Softwarekomponente eingebettet ist. Sie ist zwar ebenfalls nach außen hin abgeschlossen und kommuniziert nur über exakt definierte Schnittstellen zu anderen Softwarekomponenten, sie wird aber nicht direkt auf dem Betriebssystem ausgeführt, sondern in der Umgebung der sie umschließenden Softwarekomponente.
-
Als Container wird in der Informatik ein Programm bezeichnet, welches aus direkt ablauffähigem Softwarecode besteht und zumindest eine Schnittstelle zu einer eingebetteten (embedded) Softwarekomponente und zumindest eine Schnittstelle zum Betriebssystem aufweist und direkt auf dem Betriebssystem ablauffähig ist. Im Folgenden wird ein Container, der seinerseits als Softwarekomponente ausgebildet ist und eine universell einsetzbare Ablaufumgebung für eine oder mehrere eingebettete Softwarekomponenten bildet, als „Ablaufcontainer” bezeichnet. Der Ablaufcontainer stellt demnach einerseits ein Koppelelement zwischen einer beliebigen eingebetteten Softwarekomponente und dem Betriebssystem dar und ermöglicht den Ablauf der eingebetteten Softwarekomponente auf dem Rechner. Andererseits vermittelt und verwaltet er in seiner Eigenschaft als Softwarekomponente auch die Kommunikation zwischen den eingebetteten Softwarekomponenten und anderen Softwarekomponenten außerhalb des Containers mittels externer Schnittstellen.
-
Unter Instanz ist in diesem Zusammenhang die konkrete Verwendung eines Typs einer Softwarekomponente im System zu verstehen.
-
Die Erfindung wird nachfolgend anhand von in den Zeichnungen dargestellten Ausführungsbeispielen näher erläutert. Dabei zeigen
-
1A ein Blockschaltbild einer möglichen Realisierung eines Leitsystems einer technischen Anlage mit seinen Hardwarekomponenten, SdT,
-
1B eine schematische Darstellung der Steuersoftware eines beispielhaften Leitsystems, SdT,
-
2 eine schematische Darstellung einer ersten Ausführungsvariante des erfindungsgemäßen Simulationssystems und
-
3 eine schematische Darstellung einer zweiten Ausführungsvariante des erfindungsgemäßen Simulationssystems.
-
In 1A ist in vereinfachter Form das Blockschaltbild einer möglichen Realisierung eines Leitsystems einer technischen Anlage dargestellt. In dieser Darstellung ist allein die Hardware gezeigt. Der mittels des Leitsystems zu steuernde zu Grunde liegende physikalische Prozess ist durch den Kasten P verdeutlicht. Dabei kann es sich beispielsweise um einen Prozess zur Energiegewinnung in einem Kraftwerk, eine Müllverbrennung oder einen chemischen Prozess handeln. Grundsätzlich kann es sich bei dem der technischen Anlage zu Grunde liegenden Prozess um einen physikalischen, chemischen, biologischen oder sonstigen technischen Prozess handeln. Die mittels Sensoren aufgenommenen Signale werden an Eingabe- und Ausgabe-Baugruppen EA1, EA2 bis EAN weitergegeben. Dabei kann es sich um reine Ein-Ausgabe-Baugruppen handeln oder auch um intelligente Feldgeräte. Gleichzeitig werden über die Baugruppen EA1, EA2 bis EAN auch Steuersignale an die Feldgeräte im Prozess weitergegeben. Der bidirektionale Signalfluss ist durch die Pfeile verdeutlicht. Die Baugruppen EA1, EA2 bis EAN sind auf der vom Prozess abgewandten Seite hin mit einem externen oder internen Bussystem BS verbunden, welcher die Signale sammelt und beispielsweise an mindestens einen Automatisierungsserver AUTS weiterleitet. Bei den Baugruppen EA1 bis EAN kann es sich auch um intelligente Feldgeräte handeln, bei denen Sensor und/oder Aktuator zusammen mit einer Verarbeitungslogik in einem Gerät integriert sind, das direkt über das Bussystem BS mit dem Automatisierungsserver AUTS verbunden ist. Der Automatisierungsserver AUTS wiederum kann – wie in diesem Beispiel ausgeführt – über einen Kommunikationsbus KB mit mindestens einem Applikationsserver APPS verbunden sein. Aus Verfügbarkeitsgründen sind i. a. jegliche Verbindungen zwischen den Servern und Bussen zumeist redundant ausgelegt, was durch die doppelten Verbindungslinien angedeutet ist. An den Kommunikationsbus KB ist ferner eine beliebige Benutzeroberfläche angeschlossen. Dabei handelt es sich um eine beliebige graphische Benutzerschnittstelle (engl. „graphical user interface”) GUI. Dabei kann es sich beispielsweise um thin clients handeln. Unter GUI sind hier jegliche Bedien- und Beobachtungssysteme, Engineering Clients oder sonstige Darstellungssysteme zu verstehen.
-
Wie bereits in der Einleitung ausgeführt, werden Simulationssysteme gemäß dem Stand der Technik SdT meist derart ausgeführt, dass entweder ein sehr leistungsfähiger Rechner bereitgestellt wird, der die gesamte Benutzeroberfläche GUI des Leitsystems simuliert (wie in der Figur durch den Kasten SIM1 angedeutet) oder dass über die Benutzeroberfläche GUI des Leitsystems statt auf den Automatisierungsserver AUTS auf einen separaten Simulationsrechner SIM2 zugegriffen wird. Letztere Lösung kann auch durch zwei Rechner realisiert sein, beispielsweise durch einen Rechner SIMHW, welcher die Hardware des zugrunde liegenden Automatisierungsprozesses simuliert, und durch einen Rechner SIMP, welcher den zugrunde liegenden Prozess simuliert.
-
In 1B ist eine mögliche Ausführungsvariante für die Softwarearchitektur eines beispielhaften Leitsystems, wie in 1A anhand der Hardware beschrieben, dargestellt. Die Software der Leittechnik ist in diesem Ausführungsbeispiel auf wenige Komponenten reduziert worden, um einen besseren Überblick zu gewährleisten: Als Grundfunktionen sind hier eine Präsentationssoftware 51 zu nennen, welche eine Darstellung unterschiedlichster Bedienbilder ermöglicht. Dabei kann es sich beispielsweise um einen Web-Browser handeln, der auf einem thin client abläuft. Die Ablaufumgebung ist mit 50 bezeichnet. Außerdem existieren zahlreiche Softwaremodule wie zum Beispiel 61, 62 und 63, welche zum Beispiel für das Engineering der Anlage, die Archivierung von Daten, das Meldemanagement, oder das Ressourcenmanagement verantwortlich sind. All diese Softwaremodule erfüllen demnach unterschiedliche Funktionen. Sie können in einer eigenen Ablaufumgebung ablaufen, welche hier mit 60 bezeichnet ist. Alle Softwaremodule sind miteinander verbunden, d. h. zwischen allen Modulen können Daten ausgetauscht werden.
-
Die Automatisierungsfunktion des Leitsystems ist in diesem Ausführungsbeispiel durch eine eigene Software dargestellt. Es handelt sich dabei um einen Ablaufcontainer 10, d. h. einen Container, der seinerseits als Softwarekomponente 1 ausgebildet ist und eine universell einsetzbare Ablaufumgebung für eine oder mehrere eingebettete Softwarekomponenten 101, 102, 111 und 112 bildet. Der Ablaufcontainer 10 verwaltet und führt alle vorhandenen Automatisierungsfunktionen einschließlich der Verarbeitungsfunktionen aus. Typischerweise weist der Ablaufcontainer 10 mehrere Schnittstellen auf. Unter Schnittstelle wird im Folgenden stets eine Datenschnittstelle gemeint. Dabei kann es sich beispielsweise um eine Schnittstelle 13 für das Engineering handeln oder um die Schnittstellen 11 und 12, welche mit der restlichen Leittechnik verbunden sind, u. a. auch mit anderen Instanzen einer Ablaufumgebung. Außerdem können Schnittstellen für die Diagnose, für bestimmte Meldungen oder die Bedienung vorhanden sein. Innerhalb des Ablaufcontainers 10 sind in 1B eingebettete Softwarekomponenten 101 und 102 dargestellt. Diese weisen wiederum interne, standardisierte Schnittstellen, welche als Punkte dargestellt sind auf. Die eingebetteten Softwarekomponenten 101 und 102 enthalten Hauptfunktionen wie sämtliche Automatisierungsaufgaben, Steuerungen, Regelungen, Berechnungen, Verarbeitungsfunktionen, Alarmverwaltung und Ausführungsverwaltung.
-
Ferner sind innerhalb des Ablaufcontainers 10 so genannte Stellvertretermodule 111 und 112 dargestellt. Die Stellvertretermodule repräsentieren im Wesentlichen vorhandene Hardwarekomponenten wie beispielsweise eine Eingabe- oder Ausgabebaugruppe. Deren Software ist hier durch 81 und 82 verdeutlicht. Die Stellvertretermodule 111 und 112 sorgen für die Anbindung der Eingangsrohdaten an/von den Feldgeräten und überwacht diese und ist demnach für die Kommunikation mit den Feldgeräten zuständig. Für diese Anbindung wird das Businterface 18 verwendet. Diese Schnittstelle des Ablaufcontainers 10 zu einem Automatisierungsbus (Businterface zum Bussystem BS), über den die Ein- und Ausgabebaugruppen und die intelligenten Feldgeräte mit dem Automatisierungsserver verbunden sind. Über diese Schnittstelle kommunizieren die Stellvertretermodule 111 und 112 im Inneren des Ablaufcontainers 10 mit den Ein- und Ausgabebaugruppen (und intelligenten Feldgeräten), die sich ja außerhalb des Automatisierungsservers (und damit außerhalb des Ablaufcontainers 10) befinden. Beim Automatisierungsbus kann es sich je nach Ausführung z. B. um einen Profibus, einen Modbus, einen anderen seriellen Bus oder auch um einen Ethernet basierten Bus (wie z. B. Profinet oder eine reine TCP/IP oder UDP basierte Kommunikation) handeln.
-
Im laufenden Betrieb des Leitsystems kommt es zum Ablauf der Softwarekomponente 1 und damit auch der innerhalb von 1 eingebetteten Softwarekomponenten 101, 102 und Stellvertretermodule 111 und 112, die über ihre internen Schnittstellen derart verschaltet sind, dass der gesamte Automatisierungsprozess implementiert ist.
-
In den 2 und 3 sind Ausführungsvarianten des erfindungsgemäßen Simulationssystems dargestellt. Es handelt sich dabei jeweils um eine Softwarearchitektur, welche direkt mit der in 1B gezeigten Architektur vereinbar ist und an diese anschließt.
-
So umfasst in 2 das erfindungsgemäße Simulationssystem 100a in diesem ersten Ausführungsbeispiel neben der in 1B beschriebenen Ablaufumgebung 10 für die Automatisierungsfunktion eine weitere Ablaufumgebung 20, welche die Hardware der Peripherie des Leitsystems mit all seinen Verschaltungen in Software nachbildet. In diese Ablaufumgebung 20 sind so genannte Stellvertretermodule 211 und 212 eingebettet, welche die Leitsystemperipherie repräsentieren, die sich z. B. direkt an das Bussystem BS aus 1A anschließt. Dies können beispielsweise Baugruppen sein, andere Busanschlussmodule, intelligente Feldgeräte wie Aktoren (Stelleantriebe, Motorsteuergeräte) und Sensoren oder auch Kommunikationsbausteine zu Fremdsystemen. Die Softwarekomponente 201 simuliert z. B. das Verhalten eines Stellantriebs mit Befehlen in Richtung Auf- oder Zu-Richtung und entsprechenden Rückmeldungen oder das Verhalten des Einschubs der Schaltanlage für einen Motor einer verfahrenstechnischen Komponente. Die Softwarebausteine 201, 211, 212 besitzen dazu jeweils interne Schnittstellen (engl. „internal interfaces”) über welche zum Beispiel physikalische Größen oder sonstige Daten und Parameter ausgetauscht werden können. Die Verbindungslinien zwischen den einzelnen Bausteinen und Schnittstellen repräsentieren diesen Signalaustausch der in der realen Anlage z. B. über vorhandene Kabel/Drähte im Leitsystem oder durch Datenübertragung in Feldbussystemen erfolgt. (Je nach Verdrahtungs- oder Verkabelungsvariante können auch Klemmestellen z. B. als Verteiler oder Repeater bei Feldbus einbezogen werden. Diese Komponenten sind in der Grafik zur Vereinfachung nicht dargestellt) Die Stellvertretermodule 211 und 212 sind invers zu Stellvertretermodulen 111 und 112 ausgebildet. Mit invers ist hier gemeint, dass Ein- Und Ausgänge der jeweiligen Schnittstellen vertauscht sind. Während ein Stellvertretermodul des Typs wie 111 und 112 in der Regel für die Anbindung der Eingangsrohdaten an/von der Leittechnik-Schnittstelle sorgt, simuliert ein Stellvertretermodul des Typs wie 211 und 212 bereits eine Baugruppe und ist somit für die Umwandlung der Felddaten in die Eingangsrohdaten für höher gelegene Softwaremodule zuständig. Ferner gilt, dass den Stellvertretermodulen sowohl reale Prozessgrößen als auch vorgegebene oder simulierte Größen zugeführt werden können.
-
Die gesamte Ablaufumgebung 20 kann nun gemäß der oben beschriebenen Containerdefinition als Ablaufcontainer ausgebildet sein oder als Softwarekomponente 2. In beiden Fällen existieren externe Schnittstellen (engl. „external interfaces”) einer bestimmten Anzahl wie beispielsweise 21, 22 und 23, welche eine Kommunikation mit den übrigen Programmteilen des Leitsystems ermöglichen. Die Schnittstelle 23 kann wie die Schnittstelle 13 der ersten für die Automatisierung zuständige Ablaufumgebung 10 für die Befüllung des Containers mit Engineering-Daten zuständig sein und mit dem Komponentenbus 90 verbunden sein. Die Kommunikation zwischen den Softwarekomponenten 1 und 2 bzw. den Ablaufumgebungen 10 und 20 kann über die Schnittstellen 18 und 28 erfolgen. Die Schnittstelle 28 ist je nach Bustyp entweder zur Schnittstelle 18 identisch (i. a. für Ethernet basierte Bussysteme), oder stellt je nach Bussystem die komplementäre Schnittstelle zur Schnittstelle 18 zur Verfügung (i. a. für serielle Bussysteme mit Master-Slave Funktionalität). Zusätzlich kann eine weitere Schnittstelle 24 vorhanden sein, welche den Anschluss an den Prozess erlaubt. Über diese Schnittstelle 24 können Prozessdaten übermittelt werden, die von einem Prozesssimulator, i. e. einem nur für den technischen Prozess zuständigen Simulationsrechner, übermittelt werden.
-
Erfindungsgemäß sind die Schnittstellen 11, 12, 13 der ersten (für die Automatisierung des Leitsystems zuständigen) Ablaufumgebung 10 nahezu identisch zu den Schnittstellen 21, 22, 23 der zweiten (für die Hardware der Peripherie zuständige) Ablaufumgebung 20. Dies bedeutet, dass die Kommunikation der beiden Container 10 und 20 über die gleiche(n) Schnittstelle(n) läuft, welche zum Leitsystem führt. Die Schnittstellen 11, 12 und 13 sind in ihrer Funktion und physikalisch genauso ausgeführt wie die Schnittstellen 21, 22, 23. Geringfügige Änderungen zur Anpassung an bestimmte Randbedingungen können möglich sein.
-
In einer zweiten Ausführungsvariante, welche in 3 dargestellt ist, sind die beiden Ablaufumgebungen 10 und 20 zu einer einzigen Ablaufumgebung 15 zusammengefasst. In dieser Ausführungsvariante besteht das Simulationssystem 100b nun aus nur einer Ablaufumgebung. Diese kann auch als Softwarekomponente 15' ausgebildet sein. Eingebettete Softwarekomponenten und Stellvertreter-Module der einzelnen Softwarekomponenten 1 und 2 kommen nun in einer Ablaufumgebung 15 zur Ausführung. Zuvor containerübergreifende Verbindungen oder Verschaltungen zwischen den eingebetteten Komponenten und Modulen aus vorher 10 und 20 werden nun zu containerinternen Verbindungen oder Verschaltungen. Zuvor externe Schnittstellen werden nun zu internen (im Container eingeschlossen) Schnittstellen. Ein Beispiel hierfür stellen die Verbindungen zwischen den Stellvertretermodulen 111 und 112 der ersten Softwarekomponente 1 und den Stellvertretermodulen 211 und 212 der zweiten Softwarekomponente 2 dar. Für die Kommunikation mit dem Leitsystem stehen nun mindestens die Schnittstellen 11, 12 und 13 zur Verfügung. Zusätzlich kann auch hier eine weitere Schnittstelle 24 vorhanden sein, welche den Anschluss an den Prozess erlaubt.
-
Unabhängig ob das Simulationssystem nun gemäß 2 aus zwei Ablaufumgebungen für die Automatisierung und Hardware der Peripherie des Leitsystems ausgebildet ist (Variante 100a) oder beide Funktionen in einer Ablaufumgebung ausgeführt werden gemäß 3 (Variante 100b) existieren unterschiedliche Möglichkeiten zur Anbindung von Prozessdaten. Diese können beispielsweise einem Prozesssimulator 200 entnommen werden.
-
Gemäß 2 kann der Prozesssimulator 200 direkt über diverse Schnittstellen an das Simulationssystem 100 angeschlossen werden. Zum Einen kann der Prozesssimulator 200 über eine extra hierfür vorgesehene Schnittstelle 33 an die Schnittstelle 24 des Hardwaresimulators angeschlossen werden. Zum Anderen kann der Prozesssimulator 200 durch Umsetzung der Schnittstellen 11, 12 oder 21, 22 des Simulationssystems 100 auf Schnittstellen 31, 32 des Prozesssimulators 200 angeschlossen werden. In einer weiteren Ausführungsvariante gemäß 3 ist auch eine Anbindung des Prozesssimulators 200 über einen eigens dafür vorgesehenen Adapter 99 möglich. Dabei kann es sich um ein Programm zur Zuordnung und Umwandlung beliebiger Prozessdaten handeln. Auch in diesem Fall ist ein Anschluss an den Simulator 100b über eine eigens dafür vorgesehene Schnittstelle 24 oder durch Umsetzung von Schnittstellen 11 und 12 möglich.
-
Eine Simulation des Leitsystems oder von Teilen davon wird nun folgendermaßen durchgeführt:
- – Die erste Ablaufumgebung 10 wird mittels eines Projektierungswerkzeugs des Leitsystems erzeugt.
- – Die zweite Ablaufumgebung 20 mit sämtlichen eingebetteten Softwarekomponenten wie beispielsweise 201, den Stellvertreter-Modulen 211, 212 und Verschaltungen wird ebenfalls mittels des zuvor für die erste Ablaufumgebung verwendeten Projektierungswerkzeugs des Leitsystems erzeugt.
- – Die Ablaufumgebung 10, welche dazu ausgebildet ist, den der Anlage zugrunde liegenden Automatisierungsprozess mit seinen Verschaltungen nachzubilden wird anschließend in einen Simulationsmode versetzt ohne die bestehende Projektierung zu ändern.
- – In einem nächsten Schritt kommen die Ablaufumgebungen 10 und 20 entweder getrennt voneinander oder zusammen zur Ausführung, wobei eine Simulation der technischen Anlage oder von Teilen der technischen Anlage durchgeführt wird.