Method and device for automatically generating a gsdml process data list from an IODD process data list

Abstract

The invention relates to a computer-implemented method for automatically generating a GSDML process data list from an IODD process data list, the IODD process data list comprising one or more IODD process data elements. The method comprises determining a length of each of the IODD process data elements and adding the IODD process data elements, according to their length, to the GSDML process data list.

Description

[0001] Tautz & Schuhmacher Law TUR1120P12WO August 19, 2025

[0002] 1 / 28

[0003] METHOD AND DEVICE FOR AUTOMATICALLY GENERATING A GSDML PROCESS DATA LIST FROM AN IODD PROCESS DATA LIST

[0004] The present disclosure relates to a method for automatically generating a GSDML process data list from an IODD process data list. The present disclosure relates to a data processing device configured to execute the method. The present disclosure relates to a computer program comprising instructions that, when executed by a computer, cause the computer to execute the method. The present disclosure relates to a computer-readable medium comprising instructions that, when executed by a computer, cause the computer to execute the method.

[0005] The present disclosure lies in the technical field of automation technology.

[0006] The IO-Link standard is used there. The IO-Link brand name refers to a communication system for connecting intelligent sensors and actuators to an automation system, standardized in IEC 61131-9 under the name 'single-drop digital communication interface for small sensors and actuators' (SDCI). This standardization encompasses both the electrical connection data and a digital communication protocol through which the sensors and actuators engage in bidirectional data exchange with the automation system.

[0007] An IO-Link system consists of an IO-Link master and one or more IO-Link devices, i.e., sensors and / or actuators. The IO-Link master provides the interface to the higher-level controller (PLC) and manages the communication with the connected IO-Link devices.

[0008] An IO-Link master can have one or more IO-Link ports, to which only one IO-Link device can be connected at a time. This can also be a "hub," which acts as a concentrator, enabling the connection of conventionally switching sensors and actuators. Tautz & Schuhmacher Law TUR1120P12WO August 19, 2025

[0009] 2 / 28

[0010] An IO-Link device can be an intelligent sensor, actuator, hub, and / or, due to its bidirectional communication capabilities, a mechatronic component such as a gripper, and / or a power supply with an IO-Link connection. In the context of IO-Link, "intelligent" means that a device has identification data, such as a type designation and / or serial number, and / or parameter data (e.g., sensitivities, switching delays, and / or characteristic curves) that can be read and written via the IO-Link protocol. This allows parameters to be changed, in some cases, by the PLC during operation. "Intelligent" also means that the IO-Link device can provide (detailed) diagnostic information.

[0011] The parameters of IO-Link devices are device- and technology-specific; therefore, parameter information exists for each device in the form of an IO Device Description (IODD) using the description language XML (Extensible Markup Language). Interfaces also exist to a so-called "IODD Finder," which can be used by engineering or master tools to find the appropriate IODD for a given IO-Link device.

[0012] Furthermore, Profinet (Process Field Network) is used in automation technology as an open Industrial Ethernet standard. Profinet uses TCP / IP and IT standards, is real-time capable, and enables the integration of fieldbus systems.

[0013] The Profinet concept is modular, allowing users to choose the functionality they need. Profinet is used to connect distributed peripherals to a controller.

[0014] PROFINET IO allows the connection of distributed I / O to a controller and can therefore be seen as the direct successor to PROFIBUS DP. PROFINET IO describes the entire data exchange between devices with control and / or regulation functionality (IO controllers) and field devices (IO devices) for cyclic data exchange, parameterization, and diagnostics. PROFINET IO uses Ethernet-based protocols, follows the producer / consumer model, and, depending on the conformance class, is suitable for bus cycle times from several milliseconds down to 31.25 ps. (Tautz & Schuhmacher Law TUR1120P12WO, August 19, 2025)

[0015] 3 / 28

[0016] Field devices in a subordinate fieldbus segment can be integrated into the Profinet IO system via an IO proxy (a representative for a subordinate bus system). This allows existing Profibus and other fieldbus systems to be integrated into a Profinet IO system and continue to be used.

[0017] When configuring a PROFINET IO system, the properties of a PROFINET IO device are described by the device manufacturer in a GSDML (General Station Description) file. GSDML (GSD Markup Language), an XML-based language, is used for this purpose. The GSDML file serves as the basis for planning the configuration of a PROFINET IO system within an engineering environment or PROFINET configuration software. It is possible to plan and parameterize the PROFINET IO device offline within a project before the project goes online, i.e., before it is actually connected to the network and the connected devices.

[0018] Integrating an IO-Link device into a PROFINET 10 system presents a challenge, as the IO-Link device does not have a GSDML file but is supplied with an IODD file, as described above. The PROFINET configuration software therefore cannot readily recognize the IO-Link device, and users are often forced to manually enter the device's properties, such as a device class and / or manufacturer identifier. Parameters, such as measuring ranges and / or output signals, must conventionally be programmed (manually) and optionally configured (manually) using additional software.

[0019] DE 10 2021 100 762 A1 describes a method for controlling an automated I / O device system for executing a production process with at least one production parameter. The I / O device system comprises an I / O controller with control software and at least one I / O field device, which are interconnected via a network with a gateway serving as a software and / or hardware interface for communication over the network. The method includes executing configuration software, in particular an engineering tool, and scanning for further I / O field devices via the network. The method includes the identification of the I / O field device by the configuration software and a Tautz & Schuhmacher Law TUR1120P12WO 19 August 2025

[0020] 4 / 28

[0021] Provision of a configuration database containing at least one IODD of the 10-field device. The procedure includes providing a support tool for generating a GSDML file, which forms the interface between the configuration software and the gateway. The procedure includes generating the GSDML file via the support tool by assigning an IODD based on parameters of the IO field device and / or production parameters, and adding at least one parameter and the article number from the IODD to the GSDML file. The procedure includes transferring the GSDML file to the 10-controller and / or the control software via the configuration software and executing the control software to control the IO field device.

[0022] JPH0746141A describes a method for converting a variable-length word data format to a continuous fixed-length word data format. D1 focuses on a fast, low-latency hardware method for converting variable-length data, such as Huffman-coded video data, to fixed-length data, using a rotating buffer and precise bit-level control.

[0023] Against the background of this prior art, the purpose of the present disclosure is to specify a device and / or a method, each of which is suitable to enrich the prior art.

[0024] One specific task of the disclosure can be seen as providing a solution for the reliable and detailed automated conversion of process data from an IODD to a GSDML file.

[0025] The problem is solved by the features of the independent claims. The dependent and subordinate claims each contain optional further developments of the disclosure.

[0026] The task is then solved by a computer-implemented method for automatically generating a GSDML process data list from an IODD process data list, where the IODD process data list comprises one or more IODD process data elements. The method includes determining a Tautz & Schuhmacher Law TUR1120P12WO 19 August 2025

[0027] 5 / 28 respective length of the IODD process data elements, and adding the IODD process data elements to the GSDML process data list depending on their length.

[0028] A method for converting an IODD process data list into a GSDML process data list is proposed. The IODD process data list can also be referred to as the first description file or part of a first description file, and the GSDML process data list as the second description file or part of a second description file.

[0029] A computer-implemented method can be understood as a method in which at least one of the steps of the method is at least partially carried out by a computer or a data processing device.

[0030] The IODD process data list can be part of an IODD file. The GSDML process data list can be part of a GSDML file. For the definitions of IODD and GSDML files, please refer to the above. Furthermore, it should be noted that both files contain so-called functional data, meaning their respective structure or format serves a technical function within a technical system. More precisely, the GSDML process data list format, into which the IODD process data list is converted, enables the control of an IO-Link device's operation within a PROFINET system. Replacing, expanding, or adding a single IO-Link device can be accomplished with minimal research effort using the automatically generated GSDML process data list. Moreover, the automated generation of the GSDML process data list contributes to system safety.

[0031] A list can be understood as a digital (optionally written) compilation or sequence of a large number of process data elements.

[0032] A process data element, or process data, can be understood as data that describes a process value, process quantity, or property of a device to which the IODD is assigned, in its specific form. The process data could, for example, relate to a temperature, as defined by Tautz & Schuhmacher Law TUR1120P12WO, August 19, 2025.

[0033] 6 / 28

[0034] The device is being measured, or a switching state in which the device is located or in which it is supposed to be located.

[0035] Insofar as the length or size of a data element is mentioned here, this can be understood to mean the length of the respective data element in bits and / or bytes.

[0036] Instead of 1ODD process data list, one can also generally speak of a first file which has a first predetermined structure or format in which information is stored that describes a field device with regard to its process data (and optionally identification, structure, communication characteristics, parameters and / or diagnosis).

[0037] Instead of a GSDML process data list, one can also generally speak of a second file, which has a second predefined structure or format, in which information is stored that describes a field device with regard to its process data (and optionally identification, structure, communication characteristics, parameters and / or diagnostics). The first differs from the second structure.

[0038] The procedure described above offers a number of advantages, which are described below by way of example and not exhaustively.

[0039] As already mentioned at the beginning, IODD and GSDML files have different formats and structures. This presents a challenge when (automatically) converting IODD process data lists to GSDML process data lists. Specifically, the GSDML file is composed of GSDML process data elements, which typically have a predetermined length, such as 8 bits, 16 bits, 32 bits, and 64 bits. The IODD file, on the other hand, allows for individual specification of the length of each process data element. Following the procedure described above, it is now proposed to add the IODD process data elements to the GSDML process data list based on their respective lengths. That is, the decision is made based on the length of each IODD process data element. (Tautz & Schuhmacher Law TUR1120P12WO, August 19, 2025)

[0040] 7 / 28 how this ODD process data element should appear in the GSDML process data list. This allows the ODD process data elements to be adapted to the GSDML format, so that the ODD process data list can be automatically converted to the GSDML format with minimal loss of accuracy.

[0041] The following section describes optional advanced training courses for the procedure in detail.

[0042] The GSDML process data list can comprise one or more GSDML process data elements, each with at least one predetermined length. Those of the 1ODD process data elements can be added to the GSDML process data list as a single GSDML process data element, the respective length of which corresponds to at least one predetermined length of the GSDML process data elements.

[0043] In other words, as mentioned above, GSDML process data elements have a fixed length. Typically, GSDML process data elements with lengths of 8 bits, 16 bits, 32 bits, and 64 bits (so-called GSDML integer limits) can be selected. The goal is to insert the IODD process data elements into the GSDML process data list with as little loss of precision as possible. This can be achieved, among other things, by creating a GSDML process data element of the same length for each IODD process data element with a length of 8 bits, 16 bits, 32 bits, or 64 bits. This allows for the conversion of such IODD process data elements without any loss of precision.

[0044] Several of the ODD process data elements can be combined into a single GSDML process data element when added to the GSDML process data list, the respective length of which is shorter than the shortest length of at least one predetermined length of the GSDML process data elements.

[0045] In other words, in addition to the IODD process data elements already described above, whose length lies on one of the GSDML integer boundaries, the IODD process data list can also contain IODD process data elements that are shorter than 8 bits. This ensures that these are not affected during the IODD conversion. (Tautz & Schuhmacher Law TUR1120P12WO, August 19, 2025)

[0046] 8 / 28

[0047] To prevent the process data list from being lost in the GSDML process data list, several of these short ODD process data elements can be combined into one GSDML process data element.

[0048] It is conceivable that when adding the ODD process data elements to the GSDML process data list, those elements whose respective lengths are longer than the shortest length of at least one predetermined length of the GSDML process data elements and whose respective lengths do not correspond to any of the at least one predetermined length of the GSDML process data elements are split into several GSDML process data elements.

[0049] In other words, in addition to the IODD process data elements already described above, whose length lies on one of the GSDML integer limits, the IODD process data list can also contain IODD process data elements that are longer than 8 bits and whose length does not lie on one of the GSDML integer limits (e.g., 12 bits, 20 bits, or 36 bits). To prevent these from being partially lost or truncated when converting the IODD process data list to the GSDML process data list, several of these long IODD process data elements that do not fit the GSDML integer type limits can be split into multiple GSDML process data elements. For example, for an IODD process data element of length 20 bits, one GSDML process data element of length 16 bits and another of length 8 bits can be provided.

[0050] The procedure can include populating the IODD process data list with dummy IODD process data elements to obtain a consistent IODD process data list. This consistent IODD process data list can then be used as the IODD process data list when generating the GSDML process data list.

[0051] In detail, the IODD process data list does not initially need to be continuous. This means that fields or individual bits in the IODD process data list can be unused. For example, an IODD process data list might contain a first IODD process data element of length 3 bits, i.e., with a bit offset of 2 bits. For example, this IODD process data list might contain a second IODD... Tautz & Schuhmacher Law TUR1120P12WO August 19, 2025

[0052] 9 / 28

[0053] The process data element has a length of 3 bits, but a bit offset of 4 bits. The 4-bit offset, or the fourth bit, would therefore be unused. This poses a challenge when converting the IODD process data list to the GSDML process data list, as the latter must be contiguous. Therefore, the empty spaces in the IODD process data list can be filled before conversion. In the example just described, a dummy IODD process data element, which can also be called a reserved bit, with a length of one bit and a bit offset of 4 bits can be inserted into the IODD process data list. This results in a contiguous IODD process data list that can be converted automatically.

[0054] A dummy or placeholder IODD process data element can therefore be understood as an IODD process data element with predetermined content. For example, an IODD process data element of the IODD data type booleanT can be inserted under the label "reserved".

[0055] Padding can be understood as inserting enough dummy IODD process data elements of appropriate length and bit offset into the process data list to ensure that no gaps or empty spaces remain between the individual IODD process data elements in the (optionally bit-offset-sorted) IODD process data list. Such a padded list can then be referred to as a continuous IODD process data list. It is conceivable that the IODD process data list, after padding, has a predetermined or determinable length (in bytes or bits). Multiples of 8 bits are particularly relevant here.

[0056] This offers the advantage that the fine-grained IQDD process data list can be automatically converted into the GSDML process data list with minimal loss of quality. Specifically, the fine-grained IQDD specification allows, among other things, the definition of so-called bit fields (2-256 bits) with regard to data definitions, which cannot be represented using the GSDML specification. For example, a 14-bit process value (e.g., temperature) plus 2 status bits can be defined in the IQDD. In an IQDD XML file, it is also permissible to define only a single process data element (e.g., 14 bits), which, however, does not represent the entire process data width specified for the device (e.g., Tautz & Schuhmacher Law TUR1120P12WO, August 19, 2025).

[0057] 10 / 28

[0058] 256 bits). Such aspects are automatically taken into account by IODD interpreters. However, the resulting gaps in the IODD process data list cannot be defined in a PROFINET GSDML file. By filling these gaps with dummy IODD process data elements, a usable GSDML process data list can be generated.

[0059] The order in which the ODD process data elements are added to the GSDML process data list can depend on their respective bit offsets.

[0060] The procedure can therefore include converting the IODD process data list into the GSDML process data list based on a specific bit offset of the respective IODD process data elements.

[0061] The procedure can involve determining a specific byte offset and / or a bit offset for each of the ODD process data elements in the GSDML process data list. This can be done using the following formulas:

[0062] ByteOffsetcsDML = (BitSizelndexioDD - BitSizeSubindexioDD - BitOffsetioDD) / 8 (without remainder)

[0063] BitOffsetcsDML = BitOffsetioDD % 8

[0064] The ByteOffsetcsDML specifies the byte offset of the respective GSDML process data element in the GSDML process data list that includes the respective IODD process data element.

[0065] The BitOffsetcsDML specifies the bit offset of the respective IODD process data element within the GSDML process data element that comprises the respective IODD process data element.

[0066] The BitSizelndexioDD specifies a bit size index of the respective IODD process data element in the IODD process data list. This value is included in the IODD process data list by default. Tautz & Schuhmacher Law TUR1120P12WO August 19, 2025

[0067] 11 / 28

[0068] The BitSizeSubindexioDD specifies a bit size subindex of the respective IODD process data element in the IODD process data list. This value is included in the IODD process data list by default.

[0069] The BitOffsetioDD specifies a bit offset of the respective IODD process data element in the IODD process data list. This value is included in the IODD process data list by default.

[0070] As described earlier, both the GSDML file and the IODD file are XML files. However, the XML language dialects I / O-Link IODD and PROFINET GSDML differ. The same applies to the byte order of the respective process data elements in the process data images. A corresponding conversion of the data points or process data elements with respect to the byte order (byte / bit offsets) is advantageous so that, after conversion, the process data can be accessed appropriately (e.g., in an engineering environment). This can be taken into account using the formulas described above for calculating the byte and bit offset in GSDML from the bit offset of IODD. This makes it possible to automatically convert an IODD process data list into a GSDML process data list so that a GSDML process data list can be loaded in an engineering environment and the process data can be accessed correctly.

[0071] The procedure can involve determining a specific GSDML data type for each of the ODD process data elements in the GSDML process data list, based on the ODD data type of the respective ODD process data element. The specific GSDML data type can be determined as follows:

[0072] - If the iODD data type is recordT or uintegerT, then the GSDML data type is UnsignedX with X = 8, 16, 32 or 64 depending on a data length in bytes of the iODD process data element;

[0073] - If the IODD data type is integerT, then the GSDML data type is IntegerX with X = 8, 16, 32 or 64 depending on a data length in bytes of the IODD process data element;

[0074] - If the ODD data type is float32T, then the GSDML data type is Float32; Tautz & Schuhmacher Law TUR1120P12WO August 19, 2025

[0075] 12 / 28

[0076] - If the ODD data type is stringT, then the GSDML data type is VisibleString;

[0077] - If the ODD data type is octetstringT, then the GSDML data type is octetstring; and

[0078] - If the iODD data type is booleanT, then the GSDML data type is BitDataLtem (below the respective used data type unsignedX with X = 8, 16, 32 or 64 and the UseAsBits attribute enabled = true).

[0079] Converting or adding the GSDML process data list can be done based on or depending on the specific GSDML data type.

[0080] The differences between IODD and GSDML files have already been mentioned above. In addition to these differences, not all data types from IODD can be directly transferred to PROFINET GSDML. The data type conversion and selection described above allows for an effective and appropriate selection of GSDML data types for the respective defined IODD process data elements, and, if necessary, the grouping (and labeling) of several IODD process data elements within a single GSDML process data element.

[0081] The procedure can involve splitting the OODD process data elements into input and output process data and separately performing the procedure described above for the input and output process data.

[0082] Output process data can be understood as the process data that is output by the higher-level control unit during the operation of the (IO) field device connected to the control unit, or that is received by the field device.

[0083] Input process data can be understood as the process data that is received by a higher-level control unit, optionally a PLC controller, during the operation of the (IO) field device connected to the control unit, or that is received by the control unit.

[0084] The procedure may include generating a GSDML fragment, optionally a GSDML file, based on the generated GSDML process data list. Tautz & Schuhmacher Law TUR1120P12WO August 19, 2025

[0085] 13 / 28

[0086] In other words, since the GSDML process data list represents only a part of the entire GSDML file, the complete conversion process from IODD to GSDML can be performed using the method described herein.

[0087] Furthermore, a computer or data processing device or a device for data processing is provided which is designed to carry out the procedure described above.

[0088] In detail, the data processing device can be configured to automatically generate a GSDML process data list from an IODD process data list or to convert an IODD process data list into a GSDML process data list, where the IODD process data list comprises multiple IODD process data elements. For this purpose, the device can include a module for determining the length of each IODD process data element, as well as a module for adding the IODD process data list to the GSDML process data list depending on its (determined) length.

[0089] Each of the modules can be implemented as a hardware and / or software module.

[0090] The above description with reference to the process also applies analogously to the device for data processing and vice versa.

[0091] Furthermore, a computer program comprising commands that, when executed by a computer, cause it to at least partially execute the procedure described above is provided.

[0092] What has been described above with reference to the method and the device for data processing also applies analogously to the computer program and vice versa.

[0093] Furthermore, a computer-readable medium, and optionally a computer-readable storage medium, is provided. The computer-readable medium contains instructions which, when executed by a computer, cause it to execute at least part of the procedure described above. Tautz & Schuhmacher Law TUR1120P12WO August 19, 2025

[0094] 14 / 28

[0095] This means that a computer-readable medium can be provided that includes a computer program as defined above.

[0096] The computer-readable medium can be any digital data storage device, such as a USB stick, a hard drive, a CD-ROM, an SD card or an SSD card.

[0097] The computer program does not necessarily have to be stored on such a computer-readable storage medium in order to be made available to the computer, but can also be obtained via the Internet or other external sources.

[0098] The computer-readable medium can therefore also be a data signal.

[0099] The above description relating to the method, the data processing device and the computer program also applies analogously to the computer-readable medium and vice versa.

[0100] An optional embodiment of the disclosure is described below with reference to Figures 1 to 7.

[0101] Fig. 1 schematically and exemplarily shows a possible flowchart of a computer-implemented method according to the disclosure for the automated generation of a GSDML process data list from an IODD process data list,

[0102] Fig. 2 shows an example of an excerpt from an ODD process data list,

[0103] Fig. 3 shows an example visualization of the ODD process data list from Figure 2 using a tool specifically designed for this purpose, Tautz & Schuhmacher Law TUR1120P12WO 19 August 2025

[0104] 15 / 28

[0105] Fig. 4 shows an example of a sorted, continuous IODD process data list, which is generated from the IODD within the framework of the disclosed method.

[0106] The process data list was generated from Figure 2.

[0107] Fig. 5 shows an example of a case where a suitable IODD-

[0108] A process data element is added to the GSDML process data list as a single GSDML process data element.

[0109] Fig. 6 shows an example of a case where several short IODD process data elements are combined into a single GSDML process data element.

[0110] Fig. 7 shows an example of a case where a long ODD process data element is split into several GSDML process data elements.

[0111] Fig. 8 shows schematically and by way of example a possible flowchart of a computer-implemented procedure according to the disclosure for selecting a GSDML data type for the ODD process data elements in the GSDML process data list,

[0112] Fig. 9 shows an example of a section of a GSDML process data list that was generated from the 1ODD process data list from Figure 2 using the method disclosed, and

[0113] Fig. 10 shows an example of a process data image of the GSDML process data list from Figure 9 when visualized with an engineering tool.

[0114] As can be seen from Figure 1, the procedure for automatically generating a GSDML process data list 4 from an ODD process data list 1 essentially comprises seven steps S1 - S6.

[0115] Figure 2 shows an example of a part or section of an IODD process data list 1 comprising several IODD process data elements 2. The process data list

[0116] 1, which is part of an IODD and thus a standardized XML file, has a Tautz & Schuhmacher Law TUR1120P12WO dated August 19, 2025

[0117] 16 / 28

[0118] A collection of XML elements, the so-called IODD process data elements 2, is defined. Process input data is defined within the IODD process data list 1 under the XML element "ProcessDataln" and process output data under the XML element "ProcessDataOut". Figure 2 shows only the process input data. Each IODD process data element 2 from the IODD process data list 1 represents a single piece of data that describes a process value, a process parameter, or a property of the device to which the IODD is assigned (e.g., a temperature or a switching state) in its specific form.

[0119] Since the structure of the IODD process data list 1 and the individual IODD process data elements 2 is standardized, a visualization 3 (see Figure 3) of the process data list 1 can be automatically generated using dedicated software. Similar to visualization 3, an IODD process data image of the IODD process data list 1 can be generated in a graphical user interface using an engineering tool. The unique position of each individual IODD process data element 2 within the IODD process data image is determined by its respective bit offset and bit length (i.e., the data length in bits). Furthermore, each IODD process data element 2 includes a unique text identifier, such as Tl_lnput_7, under which the IODD process data element 2 can be found within the IODD process data image.This allows, for example, the parameterization of the IODD device via the engineering tool, whose IODD process data list 1 was loaded or visualized with the engineering tool.

[0120] In the first step S1 of the procedure, the IODD process data elements 2 are split into input and output process data before the subsequently described steps S2 - S7 of the procedure are carried out separately for the input and output process data. Thus, the IODD process data elements 2 listed under "ProcessDataIn" in the IODD process data list 1 are transferred to an input process data list, and the IODD process data elements 2 listed under "ProcessDataOut" in the IODD process data list 1 are transferred to a further, separate output process data list. This has already been done in the IODD process data list 1 shown in Figure 2, so that only Tautz & Schuhmacher Law TUR1120P12WO 19 August 2025

[0121] The input process data can be seen on pages 17 / 28. The procedure is described below in general terms with reference to IODD process data or an IODD process data list 1, whereby this description applies analogously to the input and output process data or their respective IODD process data lists.

[0122] In a second step S2 of the procedure, the IODD process data elements 2 in the IODD process data list 1 are sorted according to their bit offset to obtain a sorted IODD process data list 1 comprising the IODD process data elements 2 sorted by bit offset. Figure 2 already shows the sorted IODD process data list 1.

[0123] In a third step S3 of the procedure, the sorted IODD process data list 1 is populated, if necessary, to obtain a continuous (bit offset) sorted IODD process data list 1'. Such a continuous sorted IODD process data list 1' is shown in Figure 4. Dummy IODD process data elements 2' with a bit length of 1 (data type BooleanT) and the designation "reserved" are used for populating the list. The padding can be carried out such that the total length of the continuous, sorted ODD process data list 1' is an integer multiple of eight, since the GSDML process data list 4 to be generated must be continuous and the GSDML process data elements 5 contained therein are grouped into subgroups, the so-called GSDML process data elements 5, using the data type UnsignedX or IntegerX (with X = 8, 16, 32 or 64 bits). In the example shown in Figure 4, the length of the entire padded or sorted list is...continuous, sorted OODD process data list 1 ' 32 bit.

[0124] In a fourth step S4 of the procedure, the respective length of the (dummy) lODD process data elements 2, 2' is determined, which are located in the continuous, sorted lODD process data list 1 ' obtained in the third step S3.

[0125] In a fifth step S5 of the procedure, the (dummy) IODD process data elements 2, 2' are added to the GSDML process data list 4, depending on their length. This addition in the fifth step S5 is described in more detail below with reference to Figures 5-7. Tautz & Schuhmacher Law TUR1120P12WO August 19, 2025

[0126] 18 / 28

[0127] The GSDML process data list 4 can only include GSDML process data elements 5 that have a predetermined length of 8 bits, 16 bits, 32 bits or 64 bits.

[0128] Therefore, those (dummy) IODD process data elements 2, 2' whose length corresponds to one of these predetermined lengths of the GSDML process data elements 5, i.e., 8 bits, 16 bits, 32 bits, or 64 bits, are added as a single GSDML process data element 5 to the GSDML process data list 4 in a first substep S51 of the fifth step S5. Such a case is illustrated in Figure 5. In the case shown in Figure 5, the length of the (dummy) IODD process data element 2, 2' is 8 bits, so it lies on the first GSDML integer boundary of 1 byte. Consequently, a GSDML process data element 5 is created, which has a length of 8 bits or 1 byte and which accommodates the (dummy) IODD process data element 2, 2' of length 8 bits, where the identifier of the GSDML process data element 5 from Figure 5 can correspond to that of the (dummy) IODD process data element 2, 2' from Figure 5 or can be determined based on it.

[0129] Furthermore, several of the (dummy) IODD process data elements 2, 2' are combined into a single GSDML process data element 5 in a second substep S52 of the fifth step S5 when added to the GSDML process data list 4. The length of each of these combined elements is shorter than the shortest of the predetermined lengths of the GSDML process data elements 5, i.e., shorter than 8 bits. An example of this case is shown in Figure 6. In the case shown in Figure 6, four (dummy) IODD process data elements 2, 2' are combined into a single GSDML process data element 5 of length 8 bits, i.e., of data type Unsigned8 or Integers. It is conceivable that the identifier of the GSDML process data element 5 from Figure 6 could correspond to, or be determined based on, the longest identifier of the (dummy) IODD process data element 2, 2' from Figure 6.

[0130] Furthermore, those of the (dummy) ODD process data elements 2, 2' are added to the GSDML process data list 4 to multiple GSDML Tautz & Schuhmacher Law TUR1120P12WO 19 August 2025

[0131] 19 / 28

[0132] Process data elements 5 are divided into a third sub-step S53 of the fifth step S5, whose:

[0133] - the respective length is longer than the shortest of these predetermined lengths of the GSDML process data elements 5, i.e., longer than 8 bits in this case, and

[0134] - whose respective length does not correspond to any of these predetermined lengths of the GSDML process data elements 5, i.e., here as 8, 16, 32 or 64 bits.

[0135] Such a case is illustrated in Figure 7. In the case shown in Figure 7, the first of two (dummy) 16-bit IODD process data elements 2, 2' is split into two 8-bit GSDML process data elements 5. As can also be seen in Figure 7, the merging of several (dummy) IODD process data elements 2, 2' into a single GSDML process data element 5, as described above with reference to the second sub-step S52, can be combined with the splitting in the third sub-step 53. Thus, in the case shown in Figure 7, the remaining 2 bits of one of the two GSDML process data elements 5 are padded with another (dummy) 2, 2' IODD process data element. It is conceivable that the identifier of both GSDML process data elements 5 from Figure 7 can correspond to the longer of the two (dummy) ODD process data elements 2, 2' from Figure 7 or can be determined based on it.

[0136] In a fourth sub-step S54 of the fifth step S5 of the procedure, a data type is determined for each of the (dummy) IODD process data elements 2, 2', or selected from a list of data types available according to GSDML, with which the (dummy) IODD process data element 2, 2' is added to the GSDML process data list 4. The determination of the respective GSDML data type for each of the (dummy) IODD process data elements 2, 2' is based on, or dependent upon, an IODD data type of the respective (dummy) IODD process data element 2, 2'. As can be seen from the flowchart in Figure 8, the respective GSDML data type for each of the (dummy) IODD process data elements 2, 2' is determined as described below.

[0137] If, in a first step S541 of the fourth substep S54, it is determined that the IODD data type of the considered (dummy) IODD process data element 2, 2' recordT or uintegerT is, then the GSDML data type is UnsignedX with X = 8, 16, 32 or 64 in Tautz & Schuhmacher Law TUR1120P12WO 19 August 2025

[0138] 20 / 28

[0139] Dependence of a data length in bytes of the considered (dummy) IODD process data element 2, 2'.

[0140] If, in a second step S542 of the fourth substep S54, it is determined that the IODD data type of the considered (dummy) IODD process data element 2, 2' is integerT, then the GSDML data type is IntegerX with X = 8, 16, 32 or 64 depending on a data length in bytes of the considered (dummy) IODD process data element 2, 2'.

[0141] If, in a third step S543 of the fourth substep S54, it is determined that the IODD data type of the considered (dummy) IODD process data element 2, 2' is float32T, then the GSDML data type of the considered (dummy) IODD process data element 2, 2' is Float32.

[0142] If, in a fourth step S544 of the fourth substep S54, it is determined that the IODD data type of the considered (dummy) IODD process data element 2, 2' is stringT, then the GSDML data type of the considered (dummy) IODD process data element 2, 2' is VisibleString.

[0143] If, in a fifth step S545 of the fourth substep S54, it is determined that the IODD data type of the considered (dummy) IODD process data element 2, 2' is octetstringT, then the GSDML data type of the considered (dummy) IODD process data element 2, 2' is octetstring.

[0144] If, in a sixth step S546 of the fourth substep S54, it is determined that the IODD data type of the considered (dummy) IODD process data element 2, 2' is booleanT, then the GSDML data type of the considered (dummy) IODD process data element 2, 2' is BitDataltem.

[0145] In a seventh step, S547, of the fourth substep, S54, an error message can be generated if no suitable GSDML data type could be determined for the considered (dummy) lODD process data element 2, 2' in the steps S541–S546 of the fourth substep, S54, described above. Tautz & Schuhmacher Law TUR1120P12WO August 19, 2025

[0146] 21 / 28

[0147] Since in the specific case all (dummy) IODD process data elements 2, 2' from figures 2 - 4, 9 and 10 are of data type booleanT and thus have a bit length of 1, each of the (dummy) IODD process data elements 2, 2' is created individually with the data type BitDataelement and added to the GSDML process data list 4 according to the byte and bit offsets, as described below with reference to the fifth sub-step S55.

[0148] In a fifth substep S55 of the fifth step S5 of the procedure, a byte offset and a bit offset of the respective (dummy) IODD process data element 2, 2' in the (to be generated) GSDML process data list 4 are calculated. The bit offset determines the position or order of the (dummy) IODD process data elements 2, 2' within a GSDML process data element 5 in the GSDML process data list 4. The byte offset determines the assignment of the respective (dummy) IODD process data elements 2, 2' to a GSDML process data element 5 in the GSDML process data list 4. The following formulas are used to determine the byte offset and the bit offset of the respective (dummy) IODD process data element 2, 2' in the GSDML process data list 4:

[0149] ByteOffsetGSDML

[0150] BitOffsetcsDML = BitOffsetioDD % 8

[0151] ByteOffsetGSDML specifies the byte offset of the respective (dummy) IODD process data element 2, 2' in the GSDML process data list 4. BitOffsetcsDML specifies the bit offset of the respective IODD process data element 2, 2' in the GSDML process data list 4. BitSizelndexioDD specifies a bit size index of the respective (dummy) IODD process data element 2, 2' in the sorted IODD process data list 1'. BitSizeSubindexioDD specifies a bit size subindex of the respective (dummy) IODD process data element 2, 2' in the sorted IODD process data list T. BitOffsetioDD specifies a bit offset of the respective (dummy) IODD process data element 2, 2' in the sorted IODD process data list T. Tautz & Schuhmacher Law TUR1120P12WO August 19, 2025

[0152] 22 / 28

[0153] In the specific case shown in Figures 2-4, 9, and 10, all (dummy) IODD process data elements 2, 2' with a byte offset of 0 are assigned to the first (or, in Figure 9, upper) GSDML process data element 5, whereas all (dummy) 1ODD process data elements 2, 2' with a byte offset of 1 are assigned to the second (or, in Figure 9, lower) GSDML process data element 5. Within each GSDML process data element 5, the (dummy) 1ODD process data elements 2, 2' assigned to that GSDML process data element 5 are sorted in ascending order according to their bit offset (here, starting at 0 and ascending to 7).

[0154] In a sixth step, S6, a GSDML or PROFINET fragment is generated, which in turn is part of a GSDML file, based on the generated GSDML process data list 4. As shown in Figure 10, which depicts the visualization of the GSDML process data list 4 with an engineering tool, this GSDML process data list 4, added to the GSDML file in the sixth step S6 of the procedure, can be visualized. This allows a user of the tool to control the IODD device (especially if process output data is also available) and / or to further evaluate or process it (such as a temperature).

[0155] Tautz & Schuhmacher Law TUR1120P12WO August 19, 2025

[0156] 23 / 28

[0157] Reference symbol list

[0158] 1 ODD process data list

[0159] 1 ' Sorted, populated ODD process data list 2 ODD process data element

[0160] 2' Dummy ODD process data element

[0161] 3 Visualization of the ODD process data list

[0162] 4 GSDML process data list

[0163] 5 GSDML process data element 6 Visualization GSDML process data list

[0164] S1 - S6 process steps

Claims

1. Tautz & Schuhmacher Law TUR1120P12WO August 19, 2025 24 / 28 Patent claims 1. Computer-implemented method for automatically generating a GSDML process data list (4) from an IODD process data list (1), wherein the IODD process data list (1) comprises one or more IODD process data elements (2), characterized in that the method comprises: Determine (S4) a respective length of the IODD process data elements (2), and - Adding (S5) the ODD process data elements (2) to the GSDML process data list (4) depending on their length.

2. Computer-implemented method according to claim 1, characterized in that: - the GSDML process data list (4) includes one or more GSDML process data elements (5) that have at least a predetermined length, and - those of the ODD process data elements (2) are added to the GSDML process data list (4) as a single GSDML process data element (5) (S51) , the respective length of which corresponds to at least one predetermined length of the GSDML process data elements (5).

3. Computer-implemented method according to claim 2, characterized in that: - several of the ODD process data elements (2) are combined into a single GSDML process data element (5) when added (S5) to the GSDML process data list (4) (S52), the respective lengths of which are shorter than the shortest length of at least one predetermined length of the GSDML process data elements (5).

4. Computer-implemented method according to claim 2 or 3, characterized in that: - those of the ODD process data elements (2) when adding (S5) to the GSDML process data list (4) to multiple GSDML- Tautz & Schuhmacher Law TUR1120P12WO August 19, 2025 25 / 28 Process data element (5) are divided (S53), each of which has a length longer than the shortest length of at least one predetermined length of the GSDML process data elements (5) and each of which has a length that does not correspond to any of the at least one predetermined length of the GSDML process data elements (5).

5. Computer-implemented method according to any one of claims 1 to 4, characterized in that the method comprises: - Populating (S3) the IODD process data list (4) with dummy IODD process data elements (2') to obtain a continuous IODD process data list (1'); - where the continuous iODD process data list (1 ') is used as the iODD process data list (1 ) when generating the GSDML process data list (4).

6. Computer-implemented method according to one of claims 1 to 5, characterized in that the sequence with which the (dummy) IODD process data elements (2, 2') are added to the GSDML process data list (4) (S5) depends on the byte and / or bit offsets of the respective (dummy) IODD process data elements (2, 2').

7. Computer-implemented method according to claim 6, characterized in that the method comprises: - Determine (S55) a respective byte offset and / or a bit offset for each of the (dummy) ODD process data elements (2, 2') in the GSDML process data list (4) using: ByteOffsetcsDML = (BitSizelndexioDD - BitSizeSubindexioDD - BitOffsetioDD) / 8 (without remainder) BitOffsetcsDML = BitOffsetioDD % 8 Tautz & Schuhmacher Law TUR1120P12WO August 19, 2025 26 / 28 - where ByteOffsetcsDML is the byte offset of the respective (dummy) ODD process data element (2, 2') in the GSDML- Process data list (4) indicates, - where BitOffsetcsDML is the bit offset of the respective dummy) IODD process data element (2, 2') within the GSDML- Specifies process data element (5) that includes the respective (dummy) ODD process data element (2, 2'), - where BitSizelndexioDD specifies a Bit Size Index of the respective (dummy) IODD process data element (2, 2') in the IODD process data list (4), - where BitSizeSubindexioDD specifies a Bit Size Subindex of the respective (dummy) IODD process data element (2, 2') in the IODD process data list (4), and - where BitOffsetioDD specifies a bit offset of the respective (dummy) iODD process data element (2, 2') in the iODD process data list (4).

8. Computer-implemented method according to any one of claims 1 to 7, characterized in that the method comprises: - Determining (S54) a respective GSDML data type for each of the (dummy) IODD process data elements (2, 2') in the GSDML process data list (4) based on an IODD data type of the respective (dummy) IODD process data element (2, 2'), wherein the respective GSDML data type is determined as follows: - if the IODD data type is recordT or uintegerT, then the GSDML data type is UnsignedX with X = 8, 16, 32 or 64 depending on a data length in bytes of the IODD process data element, - if the iODD data type is integerT, then the GSDML data type is IntegerX with X = 8, 16, 32 or 64 depending on a data length in bytes of the iODD process data element, - if the LODD data type is float32T, then the GSDML data type is Float32, Tautz & Schuhmacher Law TUR1120P12WO August 19, 2025 27 / 28 - if the 1ODD data type is stringT, then the GSDML data type is VisibleString, - if the ODD data type is octetstringT, then the GSDML data type is octetstring, and - if the ODD data type is booleanT, then the GSDML data type is BitDataLtem.

9. Computer-implemented method according to any one of claims 1 to 8, characterized in that the method comprises: - Splitting (S1) the (dummy) ODD process data elements (2, 2') into input and output process data; and - separate execution of the method according to one of claims 1 to 8 for the input and output process data.

10. Computer-implemented method according to one of claims 1 to 9, characterized in that the method comprises generating (S7) a GSDML fragment, optionally a GSDML file, based on the generated GSDML process data list (4).

11. Data processing device, characterized in that the data processing device comprises means for carrying out the method according to one of claims 1 to 10.

12. Computer program comprising instructions which, when the program is executed by a computer, cause the computer to execute the method according to any one of claims 1 to 10.

13. Computer-readable medium comprising instructions which, when executed by a computer, cause the computer to execute the method according to any one of claims 1 to 10.

Images