WO2012175120A1 - Verfahren zum überprüfen des zu erwartenden zusammenwirkens zumindest zweier geräte sowie vorrichtung - Google Patents

Verfahren zum überprüfen des zu erwartenden zusammenwirkens zumindest zweier geräte sowie vorrichtung Download PDF

Info

Publication number
WO2012175120A1
WO2012175120A1 PCT/EP2011/060410 EP2011060410W WO2012175120A1 WO 2012175120 A1 WO2012175120 A1 WO 2012175120A1 EP 2011060410 W EP2011060410 W EP 2011060410W WO 2012175120 A1 WO2012175120 A1 WO 2012175120A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication
devices
network
virtual
time
Prior art date
Application number
PCT/EP2011/060410
Other languages
English (en)
French (fr)
Inventor
Michael Engel
Cornelia KREBS
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 PCT/EP2011/060410 priority Critical patent/WO2012175120A1/de
Publication of WO2012175120A1 publication Critical patent/WO2012175120A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/14—Arrangements for monitoring or testing data switching networks using software, i.e. software packages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40169—Flexible bus arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/4026—Bus for use in automation systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H04L41/122—Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]

Definitions

  • the invention relates to a method for checking the expected interaction of at least two devices, which are connected via a network of a fieldbus system.
  • the invention also relates to a device for checking the expected interaction of at least two devices.
  • Knipshimsten Real, simplified, rebuilt peripherals (so-called Knipshimsten) are also used and are used to simulate the real behavior of a production plant. Complex system behavior is presented using simulation ⁇ systems (z. B. Matlab, SIMIT) and real communication interfaces (z. B. SIMBApro card) transferred to a field bus manufacturing plant (z. B. ProfiBus) to simulate peripherals.
  • the controllers must have the final communication connections (eg ProfiBus DP, Ethernet, etc.) and must be equipped with signals and telephones. legrammen the periphery are supplied in the correct time.
  • the inventive method is used to check the expected interaction of at least two devices which are connected via a network of a fieldbus system. It includes the following steps:
  • Network of the field bus system nachgebil ⁇ det at least partially;
  • a virtual device is preferably associated, which at least partially ⁇ simulates the functions of the real device. It can also be provided virtual devices that do not correspond to real devices.
  • the network service can be provided in particular in the form of program code and simulate the network of the fieldbus system. Allocated to the virtual device program code modules can then in particular on the network service cooperate so that arises in the context of the simulation, a combination of the at least two virtual devices via the network service, which ei ⁇ ner real linkage of at least two assigned real devices in the field bus system corresponds. Initiating the grain Communication can be done by starting the executable program code. By the end of the simulation, the network behavior may in particular be observed, and nachvoll ⁇ be subjected, so that the interaction of the at least two devices can be checked in the process.
  • the at least two virtual devices are preferably provided in a network with the at least one computing device.
  • the network can be a real network, for example an office network or a network in the sense of cloud computing technology, between several computing devices.
  • the term "network” should also be understood to mean the internal electrical connection of a single computing device, in particular as part of an inter-process communication.
  • the communication on this network then preferably runs according to a first communication protocol.
  • This Gay ⁇ nikationsprotokoll is particularly specific to the network ⁇ plant with the at least one computing device.
  • the communi- cation can log particular regard to the jeweili ⁇ ge network structure such.
  • B. take a linear or star-shaped network structure.
  • This first communication protocol is preferably different from a second communications pro ⁇ protocol, according to which is done the communication of the devices in the network of the fieldbus system.
  • Field bus level can use different protocols (eg, in addition to ProfiBus and ProfiNet also CAN bus and others).
  • protocols eg, in addition to ProfiBus and ProfiNet also CAN bus and others.
  • the network of the field bus system in which the communication according to the second communication protocol expires and the network with the at least one computing device on which the communication according to the first communications pro ⁇ protocol expires.
  • the characteristic behavior of can be a net zes reproduced on the other network and realistically simu ⁇ lines.
  • the network service is adapted to transform Kiru ⁇ munication according to the first communication protocol in communi ⁇ cation according to the second communication protocol to transfor ⁇ mieren and / or communication according to the second communications protocol in communications according to the first Kommunikati ⁇ onsprotokoll.
  • the virtual devices can then act as if they were present in the network of the fieldbus system, because the network service ensures compatibility with the network with the at least one computing device.
  • the first communication protocol is based on an Ethernet protocol
  • the second communication protocol ⁇ additionally or alternatively based on PROFIBUS DP or PROFINET.
  • It can be used pa ⁇ rallel several fieldbus systems.
  • communication can be simulated on a real network on which the communication usually takes place in accordance with the Ethernet standard, which is usual at the field level.
  • a fieldbus system can be simulated within a LAN network. The development of a production and manufacturing plant is then particularly easy, since this can not be done at the field level but on development computers at the office level. Cost and effort can be kept very low.
  • the method is further characterized in that the at least two virtual devices provide and / or receive data according to the first communication protocol, and each of the at least two virtual devices is assigned in each case an adapter service, which in accordance with the first communication protocol received data in data the second communication protocol and / or according to the second communication protocol received data converted into data according to the first communication protocol.
  • each virtual device can be assigned an adapter service that is specific and adapted to this virtual device.
  • the adapter service can be used in particular in the form of program code. be provided.
  • the adapter service can be part of the network ⁇ factory service. The adapter service even Besse ⁇ re insertion of virtual devices is possible in the network simulation, especially if additional virtual devices are added to an existing virtual network with sol ⁇ len without the program code of the actual network service to be adjusted.
  • communication between elements of the at least one computing device proceeds according to a first time scheme
  • communication between the at least two devices of the fieldbus system proceeds according to a second time scheme different from the first time scheme.
  • a synchronization service is provided which is adapted to communicate according to the first time scheme in communication according to the second time scheme between the at least two virtual devices and / or communication according to the second time scheme in communication according to the first time scheme between the at least two virtual To convert devices.
  • This embodiment is particularly advantageous if the second time schedule satisfies real-time requirements and the first time scheme does not satisfy real-time requirements.
  • the synchronization service then ensures that real-time capability is ensured within the framework of the simulation of the behavior of the real devices in the field network. This is of particular importance if the network with the at least one computing device is an office network which is usually not real-time capable. Then can be simulated on an infrastructure by means of the synchro ⁇ tion service real-time, which usually is not real-time capable.
  • the synchronization service is adapted to at least one of the at least two virtual devices th towards ⁇ clearly the flow of program code assigned to rigid and / or stop. In this way, in particular the real-time capability of the individual virtual devices can be ensured.
  • the synchronization service is designed to generate and / or modify data regarding time information in a data packet. The synchronization service can add this time information to the data packets, in particular in the form of time stamps. Then the data packets running in the network are equipped with time information and it is particularly easy to simulate the time behavior on the field network.
  • An inventive device is used for checking the expected interaction of at least two devices, wel ⁇ surface are connected via a network of a field bus system.
  • the device comprises at least one computing device is adapted to the least partially mimic at least two devices with respect to their technical functionality as virtual devices Wenig ⁇ replicate the network of the field bus system at least partially and to cause at least two vir ⁇ tual devices to communicate with each other ,
  • the device also includes a test device for checking the expected interaction of the at least two devices based on the communication.
  • FIG. 1 shows a schematic representation of a fieldbus system
  • 2 shows a schematic representation of a Patientsnetzsys ⁇ tems
  • 3 shows a schematic representation of a virtual system with a plurality of virtual devices, between which the communication is mediated by means of a synchronization and network services
  • 4 shows a schematic representation of aticiansbei ⁇ game with virtual devices on different
  • 5A is a diagram showing a first connection
  • 5B is a diagram showing a second relationship
  • a field bus such. As Profibus DP, Profibus Net etc.
  • communication field at the field level for the commu nication between ⁇ distributed peripheral devices and controls in general.
  • 1 shows a sol ⁇ Ches fieldbus system 4 with a field bus 2 to which a plurality of real devices la to lf are connected.
  • the apparatus la is in the exemplary embodiment is an Achs Kunststoffge ⁇ advises on the devices lc to different versions of a motion controller.
  • the apparatus lb are for example a machine tool control, in which device ld a HMI (operating unit), in which device le is a network ⁇ network device for connecting other system components, and in which device lf a PLC (Programmable Logic Controller).
  • HMI operating unit
  • PLC Programmable Logic Controller
  • the office network 5 comprising a bureau network 3 in a development department is independent of the field bus 2 and the communication running on it usually builds on an Ethernet protocol. If the planned peripherals and controllers in the fieldbus system 4 are virtualized and run on the developer computers, the communication on the fieldbus 2 in the developer network, that is to say in the office network 3, can be reproduced. It will therefore become the re- All devices la to lf corresponding virtual devices la 'to lf provided, which are in the form of program code in computers of the office network system 5.
  • the Feldkommu- is munication on the office communication network or the office network system 5 of the development department at the interface of these virtual devices ⁇ len la 'to lf transformed and diverted to a synchronization and network service fourteenth
  • the field communication is virtualized and can be monitored and adapted in the synchronization and network service 14. This is shown schematically in FIG.
  • ei ⁇ ne Profibus DP (eg. As the Profibus telegrams to ensure cyclic data exchange between the device lc and the device la) may be on a real Ethernet communication
  • a virtual network service 15 in synchronization and network ⁇ service 14 Data packed and customized.
  • Various communication protocols are made possible by virtue of the fact that, with virtual transmitters and receivers, that is to say the respective virtual devices la 'to lf, upstream or downstream of transformers 13 which convert the actual signal or data into Ethernet communication.
  • the virtual network service 15 distributes the signals and data. If necessary, a conversion of the communication protocols is carried out.
  • Real controls and devices such. As the devices la to lf are synchronized in systems to each other. To conduct controls and respond accurately to events, a timing of communication is established to ensure real-time behavior. For example, as part of the Profibus DP protocol, a device as a time master vorgese ⁇ hen, which sends a synchronization message periodically.
  • time incoming signals and messages 15 are buffered and then processed in a virtual tour ⁇ len network service.
  • a more complex possibility is that the virtual machine performs a rollback and returns to the time back ⁇ to which it is to be synchronized. It is thus possible to simulate differently fast time sequences in the various virtual devices 1a 'to lf and to buffer and forward relevant time signals in the virtual network service 15.
  • FIG. 3 shows a virtual system 6.
  • the synchronization and network service 14 is embedded in the virtual plant 6. It has the task of ensuring communication between different virtual devices. Specifically, these are a virtual controller 7, a simulation 8, another virtual machine 9, a vir tual ⁇ actuator 10, a virtual axis 11, and a virtuel ⁇ ler sensor 12.
  • the transformers 13 link the virtuel- len devices 7 to 12 each with the synchronization and
  • Network service 14 These transformers 13 ensure in addition that the communication of the virtual devices 7 to 12 for synchronization and network service 14 is übertra ⁇ gene by pack respective output data into transport packets and unpack such transport packets for generating input data.
  • the synchronization and network service 14 consists of two main components, namely the network service 15 and the synchronous chronisationsdienst 16.
  • the network service 15 of the virtual devices 7 to 12 are pa ⁇ kete analyzed and transfor ⁇ mized, ie for the respective receiver adapted (for example with regard to Ethernet addresses, ProfiBus ports etc.).
  • the data telegrams are logged (logging), changed or supplemented.
  • block 17 represents the process of transformation
  • block 18 comprises signal and message monitoring, modification and simulation.
  • the synchronization service 16 takes over the generation of a time signal (possibly via the control of a time master) and starts and stops the virtual devices 7 to 12.
  • the block 19 for the control of the time master, the block 20 for starting and stopping the virtualized devices and the block 21 for the simulation of Netzverhal ⁇ least.
  • the synchronization and network service 14 can be configured via an engineering HMI 23.
  • the network configuration and, on the other, the rules for time synchronization are parameterized.
  • the engineering HMI 23 is also used to observe, change and supplement communication data.
  • Block 22 stands for the communication and Synchronisationskonfigu ⁇ ration and observing, modify and complete communication data.
  • Darge 14 provides ⁇ .
  • a production plant afrossteu be ⁇ er réelle Simotion P and an axis control Sinamics CU projective advantage. These are inserted into a productive system ⁇ to.
  • the motion controller Simotion and Sinamics Motion Control CU communicate the real system (ie in the field ⁇ bus system 4) via Profibus DP.
  • a virtualized Sinamics CU in the form of the virtual device la 'and the virtual device lc' with Simotion P are used
  • the simulation environment with the virtual device ld '(SIMIT) can be adopted.
  • Ethernet card can be used.
  • the communication of the Si ⁇ mulation is realized with PROFINET CBA.
  • the various communication protocols are shown in FIG. 4 at the respective network paths and designated by ETH (Ethernet), PN (Profinet) and PB (ProfiBus).
  • ETH Ethernet
  • PN Profilet
  • PB ProfileBus
  • the telegrams of the controllers and the data of the simulation are packaged in Ethernet packets.
  • the synchronization and network ⁇ factory service 14 to the network service 15 transforms the ProfiNet signals PN of the SIMIT simulation (virtual device ld ') and, depending on the parameterization, feeds them into cyclic or acyclic communication of the ProfiBus PB of the Simotion P control (virtual device lc').
  • the communication between Simotion P (virtual device lc ') and Virtual Sinamics (virtual device la') is not directly possible in the virtualized environment.
  • the Profibus data traffic is transmitted via the synchronization and network service 14, thus simulating a coherent bus system.
  • the time synchronization is also explained on the basis of the virtual devices 1a '(Virtual Sinamics), 1c' (Simotion P) and 1d '(SIMIT) with reference to FIGS. 5A and 5B.
  • a virtual time vt against the real time t is carried on ⁇ .
  • the curves K1 here belong to the virtual device 1a ', the curves K2 to the virtual device 1c' and the curves K3 to the virtual device 1d '.
  • time varies.
  • the virtual device ld 'or the SIMIT simulation has a freely selectable but constantly predetermined simulation cycle.
  • the virtual device lc operates approximately four times slower than a real Simotion P in the ⁇ sem example, so that a clock cycle of 0.25 ms is calculated in a millisecond. It may be in a wait status ⁇ to where internally no time passes.
  • the virtual device la reacts in real time to the cyclically incoming setpoint telegrams and provides the answers with the actual values for the next cycle.
  • This virtual device la over the communication to the timing of the virtual device lc' is coupled and the times from the Te ⁇ legrammen must assume that prescribe the time synchronization for the virtual plant as valid times.
  • the time syn- synchronization in the synchronization service 16 guarantees the synchronization of all participating virtual devices la ', ld' and lc '.
  • the synchronization service 16 stops the virtual device 1c 'for the duration of one cycle as soon as it leads the virtual device ld' by one cycle duration. Even the virtual device la 'receives thereby later the next telegram.
  • the simulated field communication can be observed, modified and supplemented. This allows not only trace and debugging at the field level of communication and the Simula ⁇ tion of non-existing field devices to more complex plant components.
  • the synchronization service 16 also allows
  • the virtual devices must be able to be synchronized (ie it must be possible to stop or lag them) or be able to roll back. In this way it allows real-time behavior in the virtuel ⁇ len environment;
  • Transmission effects can be simu ⁇ lated.
  • any other fieldbus communication protocols can be used, such as: ARCNET, ARINC 629, BITBUS, ControlNet, CAN, CANopen, DALI, DeviceNet, EtherNet / IP, EIB, EtherCAT, Ethernet Powerlink, FAIS bus, Fieldbus Foundation, FIP bus, FlexRay bus, Hart Communication, Interbus, KNX standard, LCN Local Control Net ⁇ work, LIN bus, LON, MIL-STD-1553, Modbus, MOST bus, SafetyBUS p, SERCOS interface, SmallCAN, SMI standard motor interface, Space Wire, Time-Triggered Protocol (TTP ), BACnet Building Au ⁇ tomation and Control networks, VARAN or P-NET.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Small-Scale Networks (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Überprüfen des zu erwartenden Zusammenwirkens zumindest zweier Geräte (1a-1f), welche über ein Netzwerk (2) eines Feldbussystems (4) verbunden sind mit den Schritten: - Bereitstellen von Programmcode in zumindest einer Rechenvorrichtung (24), durch welchen die zumindest zwei Geräte (1a-1f) hinsichtlich ihrer technischen Funktionalität als virtuelle Geräte (1a'-1f', 7-12) wenigstens teilweise nachgebildet werden; - Bereitstellen eines Netzwerkdienstes (15), durch welchen das Netzwerk (2) des Feldbussystems (4) wenigstens teilweise nachgebildet wird; - Verknüpfen der zumindest zwei virtuellen Geräte (1a'-1f', 7-12) über den Netzwerkdienst (15); - Initiieren einer Kommunikation zwischen den zumindest zwei virtuellen Geräten (1a'-1f', 7-12) vermittels des Netzwerkdienstes (15); und - Überprüfen des zu erwartenden Zusammenwirkens der zumindest zwei Geräte (1a-1f) anhand der Kommunikation.

Description

Beschreibung
Verfahren zum Überprüfen des zu erwartenden Zusammenwirkens zumindest zweier Geräte sowie Vorrichtung
Die Erfindung betrifft ein Verfahren zum Überprüfen des zu erwartenden Zusammenwirkens zumindest zweier Geräte, welche über ein Netzwerk eines Feldbussystems verbunden sind. Die Erfindung betrifft auch eine Vorrichtung zur Überprüfung des zu erwartenden Zusammenwirkens zumindest zweier Geräte.
In Produktions- und Fertigungsanlagen werden verschiedenste Steuerungen, Antriebe, Sensoren und sonstige Peripheriegeräte verwendet. Hierbei werden die eingesetzten Steuerungen und die auf ihnen ablaufenden Steuerungsprogramme von der realen Anlage unabhängig, also zu einer anderen Zeit und an einem anderen Ort, entwickelt, aber im Zusammenspiel mit ihren Pe¬ ripheriegeräten getestet. Es verursacht einen unverhältnismä¬ ßig hohen Zeit- und Kostenaufwand, solche Tests erst in der realen Anlage durchzuführen. Deshalb ist es bekannt, so ge¬ nannte „Test Racks" aufzubauen, welche die reale Produktions¬ und Fertigungsanlage zu einem gewissen Grad nachbilden. Da in solchen „Test Racks" reale Kabel verlegt werden, ist die Nachbildung mit einem hohen Verkabelungsaufwand verbunden. Auch die zeitliche Abfolge von Signalen in der realen Anlage lässt sich in dem Test Rack nur sehr aufwändig oder gar nicht exakt simulieren.
Es finden auch reale, vereinfacht nachgebaute Peripheriegerä- te (sogenannte Knipskästen) Anwendung und werden zur Simulation des realen Verhaltens einer Fertigungsanlage verwendet. Komplexeres Anlagenverhalten wird mithilfe von Simulations¬ systemen (z. B. Matlab, SIMIT) dargestellt und über reale Kommunikationsschnittstellen (z. B. SimbaPro-Karte) auf einen Feldbus der Fertigungsanlage (z. B. ProfiBus) übertragen, um Peripheriegeräte zu simulieren. Die Steuerungen müssen über die endgültig vorgesehenen Kommunikationsverbindungen (z. B. ProfiBus DP, Ethernet etc.) verfügen und mit Signalen und Te- legrammen der Peripherie im korrekten Zeitmaß versorgt werden .
Es ist auch bekannt, Steuerungen und Peripheriegeräte in Per- sonalcomputern (PCs) und virtuellen Maschinen zu simulieren (sogenannte Virtualisierung) und über das reale Feldnetz zu verknüpfen. Solche virtuellen Geräte kommunizieren dann über reale Kommunikationswege, welche auch von den korrespondie¬ renden realen Geräten genutzt werden.
Es ist Aufgabe der Erfindung, ein Verfahren sowie eine Vorrichtung bereitzustellen, mit denen eine Produktions- und Fertigungsanlage einfacher entwickelt werden kann. Diese Aufgabe wird durch ein Verfahren, welches die Merkmale des Patentanspruchs 1 aufweist sowie eine Vorrichtung, welche die Merkmale des Patentanspruchs 10 aufweist, gelöst.
Das erfindungsgemäße Verfahren dient zum Überprüfen des zu erwartenden Zusammenwirkens zumindest zweier Geräte, welche über ein Netzwerk eines Feldbussystems verbunden sind. Es um- fasst die folgenden Schritte:
- Bereitstellen von Programmcode in zumindest einer Rechenvorrichtung, durch welchen die zumindest zwei Geräte hin- sichtlich ihrer technischen Funktionalität als virtuelle Geräte wenigstens teilweise nachgebildet werden;
- Bereitstellen eines Netzwerkdienstes, durch welchen das
Netzwerk des Feldbussystems wenigstens teilweise nachgebil¬ det wird;
- Verknüpfen der zumindest zwei virtuellen Geräte über den Netzwerkdienst ;
- Initiieren einer Kommunikation zwischen den zumindest zwei virtuellen Geräten vermittels des Netzwerkdienstes; und
- Überprüfen des zu erwartenden Zusammenwirkens der zumindest zwei Geräte anhand der Kommunikation.
Mittels des erfindungsgemäßen Verfahrens ist es möglich, so¬ wohl die in einer Produktions- und Fertigungsanlage vorlie- genden Geräte als auch das Netzwerk, über welches diese Gerä¬ te miteinander verbunden sind, vollständig virtualisiert be¬ reitzustellen. Insbesondere kann vorgesehen sein, den Netzwerkdienst und die virtuellen Geräte auf einer Mehrzahl von vernetzten Rechenvorrichtungen, insbesondere Rechenvorrichtungen in einem Büronetzwerk, Rechenvorrichtungen in einer Rechenanlage oder Rechenvorrichtungen, welche über eine Cloud Computing Infrastruktur miteinander verbunden sind, bereitzustellen. Es kann auch vorgesehen sein, den Netzwerkdienst und die virtuellen Geräte vollständig auf einer einzelnen Rechenvorrichtung, insbesondere im Rahmen einer Interprozesskommu- nikation, bereitzustellen. Das Zusammenspiel verschiedener Anlagenteile bzw. Geräte kann sehr einfach und unkompliziert getestet werden, wobei Änderungen in der so simulierten Pro- duktions- und Fertigungsanlage sehr leicht durchführbar und hinsichtlich ihrer Funktion sehr gut überprüfbar sind. Es wird ein virtuelles Netzwerk bereitgestellt, das sehr leicht neuen Vorgaben oder Bedingungen angepasst werden kann. Die Entwicklung einer Produktions- und Fertigungsanlage gestaltet sich sehr einfach und kostengünstig. Veränderungen sind unkompliziert implementierbar und können schnell und zuverläs¬ sig getestet werden. Auch die Simulation von nicht vorhande¬ nen Feldgeräten sowie komplexen Anlagenkomponenten ist möglich.
Jedem tatsächlich im Feldbussystem real vorhandenen Gerät ist vorzugsweise ein virtuelles Gerät zugeordnet, welches zumin¬ dest teilweise die Funktionen des realen Gerätes nachbildet. Es können auch virtuelle Geräte vorgesehen sein, denen keine realen Geräte entsprechen. Der Netzwerkdienst kann insbesondere in Form von Programmcode bereitgestellt werden und das Netzwerk des Feldbussystems simulieren. Die den virtuellen Geräten zugeordneten Programmcodebausteine können dann insbesondere über den Netzwerkdienst so zusammenwirken, dass sich im Rahmen der Simulation eine Verknüpfung der zumindest zwei virtuellen Geräte über den Netzwerkdienst ergibt, welche ei¬ ner realen Verknüpfung von zumindest zwei zugeordneten realen Geräten im Feldbussystem entspricht. Das Initiieren der Korn- munikation kann dadurch erfolgen, dass der ablauffähige Programmcode gestartet wird. Durch den Ablauf der Simulation kann insbesondere das Netzverhalten beobachtet und nachvoll¬ zogen werden, sodass sich das Zusammenwirken der zumindest zwei Geräte im Rahmen des Verfahrens überprüfen lässt.
Vorzugsweise werden im Rahmen des Verfahrens die zumindest zwei virtuellen Geräte in einem Netzwerk mit der zumindest einen Rechenvorrichtung bereitgestellt. Bei dem Netzwerk kann es sich insbesondere um ein reales Netzwerk, zum Beispiel ein Büronetzwerk oder ein Netzwerk im Sinne der Cloud Computing Technologie, zwischen mehreren Rechenvorrichtungen handeln. Unter Netzwerk soll jedoch auch die interne elektrische Ver- schaltung einer einzelnen Rechenvorrichtung zu verstehen sein, insbesondere im Rahmen einer Interprozesskommunikation . Die Kommunikation auf diesem Netzwerk läuft dann vorzugsweise gemäß einem ersten Kommunikationsprotokoll ab. Dieses Kommu¬ nikationsprotokoll ist insbesondere spezifisch für das Netz¬ werk mit der zumindest einen Rechenvorrichtung. Das Kommuni- kationsprotokoll kann insbesondere Rücksicht auf die jeweili¬ ge Netzstruktur, z. B. eine lineare oder sternförmige Netzstruktur, nehmen. Dieses erste Kommunikationsprotokoll ist vorzugsweise verschieden von einem zweiten Kommunikationspro¬ tokoll, gemäß welchem die Kommunikation der Geräte in dem Netzwerk des Feldbussystems erfolgt. Die Kommunikation auf
Feldbusebene kann verschieden Protokolle verwenden (z. B. neben ProfiBus und ProfiNet auch CAN-Bus und andere) . Es liegen dann zwei völlig verschiedene Netzarchitekturen vor: einerseits das Netzwerk des Feldbussystems, auf welchem die Kommu- nikation gemäß dem zweiten Kommunikationsprotokoll abläuft, und das Netzwerk mit der zumindest einen Rechenvorrichtung, auf dem die Kommunikation gemäß dem ersten Kommunikationspro¬ tokoll abläuft. Dennoch ist durch den Netzwerkdienst sicher¬ gestellt, dass das charakteristische Verhalten des einen Net- zes auf dem anderen Netz nachgebildet und realitätsnah simu¬ liert werden kann. Vorzugsweise ist der Netzwerkdienst dazu ausgebildet, Kommu¬ nikation gemäß dem ersten Kommunikationsprotokoll in Kommuni¬ kation gemäß dem zweiten Kommunikationsprotokoll zu transfor¬ mieren und/oder Kommunikation gemäß dem zweiten Kommunikati- onsprotokoll in Kommunikation gemäß dem ersten Kommunikati¬ onsprotokoll zu transformieren. Die virtuellen Geräte können dann so agieren, als lägen sie im Netzwerk des Feldbussystems vor, denn durch den Netzwerkdienst wird die Kompatibilität zu dem Netzwerk mit der zumindest einen Rechenvorrichtung si- chergestellt .
Vorzugsweise basiert das erste Kommunikationsprotokoll auf einem Ethernetprotokoll , während das zweite Kommunikations¬ protokoll zusätzlich oder alternativ auf ProfiBus DP oder ProfiNet basiert. Es können auch mehrere Feldbussysteme pa¬ rallel verwendet werden. Auf diese Art lässt sich auf einem realen Netzwerk, auf welchem die Kommunikation üblicherweise gemäß dem Ethernetstandart abläuft, Kommunikation nachbilden, welche auf der Feldebene üblich ist. Insbesondere kann ein Feldbussystem innerhalb eines LAN-Netzwerkes nachgebildet werden. Die Entwicklung einer Produktions- und Fertigungsanlage gestaltet sich dann besonders einfach, da diese nicht auf der Feldebene sondern auf Entwicklungsrechnern der Büroebene erfolgen kann. Kosten und Aufwand lassen sich so besonders gering halten.
Vorzugsweise ist das Verfahren ferner dadurch gekennzeichnet, dass die zumindest zwei virtuellen Geräte Daten gemäß dem ersten Kommunikationsprotokoll bereitstellen und/oder empfan- gen, und jedem der zumindest zwei virtuellen Geräte jeweils ein Adapterdienst zugeordnet ist, welcher gemäß dem ersten Kommunikationsprotokoll empfangene Daten in Daten gemäß dem zweiten Kommunikationsprotokoll und/oder gemäß dem zweiten Kommunikationsprotokoll empfangene Daten in Daten gemäß dem ersten Kommunikationsprotokoll umwandelt. Insbesondere kann jedem virtuellen Gerät ein für dieses virtuelle Gerät spezifischer und angepasster Adapterdienst zugeordnet werden. Der Adapterdienst kann insbesondere in Form von Programmcode be- reitgestellt werden. Der Adapterdienst kann Teil des Netz¬ werkdienstes sein. Mit dem Adapterdienst ist eine noch besse¬ re Einfügung virtueller Geräte in die Netzwerksimulation möglich, insbesondere dann, wenn zusätzliche virtuelle Geräte in ein bestehendes virtuelles Netzwerk mit eingefügt werden sol¬ len, ohne dass der Programmcode des eigentlichen Netzwerkdienstes angepasst werden soll.
Vorzugsweise läuft eine Kommunikation zwischen Elementen der zumindest einen Rechenvorrichtung gemäß einem ersten Zeitschema ab und eine Kommunikation zwischen den zumindest zwei Geräten des Feldbussystems gemäß einem vom ersten Zeitschema verschiedenen zweiten Zeitschema ab. Dann wird vorzugsweise ein Synchronisationsdienst bereitgestellt, welcher dazu aus- gebildet ist, Kommunikation gemäß dem ersten Zeitschema in Kommunikation gemäß dem zweiten Zeitschema zwischen den zumindest zwei virtuellen Geräten und/oder Kommunikation gemäß dem zweiten Zeitschema in Kommunikation gemäß dem ersten Zeitschema zwischen den zumindest zwei virtuellen Geräten um- zuwandeln. Besonders vorteilhaft ist diese Ausführungsform dann, wenn das zweite Zeitschema EchtZeitanforderungen genügt und das erste Zeitschema keinen EchtZeitanforderungen genügt. Dann wird durch den Synchronisationsdienst sichergestellt, dass im Rahmen der Simulation des Verhaltens der realen Gerä- te im Feldnetz Echtzeitfähigkeit gewährleistet ist. Dies ist von besonderer Bedeutung, wenn das Netzwerk mit der zumindest einen Rechenvorrichtung ein Büronetz ist, welches üblicherweise nicht echtzeitfähig ist. Dann kann mittels des Synchro¬ nisationsdienstes Echtzeit auf einer Infrastruktur simuliert werden, welche üblicherweise nicht echtzeitfähig ist.
Vorzugsweise ist der Synchronisationsdienst dazu ausgebildet, wenigstens eines der zumindest zwei virtuellen Geräte hin¬ sichtlich des Ablaufs von zugeordnetem Programmcode zu star- ten und/oder anzuhalten. Auf diese Art kann dann insbesondere die Echtzeitfähigkeit der einzelnen virtuellen Geräte sichergestellt werden. Vorzugsweise ist der Synchronisationsdienst dazu ausgebildet, Daten betreffend eine Zeitinformation in einem Datenpaket zu erzeugen und/oder zu verändern. Der Synchronisationsdienst kann diese Zeitinformation insbesondere in Form von Zeitstem- peln den Datenpaketen anfügen. Dann sind die im Netzwerk laufenden Datenpakete mit einer Zeitinformation ausgestattet und es kann besonders gut das Zeitverhalten auf dem Feldnetz nachgebildet werden. Eine erfindungsgemäße Vorrichtung dient zur Überprüfung des zu erwartenden Zusammenwirkens zumindest zweier Geräte, wel¬ che über ein Netzwerk eines Feldbussystems verbunden sind. Die Vorrichtung umfasst zumindest eine Rechenvorrichtung, die dazu ausgebildet ist, die zumindest zwei Geräte hinsichtlich ihrer technischen Funktionalität als virtuelle Geräte wenigs¬ tens teilweise nachzubilden, das Netzwerk des Feldbussystems wenigstens teilweise nachzubilden und die zumindest zwei vir¬ tuellen Geräte zu einer Kommunikation miteinander zu veranlassen. Die Vorrichtung umfasst auch eine Prüfeinrichtung zum Überprüfen des zu erwartenden Zusammenwirkens der zumindest zwei Geräte anhand der Kommunikation.
Die mit Bezug auf das erfindungsgemäße Verfahren dargestell¬ ten bevorzugten Ausführungsformen und deren Vorteile gelten entsprechend für die erfindungsgemäße Vorrichtung.
Anhand von Ausführungsbeispielen wird die Erfindung im Folgenden näher erläutert. Es zeigen: FIG 1 eine schematische Darstellung eines Feldbussystems;
FIG 2 eine schematische Darstellung eines Büronetzsys¬ tems ; FIG 3 eine schematische Darstellung einer virtuellen Anlage mit mehreren virtuellen Geräten, zwischen denen die Kommunikation mittels eines Synchronisati- ons- und Netzwerkservices vermittelt wird; FIG 4 eine schematische Darstellung eines Ausführungsbei¬ spiels mit virtuellen Geräten auf verschiedenen
PCs;
FIG 5A ein Diagramm, welches einen ersten Zusammenhang
zwischen einer virtuellen Zeit und einer realen
Zeit darstellt; und
FIG 5B ein Diagramm welches einen zweiten Zusammenhang
zwischen einer virtuellen Zeit und einer realen
Zeit darstellt.
In den Figuren sind gleiche oder funktionsgleiche Elemente mit den gleichen Bezugszeichen versehen.
In einer Produktionsanlage wird auf Feldebene für die Kommu¬ nikation zwischen dezentralen Peripheriegeräten und Steuerungen in der Regel ein Feldbussystem (z. B. ProfiBus DP, Profi- Net etc.) verwendet (Feldkommunikation) . FIG 1 zeigt ein sol¬ ches Feldbussystem 4 mit einem Feldbus 2 an welchem mehrere reale Geräte la bis lf angeschlossen sind. Bei dem Gerät la handelt es sich im Ausführungsbeispiel um ein Achssteuerge¬ rät, bei den Geräten lc um verschiedene Ausführungen einer Bewegungssteuerung. Bei dem Gerät lb handelt es sich beispielsweise um eine Werkzeugmaschinensteuerung, bei dem Gerät ld um ein HMI (Bediengerät) , bei dem Gerät le um ein Netz¬ werkgerät zum Anschluss weiterer Anlagenteile und bei dem Gerät lf um eine PLC (Speicherprogrammierbare Steuerung) .
Das ein Büronetz 3 umfassende Büronetzsystem 5 in einer Entwicklungsabteilung ist von dem Feldbus 2 unabhängig und die auf ihm ablaufende Kommunikation baut in der Regel auf einem Ethernetprotokoll auf. Sind die geplanten Peripheriegeräte und Steuerungen im Feldbussystem 4 virtualisiert projektiert und auf den Entwicklercomputern lauffähig, kann die Kommunikation auf dem Feldbus 2 im Entwicklernetzwerk, das heißt im Büronetz 3, nachgebildet werden. Es werden deshalb zu den re- alen Geräten la bis lf korrespondierende virtuelle Geräte la' bis lf bereitgestellt, welche in Form von Programmcode in Rechnern des Büronetzsystems 5 vorliegen. An den Schnittstel¬ len dieser virtuellen Geräte la' bis lf wird die Feldkommu- nikation auf das Bürokommunikationsnetzwerk bzw. das Büronetzsystem 5 der Entwicklungsabteilung transformiert und zu einem Synchronisations- und Netzwerkservice 14 umgeleitet. Dadurch wird die Feldkommunikation virtualisiert und kann in dem Synchronisations- und Netzwerkservice 14 überwacht und adaptiert werden. Dies ist schematisch in FIG 2 dargestellt.
Auf diese Art kann zum Beispiel auf einem realen Ethernet ei¬ ne ProfiBus DP Kommunikation (z. B. die ProfiBus Telegramme, die den zyklischen Datenaustausch zwischen dem Gerät lc und dem Gerät la gewährleisten) realisiert werden, indem ein virtueller Netzwerkdienst 15 im Synchronisations- und Netzwerk¬ service 14 Daten verpackt und anpasst. Es werden verschiedene Kommunikationsprotokolle ermöglicht, indem man bei virtuellen Sendern und Empfängern, also den jeweiligen virtuellen Gerä- ten la' bis lf , Transformatoren 13 nach- bzw. vorschaltet, die das eigentliche Signal bzw. Daten in Ethernetkommunikati- on umwandeln. Der virtuelle Netzwerkdienst 15 verteilt die Signale und Daten. Gegebenenfalls wird eine Konvertierung der Kommunikationsprotokolle vorgenommen .
Reale Steuerungen und Geräte, wie z. B. die Geräte la bis lf, sind in Anlagen zueinander synchronisiert. Um Regelungen durchzuführen und präzise auf Ereignisse zu reagieren, ist ein Zeittakt der Kommunikation festgelegt, so dass Echtzeit- verhalten gewährleistet wird. Beispielsweise ist im Rahmen des ProfiBus DP Protokolls ein Gerät als Zeitmaster vorgese¬ hen, das regelmäßig ein Synchronisationstelegramm versendet.
In einer Umgebung mit virtuellen Geräten la' bis lf ist es dagegen üblicherweise nicht möglich, die Systemzeiten von
Host-Systemen als Basis zu verwenden, da die virtuellen Geräte la' bis lf unterschiedlich schnell arbeiten und ggf. auf Betriebssystemen aufsetzen, welche nicht echtzeitfähig sind (z. B. Windows XP) . Dies ist auch im Büronetz 3 der Fall. Die virtuellen Geräte la' bis lf haben daher ihre eigene Zeit, die unabhängig von der Zeit ihres Host-Systems ist und bei jedem der Geräte la' bis lf anders läuft. Eine Zeitüberwa- chung muss zentral erfolgen. Diese Aufgabe übernimmt ein Syn¬ chronisationsdienst 16, der den virtuellen Geräten la' bis lf mitteilt, wie viel Zeit vergangen ist. Auch ein virtuel¬ ler Zeitmaster wird auf diese Art gesteuert. Weicht die Zeit eines virtuellen Geräts la' bis lf von der Zeit des Synchronisationsdienstes 16 ab, erfolgt erneut eine Zeitsynchronisation. Geht man davon aus, dass alle virtuellen Geräten la' bis lf schnellstmöglich arbeiten und eilt die Zeitvorgabe einem virtuellen Gerät la' bis lf voraus, muss die Synchronisationszeit verlangsamt werden. Sind alle Geräte schneller als der Synchronisationsdienst 16, kann entspre¬ chend die Zeitvorgabe beschleunigt werden. Sind die virtuel¬ len Geräte la' bis lf zu langsam, warten alle schnelleren Geräte auf die langsameren. Hierfür gibt es zwei Möglichkei- ten: im einfachsten Fall stoppt man das schnellere virtuelle Gerät (suspend) und startet (resume) es wieder, ohne dass für das virtuelle Gerät virtuelle Zeit vergangen ist. In der Zwi¬ schenzeit eingehende Signale und Meldungen werden im virtuel¬ len Netzwerkdienst 15 gepuffert und anschließend bearbeitet. Eine komplexere Möglichkeit besteht darin, dass das virtuelle Gerät einen Rollback ausführt und zu dem Zeitpunkt zurück¬ kehrt, auf den es synchronisiert werden soll. So ist möglich, in den verschiedenen virtuellen Geräten la' bis lf unterschiedlich schnelle Zeitabläufe zu simulieren und relevante Zeitsignale im virtuellen Netzwerkdienst 15 zu puffern und weiterzuleiten .
Im virtuellen Netzwerkdienst 15 können zusätzlich Netz- und Übertragungsverhaltensweisen, wie Verzögerungen (Delay) , Netzausfall oder Zeitschwankungen der Übertragung getestet werden . Die hier beschriebene Funktionalität ist schematisch nochmals in FIG 3 dargestellt, welche eine virtuelle Anlage 6 zeigt. Der Synchronisations- und Netzwerkservice 14 ist eingebettet in die virtuelle Anlage 6. Er hat die Aufgabe, eine Kommuni- kation zwischen verschiedenen virtuellen Geräten zu gewährleisten. Im Einzelnen sind dies eine virtuelle Steuerung 7, eine Simulation 8, ein weiteres virtuelles Gerät 9, ein vir¬ tueller Aktor 10, eine virtuelle Achse 11 sowie ein virtuel¬ ler Sensor 12. Die Transformatoren 13 verknüpfen die virtuel- len Geräte 7 bis 12 jeweils mit dem Synchronisations- und
Netzwerkservice 14. Diese Transformatoren 13 stellen ergänzend sicher, dass die Kommunikation der virtuellen Geräte 7 bis 12 zum Synchronisations- und Netzwerkservice 14 übertra¬ gen wird, indem sie jeweilige Ausgangsdaten in Transportpake- te verpacken bzw. solche Transportpakete zur Erzeugung von Eingangsdaten entpacken.
Der Synchronisations- und Netzwerkservice 14 besteht aus zwei Hauptkomponenten, nämlich dem Netzwerkdienst 15 und dem Syn- chronisationsdienst 16. Im Netzwerkdienst 15 werden Datenpa¬ kete der virtuellen Geräte 7 bis 12 analysiert und transfor¬ miert, also für den jeweiligen Empfänger angepasst (zum Beispiel hinsichtlich Ethernetadressen, ProfiBus Ports etc.). Die Datentelegramme werden protokolliert (logging) , verändert oder ergänzt. Dies ist durch die Blöcke 17 und 18 schematisch dargestellt, hierbei repräsentiert der Block 17 den Vorgang der Transformation, während der Block 18 die Signal- und Telegrammbeobachtung, Änderung und Simulation umfasst. Der Synchronisationsdienst 16 übernimmt die Generierung eines Zeitsignals (evtl. über die Steuerung eines Zeitmasters) und startet und stoppt die virtuellen Geräte 7 bis 12. Er ergänzt und korrigiert ggf. die Datentelegramme um virtuell gültige Zeitinformationen (z. B. werden Telegramme mit Lebenszeichen verzögert und später versendet, wenn die virtuelle Steuerung pausiert) , sodass auch Zeitüberwachungen in den virtuellen Geräten 7 bis 12 zufrieden gestellt werden können. Auch dies ist durch die Blöcke 19, 20 und 21 symbolisch dargestellt. Hierbei steht der Block 19 für die Steuerung des Zeitmasters, der Block 20 für das Starten und Stoppen der virtualisierten Geräte und der Block 21 für die Simulation des Netzverhal¬ tens .
Der Synchronisations- und Netzwerkservice 14 kann über ein Engineering-HMI 23 konfiguriert werden. Hierbei werden zum einen die Netzwerkkonfiguration, zum anderen die Regeln für die Zeitsynchronisation parametriert . Des Weiteren wird das Engineering-HMI 23 auch benutzt, um Kommunikationsdaten zu beobachten, zu ändern und zu ergänzen. Der Block 22 steht hierbei für die Kommunikations- und Synchronisationskonfigu¬ ration sowie das Beobachten, Ändern und Ergänzen von Kommunikationsdaten .
In FIG 4 ist schematisch ein spezifisches Beispiel für den Einsatz des Synchronisations- und Netzwerkservices 14 darge¬ stellt. Für eine Produktionsanlage werden ein Bewegungssteu¬ ergerät Simotion P und eine Achssteuerung Sinamics CU projek- tiert. Diese sollen in eine produktive Anlage eingefügt wer¬ den. Das Bewegungssteuergerät Simotion und die Achssteuerung Sinamics CU kommunizieren in der realen Anlage (also im Feld¬ bussystem 4) über ProfiBus DP. Zum Testen dieses Projekts wird eine virtualisierte Sinamics CU in Form des virtuellen Gerätes la' und das virtuelle Gerät lc' mit Simotion P zur
Verfügung gestellt. Die Simulationsumgebung mit dem virtuellen Gerät ld' (SIMIT) kann übernommen werden. Das virtuelle Gerät la' kommuniziert über eine virtuelle ProfiBus-Karte, während in dem virtuellen Gerät ld' ausschließlich eine
Ethernetkarte genutzt werden kann. Die Kommunikation der Si¬ mulation ist mit ProfiNet CBA realisiert. Die verschiedenen Kommunikationsprotokolle sind in FIG 4 an den jeweiligen Netzwerkpfaden dargestellt und mit ETH (Ethernet) , PN (Profi- Net) und PB (ProfiBus) bezeichnet. In den Virtual-Network- Kommunikations-Transformatoren bzw. Transformatoren 13 werden die Telegramme der Steuerungen und die Daten der Simulation in Ethernetpakete verpackt. Der Synchronisations- und Netz¬ werksservice 14 mit dem Netzwerkdienst 15 transformiert die ProfiNet-Signale PN der über SIMIT realisierten Simulation (virtuelles Gerät ld' ) und speist diese, je nach Parametrie- rung, in eine zyklische oder azyklische Kommunikation des ProfiBus PB der Steuerung Simotion P (virtuelles Gerät lc' ) ein. Auch die Kommunikation zwischen Simotion P (virtuelles Gerät lc' ) und Virtual Sinamics (virtuelles Gerät la' ) ist in der virtualisierten Umgebung nicht direkt möglich. Der Profi- Bus-Datenverkehr wird über den Synchronisations- und Netzwerksservice 14 übertragen und so ein zusammenhängendes Bus- System simuliert.
Auch die Zeitsynchronisation sei anhand der virtuellen Geräte la' (Virtual Sinamics), lc' (Simotion P) und ld' (SIMIT) nochmals anhand der FIG 5A und FIG 5B erläutert. In beiden Figuren ist eine virtuelle Zeit vt gegen die reale Zeit t an¬ getragen. Die Kurven Kl gehören hierbei zum virtuellen Gerät la' , die Kurven K2 zum virtuellen Gerät lc' und die Kurven K3 zum virtuellen Gerät ld' . Bei allen virtuellen und simulierten Systemen läuft die Zeit unterschiedlich. Das virtuelle Gerät ld' bzw. die SIMIT- Simulation hat einen frei wählbaren aber konstant vorgegebenen Simulationstakt. Das virtuelle Gerät lc' arbeitet in die¬ sem Beispiel etwa viermal langsamer als eine reale Simotion P, sodass ein Zyklustakt von 0,25 ms in einer Millisekunde berechnet wird. Es kann in einen Wartezustand versetzt wer¬ den, bei dem intern keine Zeit vergeht. Das virtuelle Gerät la' reagiert in realer Zeit auf die zyklisch eingehenden Sollwerttelegramme und stellt für den nächsten Zyklus die Antworten mit den Ist-Werten bereit. Dadurch ist das virtuelle Gerät la' über die Kommunikation an den Zeittakt des virtuellen Geräts lc' gekoppelt und muss die Zeiten aus den Te¬ legrammen übernehmen, welche die Zeitsynchronisation für die virtuelle Anlage als gültige Zeiten vorgeben.
Das virtuelle Gerät ld' läuft nacheilend mit 1/5 der Zeit, da es nicht weiter beeinflusst werden kann. So ergeben sich die abgebildeten Zeitverläufe im virtuellen System. Die Zeitsyn- chronisation im Synchronisationsdienst 16 gewährleistet den Gleichlauf aller beteiligten virtuellen Geräte la' , ld' und lc' . Dazu hält der Synchronisationsdienst 16 das virtuelle Gerät lc' für die Dauer eines Zyklus an, sobald dieses um ei- ne Zyklusdauer dem virtuellen Gerät ld' vorauseilt. Auch das virtuelle Gerät la' erhält hierdurch erst später das nächste Telegramm.
Mittels der vorgestellten Vorrichtung lassen sich sowohl die Kommunikation als auch die Zeitsynchronisation problemlos beherrschen. Es wird ein adaptives Netzwerk mit virtueller Echtzeit für Simulationszwecke bereitgestellt. Auf diese Art ergeben sich wesentliche Vorteile gegenüber dem Stand der Technik :
- Eine Simulation ist auch für eine Feldkommunikation mit verschiedenen Kommunikationsprotokollen (ProfiBus DP, Pro- fiNet, Ethernet etc.) möglich, indem Transformatoren 13 die Daten auf ihrem Weg zu dem Synchronisations- und Netz¬ werksservice 14 so verpacken, wie es für die Ethernet- Kommunikation erforderlich ist. Durch die virtuelle Buskommunikation ist die Verbindung virtueller Geräte unabhängig von dem tatsächlich verwendeten Netzwerk, sodass in einem Test die virtuellen Geräte mit ihren realen Paramet- rierungen und Kommunikationsprotokollen verwendet werden können. Hierbei wird jedoch das im Testbetrieb zur Verfü¬ gung stehende Netzwerk (nämlich z. B. das Bürokommunikati¬ onsnetzwerk) genutzt.
- Die simulierte Feldkommunikation kann beobachtet, verändert und ergänzt werden. Dies ermöglicht neben Trace und Debugging auf der Feldkommunikationsebene auch die Simula¬ tion von nicht vorhandenen Feldgeräten bis hin zu komplexeren Anlagenkomponenten.
Hierauf aufbauend ermöglicht der Synchronisationsdienst 16 darüber hinaus,
- dass das Zeitverhalten der virtuellen Geräte beeinflusst und synchronisiert werden kann, indem Zeitstempel in der Kommunikation verwendet und angepasst werden. Die virtuel- len Geräte müssen dazu synchronisierbar sein (d. h. es muss möglich sein, sie anzuhalten oder nacheilen zu lassen) oder in der Lage sein Rollbacks durchzuführen. Auf diese Art ermöglicht man Echtzeitverhalten in der virtuel¬ len Umgebung; und
- dass das Netzwerkverhalten hinsichtlich verschiedener
Übertragungseffekte (Jitter, Delay, Ausfall, etc.) simu¬ liert werden kann.
Statt ProfiBus DP oder ProfiNet können auch beliebige andere Feldbuskommunikationsprotokolle angewandt werden, wie z. B. ARCNET, ARINC 629, BITBUS, ControlNet, CAN, CANopen, DALI, DeviceNet, EtherNet/IP, EIB, EtherCAT, Ethernet Powerlink, FAIS-Bus, Fieldbus Foundation, FIP-Bus, FlexRay-Bus, Hart Communication, Interbus, KNX-Standard, LCN Local Control Net¬ work, LIN-Bus, LON, MIL-STD-1553, Modbus, MOST-Bus, SafetyBUS p, SERCOS interface, SmallCAN, SMI Standard Motor Interface, Spacewire, Time-Triggered Protocol (TTP) , BACnet Building Au¬ tomation and Control Networks, VARAN oder P-NET.
Bezugs zeichenliste
la-lf Gerät
la'-lf virtuelles Gerät
2 Feldbus
3 Büronetz
4 Feldbussystem
5 Büronetzsystem
6 virtuelle Anlage
7 virtuelle Steuerung
8 Simulation
9 virtuelles Gerät
10 virtueller Aktor
11 virtuelle Achse
12 virtueller Sensor
13 Transformator
14 Synchronisations- und Netzwerkservice
15 Netzwerkdienst
16 Synchronisationsdienst
17-22 Block
23 Engineering-HMI
24 PC
PB ProfiBus
PN ProfiNet
ETH Ethernet
t Zeit
vt virtuelle Zeit
Kl, K2, K3 Kurve

Claims

Patentansprüche
1. Verfahren zum Überprüfen des zu erwartenden Zusammenwirkens zumindest zweier Geräte (la-lf), welche über ein Netz- werk (2) eines Feldbussystems (4) verbunden sind mit den Schritten :
- Bereitstellen von Programmcode in zumindest einer Rechenvorrichtung (24), durch welchen die zumindest zwei Geräte (la-lf) hinsichtlich ihrer technischen Funktionalität als virtuelle Geräte (la'-lf, 7-12) wenigstens teilweise nach¬ gebildet werden;
- Bereitstellen eines Netzwerkdienstes (15), durch welchen das Netzwerk (2) des Feldbussystems (4) wenigstens teilwei¬ se nachgebildet wird;
- Verknüpfen der zumindest zwei virtuellen Geräte (la'-lf', 7-12) über den Netzwerkdienst (15);
- Initiieren einer Kommunikation zwischen den zumindest zwei virtuellen Geräten (la'-lf', 7-12) vermittels des Netzwerkdienstes (15); und
- Überprüfen des zu erwartenden Zusammenwirkens der zumindest zwei Geräte (la-lf) anhand der Kommunikation.
2. Verfahren nach Anspruch 1,
dadurch gekennzeichnet, dass
die zumindest zwei virtuellen Geräte (la'-lf', 7-12) in einem Netzwerk (3) mit der zumindest einen Rechenvorrichtung (24) bereitgestellt werden und die Kommunikation auf diesem Netzwerk (3) gemäß einem ersten Kommunikationsprotokoll (ETH) ab¬ läuft, welches verschieden von einem zweiten Kommunikations- protokoll (PB, PN) ist, gemäß welchem die Kommunikation der
Geräte (la-lf) in dem Netzwerk (2) des Feldbussystems (4) er¬ folgt .
3. Verfahren nach Anspruch 2,
dadurch gekennzeichnet, dass
der Netzwerkdienst (15) dazu ausgebildet ist, Kommunikation gemäß dem ersten Kommunikationsprotokoll (ETH) in Kommunika tion gemäß dem zweiten Kommunikationsprotokoll (PB, PN) zu transformieren und/oder Kommunikation gemäß dem zweiten Kommunikationsprotokoll (PB, PN) in Kommunikation gemäß dem ers¬ ten Kommunikationsprotokoll (ETH) zu transformieren.
4. Verfahren nach Anspruch 2 oder 3,
dadurch gekennzeichnet, dass
das erste Kommunikationsprotokoll (ETH) auf einem Ethernet- Protokoll basiert, und/oder das zweite Kommunikationsproto¬ koll (PB, PN) ProfiBus DP oder ProfiNet ist.
5. Verfahren nach einem der Ansprüche 2 bis 4,
dadurch gekennzeichnet, dass
die zumindest zwei virtuellen Geräte (la'-lf', 7-12) Daten gemäß dem ersten Kommunikationsprotokoll (ETH) bereitstellen und/oder empfangen, und jedem der zumindest zwei virtuellen Geräte (la'-lf', 7-12) jeweils ein Adapterdienst (13) zuge¬ ordnet ist, welcher gemäß dem ersten Kommunikationsprotokoll (ETH) empfangene Daten in Daten gemäß dem zweiten Kommunikationsprotokoll (PB, PN) und/oder gemäß dem zweiten Kommunika- tionsprotokoll (PB, PN) empfangene Daten in Daten gemäß dem ersten Kommunikationsprotokoll (ETH) umwandelt.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass
eine Kommunikation zwischen Elementen der zumindest einen Rechenvorrichtung (24) gemäß einem ersten Zeitschema abläuft und eine Kommunikation zwischen den zumindest zwei Geräten (la-lf) des Feldbussystems (4) gemäß einem vom ersten Zeit¬ schema verschiedenen zweiten Zeitschema abläuft, und ein Syn- chronisationsdienst (16) bereitgestellt wird, welcher dazu ausgebildet ist, Kommunikation gemäß dem ersten Zeitschema in Kommunikation gemäß dem zweiten Zeitschema zwischen den zumindest zwei virtuellen Geräten (la'-lf', 7-12) und/oder Kommunikation gemäß dem zweiten Zeitschema in Kommunikation ge- mäß dem ersten Zeitschema zwischen den zumindest zwei virtu¬ ellen Geräten (la'-lf', 7-12) umzuwandeln.
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass
das zweite Zeitschema EchtZeitanforderungen genügt und das erste Zeitschema keinen EchtZeitanforderungen genügt.
8. Verfahren nach Anspruch 6 oder 7,
dadurch gekennzeichnet, dass
der Synchronisationsdienst (16) dazu ausgebildet ist, wenigs¬ tens eines der zumindest zwei virtuellen Geräte (la'-lf', 7- 12) hinsichtlich des Ablaufs von zugeordnetem Programmcode zu starten und/oder anzuhalten.
9. Verfahren nach einem der Ansprüche 6 bis 8,
dadurch gekennzeichnet, dass
der Synchronisationsdienst (16) dazu ausgebildet ist, Daten betreffend eine Zeitinformation in einem Datenpaket zu erzeu¬ gen und/oder zu verändern.
10. Vorrichtung (14) zur Überprüfung des zu erwartenden Zusammenwirkens zumindest zweier Geräte (la-lf), welche über ein Netzwerk (2) eines Feldbussystems (4) verbunden sind, mit zumindest einer Rechenvorrichtung (24), die dazu ausgebildet ist, die zumindest zwei Geräte (la-lf) hinsichtlich ihrer technischen Funktionalität als virtuelle Geräte (la'-lf, 7- 12) wenigstens teilweise nachzubilden, das Netzwerk (2) des Feldbussystems (4) wenigstens teilweise nachzubilden und die zumindest zwei virtuellen Geräte (la'-lf', 7-12) zu einer Kommunikation miteinander zu veranlassen sowie einer Prüfeinrichtung zum Überprüfen des zu erwartenden Zusammenwirkens der zumindest zwei Geräte (la-lf) anhand der Kommunikation.
PCT/EP2011/060410 2011-06-22 2011-06-22 Verfahren zum überprüfen des zu erwartenden zusammenwirkens zumindest zweier geräte sowie vorrichtung WO2012175120A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2011/060410 WO2012175120A1 (de) 2011-06-22 2011-06-22 Verfahren zum überprüfen des zu erwartenden zusammenwirkens zumindest zweier geräte sowie vorrichtung

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2011/060410 WO2012175120A1 (de) 2011-06-22 2011-06-22 Verfahren zum überprüfen des zu erwartenden zusammenwirkens zumindest zweier geräte sowie vorrichtung

Publications (1)

Publication Number Publication Date
WO2012175120A1 true WO2012175120A1 (de) 2012-12-27

Family

ID=44503749

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2011/060410 WO2012175120A1 (de) 2011-06-22 2011-06-22 Verfahren zum überprüfen des zu erwartenden zusammenwirkens zumindest zweier geräte sowie vorrichtung

Country Status (1)

Country Link
WO (1) WO2012175120A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3211830A1 (de) * 2016-02-23 2017-08-30 Siemens Aktiengesellschaft Verfahren zum überwachen und planen einer produktionszelle und netzwerkmanagementsystem für eine produktionszelle
CN111762299A (zh) * 2020-08-04 2020-10-13 青岛科技大学 一种船舶动力定位吊舱推进控制实验系统及方法
US11262716B2 (en) 2017-07-04 2022-03-01 Sick Ag Method for the parameterization of a sensor

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030212908A1 (en) * 2002-05-10 2003-11-13 Lockheed Martin Corporation Method and system for simulating computer networks to facilitate testing of computer network security
US20090112569A1 (en) * 2007-10-31 2009-04-30 The Boeing Company Method and Apparatus for Simulating Aircraft Data Processing Systems

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030212908A1 (en) * 2002-05-10 2003-11-13 Lockheed Martin Corporation Method and system for simulating computer networks to facilitate testing of computer network security
US20090112569A1 (en) * 2007-10-31 2009-04-30 The Boeing Company Method and Apparatus for Simulating Aircraft Data Processing Systems

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3211830A1 (de) * 2016-02-23 2017-08-30 Siemens Aktiengesellschaft Verfahren zum überwachen und planen einer produktionszelle und netzwerkmanagementsystem für eine produktionszelle
US11262716B2 (en) 2017-07-04 2022-03-01 Sick Ag Method for the parameterization of a sensor
EP3425324B2 (de) † 2017-07-04 2022-11-16 Sick Ag Verfahren zur parametrierung eines sensors
CN111762299A (zh) * 2020-08-04 2020-10-13 青岛科技大学 一种船舶动力定位吊舱推进控制实验系统及方法

Similar Documents

Publication Publication Date Title
EP3522482B1 (de) Verfahren zur daten-kommunikation in einem industriellen netzwerk, steuerungsverfahren, vorrichtung, computerprogramm sowie computerlesbares medium
EP1430627B1 (de) Verfahren zur synchronisation von knoten eines kommunikationssystems
DE102010020446B4 (de) Automatisierungsgerät und Verfahren zur beschleunigten Verarbeitung von selektierten Prozessdaten
DE102012101957B3 (de) Busteilnehmer-Einrichtung zum Anschluss an einen linienredundanten, seriellen Datenbus und Verfahren zur Steuerung der Kommunikation eines Busteilnehmers mit einem linienredundanten, seriellen Datenbus
EP3632050B1 (de) Busumsetzer
EP3814856A1 (de) Echtzeit-automatisierungseinrichtung mit einem echtzeit-datenbus
EP1193926A2 (de) Verfahren und System zur Echtzeitkommunikation in einem Netz mit Ethernet-Physik
EP1826646B1 (de) Verfahren, Knoten und Netzwerk zum zyklischen Versenden von Ethernet-Telegrammen
WO2012175120A1 (de) Verfahren zum überprüfen des zu erwartenden zusammenwirkens zumindest zweier geräte sowie vorrichtung
EP3042472A1 (de) Verfahren zum überwachen eines ersten teilnehmers in einem kommunikationsnetzwerk und überwachungssystem
EP3715983B1 (de) Verfahren zur bereitstellung von steuerungsanwendungen über ein kommunikationsnetz zur übermittlung zeitkritischer daten und koordinierungseinrichtung
EP2713227A1 (de) System und Verfahren zur Steuerung und/oder Überwachung von technischen Prozessen in einem industriellen Automatisierungssystem
EP2506503B1 (de) Automatisierungsnetzwerk mit Leitsystemkomponente
DE102010027286B4 (de) Verfahren und Vorrichtung zur Übertragung von Daten in einem Automatisierungssystem
WO2020048868A1 (de) Verfahren zur simulation einer technischen anlage, gerät, system, computerprogramm und computerprogrammprodukt
EP3485614B1 (de) Feldbusgerät zum kommunizieren mit einem entfernten automatisierungsgerät
DE102017108578B4 (de) Steuern eines Automatisierungsprozesses über ein Datennetzwerk
EP3631630B1 (de) Verteilte verarbeitung von prozessdaten
DE102007003122A1 (de) Verfahren zum Übertragen von Applikationsdaten über ein Kommunikationsmedium eines Kommunikationssystems, Teilnehmer eines Kommunikationssystems und Kommunikationssystem
DE102021206985A1 (de) System zur Verarbeitung von Daten
EP4068014A1 (de) Hochverfügbare cloud-basierte automatisierungslösung mit optimierten übertragungszeiten
DE102015222848B4 (de) System und Verfahren zum Analysieren eines Netzwerks
EP1371193A2 (de) Electronical switch and method for a communication interface with cut through buffer memory
DE102023203210A1 (de) Verfahren zur Synchronisation von Netzwerken
EP3700146A1 (de) Verfahren zum betrieb eines kommunikationssystems zur übermittlung zeitkritischer daten und kommunikationsgerät

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11741136

Country of ref document: EP

Kind code of ref document: A1