-
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 des jeweiligen unabhängigen Patentanspruchs 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, für die Simulation der Hardware der Peripherie des Leitsystems und für die Simulation des in der technischen Anlage ablaufenden Prozesses. Alle 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, Geräten und rechnerischen Modellen oder sonstigen Recheneinheiten des Prozesses.
-
Durch das erfindungsgemäße Simulationssystem werden die Automatisierungsfunktion selbst, die Simulation der Hardware der Peripherie des Leitsystems und die Simulation des der technischen Anlage zu Grunde liegenden Prozesses 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 Automatisierung, die Hardware und den Prozess zu simulieren. Die Simulation der gesamten Automatisierung, der Hardware der Peripherie des Leitsystems als auch die Prozesssimulation laufen hier vorteilhaft in einer Instanz ab. Dazu werden nur Erweiterungen in der Bausteinbibliothek um Simulationsbausteine für die Hardware der Peripherie des Leitsystems und gegebenenfalls Prozesssimulationsbausteine für den Prozess benötigt.
-
Leitsystem und Simulator 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 den 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 so 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, welches 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 Resourcenmanagement 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 besteht das erfindungsgemäße Simulationssystem in dem in 2 dargestellten Ausführungsbeispiel 300a aus drei Ablaufumgebungen. In dem in 3 dargestellten Ausführungsbeispiel 300b sind alle Ablaufumgebungen zu einer einzigen Ablaufumgebung zusammengefasst und das Simulationssystem 300b umfasst hier nur diese eine Ablaufumgebung.
-
So umfasst in 2 das erfindungsgemäße Simulationssystem 300a 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 und einen Prozesssimulator hier als Ablaufumgebung 30 ausgestaltet. In die Ablaufumgebung 20 sind so genannte Stellvertreter-Module 211 und 212 eingebettet, welche die Leitsystemperipherie repräsentieren, die sich z. B. direkt an das Bussystem 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.
-
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ändigen 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.
-
Der Prozesssimulator besteht hier aus der Ablaufumgebung 30, welche den der technischen Anlage zu Grunde liegenden Prozess in Software nachbildet. Bei dem der technischen Anlage zu Grunde liegenden Prozess kann es sich um einen physikalischen, chemischen, biologischen oder sonstigen technischen Prozess handeln. In 2 ist der Prozesssimulator beispielhaft als eigene Ablaufumgebung 30 und/oder als eigene Softwarekomponente 3 ausgebildet. Die Softwarearchitektur des Prozesssimulators würde somit in Einklang mit der Architektur der Ablaufumgebungen 10 und 20 und der Softwarekomponenten 1 und 2 stehen und eine Integration ins Leitsystem erleichtern. Analog würde der Prozesssimulator in diesem Fall eine Vielzahl von eingebetteten Softwarekomponenten wie beispielsweise 71, 72 und 73 enthalten, welche beispielsweise ein physikalisches Modell der technischen Anlage repräsentieren. Die Softwarekomponenten 71, 72 und 73 könnten auch andere Berechnungsmodule enthalten. In einem Kraftwerk ist der zu Grunde liegende Prozess die Energiegewinnung durch Verbrennung beispielsweise von Kohlestaub unter Zuführung von Luft bei Entstehung von Rauchgas. Ferner wird Dampf erzeugt und auf unterschiedliche Temperaturen gebracht, um eine Turbine anzutreiben, welche für die Erzeugung von elektrischem Strom eingesetzt wird. Die Simulation jeder dieser Prozessschritte kann beispielsweise in Softwarekomponenten untergebracht werden. Die Materialströme und Prozesssignale würden dann über die Schnittstellen übertragen werden. Die gestrichelt eingezeichneten Verbindungslinien zwischen den einzelnen Bausteinen 71, 72 und 73 und den Schnittstellen 31 und 32 repräsentieren den Austausch von Prozesssignalen und stellen im Gegensatz zu den durchgezogenen Linien keine Drahtkonnektoren dar.
-
Erfindungsgemäß sind die Schnittstellen 11, 12, 13 der Automatisierungsfunktion i. e. der Ablaufumgebung 10 und die Schnittstellen 21, 22, 23 der Ablaufumgebung 20 nahezu identisch zu den Schnittstellen 33, 32, 33 der Ablaufumgebung 30. Dies bedeutet, dass die Kommunikation der Container 10, 20 und 30 über die gleiche Schnittstelle läuft, welche zum Leitsystem führt. Die Schnittstellen 11, 12, 13, 21, 22 und 23 sind in ihrer Funktion und physikalisch genauso ausgeführt wie die Schnittstellen 31, 32 und 33. Geringfügige Änderungen zur Anpassung an bestimmte Randbedingungen können möglich sein.
-
Grundsätzlich sind mehrere Varianten der Verbindung der Ablaufumgebungen möglich. Die Ablaufumgebung 10 kann beispielsweise wie in 2 gezeigt über besondere Schnittstellen wie die Verbindung der Busschnittstelle 18 mit der Schnittstelle 28 oder durch Umsetzung von Schnittstellen über eine Verbindung zwischen den Schnittstellen 11 und 12 mit den Schnittstellen 21 und 22 an die Ablaufumgebung 20 angeschlossen werden. Die für den Prozesssimulator zuständige Ablaufumgebung 30 kann ebenfalls direkt über diverse Schnittstellen an die für die Simulation der Hardwareperipherie zuständige Ablaufumgebung 20 angeschlossen werden. Zum Einen kann der Prozesssimulator 30 über eine extra hierfür vorgesehene Schnittstelle 33 mit einer ebenfalls extra hierfür vorgesehenen Schnittstelle 24 des Hardwaresimulators angeschlossen werden. Zum Anderen kann der Prozesssimulator 30 durch Umsetzung der Schnittstellen 21 und 22 des Hardwaresimulators auf Schnittstellen 31 und 32 des Prozesssimulators angeschlossen werden.
-
In einer zweiten Ausführungsvariante 300b für das erfindungsgemäße Simulationssystem, welche in 3 dargestellt ist, sind die Ablaufumgebungen 10, 20 und 30 zu einer einzigen Ablaufumgebung 35 zusammengefasst. Automatisierungs-, Hardware- und Prozesssimulation laufen in einer Instanz ab. Eingebettete Softwarekomponenten und Stellvertreter-Module der einzelnen Softwarekomponenten 1, 2 und 3 kommen nun in einer Ablaufumgebung 35 zur Ausführung. Außerdem kann die neu gebildete Ablaufumgebung 35 selbst eine Softwarekomponente 35' darstellen. Zuvor containerübergreifende Verbindungen oder Verschaltungen zwischen den eingebetteten Komponenten und Modulen aus vorher 10, 20 und 30 werden nun zu containerinternen Verbindungen oder Verschaltungen. Zuvor externe Schnittstellen werden nun zu internen (im Container eingeschlossen) Schnittstellen oder können komplett weggelassen werden. Auch hier repräsentieren die gestrichelt eingezeichneten Verbindungslinien z. B. zwischen den einzelnen Bausteinen 71, 72 und 73 den Austausch von Prozesssignalen und stellen im Gegensatz zu den durchgezogenen Linien keine Drahtkonnektoren dar. In dieser Ausführungsvariante besteht das Simulationssystem 300b nun aus nur einer Ablaufumgebung. Für die Kommunikation mit dem Leitsystem stehen nun mindestens die Schnittstellen 11 und 12 zur Verfügung. Zusätzlich ist auch hier eine weitere Schnittstelle 13 vorhanden, welche die Befüllung des Containers mit Engineering-Daten aus dem Bussystem 90 erlaubt.
-
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 und dritte Ablaufumgebung 20 und 30 mit sämtlichen eingebetteten Softwarekomponenten wie beispielsweise 201, den Stellvertreter-Modulen 211, 212 und Verschaltungen werden ebenfalls mittels des zuvor für die erste Ablaufumgebung verwendeten Projektierungswerkzeugs des Leitsystems erzeugt. Module vom Typ 211, 212 können sogar automatisch generiert werden.
- – Die Ablaufumgebung 10 oder Teile davon, welche dazu ausgebildet ist, den der Anlage zugrunde liegenden Automatisierungsprozess mit seinen Verschaltungen nachzubilden, kommen zur Ausführung und steuern so die Anlage.
- – Unabhängig vom Geschehen in der realen Anlage kommen parallel zur Ablaufumgebung 10 die Ablaufumgebungen 20 und 30 entweder getrennt voneinander oder zusammen zur Ausführung, wobei eine Simulation der technischen Anlage oder von Teilen der technischen Anlage durchgeführt wird.
