WO2012168214A1 - Simulationssystem, verfahren zur durchführung einer simulation, leitsystem und computerprogrammprodukt - Google Patents

Simulationssystem, verfahren zur durchführung einer simulation, leitsystem und computerprogrammprodukt Download PDF

Info

Publication number
WO2012168214A1
WO2012168214A1 PCT/EP2012/060556 EP2012060556W WO2012168214A1 WO 2012168214 A1 WO2012168214 A1 WO 2012168214A1 EP 2012060556 W EP2012060556 W EP 2012060556W WO 2012168214 A1 WO2012168214 A1 WO 2012168214A1
Authority
WO
WIPO (PCT)
Prior art keywords
simulation
interfaces
simulation system
control system
environment
Prior art date
Application number
PCT/EP2012/060556
Other languages
English (en)
French (fr)
Inventor
Andreas RATHGEB
Rainer Speh
Michael Unkelbach
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to CN201280028224.2A priority Critical patent/CN103597414A/zh
Priority to US14/123,966 priority patent/US20140172402A1/en
Priority to EP12726415.8A priority patent/EP2718773A1/de
Publication of WO2012168214A1 publication Critical patent/WO2012168214A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/20—Design optimisation, verification or simulation
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B17/00—Systems involving the use of models or simulators of said systems
    • G05B17/02—Systems involving the use of models or simulators of said systems electric

Definitions

  • Simulation system method for carrying out a simulation, control system and computer program product
  • the invention relates to a simulation system, in particular for a control system, which controls a process running in a technical installation, wherein the control system comprises at least ei ⁇ ne designed as a container first plinUm constitution, which is designed to the system underlying the ⁇ simulate the automation process and corresponding Has interfaces to the control system.
  • the invention further relates to a method for carrying out a simulation by means of the simulation system according to the invention. Also indicated is a corresponding control system and computer program product.
  • simulators are also used for testing purposes in the engineering of a technical system, in order to give a project engineer the opportunity to find optimal solutions for the interconnection of functions within the technical system or to detect faults before the realization of the system and thus commissioning shorten.
  • a simulator is usually one
  • a power plant is simulated as software in the simulator, in principle.
  • the simulator behaves identically to the real power plant. If the power plant is operated with a specific control system, such as the Siemens SPPA-T3000 control system, all the details on the simulator screen correspond to those from the control console of the real plant.
  • simulation computers are used to simulate power plants, which are independent of the control system, i. represent their own separate computer system.
  • the effort required for this usually requires a gigantic computer performance of the simulation computer used.
  • the hardware for the simulation computer must be set up, installed and maintained at each site.
  • simulators in which the control and monitoring system of the original control system is used, and simulators, which include the control and Be ⁇ care system of the control system, ie the entire Simulate user interface with - but this is very complicated and the results are generally also unsatisfactory.
  • This solution is aimed mostly reasonable only in older control systems, such as when the operating and Beobachtungssys ⁇ system is not capable of simulation because eg no simulator time ⁇ support is available.
  • simulators which are separate computers for the hardware, which are the automation servers of the control system and the hardware connected to the control system such as I / O modules, motors, valves, etc., and for have the physical process underlying the physical process (see also description of Fig. 1A)
  • the software as well as the hardware of the simulators is decoupled from the control system.
  • Often parts of the original software engineering data relating to the automation of the control system are used, ie the inputs for the simulation software receive values from the Leitsys ⁇ tem, but which are written in a software separate from the control system.
  • the configuration of these simulators is very complex (sometimes not accessible to the user in the process simulators) and takes place with completely different configuration tools than the control system. A consistency check between simulators and control system does not take place.
  • the configuration of simulators generally does not take into account the engineering data for cabling or wiring connected hardware (sensors, actuators).
  • the simulation system comprises in this Va ⁇ riante runtime environments for automation and for the simulation of the hardware of the periphery of the control system. Both execution environments have the same interfaces, and are connected via these to the bus system.
  • the sequence Conversely ⁇ exercises can also comparable to a single runtime environment melt.
  • each run environment itself can be a software component.
  • embedded software components exist as representatives of functions, assemblies, and devices.
  • the automation function itself and the simulation of the hardware of the periphery of the control system are integrated into the software of the control system.
  • this hinUm constitution can now be used both in the normal control system in real time for the automation of example ei ⁇ nes power plant, as well as in other instances, to simulate the hardware.
  • the simulation of the entire automation and the hardware of the periphery of the control ⁇ system run here advantageously in one instance. For this purpose, only extensions in the block library with simulation blocks for the hardware of the periphery of the control system are required.
  • control system and hardware simulator merge into one unit in terms of software and thus also in terms of computer technology, which brings numerous advantages:
  • the simulation system is configured using the same engineering or configuration tools as the control system configuration.
  • the invention provides a simplified simulation system for training and testing purposes. As a result, Reduced equipment downtime, shortening and improvement in commissioning, and improved simulation quality because consistency is present throughout the simulator solution and everything runs on one platform.
  • a program be is a software component ⁇ stands that consists of directly on an operating system aus Kunststoffba ⁇ rem software code, and is closed to the outside, so that communication other software components only via exactly defined interfaces to other software components.
  • An embedded (English, "embedded") Soft ⁇ ware component is a software component that is embedded in a ande ⁇ re software component. She is also closed to the outside and communicates only through well-defined interfaces to other software components, but it will not directly running on the operating system, but in the environment of the surrounding software component.
  • a program As a container in computer science, a program is called, which consists of directly executable software code and ⁇ at least one interface to an embedded (embedded) software component and at least one interface to Be ⁇ operating system has and is executable directly on the operating system.
  • a container which is for its part constructed as a software component and forms a univer ⁇ sell usable runtime environment for one or more inserted ⁇ embedded software components, referred to as "flow container” will be.
  • the process container provides therefore on the one hand a coupling element between any embedded software software component and the operating system and enables the flow of embedded software component on the computer.
  • Fig. 1A is a block diagram of a possible realization of a control system of a technical installation with i ⁇ NEN hardware components, SDT
  • 1B is a schematic representation of the control software of an exemplary control system, SdT,
  • FIG. 2 shows a schematic illustration of a first embodiment variant of the simulation system according to the invention
  • Fig. 3 is a schematic representation of a second embodiment of the invention Simulationssys ⁇ tems.
  • Fig. 1A the block diagram of a possible implementation of a control system of a technical system is shown in simplified form. In this illustration, only the hardware is shown.
  • the underlying by the control system ⁇ de underlying physical process is illustrated by the box P.
  • This can be, for example, a process for generating energy in a power plant, waste incineration or a chemical process.
  • the process underlying the technical installation may be a physical, chemical, biological or other technical process.
  • the signals recorded by sensors are forwarded to input and output modules EA1, EA2 to EAN. These can be pure input-output modules or even order intelligent field devices. At the same time, be passed on to EA2 EAN control signals to the field devices in the process about the construction ⁇ groups EA1.
  • the bidirectional signal flow is illustrated by the arrows.
  • the modules EA1, EA2 to EAN are connected on the side facing away from the process with an external or internal bus system BS, which collects the signals and forwards, for example, to at least one auto ⁇ automation server AUTS.
  • the modules EA1 to EAN can also be intelligent field devices in which sensor and / or actuator are integrated together with processing logic in a device which is connected directly to the automation server AUTS via the bus system BS.
  • the automation server AUTS in turn, can-as described in this example-be connected to at least one application server APPS via a communication bus KB. For availability reasons, in general all connections between the servers and buses are designed to be redundant, as indicated by the double connection lines.
  • An arbitrary user interface is also connected to the communication bus KB. This is an arbitrary graphical user interface
  • GUI graphical user interface
  • thin clients which means any operator control and monitoring systems, engineering clients or other display systems.
  • simulation ⁇ systems are mostly such out ⁇ leads according to the prior art SdT that either a very powerful computer is riding provided loading, which simulates the entire user interface GUI of the control system (as shown in the figure by box SIM1 indicated), or that from the user interface GUI of the control system instead of the automation server AUTS on ei ⁇ NEN separate simulation computer SIM2 is accessed.
  • the latter solution can also be realized by two computers, for example by a computer SIMHW, which simulates the hardware of the underlying automation process. liert, and by a computer SIMP, which simulates the underlying process.
  • FIG. 1B shows a possible embodiment variant for the software architecture of an exemplary control system, as described in FIG. 1A with reference to the hardware.
  • the software of the control system has been reduced in this embodiment to a few components to ensure a better overview:
  • the basic functions are here to call 51 that allows depicting ⁇ development Kunststoffster operating screens presentation software. This could be, for example, a web browser running on a thin client.
  • the execution environment is be distinguished ⁇ with 50th
  • there are numerous software modules such as 61, 62 and 63, which are responsible, for example, for the engi ⁇ neering of the system, the archiving of data, the message management, or resource management. All these software modules therefore fulfill different functions. They can run in their own drainage environment, which is designated here by 60. All software modules are interconnected, ie data can be exchanged between all modules.
  • the automation function of the control system is shown in this embodiment by its own software.
  • the flow container 10 has multiple interfaces.
  • an interface is always meant to mean a data interface. It may, for example, a sectional ⁇ point 13 act for the engineering or near the interfaces 11 and 12, which are connected to the rest of the control system, including with other instances of a Budapestum- 10.1.
  • embedded software components 101 and 102 are shown in FIG. 1B. These in turn have internal, standardized interfaces, which are shown as dots.
  • the embedded Softwarekompo ⁇ components 101 and 102 contain the main functions such as all automation tasks, controls, regulations, calculations, processing functions, alarm management and exemplary administration.
  • proxy modules 111 and 112 are shown within the dormitorContainer.
  • the deputy ⁇ representative module representing existing hardware components such as an input or Ausga ⁇ bebaueria substantially. Their software is here by 81 and 82 verdeut ⁇ light.
  • the proxy modules 111 and 112 provide for the connection of the input raw data to / from the field devices and monitors them and is therefore responsible for the communication with the field devices.
  • the bus interface 18 is used. This interface of theticians 10 to an automation bus (bus interface to the bus system BS), via which the input and output modules and the intelligent field devices are connected to the automation server.
  • the Stellvertre ⁇ termodule 111 and 112 communicate the interior of the drain container 10 to the input and output modules (and intelligent field devices) extending yes outside the automation server (and thus outside of the flow container 10) are located.
  • the automation bus can be, for example, a Profibus, a Modbus, another serial bus or even an Ethernet-based bus (such as Profinet or pure TCP / IP or UDP-based communication).
  • FIGS. 2 and 3 show variant embodiments of the simulation system according to the invention.
  • this is a software architecture which is directly compatible with the architecture shown in FIG. 1B and follows it.
  • the simulation system 100a according to the invention comprises, in addition to the runoff environment 10 for the automation function described in FIG. 1B, a further runtime environment 20, which simulates the hardware of the periphery of the control system with all its interconnections in software.
  • proxy modules 211 and 212 are embedded, which represent the Leitsystemperipherie, for example, connects directly to the bus system BS of FIG. 1A.
  • the software component 201 simulates, for example, the behavior of an actuator with commands in the direction of open or closed direction and corresponding feedback or the behavior of the insertion of the switchgear for a motor ei ⁇ ner procedural component.
  • the software modules 201, 211, 212 have to respective internal interfaces (English, "internal interfaces") over which, for example, physi ⁇ -earth sizes or other data and parameters may be exchanged.
  • connection lines between the individual modules and interfaces represent this signal exchange This is done in the real system, eg via existing cables / wires in the control system or by data transmission in fieldbus systems (depending on the wiring or cabling variant, terminal points, eg as a distributor or repeater, can also be included in the fieldbus.) These components are shown in the diagram for simplification not shown)
  • the proxy modules 211 and 212 are inverse to each other. formed tretermodulen 111 and 112. Inverse here means that inputs and outputs of the respective interfaces are reversed.
  • a proxy module of the type such as 111 and 112 usually provides for the connection of the incoming raw data to / from the process control interface
  • a proxy module of the type such as 211 and 212 already simulates an assembly and is therefore suitable for the conversion of the field data into the input raw data for software modules higher up to ⁇ ever. Further, is valid that the substitute modules both real process variables as well as predetermined or simulated large ⁇ SEN may be supplied.
  • the entire drain environment 20 can now be designed as a flow container or as a software component 2 according to the container definition described above.
  • external interfaces English, "external interfaces" of a certain number, such as 21, 22 and 23, exist that communicate
  • the interface 23 like the interface 13 of the first automation environment 10, can be responsible for filling the container with engineering data and can be connected to the component bus 90.
  • the communication between the software components 1 and 2 or the drain environments 10 and 20 can take place via the interfaces 18 and 28.
  • the interface 28 is either identical to the interface 18 (in general for Ethernet-based bus systems) or provides the complementary interface to the interface 18 depending on the bus system (ia for s serial bus systems with master - slave functionality).
  • a white ⁇ direct interface 24 may be provided, which allows the connection to the process. Via this interface 24 pro ⁇ process data can be transmitted, which are of a process simulator, ie a responsible only for the technical process simulation lationsrechner transmitted.
  • the interfaces 11, 12, 13 of the first (responsible for the automation of the control system) process Environment 10 almost identical to the interfaces 21, 22, 23 of the second (responsible for the hardware of the periphery) Ab ⁇ running environment 20.
  • the interfaces 11, 12 and 13 are executed in their function and physically as well as the interfaces 21, 22, 23. Minor changes to adapt to certain boundary conditions may be possible.
  • the two runtime environments are combined 10 and 20 to ei ⁇ ner single runtime environment of 15 °.
  • the simulation system 100b now consists of only one drain environment.
  • This can also be designed as a software component 15 '.
  • Embedded Softwarekompo ⁇ components and alternate modules of the individual Softwarekompo ⁇ components 1 and 2 now come in an execution environment 15 for execution.
  • cross-container connections or interconnections between the embedded components and modules from previously 10 and 20 now become container-internal connections or interconnections.
  • external interfaces became internal interfaces (included in the container).
  • simulation system in accordance with FIG. 2 consists of two execution environments for automation and hardware of the Pe- ripherie of the control system is formed (variant 100a), or both functions are performed in an execution environment according to Fig. 3 (variant 100b) are different Mög ⁇ opportunities for the connection of process data. These can be For example, a process simulator 200 are taken.
  • the process simulator 200 can be connected directly to the simulation system 100 via various interfaces.
  • the process simulator of the hardware simulator can imagine the interface ⁇ 200 via a specially provided for this purpose interface 33 24 are connected.
  • the process simulator 22 32 200 the process simulator On the other 200 can be attached ⁇ joined by reacting the interfaces 11,12 or 21, the simulation system 100 to interfaces 31.
  • a connection of the process simulator 200 via a specially provided adapter 99 is also possible. This can be a program for the assignment and conversion of any process data. Also in this case is one
  • FIG. A simulation of the control system or parts thereof is now performed as follows:
  • the first execution environment 10 is created by means of a configu ⁇ approximately tool of the control system.
  • the second clearance 20 with all embedded software components such as 201, the Stellvertre ⁇ ter modules 211, 212 and interconnections is also generated by means of the planning tool used previously for the first plinUmpractic the control system.
  • the drain environments 10 and 20 come either separately or together to run, with a simulation of the technical system or parts of the technical system is performed.

Abstract

Die Erfindung betrifft ein Simulationssystem insbesondere für ein Leitsystem, welches einen in einer technischen Anlage ablaufenden Prozess (P) steuert, wobei das Leitsystem zumindest eine als Container ausgebildete erste AblaufUmgebung (10) umfasst, welche dazu ausgebildet ist, den der Anlage zugrunde liegenden Automatisierungsprozess nachzubilden und entsprechende Schnittstellen (11, 12, 13) zum Leitsystem aufweist. Das Simulationssystem (100a) umfasst neben der ersten Ablaufumgebung (10) erfindungsgemäß eine als Container ausgebildete zweite AblaufUmgebung (20) für die Simulation der Hardware der Peripherie des Leitsystems. In einer weiteren Ausführungsvariante (100b) des Simulationssystems können die beiden AblaufUmgebungen (10, 20) auch zu einer einzigen Ablaufumgebung (15) zusammengefasst sein. In beiden Varianten sind die Schnittstellen (11, 12, 13) der ersten AblaufUmgebung (10) nahezu identisch zu den Schnittstellen (21, 22, 23) der zweiten AblaufUmgebung (20). Die Erfindung betrifft ferner ein Verfahren zur Durchführung einer Simulation mittels des erfindungsgemäßen Simulationssystems. Angegeben ist auch ein entsprechendes Leitsystem und Computerprogrammprodukt.

Description

Beschreibung
Simulationssystem, Verfahren zur Durchführung einer Simulation, Leitsystem und Computerprogrammprodukt
Die Erfindung betrifft ein Simulationssystem insbesondere für ein Leitsystem, welches einen in einer technischen Anlage ablaufenden Prozess steuert, wobei das Leitsystem zumindest ei¬ ne als Container ausgebildete erste AblaufUmgebung umfasst, welche dazu ausgebildet ist, den der Anlage zugrunde liegen¬ den 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 Warten- personal für den Betrieb des Kraftwerks zu schulen und um
Ausnahmesituationen und kritische Betriebszustände zu trai¬ nieren, welche beim tatsächlichen Betrieb des Kraftwerks auf¬ treten 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 Rech¬ ner nachzubilden, ist es erforderlich, sowohl den Verfahrens- technischen 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 ein- gesetzte 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 Si- mulationsrechner 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 Fig. 1A) : Simulatoren, bei denen das Bedien- und Beobachtungssystem des originalen Leitsystems verwendet wird, und Simulatoren, die auch das Bedien- und Be¬ obachtungssystem 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 ange- wendet, beispielsweise wenn das Bedien- und Beobachtungssys¬ tem nicht simulationsfähig ist weil z.B. keine Simulatorzeit¬ unterstü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 physikalische Prozess aufweisen, (vgl. auch Beschreibung von Fig. 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 Leitsys¬ tem, die aber in eine vom Leitsystem separate Software ge- schrieben 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 Leit- System 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) .
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 unabhängigen Pa- tentanspruchs gelöst. Vorteilhafte Ausgestaltungen sind je¬ weils in den abhängigen Patentansprüchen wiedergegeben.
Das erfindungsgemäße Simulationssystem umfasst in dieser Va¬ riante 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 AblaufUmge¬ bungen können auch zu einer einzigen AblaufUmgebung ver- schmelzen. 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 Leitsys- tems 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 ei¬ nes Kraftwerks benutzt werden, als auch in weiteren Instan- zen, um die Hardware zu simulieren. Die Simulation der gesamten Automatisierung und der Hardware der Peripherie des Leit¬ systems laufen hier vorteilhaft in einer Instanz ab. Dazu werden nur Erweiterungen in der Bausteinbibliothek um Simulationsbausteine für die Hardware der Peripherie des Leitsys- tems 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 gra¬ phischen Werkzeugen in Bausteintechnik genauso wie die Pro- jektierung der realen Anlage innerhalb des Leitsystems.
- Aufgrund der Verwendung gleicher Werkzeuge für Konfigurati¬ on 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 resultie- ren 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 be¬ zeichnet, das aus direkt auf einem Betriebssystem ausführba¬ rem Softwarecode besteht, und nach außen hin abgeschlossen ist, so dass Kommunikation zu anderen Softwarekomponenten nur über exakt definierte Schnittstellen zu anderen Softwarekom- ponenten erfolgt. Eine eingebettete (engl, „embedded") Soft¬ warekomponente ist eine Softwarekomponente, die in eine ande¬ re 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 zu¬ mindest eine Schnittstelle zu einer eingebetteten (embedded) Softwarekomponente und zumindest eine Schnittstelle zum Be¬ triebssystem aufweist und direkt auf dem Betriebssystem ablauffähig ist. Im Folgenden wird ein Container, der seiner- seits als Softwarekomponente ausgebildet ist und eine univer¬ sell einsetzbare AblaufUmgebung für eine oder mehrere einge¬ bettete Softwarekomponenten bildet, als „AblaufContainer" bezeichnet. Der AblaufContainer stellt demnach einerseits ein Koppelelement zwischen einer beliebigen eingebetteten Soft- warekomponente und dem Betriebssystem dar und ermöglicht den Ablauf der eingebetteten Softwarekomponente auf dem Rechner. Andererseits vermittelt und verwaltet er in seiner Eigen¬ schaft 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 verste¬ hen .
Die Erfindung wird nachfolgend anhand von in den Zeichnungen dargestellten Ausführungsbeispielen näher erläutert. Dabei zeigen
Fig. 1A ein Blockschaltbild einer möglichen Realisierung eines Leitsystems einer technischen Anlage mit sei¬ nen Hardwarekomponenten, SdT,
Fig. 1B eine schematische Darstellung der Steuersoftware eines beispielhaften Leitsystems, SdT,
Fig. 2 eine schematische Darstellung einer ersten Ausführungsvariante des erfindungsgemäßen Simulationssys¬ tems und
Fig. 3 eine schematische Darstellung einer zweiten Ausführungsvariante des erfindungsgemäßen Simulationssys¬ tems .
In Fig. 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 steuern¬ de 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 Bau¬ gruppen 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 Auto¬ matisierungsserver 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 Kommunikati- onsbus 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 be- liebige 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 Simulations¬ systeme gemäß dem Stand der Technik SdT meist derart ausge¬ führt, dass entweder ein sehr leistungsfähiger Rechner be- reitgestellt 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 ei¬ nen separaten Simulationsrechner SIM2 zugegriffen wird. Letz- tere Lösung kann auch durch zwei Rechner realisiert sein, beispielsweise durch einen Rechner SIMHW, welcher die Hardware des zugrunde liegenden Automatisierungsprozesses simu- liert, und durch einen Rechner SIMP, welcher den zugrunde liegenden Prozess simuliert.
In Fig. 1B ist eine mögliche Ausführungsvariante für die Softwarearchitektur eines beispielhaften Leitsystems, wie in Fig. 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 ei- ne Präsentationssoftware 51 zu nennen, welche eine Darstel¬ lung 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 be¬ zeichnet. Außerdem existieren zahlreiche Softwaremodule wie zum Beispiel 61, 62 und 63, welche zum Beispiel für das Engi¬ neering 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 ablau- fen, 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 ausgebil¬ det 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 Schnitt¬ stelle 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 Ablaufum- gebung. Außerdem können Schnittstellen für die Diagnose, für bestimmte Meldungen oder die Bedienung vorhanden sein. Innerhalb des AblaufContainers 10 sind in Fig. 1B eingebettete Softwarekomponenten 101 und 102 dargestellt. Diese weisen wiederum interne, standardisierte Schnittstellen, welche als Punkte dargestellt sind auf. Die eingebetteten Softwarekompo¬ nenten 101 und 102 enthalten Hauptfunktionen wie sämtliche Automatisierungsaufgaben, Steuerungen, Regelungen, Berechnungen, Verarbeitungsfunktionen, Alarmverwaltung und Ausfüh- rungsverwaltung .
Ferner sind innerhalb des AblaufContainers 10 so genannte Stellvertretermodule 111 und 112 dargestellt. Die Stellver¬ tretermodule repräsentieren im Wesentlichen vorhandene Hard- warekomponenten wie beispielsweise eine Eingabe- oder Ausga¬ bebaugruppe. Deren Software ist hier durch 81 und 82 verdeut¬ licht. 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 Stellvertre¬ termodule 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 Auto- matisierungsbus 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 ein¬ gebetteten Softwarekomponenten 101, 102 und Stellvertretermodule 111 und 112, die über ihre internen Schnittstellen der- art verschaltet sind, dass der gesamte Automatisierungspro- zess implementiert ist.
In den Figuren 2 und 3 sind Ausführungsvarianten des erfin- dungsgemäßen Simulationssystems dargestellt. Es handelt sich dabei jeweils um eine Softwarearchitektur, welche direkt mit der in Fig. 1B gezeigten Architektur vereinbar ist und an diese anschließt. So umfasst in Fig. 2 das erfindungsgemäße Simulationssystem 100a in diesem ersten Ausführungsbeispiel neben der in Fig. 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 Fig. 1A anschließt. Dies können bei¬ spielsweise Baugruppen sein, andere Busanschlussmodule, in- telligente Feldgeräte wie Aktoren (Stelleantriebe, Motorsteu¬ ergeräte) und Sensoren oder auch Kommunikationsbausteine zu Fremdsystemen. Die Softwarekomponente 201 simuliert z.B. das Verhalten eines Stellantriebs mit Befehlen in Richtung Aufoder Zu-Richtung und entsprechenden Rückmeldungen oder das Verhalten des Einschubs der Schaltanlage für einen Motor ei¬ ner verfahrenstechnischen Komponente. Die Softwarebausteine 201, 211, 212 besitzen dazu jeweils interne Schnittstellen (engl, „internal interfaces") über welche zum Beispiel physi¬ kalische Größen oder sonstige Daten und Parameter ausge- tauscht 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 Verkabe- lungsvariante 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 Stellver- tretermodulen 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 Eingangsrohda- ten 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 zu¬ stä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 ausgebil- det 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 wei¬ tere Schnittstelle 24 vorhanden sein, welche den Anschluss an den Prozess erlaubt. Über diese Schnittstelle 24 können Pro¬ zessdaten übermittelt werden, die von einem Prozesssimulator, i.e. einem nur für den technischen Prozess zuständigen Simu- lationsrechner, übermittelt werden.
Erfindungsgemäß sind die Schnittstellen 11, 12, 13 der ersten (für die Automatisierung des Leitsystems zuständigen) Ablauf- Umgebung 10 nahezu identisch zu den Schnittstellen 21, 22, 23 der zweiten (für die Hardware der Peripherie zuständige) Ab¬ laufumgebung 20. Dies bedeutet, dass die Kommunikation der beiden Container 10 und 20 über die gleiche (n) Schnittstel- le (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 Fig. 3 darge¬ stellt ist, sind die beiden AblaufUmgebungen 10 und 20 zu ei¬ ner 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 Softwarekompo¬ nenten und Stellvertreter-Module der einzelnen Softwarekompo¬ nenten 1 und 2 kommen nun in einer AblaufUmgebung 15 zur Ausführung. Zuvor containerübergreifende Verbindungen oder Ver- Schaltungen 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 zwi- sehen 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äß Fig. 2 aus zwei AblaufUmgebungen für die Automatisierung und Hardware der Pe- ripherie des Leitsystems ausgebildet ist (Variante 100a) oder beide Funktionen in einer AblaufUmgebung ausgeführt werden gemäß Fig. 3 (Variante 100b) existieren unterschiedliche Mög¬ lichkeiten zur Anbindung von Prozessdaten. Diese können bei- spielsweise einem Prozesssimulator 200 entnommen werden.
Gemäß Fig. 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 Schnitt¬ stelle 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 ange¬ schlossen werden. In einer weiteren Ausführungsvariante gemäß Fig. 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 be- liebiger Prozessdaten handeln. Auch in diesem Fall ist ein
Anschluss an den Simulator 100b über eine eigens dafür vorge¬ sehene Schnittstelle 24 oder durch Umsetzung von Schnittstel¬ len 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 Projektie¬ rungswerkzeugs des Leitsystems erzeugt.
- Die zweite AblaufUmgebung 20 mit sämtlichen eingebetteten Softwarekomponenten wie beispielsweise 201, den Stellvertre¬ ter-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 än¬ dern .
- 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.

Claims

Patentansprüche
1. Simulationssystem (100a) insbesondere für ein Leitsystem, welches einen in einer technischen Anlage ablaufenden Prozess (P) steuert,
wobei das Leitsystem zumindest eine als Container ausgebilde¬ te erste AblaufUmgebung (10) umfasst, welche dazu ausgebildet ist, den der Anlage zugrunde liegenden Automatisierungspro- zess nachzubilden und entsprechende Schnittstellen (11, 12, 13) zum Leitsystem aufweist,
dadurch gekennzeichnet,
dass das Simulationssystem (100a) neben der ersten Ablaufumgebung (10) zumindest eine zweite als Container ausgebildete AblaufUmgebung (20) umfasst,
welche dazu ausgebildet ist, die Hardware der Peripherie des Leitsystems mit seinen Verschaltungen nachzubilden und die Schnittstellen (21, 22, 23) zum Leitsystem und zumindest eine weitere optionale Schnittstelle (24) über welche Prozessdaten übermittelbar sind, aufweist, und
dass die Schnittstellen (11, 12, 13) der ersten Ablaufumge¬ bung (10) nahezu identisch zu den Schnittstellen (21, 22, 23) der zweiten AblaufUmgebung (20) sind.
2. Simulationssystem (100a) nach Anspruch 1,
dadurch gekennzeichnet,
dass die AblaufUmgebungen (10, 20) selbst Softwarekomponenten (1, 2) darstellen.
3. Simulationssystem (100a) nach Anspruch 1 oder 2,
dadurch gekennzeichnet,
dass eine Kommunikation zwischen der ersten AblaufUmgebung (10) oder der ersten Softwarekomponente (1) und der zweiten AblaufUmgebung (20) oder der zweiten Softwarekomponente (2) über Busschnittstellen (18, 28) erfolgt.
4. Simulationssystem (100b) nach Anspruch 1,
dadurch gekennzeichnet, dass die erste AblaufUmgebung (10) und die zweite Ablaufumge¬ bung (20) zu einer einzigen AblaufUmgebung (15) zusammenge- fasst sind.
5. Simulationssystem (100b) nach Anspruch 4,
dadurch gekennzeichnet,
dass die AblaufUmgebung (15) selbst eine Softwarekomponente (15') darstellt.
6. Simulationssystem (100a, 100b) nach einem der Ansprüche 1 bis 5 ,
dadurch gekennzeichnet,
dass die AblaufUmgebungen (10, 20, 15) oder die Softwarekomponenten (1, 2, 15') eingebettete Softwarekomponenten (101, 102, 201) und Stellvertreter-Module (111, 112, 211, 212) um¬ fassen, welche entsprechend einer Funktion miteinander verschaltet sind, und dass bei Aufruf dieser Funktion die Soft¬ warekomponenten und Stellvertreter-Module zum Ablauf kommen.
7. Simulationssystem (100a, 100b) nach Anspruch 6,
dadurch gekennzeichnet,
dass die zweite AblaufUmgebung (20) eingebettete Softwarekom¬ ponenten (201) und Stellvertreter-Module (211, 212) für Bau¬ gruppen und Geräte einschließlich deren Vernetzung bzw. Ver- kabelung in der Peripherie des Leitsystems umfasst.
8. Simulationssystem (100a, 100b) nach Anspruch 7,
dadurch gekennzeichnet,
dass die Schnittstellen der Stellvertreter-Module (211, 212) der zweiten AblaufUmgebung (20) derart ausgebildet sind, dass sie die Schnittstellen der Ein- und Ausgänge der Drahtkonnek- toren des Leitsystems nachbilden.
9. Simulationssystem (100a, 100b) nach Anspruch 7 oder 8, dadurch gekennzeichnet,
dass die Stellvertreter-Module (211, 212) der zweiten Ablauf¬ umgebung (20) invers zu Stellvertreter-Modulen der ersten Ab- laufumgebung (10) ausgebildet sind, wobei Ein- Und Ausgänge der Schnittstellen vertauscht werden.
10. Simulationssystem (100a, 100b) nach Anspruch 7 bis 9, dadurch gekennzeichnet,
dass den Stellvertreter-Modulen (211, 212) der zweiten Ablaufumgebung (20) sowohl reale Prozessgrößen als auch vorgegebene oder simulierte Größen zugeführt werden.
11. Simulationssystem (100a, 100b) nach einem der Ansprüche 1 bis 10,
dadurch gekennzeichnet,
dass das Simulationssystem (100a, 100b) mit einem Prozesssi¬ mulator (200) verbunden ist.
12. Simulationssystem (100a, 100b) nach Anspruch 11,
dadurch gekennzeichnet,
dass der Prozesssimulator (200) durch Umsetzung der Schnittstellen (11,12, 21, 22) des Simulationssystems (100a, 100b) auf Schnittstellen (31, 32) des Prozesssimulators (200) ange¬ schlossen ist.
13. Simulationssystem (100a, 100b) nach Anspruch 11,
dadurch gekennzeichnet,
dass der Prozesssimulator (200) über einen Adapter (99) angeschlossen ist, wobei die Schnittstellen (11,12, 21, 22) des Simulationssystems (100a, 100b) auf Schnittstellen des Adap¬ ters (99) umgesetzt werden.
14. Verfahren zur Durchführung einer Simulation mittels eines Simulationssystems (100a, 100b) gemäß einem der Ansprüche 1 bis 13,
dadurch gekennzeichnet,
- dass die erste AblaufUmgebung (10) mittels eines Projektie- rungswerkzeugs des Leitsystems erzeugt wird,
- dass die zweite AblaufUmgebung (20) mit ihren eingebetteten Softwarekomponenten (201), Stellvertreter-Modulen (211, 212) und Verschaltungen ebenfalls mittels des zuvor für die erste AblaufUmgebung verwendeten Projektierungswerkzeugs des Leit¬ systems erzeugt wird,
- dass die AblaufUmgebung (10), welche dazu ausgebildet ist, den der Anlage zugrunde liegenden Automatisierungsprozess mit seinen Verschaltungen nachzubilden, in einen Simulationsmode versetzt wird ohne die bestehende Projektierung zu ändern,
- und dass anschließend in den AblaufUmgebungen (10, 20) die Simulation der technischen Anlage oder von Teilen der technischen Anlage durchgeführt wird.
15. Verfahren nach Anspruch 14,
dadurch gekennzeichnet,
dass die Projektierung von Hardware mit Verkabelung bzw. Vernetzung der zweiten AblaufUmgebung (20) aus der Hardwarepro- jektierung der Anlage automatisch erzeugt wird.
16. Leitsystem, welches einen in einer technischen Anlage ablaufenden Prozess (P) steuert,
dadurch gekennzeichnet,
dass ein Simulationssystem (100a, 100b) gemäß einem der Ansprüche 1 bis 13 umfasst ist und zur Simulation ein Verfahren gemäß einem der Ansprüche 14 oder 15 zum Ablauf kommt.
17. Leitsystem nach Anspruch 16,
dadurch gekennzeichnet,
dass das Simulationssystem (100a, 100b) mit den gleichen Projektierungswerkzeugen konfiguriert wird, wie andere Teile des Leitsystems .
18. Leitsystem nach Anspruch 16 oder 17,
dadurch gekennzeichnet,
dass das Simulationssystem (100a, 100b) graphisch in Bausteintechnik projektiert wird.
19. Computerprogrammprodukt, das in den Speicher eines Compu¬ ters geladen wird und Softwarecodeabschnitte umfasst, mit de¬ nen ein Verfahren gemäß einem der Ansprüche 14 oder 15 ausgeführt wird, wenn das Produkt auf einem Computer läuft.
PCT/EP2012/060556 2011-06-09 2012-06-05 Simulationssystem, verfahren zur durchführung einer simulation, leitsystem und computerprogrammprodukt WO2012168214A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201280028224.2A CN103597414A (zh) 2011-06-09 2012-06-05 仿真系统、用于执行仿真的方法、控制系统和计算机程序产品
US14/123,966 US20140172402A1 (en) 2011-06-09 2012-06-05 Simulation system, method for carrying out a simulation, guidance system, and computer program product
EP12726415.8A EP2718773A1 (de) 2011-06-09 2012-06-05 Simulationssystem, verfahren zur durchführung einer simulation, leitsystem und computerprogrammprodukt

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102011077318.5A DE102011077318B4 (de) 2011-06-09 2011-06-09 Simulationssystem, Verfahren zur Durchführung einer Simulation, Leitsystem und Computerprogrammprodukt
DE102011077318.5 2011-06-09

Publications (1)

Publication Number Publication Date
WO2012168214A1 true WO2012168214A1 (de) 2012-12-13

Family

ID=46229478

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2012/060556 WO2012168214A1 (de) 2011-06-09 2012-06-05 Simulationssystem, verfahren zur durchführung einer simulation, leitsystem und computerprogrammprodukt

Country Status (5)

Country Link
US (1) US20140172402A1 (de)
EP (1) EP2718773A1 (de)
CN (1) CN103597414A (de)
DE (1) DE102011077318B4 (de)
WO (1) WO2012168214A1 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011077317B4 (de) * 2011-06-09 2015-10-01 Siemens Aktiengesellschaft Simulationssystem, Verfahren zur Durchführung einer Simulation, Leitsystem und Computerprogrammprodukt
DE102014219711A1 (de) * 2014-09-29 2016-03-31 Siemens Aktiengesellschaft Verfahren zur Kraftwerkssimulation
CN109932925B (zh) * 2017-12-15 2021-12-10 北京机电工程研究所 多侦察点仿真方法
US11501036B2 (en) 2018-03-28 2022-11-15 Abb Schweiz Ag Simulations in a model of a process control system
EP3671378A1 (de) * 2018-12-17 2020-06-24 Siemens Aktiengesellschaft Datencontainer für ein steuersystem einer technischen anlage
CN111142405B (zh) * 2019-12-20 2022-12-09 国家工业信息安全发展研究中心 污水处理过程控制系统仿真测试平台
CN111163486B (zh) * 2019-12-24 2022-04-15 重庆邮电大学 一种d2d通信仿真与性能测试系统与方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10347078A1 (de) * 2002-10-10 2004-04-22 Mitsubishi Heavy Industries, Ltd. Simulations-Verifikationsverfahren für eine Steuerlogik und Simulations-Verifikations-Personal-Computer
EP1857896A1 (de) * 2006-05-16 2007-11-21 Ansaldo Energia S.P.A. Emulator einer Steuerung einer industriellen Anlage
EP1933214A2 (de) * 2006-12-15 2008-06-18 Robert Bosch Gmbh Automatisierte Erstellung und Adaption eines Maschinen- oder Anlagenmodells
US20090089031A1 (en) * 2007-09-28 2009-04-02 Rockwell Automation Technologies, Inc. Integrated simulation of controllers and devices
US20090132060A1 (en) * 2007-11-21 2009-05-21 Winston Jenks Foundation fieldbus simulation system

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3903403A (en) * 1973-02-23 1975-09-02 Westinghouse Electric Corp Nuclear power plant training simulator system and method
JP2007536634A (ja) * 2004-05-04 2007-12-13 フィッシャー−ローズマウント・システムズ・インコーポレーテッド プロセス制御システムのためのサービス指向型アーキテクチャ
CN100399341C (zh) * 2006-03-31 2008-07-02 电子科技大学 一种矢量模式软硬件协同仿真/验证方法
US8527252B2 (en) * 2006-07-28 2013-09-03 Emerson Process Management Power & Water Solutions, Inc. Real-time synchronized control and simulation within a process plant
DE102006045503A1 (de) * 2006-09-27 2008-04-03 Abb Technology Ag System und Verfahren zur Integration von Prozessleitsystemen in eine Trainingssimulation
US8825462B2 (en) * 2008-09-17 2014-09-02 Accenture Global Services Limited Method and system for simulating a plurality of devices
CN101604146B (zh) * 2009-07-15 2011-05-04 中冶南方工程技术有限公司 高炉供料自动控制系统的控制方法
US8316313B2 (en) * 2009-10-14 2012-11-20 Fisher-Rosemount Systems, Inc. Method for selecting shapes in a graphical display
DE102009055810A1 (de) * 2009-11-13 2011-05-19 Technische Universität Ilmenau Verfahren zur Simulation und Automatisierung eines komplexen Betriebsführungsprozesses

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10347078A1 (de) * 2002-10-10 2004-04-22 Mitsubishi Heavy Industries, Ltd. Simulations-Verifikationsverfahren für eine Steuerlogik und Simulations-Verifikations-Personal-Computer
EP1857896A1 (de) * 2006-05-16 2007-11-21 Ansaldo Energia S.P.A. Emulator einer Steuerung einer industriellen Anlage
EP1933214A2 (de) * 2006-12-15 2008-06-18 Robert Bosch Gmbh Automatisierte Erstellung und Adaption eines Maschinen- oder Anlagenmodells
US20090089031A1 (en) * 2007-09-28 2009-04-02 Rockwell Automation Technologies, Inc. Integrated simulation of controllers and devices
US20090132060A1 (en) * 2007-11-21 2009-05-21 Winston Jenks Foundation fieldbus simulation system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
THORSTEN GARRELS ET AL: "A Generic Approach for the Simulation of Distributed Control Systems using J2EE Technology", INDUSTRIAL INFORMATICS, 2007 5TH IEEE INTERNATIONAL CONFERENCE ON, IEEE, PI, 1 July 2007 (2007-07-01), pages 805 - 810, XP031161891, ISBN: 978-1-4244-0850-4 *

Also Published As

Publication number Publication date
US20140172402A1 (en) 2014-06-19
DE102011077318B4 (de) 2015-07-16
DE102011077318A1 (de) 2012-12-13
EP2718773A1 (de) 2014-04-16
CN103597414A (zh) 2014-02-19

Similar Documents

Publication Publication Date Title
DE102011077319B4 (de) Simulationssystem, Verfahren zur Durchführung einer Simulation, Leitsystem und Computerprogrammprodukt
EP2801873B1 (de) Testeinrichtung zum Test eines virtuellen Steuergeräts
DE102011077318B4 (de) Simulationssystem, Verfahren zur Durchführung einer Simulation, Leitsystem und Computerprogrammprodukt
EP2685382B1 (de) Verfahren und Vorrichtung zum Erstellen und Testen eines Steuergeräteprogramms
EP1738236B1 (de) Automatisierungsnetzwerk mit zustandsmeldenden netzwerkkomponenten
DE102010062266A1 (de) Verfahren zur Realisierung von zumindest einer Zusatzfunktion eines Feldgeräts in der Automatisierungstechnik
WO1997012301A1 (de) Entwurfsverfahren für die anlagentechnik und rechnergestütztes projektierungssystem zur verwendung bei diesem verfahren
WO2005054965A1 (de) Verfahren zur bereitstellung und installation von gerätespezifischen funktionalitäten und/oder informationen für die feldgeräte eines verteilten systems
EP1664954A1 (de) Bereitstellung von diagnoseinformationen
EP3079028A1 (de) Planungs- und engineering-verfahren, -software-tool und simulationswerkzeug für eine automatisierungslösung
EP1431877A2 (de) Parametrier-/Diagnosesystem für Feldgeräte
DE102008026409A1 (de) Bedienungstrainingsystem und Bedienungstrainingverfahren
DE102011077317B4 (de) Simulationssystem, Verfahren zur Durchführung einer Simulation, Leitsystem und Computerprogrammprodukt
EP2985663A1 (de) Verfahren zur Simulation einer automatisierten industriellen Anlage
DE102014101321A1 (de) Testeinrichtung zum Test eines virtuellen Steuergeräts
DE19725915A1 (de) Rechnergestützte Diagnoseeinrichtung und Diagnoseverfahren für elektronisch gesteuerte Systeme
DE102007063291A1 (de) Sicherheitssteuerung
EP2247989B1 (de) Vorrichtung und verfahren zum projektieren von feldgeräten einer technischen anlage
EP2672660B1 (de) Verfahren zur Beeinflussung der Buskommunikation eines Steuergeräts
EP2557464A1 (de) Verfahren zum Betrieb eines Automatisierungssystems
EP2048587A1 (de) Vorrichtung und Verfahren zur Planung einer Produktionsanlage
EP3470939A1 (de) Verfahren und vorrichtungen zum überwachen der sicherheitsintegrität einer durch ein sicherheitssystem bereitgestellten sicherheitsfunktion
WO2015124320A1 (de) Dynamisches speicherprogrammierbares steuergerät zum emulieren eines steuergerätes
DE10394242T5 (de) Verfahren und Instrument zur Zuweisung von Rechenressourcen in einem verteilten Steuersystem
DE102006015207A1 (de) Verfahren und Vorrichtung zur Entwicklung eines Systems für die Betriebsdiagnostik von Fahrzeugen

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12726415

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
REEP Request for entry into the european phase

Ref document number: 2012726415

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2012726415

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 14123966

Country of ref document: US