WO2012168215A1 - 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
WO2012168215A1
WO2012168215A1 PCT/EP2012/060558 EP2012060558W WO2012168215A1 WO 2012168215 A1 WO2012168215 A1 WO 2012168215A1 EP 2012060558 W EP2012060558 W EP 2012060558W WO 2012168215 A1 WO2012168215 A1 WO 2012168215A1
Authority
WO
WIPO (PCT)
Prior art keywords
simulation
control system
environment
interfaces
simulation system
Prior art date
Application number
PCT/EP2012/060558
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 US14/123,976 priority Critical patent/US10198536B2/en
Priority to CN201280028176.7A priority patent/CN103608735B/zh
Priority to EP12726416.6A priority patent/EP2718774A1/de
Publication of WO2012168215A1 publication Critical patent/WO2012168215A1/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
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]

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, for the simulation of the hardware of the periphery of the control system and for the simulation of processes occurring in the technical installation process. All run environments have the same interfaces and are connected to the bus system via them. The run environments can also merge into a single runtime environment. In addition, each run environment itself can be a software component. Within the flow Conversely ⁇ environments and software components embedded software components exist as representative of functions, modules, devices and computational models or other computing units of the process.
  • the inventive simulation system automation function itself, the simulation of the hardware of the periphery of the control system and the simulation of the technical rule ⁇ system underlying process be integrated into the software of the control system.
  • this runtime environment can now be used in both the normal control system in real-time for automation, for example, a power plant, as well as in white ⁇ direct instances to automation, hardware and Simulate process.
  • the simulation of the entire automation, the hardware of the periphery of the control system as well as the process simulation run here advantageously in one instance. For this purpose, only extensions in the block library to simulation blocks for the hardware of Periphe ⁇ line of the control system and, if necessary, process simulation modules for the process are needed.
  • control system and the simulator merge into one unit in terms of software and thus also in terms of computer technology, which entails 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. This resultie ⁇ ren less downtime in the operation of a technical installation, shortening and improvement in the start-up and improved quality of the simulation because consistency throughout the simulator solution exists 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 a univer ⁇ sell usable runtime environment for forming one or more inserted ⁇ embedded software components, referred to as "flow container”.
  • the flow container is, therefore, a one part, Coupling element between any embedded software component and the operating system and allows the flow of the embedded software component to the computer.
  • a software component it also conveys and manages the communication between the embedded software components and other software components outside the container via external means
  • Interfaces Under Instance in this context is the specific use of a type of a software component in the system to verste ⁇ hen.
  • 1A is a block diagram of a possible implementation of a control system of a technical system with its 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 technical equipment may be de lying process to act 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 intelligent field devices.
  • the modules EA1, EA2 to EAN are connected through on the side remote from the process side with an external or internal bus system BS, which collects the signals and forwards for example, at least one car ⁇ mattechnischsserver 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 via the user interface GUI of the control system instead of on the automation server AUTS on a 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, 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 technology has been reduced in this embodiment to a few components in order to ensure a better overview:
  • a presentation software 51 which allows a presentation ⁇ different screens. This could be, for example, a web browser running on a thin client.
  • the execution environment is be distinguished ⁇ with 50th
  • 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 the resource management. All these software modules therefore fulfill different functions. They can run in their own expiration 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. It is a flow container 10, ie a container, which in turn is latestbil ⁇ det as software component 1 and a universally applicable SeaUm consultancy for one or more embedded software components 101, 102, 111 and 112 forms.
  • the workflow container 10 manages and executes all existing automation functions, including the processing functions.
  • the flow container 10 has multiple interfaces. In the following, an interface will always be a data interface meant. This may ⁇ point 13 act for the engineering or near the interfaces 11 and 12, which are connected to the rest of the control environment including with other instances of a situated beneath-, for example, a section. There may also be interfaces for diagnostics, for certain messages or for operation.
  • 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 execution management.
  • proxy modules 111 and 112 are shown within the dormitorContainer.
  • the deputy ⁇ representative module representing existing hardware components essentially as described, for example, an input or expenditure bebaueria. 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 for this connection. This interface of theticianContainers 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 repeater modules 111 and 112 inside the outflow container 10 communicate with the input and output modules (and intelligent field devices) which are located outside the automation server (and thus outside of the outflow container 10).
  • the car ⁇ matmaschinesbus may ever acting on the model, for example to a Profibus, Modbus one, another serial bus or an Ethernet-based bus (such as Profinet or a pure TCP / IP or UDP based communication).
  • a Profibus Modbus one
  • an Ethernet-based bus such as Profinet or a pure TCP / IP or UDP based communication.
  • the software component 1 During operation of the control system it is the end of the software component 1 and thus also the course of 1 a ⁇ bedded software components 101, 102 and Stellvertretermo ⁇ modules 111 and 112, the DER about their internal interfaces are connected art that the entire Automatmaschinespro- zess is implemented.
  • the simulation system 300a comprises, in addition to the flow environment 10 for the automation function described in FIG. 1B, a further flow environment 20, which simulates the hardware of the periphery of the control system with all its interconnections in software and a process simulator here as Drain environment 30 designed.
  • proxy modules 211 and 212 are embedded, which represent the Leitsystemperipherie, for example, connects directly to the bus system of Fig. 1A.
  • This may for example be assemblies, other bus modules, intelligent field devices such as actuators (point drives, Mo ⁇ tor Strukturtechnik) and sensors or Lichtunikationsbau ⁇ stones to external systems.
  • 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 of a process component.
  • the software modules 201, 211, 212 each have internal
  • Interfaces (English, "internal interfaces") about which to Example physical variables or other data and parameters can be exchanged ⁇ ter.
  • the connecting lines between the individual blocks and interfaces represent this signal exchange, which takes place in the real plant, for example via existing cables / wires in the control system or by data transmission in fieldbus systems. (Depending on the wiring or wiring variant, it is also possible to include terminal points, for example, as a distributor or repeater in the case of fieldbus.) These components are not shown in the diagram for the sake of simplicity)
  • the substitute modules 211 and 212 are configured inversely to substitute modules 111 and 112. With inverse is meant here that inputs and outputs of jeweili ⁇ gen interfaces are interchanged.
  • a Stellvertre ⁇ termodul of the type such as 111 and 112 in the rule for the Anbin- the input raw dung to / from the process control interface provides a substitute module of the type such as 211 and 212 simulated already an assembly and thus for the conversion of the Field Data responsible for the input raw data for higher-level software modules.
  • the entire drain environment 20 can now be designed as a flow container or as a software component 2 in accordance with the container definition described above.
  • external interfaces English, "external interfaces" of a certain number, such as 21, 22 and 23, exist which communicate
  • the interface 23 like the interface 13 of the first automation environment 10 responsible for the filling of the container, 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 serial bus systems with master - slave functionality).
  • a tere interface 24 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 process simulator here consists of theticianUméclairage 30, which simulates the process underlying the technical system in software.
  • the technical system underlying process may be a physi ⁇ , chemical, biological or other technical process.
  • the process simulator is constructed, for example as a separate runtime environment 30 and / or as a separate soft ware ⁇ Component 3.
  • the software architecture of the process simulator would thus be consistent with the architecture of the flow environments 10 and 20 and the software components 1 and 2 and facilitate integration into the control system.
  • Analog would contain the process simulator in this case, a plurality of embedded software components such as 71, 72 and 73, which represent for example a physi ⁇ ULTRASONIC model of the technical installation.
  • Software components 71, 72 and 73 could also include other computation modules.
  • a power plant of the basic process is the production of energy by combustion examples play of pulverized coal under supply of air at Ent ⁇ stehung of flue gas. Further, steam is generated and brought to un ⁇ ter Kunststoffliche temperatures to a turbine ⁇ drive, which is used for the generation of electric power.
  • the simulation of each of these process steps for example, housed in software components who ⁇ .
  • the material streams and process signals would then be transmitted via the interfaces.
  • the connecting lines drawn in dashed lines between the individual components 71, 72 and 73 and the interfaces 31 and 32 represent the exchange of process signals and, in contrast to the solid lines, are not wire connectors.
  • Interfaces 21, 22, 23 of the complicatUm profession 20 almost identical to the interfaces 33, 32, 33 of theticianUm profession 30. This means that the communication of the containers 10, 20 and 30 runs on the same interface, which leads to Leit ⁇ system.
  • the interfaces 11, 12, 13, 21, 22 and 23 are functionally and physically the same as the interfaces 31, 32 and 33. Minor changes to accommodate certain constraints may be possible.
  • the drain environment 10 can, for example, as shown in FIG. 2, be connected to the drain environment 20 via special interfaces such as the connection of the bus interface 18 to the interface 28 or by the implementation of interfaces via a connection between the interfaces 11 and 12 with the interfaces 21 and 22 be connected.
  • the person responsible for the process simulator execution environment 30 may also be connected to the body responsible for the simulation of the hardware peripheral flow ⁇ environment 20 directly via various interfaces.
  • the process simulator of the hardware simulator can also be a specially provided for this purpose interface imagine ⁇ 30 via a specially provided for this purpose interfaces le 33 24 are connected.
  • the process simulator 30 can provide on average ⁇ 31 and 32 of the process simulator are connected by implementation of the interfaces 21 and 22 of the hardware simulator.
  • a second embodiment 300b of the Invention ⁇ proper simulation system, which is shown in Fig. 3, the execution environments 10, 20 and 30 are combined into a single runtime environment 35th Automation, hardware and process simulation run in one instance.
  • Embedded software components and proxy modules of the individual ⁇ nen software components 1, 2 and 3 are now in a runtime environment 35 for execution.
  • the flow environment 35 itself represents a software component 35 '.
  • cross-container connections or interconnections between the embedded components and modules from previously 10, 20 and 30 now become container-internal connections or interconnections.
  • external interfaces now become internal (in the container included) interfaces or can be completely omitted.
  • the connecting lines drawn in dashed lines represent the exchange of process signals and, in contrast to the solid lines, represent no wire connectors.
  • the simulation system 300b now consists of only one drain environment. At least the interfaces 11 and 12 are now available for communication with the control system. In addition, here is another interface 13 is available, which allows the filling of Contai ⁇ ners with engineering data from the bus system 90.
  • the first execution environment 10 is created by means of a configu ⁇ approximately tool of the control system.
  • the drain environments 20 and 30 are either separately or together executed, with a simulation of the technical plant or parts of the technical plant 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 (300a) umfasst erfindungsgemäß neben der ersten AblaufUmgebung (10) eine als Container ausgebildete zweite AblaufUmgebung (20) für die Simulation der Hardware der Peripherie des Leitsystems und eine als Container ausgebildete dritte AblaufUmgebung (30) für die Simulation des der technischen Anlage zu Grunde liegenden Prozesses. In einer weiteren Ausführungsvariante (300b) des Simulationssystems können alle AblaufUmgebungen auch zu einer einzigen Ablaufumgebung (35) zusammengefasst sein. In beiden Varianten sind die Schnittstellen (11, 12, 13) der ersten AblaufUmgebung (10) und die Schnittstellen (21, 22, 23) der zweiten Ablaufumgebung (20) nahezu identisch zu den Schnittstellen (31, 32, 33) der dritten AblaufUmgebung (30). 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, für die Si- mulation 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 AblaufUmge¬ bungen und Softwarekomponenten existieren eingebettete Soft- warekomponenten 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 techni¬ schen Anlage zu Grunde liegenden Prozesses in die Software des Leitsystems eingebunden. In einem Leitsystem, welches eine universell einsetzbare AblaufUmgebung für Softwarekompo¬ nenten besitzt, kann diese AblaufUmgebung nun sowohl im normalen Leitsystem in Echtzeit für die Automatisierung beispielsweise eines Kraftwerks benutzt werden, als auch in wei¬ teren 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 Periphe¬ rie des Leitsystems und gegebenenfalls Prozesssimulationsbau- steine 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 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ön- nen 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 Softwarekomponente und dem Betriebssystem dar und ermöglicht den Ablauf der eingebetteten Softwarekomponente auf den Rechner. Andererseits vermittelt und verwaltet er in seiner Eigen- schaff 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 Grun- de 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 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, welches 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. Letztere 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 eine 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 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 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 Ablaufumge- bung. 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ührungsverwaltung .
Ferner sind innerhalb des AblaufContainers 10 so genannte Stellvertretermodule 111 und 112 dargestellt. Die Stellver¬ tretermodule repräsentieren im Wesentlichen vorhandene Hardwarekomponenten 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 Businter- face 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 Stellvertretermo¬ dule 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 erfindungsgemäß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 besteht das erfindungsgemäße Simulati¬ onssystem in dem in Fig. 2 dargestellten Ausführungsbeispiel 300a aus drei AblaufUmgebungen . In dem in Fig. 3 dargestell- ten Ausführungsbeispiel 300b sind alle AblaufUmgebungen zu einer einzigen AblaufUmgebung zusammengefasst und das Simula¬ tionssystem 300b umfasst hier nur diese eine AblaufUmgebung .
So umfasst in Fig. 2 das erfindungsgemäße Simulationssystem 300a 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 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 Fig. 1A anschließt. Dies können beispielsweise Baugruppen sein, andere Busanschlussmodule, intelligente Feldgeräte wie Aktoren (Stelleantriebe, Mo¬ torsteuergeräte) und Sensoren oder auch Kommunikationsbau¬ steine 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 Parame¬ ter 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 Verdrah- tungs- 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 jeweili¬ gen Schnittstellen vertauscht sind. Während ein Stellvertre¬ termodul des Typs wie 111 und 112 in der Regel für die Anbin- dung 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 inter- faces") 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 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.
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 physikali¬ schen, chemischen, biologischen oder sonstigen technischen Prozess handeln. In Fig. 2 ist der Prozesssimulator beispielhaft als eigene AblaufUmgebung 30 und/oder als eigene Soft¬ warekomponente 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 physikali¬ sches 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 bei- spielsweise von Kohlestaub unter Zuführung von Luft bei Ent¬ stehung von Rauchgas. Ferner wird Dampf erzeugt und auf un¬ terschiedliche Temperaturen gebracht, um eine Turbine anzu¬ treiben, welche für die Erzeugung von elektrischem Strom eingesetzt wird. Die Simulation jeder dieser Prozessschritte kann beispielsweise in Softwarekomponenten untergebracht wer¬ den. 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äsen- tieren den Austausch von Prozesssignalen und stellen im Gegensatz zu den durchgezogenen Linien keine Drahtkonnektoren dar . Erfindungsgemäß sind die Schnittstellen 11, 12, 13 der Auto¬ matisierungsfunktion 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 Leit¬ system 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 beispiels- weise wie in Fig. 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 wer- den. 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 Ablauf¬ umgebung 20 angeschlossen werden. Zum Einen kann der Prozesssimulator 30 über eine extra hierfür vorgesehene Schnittstel- le 33 mit einer ebenfalls extra hierfür vorgesehenen Schnitt¬ stelle 24 des Hardwaresimulators angeschlossen werden. Zum Anderen kann der Prozesssimulator 30 durch Umsetzung der Schnittstellen 21 und 22 des Hardwaresimulators auf Schnitt¬ stellen 31 und 32 des Prozesssimulators angeschlossen werden.
In einer zweiten Ausführungsvariante 300b für das erfindungs¬ gemäße Simulationssystem, welche in Fig. 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 einzel¬ nen Softwarekomponenten 1, 2 und 3 kommen nun in einer Ablaufumgebung 35 zur Ausführung. Außerdem kann die neu gebil- dete 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 containerinter- nen 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 Contai¬ ners 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 Projektie¬ rungswerkzeugs des Leitsystems erzeugt.
- Die zweite und dritte AblaufUmgebung 20 und 30 mit sämtli¬ chen eingebetteten Softwarekomponenten wie beispielsweise 201, den Stellvertreter-Modulen 211, 212 und Verschaltungen werden ebenfalls mittels des zuvor für die erste Ablaufumge¬ bung verwendeten Projektierungswerkzeugs des Leitsystems er¬ zeugt. Module vom Typ 211, 212 können sogar automatisch generiert werden.
- Die AblaufUmgebung 10 oder Teile davon, welche dazu ausge¬ bildet ist, den der Anlage zugrunde liegenden Automatisie- rungsprozess mit seinen Verschaltungen nachzubilden, kommen zur Ausführung und steuern so die Anlage.
- Unabhängig vom Geschehen in der realen Anlage kommen paral- lel 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.

Claims

Patentansprüche
1. Simulationssystem (300a) insbesondere für ein Leitsystem, welches einen in einer technischen Anlage ablaufenden physi- kaiischen 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 (300a, 300b) neben der ersten Ablaufumgebung (10)
eine zweite als Container ausgebildete AblaufUmgebung (20) umfasst, welche dazu ausgebildet ist, die Hardware der Peri¬ pherie des Leitsystems mit seinen Verschaltungen nachzubilden und die Schnittstellen (21, 22, 23) zum Leitsystem aufweist, und
eine dritte als Container ausgebildete AblaufUmgebung (30) umfasst, welche dazu ausgebildet ist, den der Anlage zugrunde liegenden physikalischen Prozess (P) zu simulieren,
wobei die Schnittstellen (11, 12, 13) der ersten Ablaufumge¬ bung (10) nahezu identisch zu den Schnittstellen (21, 22, 23) der zweiten AblaufUmgebung (20) und nahezu identisch zu den Schnittstellen (31, 32, 33) der dritten AblaufUmgebung (30) sind .
2. Simulationssystem (300b) nach Anspruch 1,
dadurch gekennzeichnet,
dass die erste AblaufUmgebung (10), die zweite AblaufUmgebung (20) und die dritte AblaufUmgebung (30) zu einer einzigen Ablaufumgebung (35) zusammengefasst sind.
3. Simulationssystem (300a) nach Anspruch 1,
dadurch gekennzeichnet,
dass die AblaufUmgebungen (10, 20, 30) selbst Softwarekompo¬ nenten (1, 2, 3) darstellen.
4. Simulationssystem (300b) nach Anspruch 2,
dadurch gekennzeichnet,
dass die AblaufUmgebung (35) selbst eine Softwarekomponente (35') darstellt.
5. Simulationssystem (300a) nach Anspruch 1 oder 3,
dadurch gekennzeichnet,
dass eine Kommunikation zwischen der ersten AblaufUmgebung (10) oder der Softwarekomponente (1) und der zweiten Ablauf- Umgebung (20) oder der Softwarekomponente (2) über Bus¬ schnittstellen (18, 28) erfolgt.
6. Simulationssystem (300a, 300b) nach einem der Ansprüche 1 bis 5 ,
dadurch gekennzeichnet,
dass die AblaufUmgebungen (10, 20) oder die Softwarekomponenten (1, 2) eingebettete Softwarekomponenten (101, 102, 201) und Stellvertreter-Module (111, 112, 211, 212) umfassen, wel¬ che entsprechend einer Funktion miteinander verschaltet sind, und dass bei Aufruf dieser Funktion die Softwarekomponenten und Stellvertreter-Module zum Ablauf kommen.
7. Simulationssystem (300a, 300b) 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. Verkabelung in der Peripherie des Leitsystems umfasst.
8. Simulationssystem (300a, 300b) 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 (300a, 300b) nach Anspruch 6 bis 8, dadurch gekennzeichnet, dass die Stellvertreter-Module (211, 212) der zweiten Ablauf¬ umgebung (20) invers zu Stellvertreter-Modulen der ersten Ablaufumgebung (10) ausgebildet sind, wobei Ein- und Ausgänge der Schnittstellen vertauscht werden.
10. Simulationssystem (300a, 300b) nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass den Stellvertreter-Modulen (211, 212) der zweiten Ab- laufumgebung (20) sowohl reale Prozessgrößen als auch vorgegebene oder simulierte Größen zugeführt werden können.
11. Simulationssystem (300a, 300b) nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass die dritte AblaufUmgebung (30) eingebettete Softwarekom¬ ponenten (71, 72, 73) enthält, durch welche ein physikali¬ sches Modell der technischen Anlage realisiert ist.
12. Verfahren zur Durchführung einer Simulation mittels eines Simulationssystems gemäß einem der Ansprüche 1 bis 11, 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 dritte AblaufUmgebung (30) mittels eines Projek¬ tierungswerkzeugs des Leitsystems erzeugt und konfiguriert 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, 30) die Simulation der technischen Anlage oder von Teilen der technischen Anlage durchgeführt wird.
13. Verfahren nach Anspruch 12,
dadurch gekennzeichnet,
dass die Projektierung von Hardware der zweiten Ablaufumge¬ bung (20) aus der Hardwareprojektierung der Anlage automatisch erzeugt wird.
14. Leitsystem, welches einen in einer technischen Anlage ablaufenden physikalischen Prozess (P) steuert,
dadurch gekennzeichnet,
dass ein Simulationssystem (300a, 300b) gemäß einem der Ansprüche 1 bis 11 umfasst ist und zur Simulation ein Verfahren gemäß einem der Ansprüche 12 oder 14 zum Ablauf kommt.
15. Leitsystem nach Anspruch 14,
dadurch gekennzeichnet,
dass das Simulationssystem (300a, 300b) mit den gleichen Pro- j ektierungswerkzeugen konfiguriert wird, wie andere Teile des Leitsystems .
16. Leitsystem nach Anspruch 15 oder 16,
dadurch gekennzeichnet,
dass das Simulationssystem (300a, 300b) graphisch in Bausteintechnik projektiert wird.
17. Computerprogrammprodukt, das in den Speicher eines Compu¬ ters geladen wird und Softwarecodeabschnitte umfasst, mit de- nen ein Verfahren gemäß einem der Ansprüche 11 oder 12 ausgeführt wird, wenn das Produkt auf einem Computer läuft.
PCT/EP2012/060558 2011-06-09 2012-06-05 Simulationssystem, verfahren zur durchführung einer simulation, leitsystem und computerprogrammprodukt WO2012168215A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US14/123,976 US10198536B2 (en) 2011-06-09 2012-06-05 Simulation system, method for carrying out a simulation, control system, and computer program product
CN201280028176.7A CN103608735B (zh) 2011-06-09 2012-06-05 仿真系统、用于执行仿真的方法、控制系统和计算机程序产品
EP12726416.6A EP2718774A1 (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
DE102011077319.3A DE102011077319B4 (de) 2011-06-09 2011-06-09 Simulationssystem, Verfahren zur Durchführung einer Simulation, Leitsystem und Computerprogrammprodukt
DE102011077319.3 2011-06-09

Publications (1)

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

Family

ID=46229479

Family Applications (1)

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

Country Status (5)

Country Link
US (1) US10198536B2 (de)
EP (1) EP2718774A1 (de)
CN (1) CN103608735B (de)
DE (1) DE102011077319B4 (de)
WO (1) WO2012168215A1 (de)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011077319B4 (de) 2011-06-09 2015-08-06 Siemens Aktiengesellschaft Simulationssystem, Verfahren zur Durchführung einer Simulation, Leitsystem und Computerprogrammprodukt
DE102011077317B4 (de) * 2011-06-09 2015-10-01 Siemens Aktiengesellschaft Simulationssystem, Verfahren zur Durchführung einer Simulation, Leitsystem und Computerprogrammprodukt
JP6563187B2 (ja) * 2014-11-12 2019-08-21 株式会社東芝 分散制御システム、制御装置及び制御方法
EP3048598A1 (de) * 2015-01-21 2016-07-27 Siemens Aktiengesellschaft Industrielles System, Schulungssystem und Verfahren zum Schulen eines Anlagenfahrers
EP3144758A1 (de) * 2015-09-18 2017-03-22 Siemens Aktiengesellschaft Steuerungssystem sowie verfahren zum betrieb eines steuerungssystems mit einer realen und einer virtuellen steuerung
EP3151217A1 (de) * 2015-10-02 2017-04-05 Siemens Aktiengesellschaft Operator-training-system
DE102018211142A1 (de) * 2018-07-05 2020-01-09 Baumüller Nürnberg GmbH Verfahren zur Konfiguration einer Anlage
EP4086717A1 (de) 2021-05-03 2022-11-09 Siemens Aktiengesellschaft Herstellungsverfahren für eine operator training station, leitsystem, automatisierte anlage und computerprogrammprodukt
CN114035450A (zh) * 2021-11-11 2022-02-11 北京工业大学 一种面向mswi过程的多入多出回路控制半实物仿真实验平台

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 (12)

* 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 フィッシャー−ローズマウント・システムズ・インコーポレーテッド プロセス制御システムのためのサービス指向型アーキテクチャ
DE102004033593A1 (de) 2004-07-07 2006-02-02 Siemens Ag Verfahren zur Simulation einer technischen Anlage
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
WO2008047555A1 (fr) * 2006-09-27 2008-04-24 Fujitsu Ten Limited Dispositif de simulation, modèle de simulation et dispositif de formation de modèle de simulation
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
DE102009030842A1 (de) 2009-06-26 2010-12-30 Siemens Aktiengesellschaft Emulation eines Automatisierungssystems
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
DE102011077319B4 (de) 2011-06-09 2015-08-06 Siemens Aktiengesellschaft Simulationssystem, Verfahren zur Durchführung einer Simulation, Leitsystem und Computerprogrammprodukt
US9529348B2 (en) * 2012-01-24 2016-12-27 Emerson Process Management Power & Water Solutions, Inc. Method and apparatus for deploying industrial plant simulators using cloud computing technologies

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
US20140172403A1 (en) 2014-06-19
US10198536B2 (en) 2019-02-05
DE102011077319B4 (de) 2015-08-06
DE102011077319A1 (de) 2012-12-13
CN103608735A (zh) 2014-02-26
EP2718774A1 (de) 2014-04-16
CN103608735B (zh) 2019-09-13

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
EP0852759B1 (de) Entwurfsverfahren für die anlagentechnik und rechnergestütztes projektierungssystem zur verwendung bei diesem verfahren
EP2685382B1 (de) Verfahren und Vorrichtung zum Erstellen und Testen eines Steuergeräteprogramms
DE102011077318B4 (de) Simulationssystem, Verfahren zur Durchführung einer Simulation, Leitsystem und Computerprogrammprodukt
DE10021698A1 (de) Auf einem einzelnen Computer realisierte integrierende Funktionalität für ein verteiltes Prozessregelsystem
DE102009059865A1 (de) Integriertes Testsystem und Verfahren zur Bewertung eines Fertigungsautomatisierungssystems
EP1906377A1 (de) System und Verfahren zur Integration eines Prozessleitsystems in einen Trainingssimulator
WO2005036290A1 (de) Bereitstellung von diagnoseinformationen
EP3650970B1 (de) Verfahren und vorrichtung zum computergestützten simulieren eines modularen technischen systems
DE102011077317B4 (de) Simulationssystem, Verfahren zur Durchführung einer Simulation, Leitsystem und Computerprogrammprodukt
DE102008026409A1 (de) Bedienungstrainingsystem und Bedienungstrainingverfahren
EP1286322A1 (de) Simulationssystem, inbesondere für eine Kraftwerksanlage
EP2985663A1 (de) Verfahren zur Simulation einer automatisierten industriellen Anlage
EP3931653A1 (de) Verfahren zum engineering und simulation eines automatisierungssystems mittels digitaler zwillinge
EP2247989B1 (de) Vorrichtung und verfahren zum projektieren von feldgeräten einer technischen anlage
EP1866715B1 (de) Entwurfsvorrichtung zum entwerfen einer leittechnischen anlage und verfahren zum überprüfen der technologischen aufgabenstellung beim entwurf einer leittechnischen anlage
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
EP3696621A1 (de) Computerimplementiertes verfahren und vorrichtung zum steuern eines modularen technischen systems
LU500646B1 (de) Technik zur Bereitstellung einer Diagnosefunktionalität für eine auf einer speicherprogrammierbaren Steuerung basierenden Anwendung
EP2862075B1 (de) Simulieren eines komplexen systems
DE102021123596A1 (de) Technik zur Bereitstellung einer Diagnosefunktionalität für eine auf einer speicherprogrammierbaren Steuerung basierenden Anwendung
WO2014146686A1 (de) Werkzeug und verfahren zur simulation einer technischen anlage
DE102021119116A1 (de) Technik zur Realisierung einer Visualisierung für eine automatisierungstechnische Anlage mit einer speicherprogrammierbaren Steuerung

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: 12726416

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: 2012726416

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2012726416

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: 14123976

Country of ref document: US