BR112013029063B1 - method for the operation of an automation system - Google Patents

Abstract

METHOD FOR OPERATING AN AUTOMATION SYSTEM. The present invention relates, in particular, to a method for operating an automation system (10), wherein the automation system (10) comprises, in a communicatively connected form, a subordinate Link IO unit (14) and at least one modular IO Link equipment (20) that has an internal equipment bus (32) and the subunits (24, 26, 28) that can be addressed by means of the latter and whose modular IO Link equipment (20) comprises , in which the method is distinguished by the fact that communication with the modular IO Link equipment (20) involves the selection of one of the subunits (24, 26, 28) of the same, and the communication occurs only with that subunit directly and through the latter with the other subunits (24, 26, 28) of the modular IO Link equipment (20) indirectly

Description

[0001] The present invention relates to a method for operating an automation system, particularly an automation system comprising Link IO devices, and to a method for administering such Link IO devices, in particular with regard to configuration and parameterization.

[0002] A concept for the standardized connection of sensors and actuators (eg switches) to a control level via a low-cost point-to-point connection is known under the trademark IO-Link for PROFIBUS User Organization (PROFIBUS Nutzerorganisation eV). This communication pattern below the fieldbus level allows the diagnosis of central error and the location up to the sensor / actuator level. As an open interface, Link IO can be integrated with all common field buses and automation systems. The communication system mentioned above will be called below in an abbreviated form as the Link IO.

[0003] The Link IO specification (current version: V1.0, 2008/2009) describes how Link IO devices from different equipment manufacturers can be connected to a point-to-point connection. According to the specification, parameters, diagnostics, etc. for these devices they can be transferred to and from a so-called Link IO master as a subordinate Link IO unit. The term "diagnosis" is understood here and hereinafter refers, on the one hand, to diagnostic information that results from a verification or a status query of the specific device and, on the other hand, to the description of a type and / or extension of such verification or status query, as well as measured values (currents, voltages, temperatures, etc.), statistical data (hours of operation, etc.), logbooks, etc. Link IO devices, in particular the respective parameters, diagnostics, etc., are described in a dedicated device description (IODD) file.

[0004] However, the device description does not allow the modeling of modular IO Link devices such as, for example, the so-called compact initiators offered by the applicant under the name "SIRIUS 3RA6". Only compact Link IO devices can be described. Modularity information is, so to speak, from hidden devices, specifically parameters or diagnostic information (eg error messages, service life, end position, etc.) that are not required or are less relevant.

[0005] Due to this restriction, Link IO modular devices can be represented in the configuration and diagnosis of Link IO engineering software (eg SIMATIC STEP7) only as a compact device with universal configuration , diagnosis, etc. Such representations are, therefore, often misleading or even incorrect. For example, a central group error LED does not provide information about which of a plurality of subunits of a modular IO Link device is defective.

[0006] It is also not possible, in particular, to - select the individual subunits, that is, the modules or the devices of a modular IO Link Device from a hardware selection catalog; - configure the modular IO Link Device through standard user actions, such as drag and drop, either in graphical or tabular form; - represent the configuration of the real device offline and online; - perform a target / actual comparison of the configuration device; - represent the diagnostic screens (for example, device LEDs) of the individual modules / devices in the online configuration; - keep the sizes of the process images, that is, the process image of the inputs (PAE) and the process image of the outputs (PAA), accordingly; - calculate the address length and automatic assignment depending on the expansion; or - display a product image that corresponds to the actual expansion.

[0007] An additional disadvantage is that two different development tools are always necessary for Link IO engineering, that is, a first development tool, for example, the applicant's engineering software known under the name STEP7, for the configuration of the Link IO master in the automation system and a second development tool for the configuration of the Link IO master itself and the Link IO devices connected in a communicative way to it.

[0008] The configuration of a Link IO system as an integral part of an automation system using the applicant's development tools, that is, on the one hand, the development tool, known under the name SIMATIC STEP 7 (first development tool) and, on the other hand, the development tool known under the name of the port configuration tool (S7-PCT) (second development tool), will be described below for illustrative purposes.

[0009] The following steps must be performed when configuring a Link IO system in the engineering software: 1) The configuration of the Link IO master in the first development tool, for example, when dragging and dropping a Master IO Link to the hardware configuration of the first development tool, for example, in an automation device created there in the form of a programmable logic controller or similar. 2) Parameterization of the Link IO master in the first development tool. Here, the user enters the I / O addresses (start and duration) and the diagnostic parameters of the Link IO master. To determine the length of the I / O addresses, the user must know the exact number and type of the ports and / or the IO Link devices used. In modular Link IO devices, the problem is compounded by the fact that the size of the process images of the inputs and outputs in turn depends on the modules / devices used. There is no guarantee that the first development tool will support this, as in modular Link IO devices the subunits that make up the devices are not known. As a result, address assignment is prone to errors. 3) The configuration of the Link IO devices in the second development tool when calling the second development tool, for example, directly from the first development tool, and when dragging and dropping the Link IO devices in a configuration of port that the second development tool understands. For this purpose, Link IO devices, when available, can be integrated using a device description file. 4) Parameterization of Link IO devices in the second development tool by selecting the relevant port / Link IO Device and entering the device parameters. In modular Link IO devices, the subunit configuration that they comprise is inserted "hidden" in the device parameters. The individual modules / devices of the modular Link IO Device, referred to hereinafter as a sub-unit or sub-device of Link IO, cannot be selected in the hardware selection catalog. It is also not possible to configure them graphically by dragging and dropping individual subunits. 5) The download of the parameters for the Link IO master and the individual Link IO devices, through the first development tool based on the previous transfer of the parameters of the Link IO devices together with the interruption of the second development tool. The parameters are stored in the data store of the first development tool. During the download, the device parameters are loaded into a central unit of an automation device, which then transfers these at startup with the Link IO master and the Link IO devices. 6) Diagnosis of the Link IO system in the first development tool by reading and displaying the system diagnostic information for all accessible modules. In the case of the Link IO master, this is the group diagnostic information for the master (corresponds to the status of a dedicated Link IO master LED) and the diagnostic information for the Link IO ports / devices. In modular Link IO devices, this individual diagnostic information cannot represent the states possibly different from the LEDs of the individual Link IO sub-devices (subunits; feeders). 7) In order to obtain accurate diagnostic information on modular Link IO devices, the user must switch to the second development tool and view the device's diagnosis. Here, in the case of modular Link IO devices, the status of the LEDs is represented by the diagnostic information that can be obtained (group error, group warning, etc.). In addition to diagnostic information, the inputs / outputs of the individual subunits can be viewed.

[00010] A first objective of the approach proposed here is to simplify the management of modular IO Link devices and their use in an automation system.

[00011] This objective is achieved in a method to operate an automation system, the automation system that comprises, in the communicatively connected form, a subordinate Link IO unit, for example, a Link IO master, and at least one modular IO Link Device that has an internal device bus and the subunits that can be addressed through the latter and that the modular IO Link Device understands, as long as communication with the modular IO Link Device make the selection of one of the subunits of the same, and the communication takes place directly only with that subunit and indirectly through the latter with the other subunits of the modular IO Link Device.

[00012] Another objective of the approach proposed here is given the scope and complexity of the method steps hitherto necessary to configure and parameterize the modular IO Link devices, to simplify the administration of said method steps for the configuration, parameterization and / or diagnosis.

[00013] A modular IO Link Device is a "compact pseudomodular device", that is, it comprises a plurality of modules referred to here as subunits or feeders (Link IO sub-devices), which are connected via an internal bus of the device . As an example, reference can be made to the device offered by the applicant under the name "SIRIUS 3RA6 compact starter". So far, however, individual subunits are not visible externally and have not been addressed directly, that is, because they have no address, are not assigned to a port in the Link IO model, do not provide information about diagnosis, etc.

[00014] The problems described above can be eliminated through the following technical characteristics: 1) Extension of a Link IO object model to include the subunits (Link IO sub-devices); 2) Modeling of such subunits in the description of the device (for example, IODD); 3) Graphical or tabular representation of the modularity of the modular IO Link devices in a single development tool.

[00015] To that end, an automation system or method for configuring or parameterizing a modular IO Link Device in such automation system provides that when a modular IO Link Device is created in a development tool, a first object is created to represent the modular IO Link Device, a second object is created to represent a Link IO rack in the modular IO Link Device, said rack that comprises or accommodates the subunits, a third object is created to represent the selected subunit and functioning as a Link IO header module and at least a fourth object is created for each new subunit of the modular IO Link Device. The first, second, third and fourth objects or the types of objects on which each is based represent the extension of an IO Link object model. The creation of an object to represent the modular IO Link Device and any other objects is carried out using the development tool for an automation solution to control and / or monitor a technical process. The automation solution comprises the automation system and therefore also the Link IO system as an integral part of the automation system which has at least one Link IO master and a modular Link IO Device, but also the software to define the functionality of the individual units of the automation system and its configuration, parameterization, etc.

[00016] The solution proposed here is based on one of the subunits assuming external communication through Link IO and, thus, functioning as if it were, as a proxy for the entire modular IO Link Device. This subunit is also referred to below as a header module to differentiate it. The docking module can be a specified subunit, for example, a communication module, or any subunit of the modular IO Link Device that manages the communication connection of the modular IO Link Device and thus works as a header module. Only this header module needs information about the internal structure of the Link IO device. As a result, the subunits that the IO Link Device offers are addressed by the header module through an entirely internal mechanism. The presence of the subunits only influences the technological functions of the modular IO Link Device by allowing the activation, in any other appropriate way, of the functions of these subunits (through parameters, diagnostics, process images, etc.).

[00017] The extension of the Link IO object model with these subunits is necessary for this reason. The extended object model allows a modular IO Link Device to be handled in the user interface of a single development tool as a modular device with a plurality of subunits. All subunits whose modular IO Link Device comprises can thus be selected in the development tool and added in the device view to the modular IO Link Device, for example, by dragging and dropping them.

[00018] The special and main characteristics of the extended object model and the objects provided by it are described below. The basic assumption of the extended object model is that a modular IO Link Device is always modeled by a combination of the following objects: one (first) object for a Link IO device, one (second) object for a Link rack IO, one (third) object for a Link IO header module and at least one (fourth) object for a sub-unit of the modular IO Link Device. The reference will not always be made after an object as the representation of a physical unit, so instead of expressions that are complete in themselves, such as "object to model the IO-Link device", for example For example, short forms like "Link IO device" can be written. It will be evident from the context in each case whether an object is intended for the representation of a physical unit or as the physical unit itself.

[00019] The object to model the IO Link Device is that object that in a master display mode (Link IO display) is presented to represent the Link IO device. The object for modeling the Link IO rack is a container for the subunits whose modular IO Link Device understands and which can thus be configured in the development tool's device view. The rules of the first opening in relation to the object relationships to model the IO Link rack for the subunit or for each subunit are mapped, that is, such opening rules as can be verified when an object to model a subunit are combined with the Link IO rack.

[00020] The object for modeling the header module works as a proxy for a modular IO Link Device. It represents the real technological functionality of the modular IO Link Device and carries more of the device's characteristics (the device parameters, the length of the input and output address, the device diagnostics, etc.). Modular Link IO devices are pseudomodular systems, that is, they can be configured with subunits. Unlike true modular systems, however, they do not have their own parameters and therefore do not have their own contact details. Instead, a subunit changes the characteristics of the modular IO Link Device and the characteristics of the object that models the modular IO Link Device, for example, the visibility of parameters. For this, the header module must have information about which subunits are currently configured. This information can be determined through object references from the device description.

[00021] The header module is the only object for which there is a physical counterpart in each case. The header module represents the modular IO Link Device in the user interface of the development tool. It is, therefore, also the object which is designated, for example, an order number (MLFB) of an IO Link Device and can therefore be generated by the user through the hardware catalog. All other objects (Link IO rack, Link IO device, Link IO subunit) are then implicitly and additionally generated.

[00022] The relevant actions and dialogs for parameterization, diagnosis, address allocation, etc., can be accessed through the header module, that is, the object of the header module. The header module object also comprises the functionality to integrate the individual or multiple subunits and the functionality to connect to the Link IO master, that is, a dedicated Link IO port (node). The objects to manage the address information (address objects) and the IO Link port (node) are standard objects and are generated automatically, where the device description contains suitable attributes, such as the link to the Link IO master. In addition to an icon in the device view and standard dialog boxes for project information, a sub-unit of a modular IO Link Device does not have its own user interface, its own device parameters or any links to the system. IO link.

[00023] A modality of the method thus shows that when an object is created for a modular IO Link Device, an object is created automatically for the selected subunit of the modular IO Link Device that functions as a linker module. Link IO and / or an object is created for the Link IO rack of the modular IO Link Device, and in particular, and in the same way automatically, an interconnection between these objects is created. This, on the one hand, reduces the steps of the method that would otherwise be required manually and, on the other hand, ensures the consistency of the representation of the automation system in the development tool, ensuring that in a Modular Link IO The connection to Link IO is made exclusively through the subunit selected as the header module and also ensuring that the proxies are available for the Link IO device itself, which comprises the header module, and for the IO Link rack.

[00024] The approach described here also includes the modeling of the Link IO subunits in the device description. Currently, that is, according to the prior art, only the Link IO device and its characteristics (parameters, diagnostics, etc.) are described in the device description. Any IO Link Subunits are covered as far as possible by the device parameters.

[00025] Below is an example of a description of the prior art device for the device mentioned above by the applicant, that is, the SIRIUS 3RA6 compact initiator: <Text id = "TI_DS130_Byte12" value = "Starter type" /> <Text id = "TI_DS130_BGID_DS_010-040" value = "Direct starter DS 0.1 ... 0.4 A" /> <Text id = "TI_DS130_BGID_DS_032-125" value = "Direct starter DS 0.32 .. 1.25 A "/> <Text id =" TI_DS130_BGID_DS_100-400 "value =" Direct starter DS 1 ... 4 A "/> <Text id =" TI_DS130_BGID_DS_300-1200 "value =" Direct starter DS 3 .. . 12 A "/> <Text id =" TI_DS130_BGID_DS_800-3200 "value =" Direct starter DS 8 ... 32 A "/> <Text id =" TI_DS130_BGID_RS_010-040 "value =" Reversing starter RS 0.1 .. 0.4 A "/> <Text id =" TI_DS130_BGID_RS_032-125 "value =" Reversing starter RS 0.32 ... 1.25 A "/> <Text id =" TI_DS130_BGID_RS_100-400 "value =" Reversing starter RS 1 ... 4 A "/> <Text id =" TI_DS130_BGID_RS_300-120 "value =" Reversing starter RS 3 ... 12 A "/> <Text id =" TI_DS130_BGID_RS_800-3200 "value =" Reversing start er RS 8 ... 32 A "/>

[00026] For the modeling of a modular IO Link Device with Link IO, according to the approach proposed here, both the object model and the device description are extended to include at least - a description of all objects the object model, that is, Link IO device, Link IO rack, Link IO header module and Link IO subunit; - the description of the device configuration: number of openings, types of connectable devices, etc .; - usable types of Link IO subunits; - description of the Link IO subunit for its representation in the hardware catalog; and - opening rules.

[00027] Regarding the opening rules, it is possible to cover only the "rigid" opening rules, rigid in this context means that the selection of a Link IO subunit and its combination with the modular Link IO device from the catalog hardware is prevented.

[00028] Only the most important attributes that are needed to map the extended IO Link object model in the device description are described below. Where specific values are given as an example, these are often the values for the previously mentioned device, ie the compact SIRIUS 3RA6 starter. Device parameters and diagnostics can be described here, in the same way as already provided in the device description (byte offset, bit offset, data type, length, default value, identification, etc.).

[00029] The general attributes of all objects: VARIABLE Comment; // Device-specific comment, // e.g. "Conveyor belt Hall 3, Motor 12" VARIABLE Name; // Device-specific name, // e.g. "Conveyer23.Starter07" VARIABLE MLFB; // Order number, e.g. "3RA6234-0AA1-0BBX" VARIABLE ObjectType; // Type of object VARIABLE ObjectId; // Unique identification number of the object

[00030] The attributes for the objects to model an IO Link Device: VARIABLE ObjectType; // Type of object = IO_LINK_DEVICE // (unique object type number, constant) VARIABLE ObjectId; // Identification number of the object, // e.g. SIRIUS_3RA6 (unique object number, constant) VARIABLE ContainerSize: 1; // an Link IO device always includes a rack VARIABLE TypeName; // for display in the development tool, // e.g. "SIRIUS 3RA6 compact starter"

[00031] The attributes for the objects to model an IO Link rack: VARIABLE ObjectType; // Type of object = IO_LINK_DEVICE_RACK // (unique object type number, constant) VARIABLE ObjectId; // Identification number of the object, e.g. // SIRIUS_3RA6_3RA6 (unique object number, constant) VARIABLE ContainerSize: 4; // Number of available slots in the rack; // in the SIRIUS 3RA6 compact starter e.g. 4

[00032] The attributes for the objects to model an IO Link header module: VARIABLE ObjectType; // Type of object = IO_LINK_HEAD_DEVICE // (unique object type number, constant) VARIABLE ObjectId; // Identification number of the object, e.g. // SIRIUS_3RA6_HEAD (unique object number, constant) VARIABLE PositionNumber; // The current slot number of the header module, in the // SIRIUS 3RA6 compact starter, from 0 to 3 VARIABLE UICapabilities: 0; // 0 = the module is virtual and is not // displayed in the development tool VARIABLE InAddressRange; VARIABLE OutAddressRange; // Size of the input and output addresses of the slave in // the address space of the SPS / Link IO master system // e.g. in the compact starter: 8 = 8 bytes, 16 = 16 bytes VARIABLE PARAMETER_17; // A device parameter of the Link IO device, analogous to // the IODD specification VARIABLE DIAGNOSIS_27; // A device diagnosis of the Link IO device, // analogous to the IODD specification

[00033] The attributes for the objects to model a Link IO subunit: VARIABLE ObjectType; // Type of object = IO_LINK_SUB_DEVICE // (unique object type number, constant) VARIABLE ObjectId; // Identification number of the object, e.g. // SIRIUS_DIRECTSTARTER_3_12A // (unique object number, constant) VARIABLE PositionNumber: // the current slot number of the module, in the // SIRIUS 3RA6 compact starter, from 0 to 3 VARIABLE TypeCode; // including for parameterization. e.g. // Bit 15 == 1 // (Module is not parameterizable) // Bit 15 == 0 // (Module is parameterizable) VARIABLE FWMainVersion: 1; VARIABLE FWVersion: "V1.0"; // Firmware version VARIABLE UICapabilities: 1; // 1 = The module is displayed in the development tool

[00034] Based on the extended object model of Link IO described here and the description of the device, also extended, which maps the extended object model of Link IO, a modular IO Link Device can be represented in the tool development of all the subunits that comprise it. The representation comprises at least one option for the diagnosis of individual subunits of Link IO with a display of the results of the diagnosis. The representation then comprises an expansion screen and / or a configuration of the modular IO Link Device with its subunits, and performs it in the form of a table and / or graphically. Finally, the representation also includes support from the hardware catalog for device selection.

[00035] Due to the extension of the object model and the description of the IO Link Device and the graphical representation in the development tool, it is now possible, at least - to select the individual units of a modular IO Link Device from a selection catalog hardware; - configure the modular IO Link Device by dragging and dropping (in graphical or tabular form); - represent a real device configuration offline and online, respectively; - perform a target / actual comparison of the configuration; - represent the diagnostic information obtained or that can be obtained from individual subunits in the respective subunit in the hardware configuration; - keep the sizes of the input and output process images (PAE and PAA, respectively) consistent; - calculate the address length and the automatic way assignment, depending on the expansion; - display a product image that corresponds to the real expansion; and - display complete and correct customer documentation.

[00036] This makes the overall configuration of a Link IO system more efficient for the customer and less prone to errors. Fewer steps are required, in general, for the configuration and configuration of the general IO-Link system can now be performed from start to finish with the use of a development tool.

[00037] This means that in an applicant's development tool, the following steps are necessary when configuring a Link IO system, with similar or comparable procedures that are required by other development tools:

1) Link IO master configuration

[00038] All Link IO masters available from the applicant are already contained in the hardware selection catalog. A specific master IO Link is selected, for example, by dragging and dropping the selected device in the hardware configuration.

[00039] The parameters of the Link IO master can then be defined in the development tool through an object properties window that represents the Link IO master.

2) Configuration of IO Link devices

[00040] All IO Link devices available from the applicant are already contained in the hardware selection catalog. Certified devices from other vendors can be integrated into the database used by the development tool through its device description file, provided in specialized terminology as an IODD. A specific IO Link Device is selected, for example, by dragging and dropping the selected device into a configuration application.

[00041] The IO Link Device parameters can then be defined in the development tool through an object properties window that represents the IO Link device.

3) Configuration of Link IO subunits

[00042] Link IO subunits (sub-devices, feeders) can be selected in the hardware selection catalog. Graphical configuration is now possible by dragging and dropping individual Link IO subunits.

[00043] The modular IO Link devices are configured in the device view of the hardware configuration. As the number and type of Link IO devices and subunits used are known here, a beginning and duration of a data area that contains I / O addresses can be determined automatically.

[00044] The parameters of each Link IO subunit can then be defined in the development tool through an object properties window that represents the Link IO subunit.

4) IO Link Diagnosis

[00045] The diagnostic information for all modules is read and displayed. In the case of diagnostic information called for a Link IO master, this is the diagnosis of the master group (the diagnostic information corresponds to the status of an LED on the Link IO master) or the diagnostic information about Link IO devices that can be accessed from the Link IO master.

5) Diagnosis of modular IO Link devices

[00046] In modular Link IO devices, the status of the device's LEDs in each case corresponds to the relevant data that the diagnostic information comprises (group error, group warning, etc.). Diagnostic information and the status of the inputs / outputs of the individual units are visible.

[00047] An exemplary embodiment of the invention is explained in detail below with reference to the drawings. Items or elements that correspond to each other are labeled with the same reference numbers in all figures. 6) figure 1 shows an automation system that has a plurality of IO Link devices; 7) figure 2 shows an IO Link Device in a fashion as a modular IO Link Device; 8) figure 3 shows a representation of Link IO devices by a development tool; and 9) figure 4 shows a flowchart that illustrates a method for creating objects in the development tool for Link IO devices.

[00048] Figure 1 shows schematically in the highly simplified form of an automation system 10 to control and / or monitor a technical and industrial process 12 that is not shown in detail. The automation system 10 comprises at least one automation device 14, for example a programmable logic controller. The latter comprises an IO Link master 16 for connecting sensors and / or actuators via the communication standard known as Link IO. Link IO devices 18, 20, 22 are connected to Link IO master 16, in a way per se known through point-to-point connections. At least one of the connected IO Link devices 18, 20, 22 is a modular IO Link Device 20 which, as Figure 2 shows in simplified schematic form, comprises a plurality of Link IO subunits. Figure 2 also shows that the IO Link Device 20 can comprise one or more IO Link subunits 24, 26, 28, of which only one functions as a header module 24. The IO Link Device 20 has openings to accommodate the subunits 24, 26, 28 and an internal device bus 32 runs in a rack of 30 inside the IO Link Device 20 for each opening so that all the subunits that an IO Link Device 20 comprehensively understands they are connected and can be accessed in a specific way by the header module.

[00049] Link IO master 16, Link IO devices 18, 20, 22 and point-to-point connections foreseen to connect these units in a communicative way form the Link IO system (figure 1), in which Link I Master 16 functions as a subordinate unit. One of the subunits 24, 26, 28 of the modular IO Link Device 20 is selected as a header module 24 to communicate with Link IO master 16. Communication with IO-Link 16 master occurs directly only with this header module 24. All subunits 24, 26, 28, which the modular IO Link Device 20 comprises can be accessed indirectly in the IO-Link system through this header module 24, that is, from the header module 24 through the internal device bus 32.

[00050] For configuration, parameterization, diagnosis, etc. of Link IO devices, a 34 development tool (figure 1) available as software is used. This software can be run on a programming device 36 (figure 1), or similar, which can be connected at least temporarily, directly or indirectly, for example, via the Internet, to the automation system 10. The device for programming 36, for example, a personal computer, has for this purpose in a per se known way a memory 38 and a processing unit similar to a microprocessor (not shown). When the development tool 34 is loaded into memory 38, said tool can be executed by the processing unit.

[00051] For this purpose, figure 3 shows in a schematic and simplified way a possible representation of the object model of Link IO. It is shown that when a modular IO Link Device 20 is created with the development tool 34, a first object 40 is created to represent the modular IO Link Device 20, a second object 42 is created to represent the Link IO rack 30 comprising or accommodating the modular IO Link Device 20 subunits 24, 26, 28, a third object 44 is created to represent the selected subunit and functions as a Link IO header module 24 and at least one fourth object 46 is created for each additional subunit 26, 28 of the modular IO Link Device 20.

[00052] It can also be seen from figure 3 that the modular IO Link device 20 is connected to the Link IO system (figure 1) only through the header module 24 that represents the modular IO Link Device 20 externally , that is, the third object 44 generated for the Link IO 24 module. A fifth object 48 represents a point-to-point connection between the Link IO master and the Link IO modular device 20. The IO-Link master 16 is represented by a sixth object 50. The representation by the development tool 34 and the connection of the individual objects on which the representation is based make the Link IO 24 header module accessible in a communicative way in the Link IO system, specifically by Link IO master 16. Of course, a complex Link IO system can include a plurality of Link IO devices 18, 20, 22 and also a plurality of modular Link IO devices 20. Depending on of nature and choice part of the Link IO system, its representation by the 34 development tool will relate to a corresponding plurality of respective objects.

[00053] In a specific modality of software tool 34, when an object 40 is created by a modular IO Link Device 20, object 44 for the Link IO header module 24 and / or object 42 for the Link rack IO 30 are created automatically. An object 40 is created by a modular IO Link Device 20, for example, by the user of the software tool who selects the specific modular IO Link Device 20 in a hardware catalog and places it in the automation solution using actions operation, for example, drag and drop, which are now common.

[00054] The software tool 34, in such a modality or in another modality, is not shown separately since this is to some extent just an additional or alternative software functionality of the software tool 34. The modality Additional software tool 34 provides that when an object 42 for the Link IO 30 rack is created automatically, objects 46 for subunits 26, 28 that can be accommodated by the Link IO 30 rack are created in an automatic way automatic. In addition, with regard to the functionality of software tool 34, it is optional, since, when objects 42, 44, 46 are created automatically, an interconnection is also created automatically between the objects created in an automatic way. automatic 42, 44, 46. The interconnection created in this context corresponds to the interconnection represented schematically in figure 3 and provides access, for example, from object 44 that represents the header module 24, to object 42 that represents the Link IO rack 30 and indirectly to objects 40, 46 represents the modular Link IO Device 20 and / or representing subunits 26, 28, which the Link IO 30 rack comprises or that the Link IO rack 30 can accommodate.

[00055] Figure 4 makes this aspect, that is, the functionality in relation to the software tool 34, clear in a schematic and simplified way through a flow diagram: when the objects of the first functional block (52) are created with the software tool 34, a check is made to see if the object created or the type of object that was selected for the creation of an object is an object 40 that represents a modular IO Link Device 20. If this is the case, the tool branches to a second function block 54 by means of which object 42 for the IO Link rack 30 is created automatically. If the software tool 34 is a software tool 34 in the specific mode already described above, a check is made on an optional fourth functional block 56 with respect to which type of IO Link rack 30, for which object 42 was created as a proxy and then (fifth functional block 58) objects 46 are automatically created for subunits 26, 28 that the Link IO 30 rack understands or that the Link IO 30 rack can accommodate. If the physical rack of Link IO 30 represented by object 42 does not yet have any subunits 26, 28 plugged into it, placeholder objects are generated like objects 46; if the Link IO 30 rack already has the subunits 26, 28 in the individual openings or in all of them, the objects can be generated automatically in relation to the subunits 26, 28 which are, in fact, connected through the import, for example, for the latest data of the description of the relevant device.

Claims (6)

1. Method for the operation of an automation system (10), the automation system (10) comprising, communicatively connected, a subordinate unit (16), which is a master IO link, and at least one device modular IO link (20), with the modular IO link device (20) having an internal device bus (32) and subunits (24, 26, 28) that can be addressed through the latter and that the modular IO link device (20) comprises, the method comprising the following steps, communicating with the modular IO link device (20) by means of selecting one of the subunits (24, 26, 28) of the same as a module of header (24), with communication occurring only with header module (24) directly and through the header module (24) with the other subunits (26, 28) of the modular IO link device (20) indirectly, being that the modular IO link device (20) has slots to accommodate the subunits (24, 26, 28) and within the modular IO link device (20) the internal device bus (32) runs in a rack (30) until each opening, so that all subunits (24, 26, 28), which the modular IO link device (20) comprises, can be accessed by the header module (24); the method further comprising, when the modular IO link device (20) is created in a development tool (34), creating a first object (40) to represent the modular IO link device (20) ; creating a second object (42) to represent an IO link rack (30) in the modular IO link device (20), said rack that comprises or accommodates the subunits (24, 26, 28); create a third object (44) to represent the subunit that is selected and functions as an IO link header module (24); and creating at least a fourth object (46) for each additional subunit (26, 28) of the modular IO link device (20); characterized by the fact that the method also comprises generating reserved space objects such as the fourth object (46), if the physical IO link rack (30) represented by the second object (42) does not have connected subunits (26, 28) to him. 2. Method, according to claim 1, characterized by the fact that when an object (40) is created by a modular IO link device (20), an object (44) is created automatically for the selected subunit of the modular IO link device (20), said subunit that functions as the IO link module (24). 3. Method, according to claim 2, characterized by the fact that when an object (40) is created by a modular IO link device (20), an object (42) is created automatically for the link rack IO (30) of the modular IO link device (20). 4. Method, according to claim 3, characterized by the fact that when an object (42) is created automatically for the IO link rack (30), the objects (46) are created automatically for the subunits (26, 28) that can be accommodated by the IO link rack (30). 5. Method according to any one of claims 2 to 4, characterized by the fact that for the or each object created automatically (42, 44, 46), the object created automatically (42, 44, 46) is automatically interconnected with the object (40) to represent the modular IO link device (20) and / or with other objects created automatically (42, 44, 46). 6. Method according to claim 1, characterized by the fact that the IO link device comprises three subunits.

Images