EP2689305A1 - Verfahren zum betrieb eines automatisierungssystems - Google Patents

Verfahren zum betrieb eines automatisierungssystems

Info

Publication number
EP2689305A1
EP2689305A1 EP11723353.6A EP11723353A EP2689305A1 EP 2689305 A1 EP2689305 A1 EP 2689305A1 EP 11723353 A EP11723353 A EP 11723353A EP 2689305 A1 EP2689305 A1 EP 2689305A1
Authority
EP
European Patent Office
Prior art keywords
link
modular
subunits
link device
automatically
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP11723353.6A
Other languages
English (en)
French (fr)
Inventor
Herbert Weiss
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
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 AG filed Critical Siemens AG
Publication of EP2689305A1 publication Critical patent/EP2689305A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • 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
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • 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
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/4185—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by the network communication
    • 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
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • 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
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0423—Input/output
    • 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
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0426—Programming the control sequence
    • 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]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • 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
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/31—From computer integrated manufacturing till monitoring
    • G05B2219/31134—PCD profinet component description, field device description module
    • 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
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/32—Operator till task planning
    • G05B2219/32144—Define device description using dd files

Definitions

  • the invention relates to a method for operating a car ⁇ matleiterssystems, specifically an automation system with IO-Link devices, and a method for handling such IO-Link, in particular in terms of configuration and parameterization.
  • IO-Link Under the registered trademark IO-Link for the PROFIBUS user organization eV, a concept for the uniform connection of sensors and actuators (eg switching devices) to a control level by means of a cost-effective point-to-point connection is known. This communication standard below the fieldbus level enables central fault diagnostics and location up to the sensor / actuator level. As an open interface, IO-Link can be in all common fieldbus and integrated automation ⁇ insurance systems. In the following, the above-mentioned communication system will be briefly referred to as IO-Link.
  • the IO-Link specification (current version: V1.0, 2008/2009) describes how IO-Link devices (IO-Link devices) from different device manufacturers can be connected to a point-to-point connection. According to the specification, parameters, diagnostics, etc. can be transferred from and to a so-called IO-Link master as the higher-level IO-Link unit for these devices.
  • diagnosis means here and below one hand Diagnoseinforma- tion as a result of a review or a status inquiry of each device and also a description ei ⁇ ner nature and / or scope of such a review or status inquiry. But measured values (currents, voltages, Tem ⁇ temperatures, etc.), statistics (operating hours, etc.) logbooks, etc ..
  • IO-Link devices especially the respective parameters, diagnostics, etc.
  • IODD dedicated device description file
  • modular IO-Link devices such as those offered by the applicant, so-called compact starters with the designation "SIRIUS 3RA6" dellieren to mo ⁇ . Only compact IO-Link devices can be described. Modularity information is hidden as it were in device-specific, unused or less relevant parameters or diagnostic information (eg error messages, lifetime, end position, etc.).
  • This restriction modular IO-Link devices can Engineering software (eg SIMATIC Step7) are shown only as a compact device with universal ⁇ seller configuration, diagnostics, etc. in the configuration and diagnostics of an IO-Link. Sol ⁇ che representations are thus often misleading or even wrong. For example, a central collect error LED does not provide information about which of several subunits of a modular IO-Link device is disturbed.
  • a further disadvantage is that always two different development tools are required for the IO-Link engineering, namely a first development tool, eg the applicant's engineering software known under the name STEP7, for the configuration of the IO-Link master in the automation system and a second development tool for the configuration of the IO-Link master itself and the communicatively linked IO-Link devices.
  • a first development tool eg the applicant's engineering software known under the name STEP7
  • STEP7 the configuration of the IO-Link master in the automation system
  • a second development tool for the configuration of the IO-Link master itself and the communicatively linked IO-Link devices.
  • IO-Link devices Configuration of the IO-Link devices in the second development tool by calling the second development tool, eg directly from the first development tool, and by so-called drag & drop of the IO-Link devices into a port configuration included in the second development tool.
  • IO-Link devices if available, can be integrated with a device description file.
  • the configuration of comprehensive subunits "hidden" is entered in the device parameters.
  • the individual modules / devices of the modular IO-Link device - here and below referred to as a subunit or IO-Link SubDevice - can not be selected in the hardware selection catalog.
  • a graphical configuration using drag & drop of the individual subunits is also not possible.
  • the parameters are chert tospei ⁇ in the data management of the first development tool.
  • the device parameters are loaded onto a central unit of an automation device, which then transmits them to the IO-Link master and the IO-Link devices during startup.
  • Diagnosis of the IO-Link system in the first development tool by reading and displaying the system diagnosis Informatio ⁇ nen of all available modules.
  • IO-Link master When IO-Link master is this is the group diagnostic information of the master (which corresponds to the status of a dedicated LED of the IO-Link master) and the diagnostic information of the ports / IO-Link devices. In modular IO-Link devices, these individual diagnostic information can not possibly different sta- ti of the LEDs of the individual IO-Link subdevices; represent (Scheinhei ⁇ th branches).
  • a first task of the approach presented here is to facilitate the handling of modular IO-Link devices and their use in an automation system.
  • a method for operating an automation system wherein the automation system communicatively connected to a higher-level IO-Link unit, eg an IO-Link master, and at least one modular IO-Link device with a device-internal bus and responsive, from the modular IO If the device comprises subunits, it is provided that one of its subunits is selected for communication with the modular IO-Link device and that communication takes place only with it directly and indirectly via this with the other subunits of the modular IO-Link device.
  • a further object of the approach presented here is based on the complexity and complexity of the previously required process steps in the configuration and parametrization of modular IO-Link devices therein, their handling during configuration, parameterization and / or diagnostics.
  • a modular IO-Link device is a "pseudo-modular compact device", i. It includes several modules (IO-Link SubDevices) referred to here as subunits or branches, which are connected via a device-internal bus.
  • IO-Link SubDevices modules
  • subunits or branches which are connected via a device-internal bus.
  • SIRIUS 3RA6 compact starter As an example, reference may be made to the device offered by the applicant under the name "SIRIUS 3RA6 compact starter”. So far, however, the individual subunits are not visible to the outside and can not be directly addressed, namely because they have no address, do not occupy a port in the IO-Link model, do not provide diagnostic information, etc.
  • the following technical features can be used to eliminate the problems outlined above:
  • a first object for representing the modular IO-Link device a first object for representing the modular IO-Link device, a second object for representing ⁇ tion in the modular IO-Link device, the subunits comprehensive or receiving IO-Link module frame, a third object to represent the selected and as an IO-Link head assembly functioning subunit and Minim ⁇ least a fourth object for each additional subunit of the mo ⁇ dularen IO-link device is created.
  • the creation of an object for the representation of the modular IO-Link device and possible further objects takes place with the development tool for an automation ⁇ s istswishing for controlling and / or monitoring a technical process.
  • the automation solution includes the automation system and, to that extent, the IO-Link system as part of the automation system with at least one IO-Link master and a modular IO-Link device as well
  • the solution proposed here is based on the fact that one of the subunits takes over the communication via IO-Link to the outside and thus acts as a proxy for the entire modular IO-Link device.
  • This subunit is referred to below as a head assembly for distinction.
  • the head assembly may be a predetermined subunit, such as a communication module, or any Unterein ⁇ standardize the modular IO-Link device that takes the kommunikati ⁇ ve connect the modular IO-Link device and there ⁇ with works as head assembly. Only this head assembly Need Beer ⁇ Untitled information regarding the internal structure of the IO-Link device. On this basis, the sub-assemblies included in the IO-Link device are addressed by the head assembly through a completely internal mechanism.
  • the presence of the subunits has an effect only on the technological functions of the modular IO-Link device, in that the functions of these subunits (through parameters, diagnostics, process images, etc.) are enabled or otherwise activated.
  • the extended object model on the surface of exactly one development tool allows a modular IO-Link device as a modular device with a majority to be able to handle subunits.
  • all subunits included in the modular IO-Link device can be selected in the device catalog and added to the modular IO-Link device in the device view, eg by drag & drop.
  • a modular IO-Link device will always be modeled by a together ⁇ men
  • the following items a (first) object for an IO-Link device, a (second) object for an IO-Link assembly frame, a ( third) Object for an IO-Link head module and at least one (fourth) object for a subunit of the modular IO-Link device.
  • the following does not always refer to an object as a representative of a physi ⁇ cal unit, so that, for example, instead of per se complete terms such as "object for modeling the IO-Link device” briefly only "IO-Link device” is written. From the context, it follows in each case whether an object as a representative of the physical unit or physi ⁇ cal unit itself is meant.
  • the object for modeling the IO-Link device is the object that is used in a master view (IO-Link master view) for the Display of the IO-Link device is displayed.
  • the object for modeling the IO-Link module frame is a container for the subunits included in the modular IO-Link device, which can thus be configured in the device view of the development tool.
  • the relations of the object for modeling the IO-Link module frame to the or each subunit represent first slot rules, namely slot rules that can already be checked when combining an object for modeling a subunit with the IO-Link subrack.
  • the object for modeling the head module functions as a proxy for a modular IO-Link device. It represents the actual technological functionality of the modular IO-Link device and supports most device properties (device parameters, length of the input and output address, device diagnostics, etc.).
  • a modular IO-Link device is a pseudo modular system, ie it can be configured with Untereinhei ⁇ th. Unlike real modular sys- tems, however, they do not have their own parameters and accordingly no startup data of their own. Instead, a subunit changes the properties of the modular IO-Link device and the characteristics of the modular IO-Link device model ⁇ lierenden object, eg the visibility of parameters. For this, the head module must have information about which subunits are currently configured.
  • the head assembly is the only object for which there is a physical correspondence in each case.
  • the head module represents the modular IO-Link device on the surface of the development tool. Therefore, it is also the object that has a purchase order number (MLFB) of an IO-Link device, for example, and can therefore be generated by the user via the hardware catalog. All other objects (IO-Link module frame, IO-Link device, IO-Link subunit) are then additionally generated implicitly.
  • the parameter setting, diagnostics, address allocation, etc. rele ⁇ vant actions and dialogues are on the head assembly, NaEM ⁇ Lich the head assemblies premises, available.
  • the head module object includes the functionality for integrating one or more subunits and the functionality for connection to the IO-Link master, ie an IO-Link port (node) provided for this purpose.
  • Objects for managing address information (address objects) and the IO-Link port (Node) are standard objects and are generated automatically if the device description contains corresponding attributes, as well as the link to the IO-Link master system.
  • a subunit of a modular IO-Link device does except an icon in the device view and the standard dialogs for project Informa ⁇ tions not have its own surface, no own device parameters and no relations with the IO-Link system.
  • the method is accordingly seen ⁇ seen that when creating an object for a modular IO-Link device automatically an object for the selected and acting as an IO-Link head assembly subunit of modu ⁇ lar IO-Link device and / or an object For the IO-Link module frame of the modular IO-Link device, especially and also automatically an interconnection between these objects is created.
  • ⁇ Text id "TI DS130 BGID DS _032- 125"
  • ⁇ Text id "TI DS130 BGID DS _100- 400"
  • ⁇ Text id "TI DS130 BGID DS _300- 1200"
  • ⁇ Text id "TI DS130 BGID DS _800- 3200"
  • ⁇ Text id "TI DS130 BGID RS_032- 125"
  • ⁇ Text id "TI DS130 BGID RS _100- 400"
  • ⁇ Text id "TI DS130 BGID RS _300-1200"
  • ⁇ Text id "TI DS130 BGID RS _800- 3200"
  • IO-Link device IO-Link module frame
  • IO-Link head module IO-Link subunit
  • Description of the device configuration Number of slots, pluggable device types, etc.
  • slot rules it is possible to cover only so-called hard slot rules, whereby hard in this context means that a selection of an IO-Link subunit and its combination with the modular IO-Link device is prevented from the hardware catalog.
  • SIRIUS_3RA6 unique object number, constant
  • a modular IO-Link device with all its subunits can be displayed in the development tool.
  • the display includes at least one option for diagnosing individual IO-Link subunits with the display of the results of the diagnosis.
  • the representation then includes an indication of a configuration and / or a configuration of the modular IO-Link device with its subunits, in tabular form and / or graphically.
  • the presentation also includes a support of the hardware catalog in the device selection.
  • All IO-Link masters available from the applicant are already included in the hardware selection catalog.
  • a selection of a specific IO-Link master occurs e.g. by dragging and dropping the selected device into the hardware configuration.
  • the parameters of the IO-Link master can then be set in the development tool via a property window of the object representing the IO-Link master.
  • the parameters of the IO-Link device can then be set in the development tool via a property window of the object representing the IO-Link device. 3) Configuration of the IO-Link subunits
  • IO-Link subunits (subdevices, branches) can be selected in the hardware selection catalog.
  • a graphic projek ⁇ tation by dragging and dropping the individual IO-Link subunits is now possible.
  • Modular IO-Link devices are configured in the device view of the hard ⁇ ware configuration. Since the number and type of IO-Link devices and subunits used are known, a start and a length of a data area with I / O addresses can be determined automatically.
  • the parameters of each IO-Link subunit can be set in the development tool via a property window of the object representing the IO-Link subunit.
  • the diagnostic information of all modules is read out and displayed. With diagnostics information retrieved for an IO-Link master, this is the group diagnostics of the master (the diagnostic information corresponds to the status of an LED on the IO-Link master) or diagnostic information regarding the IO-Link devices that can be reached for the IO-Link master.
  • a respective status of the device LEDs with the corresponding covered by the Diagno ⁇ seinformation data corresponds (Group fault, Group warning, etc.).
  • the diagnostic information and status of the on / off ⁇ transitions of the individual subunits are visible.
  • FIG. 2 shows an IO-Link device in one embodiment as a modular IO-Link device
  • FIG. 3 shows a representation of IO-Link devices by a development tool
  • FIG. 4 shows a flow chart for illustrating a method for creating objects in the development tool for IO-Link devices.
  • the automation system 10 includes at least one automation s réelles réelle 14, for example, a programmable Steue ⁇ tion.
  • IO-Link master 16 for connecting sensors and / or actuators via the communication standard known as IO-Link.
  • IO-Link master 16 for connecting sensors and / or actuators via the communication standard known as IO-Link.
  • point-to-point connections are IO-Link Devices 18, 20, 22 connected.
  • IO-Link 20 In at least one of the connected IO-Link 18, 20, 22 is a modular unit IO-Link 20, which - as FIG 2 schematically shows schematically simplified ⁇ - a plurality of IO-Link subunits comprises.
  • the IO-Link device 20 can include one or more IO-Link subunits 24, 26, 28, of which exactly one functions as a head assembly 24.
  • the IO-Link device has 20 slots and within the module frame 30 to each slot, a device-internal bus 32 extends within the IO-Link device 20, so that all of an IO-Link device 20 included Subunits communicatively connected and are specifically available for the head assembly.
  • the IO-Link master 16, the IO-Link devices 18, 20, 22 and the point-to-point connections provided for communicative connection of these units together form the IO-Link system (FIG. 1) in which the IO-Link master 16 acts as the parent unit.
  • one of the subunits 24, 26, 28 of the modular IO-Link device 20 is selected as the head module 24.
  • the communi ⁇ cation to the IO-Link Master 16 is only with this head assembly 24 directly.
  • All subunits 24, 26, 28 encompassed by the modular IO-Link device 20 can be reached indirectly in the IO-Link system via this head assembly 24, namely, starting from the head assembly 24 via the device-internal bus 32.
  • a software development tool 34 (FIG. 1) is used.
  • This software runs on a per ⁇ programming device 36 (FIG 1) or the like are executed, that is, at least temporarily, directly or indirectly, for example via Inter- net, to the automation system 10 can be connected.
  • the programming device 36 eg a personal computer, has for this purpose in a manner known per se a memory 38 and a processing unit in the manner of a microprocessor (not shown).
  • the development tool 34 When the development tool 34 is loaded into the memory 38, it may be executed by the processing unit.
  • FIG. 3 shows a simplified schematic representation to a possible Dar ⁇ position of the IO-Link object model. It is shown that when creating a modular IO-Link device 20 with the development tool 34, a first object 40 for representing the modular IO-Link device 20, a second object 42 for rep ⁇ presentation of in the modular IO-Link device 20, the subunits 24,26, 28 or comprehensive receiving IO-link module frame 30, a third object 44 to repre ⁇ on the selected and as an IO-link head assembly 24 Fungie ⁇ leaders subunit and at least a fourth object 46 for every other subunit 26, 28 of the modular IO-Link Gerä ⁇ tes is applied 20th
  • connection of the modular IO-Link device 20 to the IO-Link system is only via the head module 24, which represents the modular IO-Link device 20 to the outside, namely that for the IO Link head assembly 24 generated third object 44 takes place.
  • a fifth object 48 represents a point-to-point connection between the IO-Link master and the modular IO-Link device 20.
  • the IO-Link master 16 is represented by a sixth object 50.
  • the representation by the development tool 34 and the links underlying the representation of the individual objects causes the communicative accessibility of the IO-Link head module 24 in the IO-Link system and especially by the IO-Link Master 16.
  • a complex IO-Link system A plurality of IO-Link devices 18, 20, 22 and also a plurality of modular IO-Link devices 20.
  • its representation by the development tool 34 refers to a corresponding plurality of the respective ones objects.
  • the object 44 for the IO-Link head assembly 24 and / or the object 42 for the IO-Link assembly frame 30 are created automatically when creating an object 40 for a modular IO-Link device 20.
  • the application of an object 40 for a modular IO-Link device 20 is effected for example by the user of the software tool the respective modular IO-Link device 20 selects a hardware catalog and placed by means of hay ⁇ te conventional control actions as drag and drop, in the automation solution.
  • the software tool 34 in such or another embodiment, not shown separately after it so far is only additional or alternative software ⁇ functionality of the software tool 34th
  • the software tool 34 is provided see that when automatically creating an object 42 for the IO-Link module frame 30, objects 46 are automatically applied to the sub-units 26, 28 that can be accommodated by the IO-Link module frame 30.
  • the functionality of the software tool 34 that automatic connection of the objects 42, 44, 46 automatically takes place between the automatically created objects 42, 44, 46.
  • the far-scale interconnection corresponds to the schematically dargestell- th interconnection in FIG 3, and makes, for example, starting from the Whether ⁇ ject 44 to represent the head assembly 24, the object 42 to represent the IO-Link module frame 30 and ⁇ telbar the objects 40, 46 for representing the modular IO-Link device 20 and / or for representing the subunits 26, 28 that can be accommodated by the IO-Link module frame 30 or can be accommodated by the IO-Link module frame 30.
  • FIG 4 makes this aspect, so the related func- tionality of the software tool 34, a simplified schematic representation of ⁇ significantly hand of a flow chart:
  • objects first function block 52
  • the software tool 34 is checked whether it is at the preferential unit object or the object type selected to create an object is an object 40 representing a modular IO-Link device 20. If this is the case, a branch is made to a second function block 54, with which object 42 is automatically created for the IO-Link module frame 30.
  • the software tool 34 is a software tool 34 in the particular embodiment already described above, it is checked in an optional fourth function block 56 as to what kind of IO-Link module frame 30 for which the object 42 has been created as a representative Then, objects (46) for subunits 26, 28 that can be accommodated by the IO-Link module frame 30 or that can be picked up by the IO-Link module frame 30 are automatically applied (fifth function block 58).
  • the automatically generated objects can be generated with respect to the actually inserted sub-units 26, 28 by, for example, taking over data from the respective device description.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • General Engineering & Computer Science (AREA)
  • Manufacturing & Machinery (AREA)
  • Quality & Reliability (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Programmable Controllers (AREA)

Abstract

Die Erfindung betrifft insbesondere ein Verfahren zum Betrieb eines Automatisierungssystems (10), wobei das Automatisierungssystem (10) in kommunikativer Verbindung eine übergeordnete IO-Link Einheit (14) und zumindest ein modulares IO-Link Gerät (20) mit einem geräteinternen Bus (32) und darüber ansprechbaren, von dem modularen IO-Link Gerät (20) umfassten Untereinheiten (24, 26, 28) umfasst, wobei sich das verfahren dadurch auszeichnet, dass zur Kommunikation mit dem modularen IO-Link Gerät (20) eine von dessen Untereinheiten (24, 26, 28) ausgewählt wird und die Kommunikation nur mit dieser direkt und über diese indirekt mit den anderen Untereinheiten (24, 26, 28) des modularen IO-Link Gerätes (20) erfolgt.

Description

Beschreibung
Verfahren zum Betrieb eines Automatisierungssystems Die Erfindung betrifft ein Verfahren zum Betrieb eines Auto¬ matisierungssystems, speziell eines Automatisierungssystems mit IO-Link Geräten, und ein Verfahren zur Handhabung solcher IO-Link Geräte, insbesondere in Bezug auf Konfiguration und Parametrierung .
Unter der für die PROFIBUS Nutzerorganisation e.V. eingetragenen Marke IO-Link ist ein Konzept zur einheitlichen Anbin- dung von Sensoren und Aktoren (z.B. Schaltgeräte) an eine Steuerungsebene mittels einer kostengünstigen Punkt-zu-Punkt Verbindung bekannt. Dieser Kommunikationsstandard unterhalb der Feldbusebene ermöglicht eine zentrale Fehlerdiagnose und -ortung bis zur Sensor-/Aktorebene . Als offene Schnittstelle lässt sich IO-Link in alle gängigen Feldbus- und Automatisie¬ rungssysteme integrieren. Im Folgenden wird auf das o.g. Kom- munikationssystem kurz als IO-Link Bezug genommen.
Die IO-Link Spezifikation (aktueller Versionsstand: V1.0, 2008/2009) beschreibt, wie IO-Link Geräte (IO-Link Devices) unterschiedlicher Gerätehersteller an eine Punkt— zu—Punkt Verbindung angeschlossen werden können. Für diese Geräte können entsprechend der Spezifikation Parameter, Diagnosen, etc. von und zu einem sogenannten IO-Link Master als übergeordneter IO-Link Einheit übertragen werden. Der Begriff Diagnose meint hier und im Folgenden einerseits eine Diagnoseinforma- tion als Ergebnis einer Überprüfung oder einer Statusabfrage des jeweiligen Gerätes und andererseits eine Beschreibung ei¬ ner Art und/oder eines Umfangs einer solchen Überprüfung oder Statusabfrage. Aber auch Messwerte (Ströme, Spannungen, Tem¬ peraturen, usw.), Statistikdaten (Betriebsstunden, usw.) Log- bücher, etc.. Die Beschreibung der IO-Link Geräte, insbesondere der jeweiligen Parameter, Diagnosen etc., erfolgt in einer dafür vorgesehenen Gerätebeschreibungsdatei (IODD). Die Gerätebeschreibung erlaubt jedoch nicht, modulare IO-Link Geräte, wie z.B. die von der Anmelderin angebotenen sogenannten Kompaktabzweige mit der Bezeichnung "SIRIUS 3RA6", zu mo¬ dellieren. Es können lediglich kompakte IO-Link Geräte be- schrieben werden. Informationen zur Modularität werden gerätespezifisch in nicht benötigten oder weniger relevanten Parametern oder Diagnoseinformationen (z.B. Fehlermeldungen, Lebensdauer, Endlage, etc.) gleichsam versteckt. Durch diese Einschränkung können modulare IO-Link Geräte in der Konfiguration und Diagnose einer IO-Link Engineeringsoftware (z.B. SIMATIC Step7) nur als kompaktes Gerät mit univer¬ seller Konfiguration, Diagnose etc. dargestellt werden. Sol¬ che Darstellungen sind damit oftmals irreführend oder sogar falsch. Zum Beispiel gibt eine zentrale Sammel-Fehler-LED keine Auskunft darüber, welche von mehreren Untereinheiten eines modularen IO-Link Gerätes gestört ist.
Weiterhin ist es insbesondere nicht möglich,
- die einzelnen Untereinheiten, nämlich Baugruppen oder Geräte, eines modularen IO-Link Gerätes aus einem Hardware¬ auswahlkatalog auszuwählen,
das modulare IO-Link Gerät durch übliche Benutzerhandlungen, wie drag & drop, zu konfigurieren und zwar weder gra- fisch noch tabellarisch,
die tatsächliche Gerätekonfiguration offline und online darzustellen,
einen Soll/Ist-Vergleich der Gerätekonfiguration durchzuführen,
- die Diagnoseanzeigen (z.B. Geräte-LEDs) der einzelnen Baugruppen/Geräte in der Online-Konfiguration darzustellen, die Größen der Prozessabbilder, nämlich des Prozessabbilds der Eingänge (PAE) und des Prozessabbilds der Ausgänge (PAA) , konsistent zu halten
- die Adresslänge und -Zuordnung abhängig vom Ausbau automa¬ tisch zu berechnen oder
eine Produktbild, das dem tatsächlichen Ausbau entspricht, anzuzeigen . Ein weiterer Nachteil ist, dass immer zwei unterschiedliche Entwicklungswerkzeuge für das IO-Link Engineering erforderlich sind, nämlich ein erstes Entwicklungswerkzeug, z.B. die unter der Bezeichnung STEP7 bekannte Engineeringsoftware der Anmelderin, für die Projektierung des IO-Link Masters im Automatisierungssystem und ein zweites Entwicklungswerkzeug für die Projektierung des IO-Link Masters selbst und der damit kommunikativ verbundenen IO-Link Geräte.
Im Folgenden wird zu Illustrationszwecken die Projektierung eines IO-Link Systems als Bestandteil eines Automatisierungs¬ systems mit den Entwicklungswerkzeugen der Anmelderin, nämlich dem unter der Bezeichnung SIMATIC Step7 bekannten Entwicklungswerkzeug (erstes Entwicklungswerkzeug) einerseits und dem unter der Bezeichnung Port Configuration Tool (S7- PCT) bekannten Entwicklungswerkzeug (zweites Entwicklungs¬ werkzeug) andererseits, beschrieben.
Folgende Schritte sind beim Projektieren eines IO-Link Sys¬ tems in der Engineeringsoftware auszuführen:
1) Konfiguration des IO-Link Masters im ersten Entwicklungswerkzeug, z.B. durch sogenanntes drag & drop eines IO-Link Masters in die Hardwarekonfiguration des ersten Entwicklungswerkzeugs, z.B. in ein dort angelegtes Automatisie¬ rungsgerät in Form einer speicherprogrammierbaren Steuerung oder dergleichen.
2) Parametrieren des IO-Link Masters im ersten Entwicklungswerkzeug. Hier gibt der Anwender die E/A-Adressen (Anfang und Länge) und die Diagnoseparameter des IO-Link Masters ein. Für die Bestimmung der Länge der E/A-Adressen muss der Anwender exakt Anzahl und Typ der verwendeten Ports bzw. IO-Link Geräte wissen. Bei modularen IO-Link Geräten wird das Problem dadurch verstärkt, dass die Größe der Prozessabbilder der Eingänge und der Ausgänge wiederum von den verwendeten Baugruppen/Geräten abhängt. Eine Unterstützung seitens des ersten Entwicklungswerkzeugs ist nicht gegeben, da bei modularen IO-Link Geräten die davon umfassten Untereinheiten nicht bekannt sind. Dadurch ist die Adressvergabe fehleranfällig. ) Konfiguration der IO-Link Geräte im zweiten Entwicklungswerkzeug durch Aufruf des zweiten Entwicklungswerkzeugs, z.B. direkt aus dem ersten Entwicklungswerkzeug, und durch sogenanntes drag & drop der IO-Link Geräte in eine vom zweiten Entwicklungswerkzeug umfasste Port-Konfiguration. Dafür lassen sich IO-Link Geräte, wenn verfügbar, mit einer Gerätebeschreibungsdatei integrieren. ) Parametrieren der IO-Link Geräte im zweiten Entwicklungswerkzeug durch Selektion des jeweiligen Ports/IO-Link Gerätes und Eingabe der Geräte-Parameter. Bei modularen IO- Link Geräten wird die Konfiguration umfasster Untereinheiten "versteckt" bei den Geräteparametern eingegeben. Die einzelnen Baugruppen/Geräte des modularen IO-Link Gerätes - hier und im Folgenden als Untereinheit oder IO-Link SubDevice bezeichnet - können nicht im Hardwareauswahlkatalog ausgewählt werden. Eine grafische Projektierung mittels drag & drop der einzelnen Untereinheiten ist ebenfalls nicht möglich. ) Download der Parameter in den IO-Link Master und die einzelnen IO-Link Geräte mittels des ersten Entwicklungswerkzeugs aufgrund einer vorherigen Übergabe der Parameter der IO-Link Geräte im Zusammenhang mit einer Beendigung des zweiten Entwicklungswerkzeugs. Die Parameter werden in der Datenhaltung des ersten Entwicklungswerkzeugs abgespei¬ chert. Beim Download werden die Geräteparameter auf eine Zentraleinheit eines Automatisierungsgerätes geladen, das diese dann beim Anlauf an den IO-Link Master und an die IO-Link Geräte überträgt. ) Diagnose des IO-Link System im ersten Entwicklungswerkzeug durch Auslesen und Anzeigen der Systemdiagnose-Informatio¬ nen aller erreichbaren Baugruppen. Beim IO-Link Master ist dies die Sammeldiagnoseinformation des Masters (stimmt mit dem Status einer dafür vorgesehenen LED des IO-Link Master überein) und die Diagnoseinformation der Ports/der IO-Link Geräte. Bei modularen IO-Link Geräten kann diese einzelne Diagnoseinformation nicht die evtl. unterschiedlichen Sta- ti der LEDs der einzelnen IO-Link-SubDevices (Untereinhei¬ ten; Abzweige) repräsentieren.
7) Um bei modularen IO-Link Geräten eine exakte Diagnosein- formation zu erhalten, muss der Anwender in das zweite
Entwicklungswerkzeug wechseln und sich dort die Geräte¬ diagnose anzeigen lassen. Hier wird bei modularen IO-Link Geräten der Status der LEDs durch die erhältliche Diagno¬ seinformation (Sammelfehler, Sammelwarnung,...) repräsen- tiert. Neben Diagnoseinformationen sind die Ein-/Ausgänge der einzelnen Untereinheiten sichtbar.
Eine erste Aufgabe des hier vorgestellten Ansatzes besteht darin, die Handhabung modularer IO-Link Geräte und deren Ver- wendung in einem Automatisierungssystem zu erleichtern.
Diese Aufgabe wird mit einem Verfahren mit den in Anspruch 1 zusammengefassten Merkmalen gelöst. Dazu ist bei einem Verfahren zum Betrieb eines Automatisierungssystems, wobei das Automatisierungssystem in kommunikativer Verbindung eine übergeordnete IO-Link Einheit, z.B. einen IO-Link Master, und zumindest ein modulares IO-Link Gerät mit einem geräteinternen Bus und darüber ansprechbaren, von dem modularen IO-Link Gerät umfassten Untereinheiten umfasst, vorgesehen, dass zur Kommunikation mit dem modularen IO-Link Gerät eine von dessen Untereinheiten ausgewählt wird und die Kommunikation nur mit dieser direkt und über diese indirekt mit den anderen Untereinheiten des modularen IO-Link Gerätes erfolgt. Eine weitere Aufgabe des hier vorgestellten Ansatzes besteht ausgehend vom Unfang und von der Komplexität der bisher erforderlichen Verfahrensschritte bei der Konfiguration und Pa- rametrierung modularer IO-Link Geräte darin, deren Handhabung bei der Konfiguration, Parametrierung und/oder Diagnose zu erleichtern .
Ein modulares IO-Link Gerät ist ein "pseudomodulares Kompakt- gerät", d.h. es umfasst mehrere hier als Untereinheiten oder Abzweige bezeichnete Module (IO-Link SubDevices), die über einen geräteinternen Bus verbunden sind. Als Beispiel kann auf das von der Anmelderin unter der Bezeichnung "Kompaktabzweig SIRIUS 3RA6" angebotene Gerät verwiesen werden. Die einzelnen Untereinheiten sind bisher aber nach außen nicht sichtbar und nicht direkt ansprechbar, nämlich weil sie keine Adresse haben, keinen Port im IO-Link Modell belegen, keine Diagnoseinformationen liefern, usw.. Durch folgende technischen Merkmale lassen sich die oben skizzierten Probleme beseitigen:
1) Erweiterung eines IO-Link Objektmodells um Untereinheiten (IO-Link SubDevices)
2) Modellierung solcher Untereinheiten in der Gerätebeschrei- bung (z.B. IODD)
3) Grafische oder tabellarische Darstellung der Modularität von modularen IO-Link Geräten in genau einem Entwicklungswerkzeug . Entsprechend wird die weitere Aufgabe mit einem Verfahren mit den in Anspruch 2 zusammengefassten Merkmalen gelöst. Dazu ist bei einem Automatisierungssystem oder einem Verfahren zum Konfigurieren oder Parametrieren eines modularen IO-Link Gerätes in einem solchen Automatisierungssystem vorgesehen, dass beim Anlegen eines modularen IO-Link Gerätes in einem
Entwicklungswerkzeug ein erstes Objekt zur Repräsentation des modularen IO-Link Gerätes, ein zweites Objekt zur Repräsenta¬ tion eines in dem modularen IO-Link Gerät die Untereinheiten umfassenden oder aufnehmenden IO-Link Baugruppenrahmens, ein drittes Objekt zur Repräsentation der ausgewählten und als IO-Link Kopfbaugruppe fungierenden Untereinheit und mindes¬ tens ein viertes Objekt für jede weitere Untereinheit des mo¬ dularen IO-Link Gerätes angelegt wird. Das erste, zweite, dritte und vierte Objekt oder die jeweils zugrunde liegenden Objekttypen stellen die Erweiterung eines IO-Link Objektmodells dar. Das Anlegen eines Objekts zur Repräsentation des modularen IO-Link Gerätes und eventueller weiterer Objekte erfolgt dabei mit dem Entwicklungswerkzeug für eine Automati¬ sierungslösung zur Steuerung und/oder Überwachung eines technischen Prozesses. Die Automatisierungslösung umfasst das Automatisierungssystem und insoweit auch das IO-Link System als Bestandteil des Automatisierungssystems mit zumindest einem IO-Link Master und einem modularen IO-Link Gerät aber auch
Software zur Festlegung der Funktionalität der einzelnen Einheiten des Automatisierungssystems und deren Konfiguration, Parametrierung, usw..
Die hier vorgeschlagene Lösung basiert darauf, dass eine der Untereinheiten die Kommunikation über IO-Link nach außen übernimmt und damit quasi als Stellvertreter für das gesamte modulare IO-Link Gerät fungiert. Diese Untereinheit wird im Folgenden zur Unterscheidung auch als Kopfbaugruppe bezeichnet. Die Kopfbaugruppe kann eine vorgegebene Untereinheit, z.B. ein Kommunikationsmodul, oder eine beliebige Unterein¬ heit des modularen IO-Link Gerätes sein, die die kommunikati¬ ve Anbindung des modularen IO-Link Gerätes übernimmt und da¬ mit als Kopfbaugruppe fungiert. Nur diese Kopfbaugruppe benö¬ tigt Informationen hinsichtlich des internen Aufbaus des IO- Link Gerätes. Auf dieser Basis werden die von dem IO-Link Gerät umfassten Untereinheiten von der Kopfbaugruppe über einen völlig internen Mechanismus angesprochen. Das Vorhandensein der Untereinheiten wirkt sich nur auf die technologischen Funktionen des modularen IO-Link Gerätes aus, indem die Funktionen dieser Untereinheiten (durch Parameter, Diagnose, Prozessabbilder, ... ) freigeschaltet oder in sonst geeigneter Weise aktiviert werden. Dafür ist die Erweiterung des IO-Link Objektmodells um solche Untereinheiten notwendig. Das erweiterte Objektmodell erlaubt an der Oberfläche genau eines Entwicklungswerkzeugs ein modu- lares IO-Link Gerät als modulares Gerät mit einer Mehrzahl von Untereinheiten hantieren zu können. Damit können im Entwicklungswerkzeug alle vom modularen IO-Link Gerät umfassten Untereinheiten im Gerätekatalog selektiert und in der Geräte¬ sicht dem modularen IO-Link Gerät hinzugefügt werden, z.B. durch drag & drop.
Im Folgenden werden die wesentlichen Besonderheiten des erweiterten Objektmodells und die dafür vorgesehenen Objekte beschrieben. Grundvoraussetzung des erweiterten Objektmodells ist, dass ein modulares IO-Link Gerät stets durch eine Zusam¬ menfassung folgender Objekte modelliert wird: ein (erstes) Objekt für ein IO-Link Gerät, ein (zweites) Objekt für einen IO-Link Baugruppenrahmen, ein (drittes) Objekt für eine IO- Link Kopfbaugruppe und mindestens ein (viertes) Objekt für eine Untereinheit des modularen IO-Link Gerätes. Im Folgenden wird nicht immer auf ein Objekt als Repräsentant einer physi¬ kalischen Einheit hingewiesen, so dass z.B. anstelle an sich vollständiger Ausdrücke wie "Objekt zur Modellierung des IO- Link Gerätes" kurz auch nur "IO-Link Gerät" geschrieben wird. Aus dem Kontext ergibt sich dabei jeweils, ob ein Objekt als Repräsentant der physikalischen Einheit oder die physikali¬ sche Einheit selbst gemeint ist.
Vorteilhafte Ausgestaltungen des Ansatzes sind Gegenstand der Unteransprüche. Dabei verwendete Rückbeziehungen weisen auf die weitere Ausbildung des Gegenstandes des Hauptanspruches durch die Merkmale des jeweiligen Unteranspruches hin; sie sind nicht als ein Verzicht auf die Erzielung eines selbstän¬ digen, gegenständlichen Schutzes für die Merkmalskombinatio- nen der rückbezogenen Unteransprüche zu verstehen. Des Weiteren ist im Hinblick auf eine Auslegung der Ansprüche bei ei¬ ner näheren Konkretisierung eines Merkmals in einem nachgeordneten Anspruch davon auszugehen, dass eine derartige Beschränkung in den jeweils vorangehenden Ansprüchen nicht vor- handen ist.
Das Objekt zur Modellierung des IO-Link Gerätes ist dasjenige Objekt, das in einer Mastersicht (IO-Link Mastersicht) zur Darstellung des IO-Link Gerätes angezeigt wird. Das Objekt zur Modellierung des IO-Link Baugruppenrahmens ist ein Container für die von dem modularen IO-Link Gerät umfassten Untereinheiten, die damit in der Gerätesicht des Entwicklungs- Werkzeugs konfiguriert werden können. Über die Relationen des Objekts zur Modellierung des IO-Link Baugruppenrahmens zu der oder jeder Untereinheit werden erste Steckplatzregeln abgebildet, nämlich solche Steckplatzregeln, die bereits beim Kombinieren eines Objekts zur Modellierung einer Untereinheit mit dem IO-Link Baugruppenrahmen geprüft werden können.
Das Objekt zur Modellierung der Kopfbaugruppe fungiert als Stellvertreter für ein modulares IO-Link Gerät. Es repräsentiert die eigentliche technologische Funktionalität des modu- laren IO-Link Gerätes und ist Träger der meisten Geräteeigenschaften (Geräteparameter, Länge der Eingangs- und Ausgangsadresse, Gerätediagnosen, usw.). Ein modulares IO-Link Gerät ist ein pseudomodulares System, d.h. es kann mit Untereinhei¬ ten konfiguriert werden. Anders als bei echten modularen Sys- temen haben diese aber keine eigenen Parameter und entsprechend keine eigenen Anlaufdaten. Stattdessen ändert eine Untereinheit die Eigenschaften des modularen IO-Link Gerätes und die Eigenschaften des das modulare IO-Link Gerät model¬ lierenden Objektes, z.B. die Sichtbarkeit von Parametern. Da- zu muss die Kopfbaugruppe Informationen darüber haben, welche Untereinheiten aktuell konfiguriert sind. Diese Information kann über Objektreferenzen aus der Gerätebeschreibung ermittelt werden. Die Kopfbaugruppe ist das einzige Objekt, für das es in jedem Fall eine physikalische Entsprechung gibt. Die Kopfbaugruppe repräsentiert das modulare IO-Link Gerät an der Oberfläche des Entwicklungswerkzeugs. Daher ist es auch das Objekt, das als Bezeichnung zum Beispiel eine Bestellnummer (MLFB) eines IO-Link Gerätes trägt und damit über den Hardwarekatalog vom Anwender erzeugt werden kann. Alle anderen Objekte (IO-Link Baugruppenrahmen, IO-Link Gerät, IO-Link Untereinheit) werden dann zusätzlich implizit erzeugt. Die zur Parametrierung, Diagnose, Adressvergabe, etc. rele¬ vanten Aktionen und Dialoge sind über die Kopfbaugruppe, näm¬ lich das Kopfbaugruppenobjekt, erreichbar. Zusätzlich umfasst das Kopfbaugruppenobj ekt die Funktionalität zur Einbindung einzelner oder mehrerer Untereinheiten und die Funktionalität zur Anbindung an den IO-Link Master, d.h. einen dafür vorgesehenen IO-Link Port (Node) . Objekte zur Verwaltung von Adressinformationen (Adressobjekte) und der IO-Link Port (Node) sind Standardobjekte und werden automatisch erzeugt, wenn die Gerätebeschreibung entsprechende Attribute enthält, ebenso wie die Verlinkung zum IO-Link Mastersystem. Eine Untereinheit eines modularen IO-Link Gerätes hat außer einem Icon in der Gerätesicht und den Standarddialogen für Projektinforma¬ tionen keine eigene Oberfläche, keine eigenen Geräteparameter und auch keine Beziehungen zum IO-Link System.
In einer Ausführungsform des Verfahrens ist entsprechend vor¬ gesehen, dass beim Anlegen eines Objekts für ein modulares IO-Link Gerät automatisch ein Objekt für die ausgewählte und als IO-Link Kopfbaugruppe fungierende Untereinheit des modu¬ laren IO-Link Gerätes und/oder ein Objekt für den IO-Link Baugruppenrahmen des modularen IO-Link Gerätes, insbesondere auch und ebenfalls automatisch eine Verschaltung zwischen diesen Objekten, angelegt wird. Dies reduziert auf der einen Seite ansonsten manuell erforderliche Verfahrensschritte und sichert auf der anderen Seite die Konsistenz der Darstellung des Automatisierungssystems im Entwicklungswerkzeug, indem sichergestellt ist, dass bei einem modularen IO-Link Gerät die Anbindung an IO-Link ausschließlich über die als Kopfbau- gruppe ausgewählte Untereinheit erfolgt und indem weiter si¬ chergestellt ist, dass Repräsentanten für das die Kopfbau¬ gruppe umfassende IO-Link Gerät selbst und den IO-Link Bau¬ gruppenrahmen zur Verfügung stehen. Der hier beschriebene Ansatz umfasst auch eine Modellierung von IO-Link Untereinheiten in der Gerätebeschreibung. Derzeit - also gemäß dem Stand der Technik - sind in der Gerätebe¬ schreibung nur das IO-Link Gerät und seine Eigenschaften (Pa- rameter, Diagnosen, ... ) beschrieben. Etwaige IO-Link Untereinheiten werden soweit möglich durch Geräteparameter er- fasst . Nachfolgend ist dazu eine beispielhafte Gerätebeschreibung gemäß dem Stand der Technik für das weiter oben bereits erwähnte Gerät der Anmelderin, nämlich Kompaktabzweig SIRIUS 3RA6, eingeblendet:
<Text id= "TI DS130 Bytel2" value=" Startertyp
<Text id= "TI DS130 BGID DS _010- 040"
value= "Direktstarter DS 0,1 ... 0,4 A" />
<Text id= "TI DS130 BGID DS _032- 125"
value= "Direktstarter DS 0, 32 • · · 1^25 A.
<Text id= "TI DS130 BGID DS _100- 400"
value= "Direktstarter DS 1 .. . 4 A" />
<Text id= "TI DS130 BGID DS _300- 1200"
value= "Direktstarter DS 3 .. . 12 A" />
<Text id= "TI DS130 BGID DS _800- 3200"
value= "Direktstarter DS 8 .. . 32 A" />
<Text id= "TI DS130 BGID RS _010- 040"
value= "Wendestarter RS 0,1 . .. 0,4 A" />
<Text id= "TI DS130 BGID RS _032- 125"
value= "Wendestarter RS 0, 32 ... 1,25 A" /
<Text id= "TI DS130 BGID RS _100- 400"
value= "Wendestarter RS 1 4 A" />
<Text id= "TI DS130 BGID RS _300- 1200"
value= "Wendestarter RS 3 12 A" />
<Text id= "TI DS130 BGID RS _800- 3200"
value= "Wendestarter RS 8 ... 32 A" />
Zur Modellierung eines modularen IO-Link Gerätes mit IO-Link wird gemäß dem hier vorgeschlagenen Ansatz nicht nur das Objektmodell sondern auch die Gerätebeschreibung erweitert und zwar zumindest um
eine Beschreibung aller Objekte des Objektmodells, nämlich IO-Link Gerät, IO-Link Baugruppenrahmen, IO-Link Kopfbaugruppe und IO-Link Untereinheit, Beschreibung der Gerätekonfiguration: Anzahl Steckplätze, steckbare Gerätetypen, usw.
verwendbare Typen von IO-Link Untereinheiten,
Beschreibung der IO-Link Untereinheit für die Darstellung im Hardwarekatalog und
Steckplatzregeln.
Hinsichtlich der Steckplatzregeln kommt in Betracht, nur sogenannte harte Steckplatzregeln abzudecken, wobei hart in diesem Zusammenhang bedeutet, dass eine Auswahl einer IO-Link Untereinheit und deren Kombination mit dem modularen IO-Link Gerät aus dem Hardwarekatalog verhindert wird.
Im Folgenden werden nur die wichtigsten Attribute beschrie- ben, die für die Abbildung des erweiterten IO-Link Objektmodells in der Gerätebeschreibung erforderlich sind. Wenn beispielhaft konkrete Werte aufgeführt werden, sind dies oftmals Werte des bereits erwähnten Gerätes, nämlich des Kompaktab¬ zweigs SIRIUS 3RA6. Die Geräteparameter und -diagnosen können dabei in der gleichen Art und Weise wie bereits derzeit in der Gerätebeschreibung vorgesehen beschrieben werden (Byte- Offset, Bit-Offset, Datentyp, Länge, Defaultwert, ID, ... ) .
Allgemeine Attribute aller Objekte:
VARIABLE Comment;
// Gerätespezifischer Kommentar,
// z.B. "Förderband Halle 3, Motor 12"
VARIABLE Name;
// Gerätespezifischer Name,
// z.B. "Conveyer23. Starter07"
VARIABLE MLFB;
// Bestellnummer, z.B. "3RA6234-0AA1-0BBX"
VARIABLE ObjectType;
// Typ des Objekts
VARIABLE Objectld;
// Eindeutige Identifikationsnummer des Objekts Attribute für Objekte zur Modellierung eines IO-Link Gerätes:
VARIABLE ObjectType;
// Typ des Objekts = IO_LINK_DEVICE
// (eindeutige Objekttypnummer, Konstante)
VARIABLE Objectld;
// Identifikationsnummer des Objekts,
// z.B. SIRIUS_3RA6 (eindeutige Objektnummer, Konstante) VARIABLE ContainerSize : 1 ;
// ein IO-Link-Device enthält immer ein Rack
VARIABLE TypeName;
/ / zur Anzeige im Entwicklungswerkzeug,
// z.B. "Kompaktabzweig SIRIUS 3RA6" Attribute für Objekte zur Modellierung eines IO-Link Baugrup¬ penrahmens :
VARIABLE ObjectType;
// Typ des Objekts = IO_LINK_DEVICE_RACK
// (eindeutige Objekttypnummer, Konstante)
VARIABLE Objectld;
// Identifikationsnummer des Objekts, z.B.
// SIRIUS_3RA6_3RA6 (eindeutige Objektnummer, Konstante) VARIABLE ContainerSize: 4;
// Anzahl der verfügbaren Steckplätze im Rack;
// beim Kompaktabzweig SIRIUS 3RA6 z.B. 4
Attribute für Objekte zur Modellierung einers IO-Link Kopf¬ baugruppe :
VARIABLE ObjectType;
// Typ des Objekts = IO_LINK_HEAD_DEVICE
// (eindeutige Objekttypnummer, Konstante)
VARIABLE Objectld;
// Identifikationsnummer des Objekts, z.B.
// SIRIUS_3RA6_HEAD (eindeutige Objektnummer, Konstante) VARIABLE PositionNumber;
// Die aktuelle Slotnummer der Kopfbaugruppe, beim
// Kompaktabzweig SIRIUS 3RA6 von 0 bis 3
VARIABLE UICapabilities : 0 ;
// 0 = das Modul ist virtuell und wird im
// Entwicklungswerkzeug nicht angezeigt
VARIABLE InAddressRange ;
VARIABLE OutAddressRange ;
// Größe der Ein- und Ausgangsadressen des Slaves im // Adressraum der SPS/des IO-Link Mastersystems
// z.B. beim Kompaktabzweig: 8 = 8 Byte, 16 = 16 Byte VARIABLE PARAMETER_17 ;
// Ein Geräteparameter des IO-Link Gerätes, analog der
// Spezifikation der IODD
VARIABLE DIAGNOS I S_27 ;
// Eine Gerätediagnose des IO-Link-Devices ,
// analog Spezifikation der IODD
Attribute für Objekte zur Modellierung einers IO-Link Unter- einheit:
VARIABLE ObjectType;
// Typ des Objekts = IO_LINK_SUB_DEVICE
// (eindeutige Objekttypnummer, Konstante)
VARIABLE Objectld;
// Identifikationsnummer des Objekts, z.B.
// SIRIUS_DIRECTSTARTER_3_12A
// (eindeutige Objektnummer, Konstante)
VARIABLE PositionNumber:
// die aktuelle Slotnummer des Moduls, beim
// Kompaktabzweig SIRIUS 3RA6 von 0 bis 3
VARIABLE TypeCode;
// u.a. für die Parametrierung . Z.B.
// Bit 15 == 1
// (Baugruppe nicht parametrierbar)
// Bit 15 == 0
// (Baugruppe ist parametrierbar) VARIABLE FWMainVersion : 1 ;
VARIABLE FWVersion: "V1.0";
// Firmwareversion
VARIABLE UICapabilities : 1 ;
// 1 = das Modul wird im Entwicklungswerkzeug angezeigt
Auf Basis des hier beschriebenen erweiterten IO-Link Objektmodells und der ebenfalls erweiterten, das erweiterte IO-Link Objektmodell abbildenden Gerätebeschreibung kann im Entwick- lungswerkzeug ein modulares IO-Link Gerät mit allen davon um- fassten Untereinheiten dargestellt werden. Die Darstellung umfasst zumindest eine Möglichkeit zur Diagnose einzelner IO- Link Untereinheiten mit der Anzeige der Ergebnisse der Diagnose. Sodann umfasst die Darstellung eine Anzeige eines Aus- baus und/oder einer Konfiguration des modularen IO-Link Gerätes mit seinen Untereinheiten und zwar tabellarisch und/oder grafisch. Schließlich umfasst die Darstellung auch eine Unterstützung des Hardwarekatalogs bei der Geräteauswahl. Durch die Erweiterung des Objektmodells und der Gerätebe¬ schreibung für IO-Link sowie der grafischen Darstellung im Entwicklungswerkzeug ist es nun zumindest möglich,
die einzelnen Untereinheiten eines modularen IO-Link Gerätes aus einem Hardwareauswahlkatalog auszuwählen,
- das modulare IO-Link Gerät durch drag & drop zu konfigu¬ rieren (grafisch oder tabellarisch) ,
eine jeweils tatsächliche Gerätekonfiguration offline und online darzustellen,
einen Soll/Ist-Vergleich der Konfiguration durchzuführen, - von den einzelnen Untereinheiten erhaltene oder erhältliche Diagnoseinformationen an der jeweiligen Untereinheit in der Hardwarekonfiguration darzustellen,
die Größen der Prozessabbilder der Eingänge und der Ausgänge (PAE bzw. PAA) konsistent zu halten,
- die Adresslänge und -Zuordnung abhängig vom Ausbau automa¬ tisch zu berechnen,
ein Produktbild, das dem tatsächlichen Ausbau entspricht, anzuzeigen und eine vollständige und korrekte Kundendokumentation anzu¬ zeigen .
Dadurch wird die gesamte Projektierung eines IO-Link Systems für den Kunden effizienter und weniger fehleranfällig. Insgesamt werden weniger Schritte für die Projektierung benötigt und die Projektierung des gesamten IO-Link Systems kann nun durchgängig mit einem Entwicklungswerkzeug erfolgen. Damit ergeben sich in einem Entwicklungswerkzeug der Anmelde¬ rin die folgenden erforderlichen Schritte beim Projektieren eines IO-Link Systems, wobei sich bei anderen Entwicklungs¬ werkzeugen ähnliche oder vergleichbare Abläufe ergeben wer¬ den :
1) Konfiguration des IO-Link Masters
Alle von der Anmelderin verfügbaren IO-Link Master sind bereits im Hardwareauswahlkatalog enthalten. Eine Auswahl eines konkreten IO-Link Masters erfolgt z.B. durch drag & drop des ausgewählten Gerätes in die Hardwarekonfiguration.
Die Parameter des IO-Link Masters können sodann im Entwicklungswerkzeug über ein Eigenschaftsfenster des den IO-Link Masters repräsentierenden Objekts eingestellt werden.
2) Konfiguration der IO-Link Geräte
Alle von der Anmelderin verfügbaren IO-Link Geräte sind bereits im Hardwareauswahlkatalog enthalten. Zertifizierte Ge¬ räte von Drittanbietern lassen sich mittels ihrer in der Fachterminologie als IODD bezeichneten Gerätebeschreibungsda¬ tei in die vom Entwicklungswerkzeug verwendete Datenbasis in¬ tegrieren. Die Auswahl eines konkreten IO-Link Gerätes erfolgt z.B. durch drag & drop des ausgewählten Gerätes in eine Konfigurationsapplikation .
Die Parameter des IO-Link Gerätes können sodann im Entwicklungswerkzeug über ein Eigenschaftsfenster des das IO-Link Gerät repräsentierenden Objekts eingestellt werden. 3) Konfiguration der IO-Link Untereinheiten
IO-Link Untereinheiten (Subdevices, Abzweige) können im Hardwareauswahlkatalog ausgewählt werden. Eine grafische Projek¬ tierung mittels drag & drop der einzelnen IO-Link Unterein- heiten ist nun möglich.
Modulare IO-Link Geräte werden in der Gerätesicht der Hard¬ warekonfiguration konfiguriert. Da hier Anzahl und Typ der verwendeten IO-Link Geräte und der Untereinheiten bekannt sind, können ein Anfang und eine Länge eines Datenbereichs mit E/A-Adressen automatisch bestimmt werden.
Die Parameter jeder IO-Link Untereinheit können im Entwicklungswerkzeug über ein Eigenschaftsfenster des die IO-Link Untereinheit repräsentierenden Objekts eingestellt werden.
4) IO-Link Diagnose
Die Diagnoseinformationen aller Baugruppen werden ausgelesen und angezeigt. Bei einer für einen IO-Link Master abgerufenen Diagnoseninformation ist dies die Sammeldiagnose des Masters (die Diagnoseinformation korrespondiert mit dem Status einer LED auf dem IO-Link Master) oder eine Diagnoseinformation bezüglich der für den IO-Link Master erreichbaren IO-Link Geräte .
5) Diagnose modularer IO-Link Geräte
Bei modularen IO-Link Geräten korrespondiert ein jeweiliger Status der Geräte-LEDs mit den entsprechenden von der Diagno¬ seinformation umfassten Daten (Sammelfehler, Sammelwarnung, etc.) . Die Diagnoseinformationen und ein Status der Ein/Aus¬ gänge der einzelnen Untereinheiten sind sichtbar.
Nachfolgend wird ein Ausführungsbeispiel der Erfindung anhand der Zeichnung näher erläutert. Einander entsprechende Gegen- stände oder Elemente sind in allen Figuren mit den gleichen Bezugszeichen versehen. Es zeigen
FIG 1 ein Automatisierungssystem mit mehreren IO-Link Geräten,
FIG 2 ein IO-Link Gerät in einer Ausführungsform als modu- lares IO-Link Gerät,
FIG 3 eine Darstellung von IO-Link Geräten durch ein Ent- wicklungswerkzeug und
FIG 4 ein Flussdiagramm zur Veranschaulichung eines Verfahrens zum Anlegen von Objekten in dem Entwicklungswerkzeug für IO-Link Geräte.
FIG 1 zeigt schematisch stark vereinacht ein Automatisie¬ rungssystem 10 zur Steuerung und/oder Überwachung eines nicht näher dargestellten industriellen technischen Prozesses 12. Das Automatisierungssystem 10 umfasst zumindest ein Automati- sierungsgerät 14, z.B. eine speicherprogrammierbare Steue¬ rung. Dieses umfasst zur Anbindung von Sensoren und/oder Aktoren über den als IO-Link bekannten Kommunikationsstandard einen IO-Link Master 16. An den IO-Link Master 16 sind in an sich bekannter Art und Weise über Punkt-zu-Punkt Verbindungen IO-Link Geräte 18, 20, 22 angeschlossen. Bei zumindest einem der angeschlossenen IO-Link Geräte 18, 20, 22 handelt es sich um ein modulares IO-Link Gerät 20, das - wie FIG 2 schema¬ tisch vereinfacht zeigt - eine Mehrzahl von IO-Link Untereinheiten umfasst. FIG 2 zeigt darüber hinaus, dass das IO-Link Gerät 20 ein oder mehrere IO-Link Untereinheiten 24, 26, 28 umfassen kann, von denen genau eine als Kopfbaugruppe 24 fungiert. Zur Aufnahme der Untereinheiten 24, 26, 28 weist das IO-Link Gerät 20 Steckplätze auf und innerhalb des IO-Link Gerätes 20 verläuft in einem Baugruppenrahmen 30 zu jedem Steckplatz ein geräteinterner Bus 32, so dass alle von einem IO-Link Gerät 20 umfassten Untereinheiten kommunikativ verbunden und speziell für die Kopfbaugruppe erreichbar sind. Der IO-Link Master 16, die IO-Link Geräte 18, 20, 22 und die zur kommunikativen Verbindung dieser Einheiten vorgesehenen Punkt-zu-Punkt Verbindungen bilden zusammen das IO-Link System (FIG 1), in dem der IO-Link Master 16 als übergeordnete Einheit fungiert. Zur Kommunikation mit dem IO-Link Master 16 wird eine von der Untereinheiten 24, 26, 28 des modularen IO- Link Gerätes 20 als Kopfbaugruppe 24 ausgewählt. Die Kommuni¬ kation mit dem IO-Link Master 16 erfolgt nur mit dieser Kopfbaugruppe 24 direkt. Alle von dem modularen IO-Link Gerät 20 umfassten Untereinheiten 24, 26, 28 sind in dem IO-Link System über diese Kopfbaugruppe 24 indirekt, nämlich ausgehend von der Kopfbaugruppe 24 über den geräteinternen Bus 32, erreichbar . Zur Konfiguration, Parametrierung, Diagnose, usw. von IO-Link Geräten wird ein als Software verfügbares Entwicklungswerkzeug 34 (FIG 1) verwendet. Diese Software kann auf einem Pro¬ grammiergerät 36 (FIG 1) oder dergleichen ausgeführt werden, das zumindest temporär direkt oder indirekt, z.B. über Inter- net, an das Automatisierungssystem 10 anschließbar ist. Das Programmiergerät 36, z.B. ein Personalcomputer, weist dafür in an sich bekannter Art und Weise einen Speicher 38 und eine Verarbeitungseinheit nach Art eines Mikroprozessors (nicht dargestellt ) auf . Wenn das Entwicklungswerkzeug 34 in den Speicher 38 geladen ist, kann es durch die Verarbeitungseinheit ausführt werden.
FIG 3 zeigt dazu schematisch vereinfacht eine mögliche Dar¬ stellung des IO-Link Objektmodells. Gezeigt ist, dass beim Anlegen eines modularen IO-Link Gerätes 20 mit dem Entwicklungswerkzeug 34 ein erstes Objekt 40 zur Repräsentation des modularen IO-Link Gerätes 20, ein zweites Objekt 42 zur Rep¬ räsentation des in dem modularen IO-Link Gerät 20 die Untereinheiten 24,26, 28 umfassenden oder aufnehmenden IO-Link Baugruppenrahmens 30, ein drittes Objekt 44 zur Repräsentati¬ on der ausgewählten und als IO-Link Kopfbaugruppe 24 fungie¬ renden Untereinheit und mindestens ein viertes Objekt 46 für jede weitere Untereinheit 26, 28 des modularen IO-Link Gerä¬ tes 20 angelegt wird.
In FIG 3 ist auch ersichtlich, dass die Anbindung des modula- ren IO-Link Gerätes 20 an das IO-Link System (FIG 1) nur über die das modulare IO-Link Gerät 20 nach außen repräsentierende Kopfbaugruppe 24, nämlich das für die IO-Link Kopfbaugruppe 24 generierte dritte Objekt 44 erfolgt. Ein fünftes Objekt 48 stellt eine Punkt-zu-Punkt Verbindung zwischen dem IO-Link Master und dem modularen IO-Link Gerät 20 dar. Der IO-Link Master 16 wird durch ein sechstes Objekt 50 repräsentiert. Die Darstellung durch das Entwicklungswerkzeug 34 und die der Darstellung zugrunde liegenden Verknüpfungen der einzelnen Objekte bewirkt die kommunikative Erreichbarkeit der IO-Link Kopfbaugruppe 24 im IO-Link System und speziell durch den IO- Link Master 16. Selbstverständlich kann ein komplexes IO-Link System eine Mehrzahl von IO-Link Geräten 18, 20, 22 und ebenfalls eine Mehrzahl von modularen IO-Link Geräten 20 umfass- ten. Je nach Art und Umfang des IO-Link Systems bezieht sich dessen Darstellung durch das Entwicklungswerkzeug 34 auf eine entsprechende Mehrzahl der jeweiligen Objekte.
Bei einer besonderen Ausführungsform des Softwarewerkzeugs 34 werden beim Anlegen eines Objekts 40 für ein modulares IO- Link Gerät 20 das Objekt 44 für die IO-Link Kopfbaugruppe 24 und/oder das Objekt 42 für den IO-Link Baugruppenrahmen 30 automatisch angelegt. Das Anlegen eines Objekts 40 für ein modulares IO-Link Gerät 20 erfolgt zum Beispiel indem der Verwender des Softwarewerkzeugs in einem Hardwarekatalog das jeweilige modulare IO-Link Gerät 20 auswählt und mittels heu¬ te üblicher Bedienhandlungen, z.B. drag&drop, in der Automatisierungslösung platziert.
Das Softwarewerkzeug 34 in einer solchen oder einer anderen Ausführungsform ist nicht separat dargestellt, nachdem es sich insoweit nur um zusätzliche oder alternative Software¬ funktionalität des Softwarewerkzeugs 34 handelt. Bei einer weiteren Ausführungsform des Softwarewerkzeugs 34 ist vorge- sehen, dass beim automatischen Anlegen eines Objekts 42 für den IO-Link Baugruppenrahmen 30 automatisch Objekte 46 für von dem den IO-Link Baugruppenrahmen 30 aufnehmbare Untereinheiten 26, 28 angelegt werden. Des Weiteren ist optional für die Funktionalität des Softwarewerkzeugs 34 vorgesehen, dass beim automatischen Anlegen von Objekten 42, 44, 46 ebenfalls automatisch eine Verschaltung zwischen den automatisch angelegten Objekten 42, 44, 46 erfolgt. Die insoweit angelegte Verschaltung entspricht der in FIG 3 schematisch dargestell- ten Verschaltung und macht zum Beispiel ausgehend von dem Ob¬ jekt 44 zur Repräsentation der Kopfbaugruppe 24 das Objekt 42 zur Repräsentation des IO-Link Baugruppenrahmens 30 und mit¬ telbar die Objekte 40, 46 zur Repräsentation des modularen IO-Link Gerätes 20 und/oder zur Repräsentation der von dem IO-Link Baugruppenrahmen 30 umfassten oder von dem IO-Link Baugruppenrahmen 30 aufnehmbaren Untereinheiten 26, 28 zugänglich .
FIG 4 macht diesen Aspekt, also die diesbezügliche Funktiona- lität des Softwarewerkzeugs 34, schematisch vereinfacht an¬ hand eines Flussdiagramms deutlich: Beim Anlegen von Objekten (erster Funktionsblock 52) mit dem Softwarewerkzeug 34 wird überprüft, ob es sich bei dem angelegen Objekt oder bei dem Objekttyp, der zum Anlegen eines Objektes ausgewählt wurde, um ein Objekt 40 zur Repräsentation eines modularen IO-Link Gerätes 20 handelt. Ist dies der Fall wird zu einem zweiten Funktionsblock 54 verzweigt, mit dem automatisch Objekt 42 für den IO-Link Baugruppenrahmen 30 angelegt wird. Wenn es sich bei dem Softwarewerkzeug 34 um ein Softwarewerkzeug 34 in der oben bereits beschriebenen besonderen Ausführungsform handelt, wird in einem optionalen vierten Funktionsblock 56 überprüft, um was für einen IO-Link Baugruppenrahmen 30, für den als Repräsentant das Objekt 42 angelegt wurde, es sich handelt und es werden sodann (fünfter Funktionsblock 58) au- tomatisch Objekte 46 für von dem IO-Link Baugruppenrahmen 30 umfasste oder von dem IO-Link Baugruppenrahmen 30 aufnehmbare Untereinheiten 26, 28 angelegt. Wenn der durch das Objekt 42 repräsentierte physikalische IO-Link Baugruppenrahmen 30 noch keine gesteckten Untereinheiten 26, 28 aufweist, werden als Objekte 46 gleichsam Platzhalterobjekte erzeugt; wenn der 10- Link Baugruppenrahmen 30 an einzelnen oder allen Steckplätzen bereits Untereinheiten 26, 28 aufweist, können die automa- tisch erzeugten Objekte in Ansehung der tatsächlich gesteckten Untereinheiten 26, 28 erzeugt werden, indem für diese z.B. Daten aus der jeweiligen Gerätebeschreibung übernommen werden .

Claims

Patentansprüche
1. Verfahren zum Betrieb eines Automatisierungssystems (10), wobei das Automatisierungssystem (10) in kommunikativer Ver- bindung eine übergeordnete Einheit (14) und zumindest ein mo- dulares IO-Link Gerät (20) mit einem geräteinternen Bus (32) und darüber ansprechbaren, von dem modularen IO-Link Gerät (20) umfassten Untereinheiten (24, 26, 28) umfasst, wobei zur Kommunikation mit dem modularen IO-Link Gerät (20) eine von dessen Untereinheiten (24, 26, 28) ausgewählt wird und die Kommunikation nur mit dieser direkt und über diese indirekt mit den anderen Untereinheiten (24, 26, 28) des modularen IO- Link Gerätes (20) erfolgt.
2. Verfahren zum Betrieb eines Automatisierungssystems (10) nach Anspruch 1 oder Verfahren zum Konfigurieren oder Para- metrieren eines modularen IO-Link Gerätes (20) in einem Automatisierungssystem (10), wobei beim Anlegen eines modularen IO-Link Gerätes (20) in einem Entwicklungswerkzeug (34) ein erstes Objekt (40) zur Repräsentation des modularen IO-Link Gerätes (20), ein zweites Objekt (42) zur Repräsentation ei¬ nes in dem modularen IO-Link Gerät (20) die Untereinheiten (24, 26, 28) umfassenden oder aufnehmenden IO-Link Baugruppenrahmens (30), ein drittes Objekt (44) zur Repräsentation der ausgewählten und als IO-Link Kopfbaugruppe (24) fungie¬ renden Untereinheit und mindestens ein viertes Objekt (46) für jede weitere Untereinheit (26, 28) des modularen IO-Link Gerätes (20) angelegt wird.
3. Verfahren nach Anspruch 2, wobei beim Anlegen eines Objekts (40) für ein modulares IO-Link Gerät (20) automatisch ein Objekt (44) für die ausgewählte und als IO-Link Kopfbau¬ gruppe (24) fungierende Untereinheit des modularen IO-Link Gerätes (20) angelegt wird.
4. Verfahren nach Anspruch 3, wobei beim Anlegen eines Objekts (40) für ein modulares IO-Link Gerät (20) automatisch ein Objekt (42) für den IO-Link Baugruppenrahmen (30) des mo- dularen IO-Link Gerätes (20) angelegt wird.
5. Verfahren nach Anspruch 4, wobei beim automatischen Anle- gen eines Objekts (42) für den IO-Link Baugruppenrahmen (30) automatisch Objekte (46) für von dem den IO-Link Baugruppenrahmen (30) aufnehmbare Untereinheiten (26, 28) angelegt wer¬ den .
6. Verfahren nach Anspruch 3, 4 oder 5, wobei für das oder jedes automatisch angelegte Objekt (42, 44, 46) automatisch eine Verschaltung des automatisch angelegten Objekts (42, 44, 46) mit dem Objekt (40) zur Repräsentation des modularen IO- Link Gerätes (20) und/oder mit anderen automatisch angelegten Objekten (42, 44, 46) erfolgt.
7. Computerprogramm mit Programmcodemitteln zur Implementation des Verfahrens nach einem der Ansprüche 1 bis 6, wenn das Computerprogramm auf einem Computer, insbesondere einem Pro- grammiergerät zum Erstellen und Bearbeiten eines Computerpro¬ gramms als Automatisierungslösung zur Steuerung und/oder Überwachung eines technischen Prozesses, ausgeführt wird.
8. Computerprogrammprodukt mit einem durch einen Computer ausführbaren Computerprogramm gemäß Anspruch 7.
9. Programmiergerät (36) zum Erstellen und Bearbeiten eines Computerprogramms als Automatisierungslösung zur Steuerung und/oder Überwachung eines technischen Prozesses mit einem Speicher (38) in den als Entwicklungswerkzeug (34) ein Compu¬ terprogramm nach Anspruch 7 geladen ist.
EP11723353.6A 2011-05-13 2011-05-13 Verfahren zum betrieb eines automatisierungssystems Withdrawn EP2689305A1 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2011/057769 WO2012155949A1 (de) 2011-05-13 2011-05-13 Verfahren zum betrieb eines automatisierungssystems

Publications (1)

Publication Number Publication Date
EP2689305A1 true EP2689305A1 (de) 2014-01-29

Family

ID=44626751

Family Applications (1)

Application Number Title Priority Date Filing Date
EP11723353.6A Withdrawn EP2689305A1 (de) 2011-05-13 2011-05-13 Verfahren zum betrieb eines automatisierungssystems

Country Status (6)

Country Link
EP (1) EP2689305A1 (de)
KR (1) KR101883731B1 (de)
CN (1) CN103518164B (de)
BR (1) BR112013029063B1 (de)
CA (1) CA2835535C (de)
WO (1) WO2012155949A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2899679A1 (de) * 2014-01-24 2015-07-29 Siemens Aktiengesellschaft Auswahl von Schaltgeräten für Motoranwendungen
LU101427B1 (de) * 2019-10-02 2021-04-08 Phoenix Contact Gmbh & Co Ein/Ausgabe-Station für ein Feldbussystem, Feldbus-Koppler für die Ein/Ausgabe-Station, sowie Platzhaltermodul für die Ein/Ausgabe-Station

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6662247B1 (en) * 1999-11-30 2003-12-09 Rockwell Automation Technologies, Inc. Protocol for extended data transfer in scan-based industrial controller I/O system
DE102004010096A1 (de) * 2004-02-27 2005-09-15 Endress + Hauser Gmbh + Co. Kg Verfahren zum Betreiben eines Feldgerätes der Automatisierungstechnik
US20060155858A1 (en) * 2004-11-16 2006-07-13 Lg Electronics Inc. Network device and information protocol for open network system
EP2098925A1 (de) * 2008-03-07 2009-09-09 Sick Ag Verfahren und Vorrichtung zum Programmieren und/oder Konfigurieren einer Sicherheitssteuerung
EP2133763A1 (de) * 2008-06-12 2009-12-16 Siemens Aktiengesellschaft Verfahren zum Betrieb eines Automatisierungssystems
DE102009013303A1 (de) * 2009-03-16 2010-09-30 Siemens Aktiengesellschaft Verwendung eines IO-Links

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2012155949A1 *

Also Published As

Publication number Publication date
KR101883731B1 (ko) 2018-08-01
CN103518164B (zh) 2016-08-17
WO2012155949A1 (de) 2012-11-22
CA2835535A1 (en) 2012-11-22
KR20140026556A (ko) 2014-03-05
CN103518164A (zh) 2014-01-15
BR112013029063B1 (pt) 2020-12-22
CA2835535C (en) 2018-12-11
BR112013029063A2 (pt) 2017-02-07

Similar Documents

Publication Publication Date Title
DE10049049B4 (de) System und Verfahren zur Konfiguration einer Prozeßsteuerung zur Verwendung mit einem Profibus-Einrichtungsnetzwerk
DE10049025B4 (de) Prozesssteuersystem, Verfahren zur Konfiguration eines Prozesssteuersystems
DE112004000223T5 (de) Schnittstellenmodul zur Verwendung mit einem Modbus-Gerätenetz und Fieldbus-Gerätenetz
DE102009054901A1 (de) Verfahren zur offline Bedienung eines Feldgeräts der Automatisierungstechnik
DE102007026678A1 (de) Verfahren zum Austausch eines defekten Feldgerätes gegen ein neues Feldgerät in einem über digitalen Feldbus kommunizierenden System, insbesondere Automatisierungssystem
DE102008007230A1 (de) Verfahren und Vorrichtungen zum Konfigurieren von Prozesssteuerungssystem-Eingängen und -Ausgängen
DE102017108539A1 (de) Verfahren und Cloud Gateway zum Überwachen einer Anlage der Automatisierungstechnik
DE102010029952A1 (de) Verfahren zum Integrieren von zumindest einem Feldgerät in ein Netzwerk der Automatisierungstechnik
WO2012139870A2 (de) Verfahren zur offline-konfiguration eines feldgeräts
WO2012089429A1 (de) Feldgerät mit langzeit-firmware-kompatibilität
DE102006062605A1 (de) Verfahren zur Online-Bedienung eines Feldgerätes der Automatisierungstechnik
WO2009074544A1 (de) Verfahren zum betreiben eines systems aufweisend ein feldgerät und ein bediensystem
DE102007054417A1 (de) Bestimmen von geräteinternen Parameteradressen aus feldbusspezifischen Parameteradressen eines Feldgerätes
DE102007028841B4 (de) Feldbuseinheit und Verfahren zur Konfiguration einer Feldbuseinheit
EP2042956A2 (de) Schnittstelle zwischen einem Fertigungsmanagementsystem und einem Automatisierungssystem
EP1714197B1 (de) Gerätetreiber für feldgeräte der prozessautomatisierungstechnik
EP1233317B1 (de) Vorrichtung und Verfahren zur Erstellung von Bedienungskomponenten
DE10208530A1 (de) Betriebseinheit, Peripheriegerät und Verfahren zum Betrieb eines Peripheriegeräts
EP1758001B1 (de) Verfahren und System zum Abbilden der Struktur einer Automatisierungsanlage auf einem Rechner
WO2012155949A1 (de) Verfahren zum betrieb eines automatisierungssystems
EP2557464B1 (de) Verfahren zum Betrieb eines Automatisierungssystems
WO2009019108A1 (de) Verfahren zum erstellen einer software in einem feldgerät durch einen benutzer
DE102006062604A1 (de) Verfahren zum Testen von Gerätebeschreibungen für Feldgeräte der Automatisierungstechnik
DE10245890B4 (de) Bildschirmelement, HMI Gerät, Automatisierungssystem und Computerprogrammprodukt zur Visualisierung und Projektierung von einfach und mehrfach verwendeten Anwendertexten und der in einem Datenverarbeitungssystem zugeordneten Verwendungsstellen
EP1454201B1 (de) Engineeringsystem und automatisierungssystem

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20131025

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20160704

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20200129