Device description file, system and procedure for setting up control and / or regulating devices

Abstract

Method for setting up control and / or regulating devices (50), in particular an I / O unit and / or a field device, wherein information is loaded into at least one control device (50) by means of at least one device description file (14, 54) and the loaded information is analyzed for program code means (22, 52, 56) executable for the at least one control device (50), executable program code means (22, 52, 56) are recognized as such and executed, and wherein at least one control device (50) is assigned at least one demand-dependent predeterminable functionality and / or configuration and the respective control device (50) is configured accordingly, wherein the device description file (14, 54) has a data structure with at least two parameter segments, wherein in at least one segment (16, 20;54a, 54c) a parameter set for parameterizing the respective control device (50) and in at least one further segment (18, 54b) a parameter set with program code means (22, 52, 56) executable for the control device (50) is contained and a real-time operating system is executed in the respective control device (50), wherein the execution of the loaded program code means (22, 52, 56) is determined by the real-time operating system.;

Description

The invention relates to a system and method for setting up control and / or regulating devices, in particular I / O control units and fieldbus devices, as well as a device description file that can be used accordingly. The setup essentially involves configuring and / or functionalizing the aforementioned devices, both of which can be carried out in a particularly application-specific and / or needs-based manner. Traditionally, control devices, such as fieldbus devices, are used with a defined, predetermined range of functions, whereby the range of functions and thus the functionality is essentially determined by the firmware implemented in the device's fixed memory or the implemented operating system environment. The publication DE 103 57 276 A1 relates to a system and a method for the directed provision and installation of device-specific functionalities and / or information for field devices arranged in a distributed system, in particular in a distributed automation system. The publication DE 102 08 013 A1 concerns a method for transferring field device data, which is stored in an internal database IDB of a process control system, to an external database. Document WO 01 23 971 A1 concerns a method for reprogramming a field device in a network for process control. Publication US 2004 015 952 A1 concerns a method for downloading firmware upgrades into non-volatile memory of a programmable field device over a communication network. Document US 2005 198 487 A1 relates to a method and corresponding devices for supporting a remote configuration code. Known systems and methods generally allow field devices to be parameterized using configuration files, whereby certain predetermined functionalities of the respective field device can only be switched on or off, or activated or deactivated, depending on the requirements and application of the respective device. As illustrated in Fig. 1, this is achieved by means of device description files, which are transmitted via at least one data processing unit in communication with the respective field device. Field device parameter data of a first field device, for example, a combined pressure and temperature sensor, are set. These parameter data can relate in particular to pressure range, fieldbus communication speed, and the like. In a second field device, in particular a decentralized input / output device (I / O device), the I / O data of the respective channels is then parameterized.This data is generally stored in non-volatile memory in the respective field device. Furthermore, systems and methods have become known in which the field device parameterization is carried out indirectly via an intermediate programmable logic controller (PLC) connected between the data processing unit and the first field device. However, it should be noted that the PLC used is configured in such a way that the PLC resets the corresponding device parameters each time the respective device is started up / runs up, thus eliminating the need to write these device parameters to a non-volatile field device memory area, and that the format of the original device description file is transferred to the PLC in a modified form. Fieldbus and device description files are typically closely linked. For example, HART (Highway Addressable Remote Transducer) field devices often use DD (Device Description) files, while PROFIBUS field devices use GSD (General Station Description) files. Similarly, other fieldbus systems also have their own individual file formats with appropriate structures. Control devices, especially field devices, can conventionally be parameterized via device description files to switch certain predetermined functionalities on and off. In well-known decentralized PLC systems, a real-time bus is typically used between the tightly coupled control elements, for example, in x-axis motion control applications, especially for actuators. The controlling central PLC is often only used via a non-real-time bus for configuring the overall application, particularly using device description files. In conventional central control systems, a real-time bus exists between the central PLC (Programmable Logic Controller) and the respective control elements, with the entire control system being centrally managed. The control units here merely serve as signal converters between actuators and sensors. A corresponding, exemplary x-axis motion control application specifies that all x-motors are configured as actuators, each with its own corresponding encoder (sensor), with the entire control loop centrally managed by the PLC. However, the disadvantage of using known methods and arrangements for parameterization is that only a limited and therefore not very needs-based and comparatively restricted functionalization and configuration of control devices, especially fieldbus devices and I / O control units, is achievable and feasible for use in the automation industry. The invention is therefore based on the objective of providing a possibility for an efficient and flexible setup of control and / or regulating devices, in particular I / O control units or field devices. This problem is solved by a method for setting up control and / or regulating devices with the features of claim 1, as described above. Advantageous embodiments and further developments of the method, as well as a corresponding system and a device description file, are specified in further claims and the following description. In the inventive method for setting up control and / or regulating devices, in particular an I / O unit and / or a field device, information is read and / or loaded into at least one control and / or regulating device by means of at least one device description file, and / or the loaded information is analyzed for program code means executable for the at least one control and / or regulating device, executable program code means are recognized as such and interpreted and / or executed, and at least one demand-dependently predeterminable functionality and / or configuration is imposed on at least one control and / or regulating device, and the respective control / regulating device is set up and / or configured accordingly. In advantageous further development, it is foreseeable that executable program code will be provided for the respective control / regulating device through the information read from the device description file. In a further process design, the read-in information, in particular the executable program code elements, are provided at least partially in binary form and / or as a file structure with individual parameters or parameter arrays. Furthermore, the read-in information can be loaded into a data storage device of the field device and / or stored in a persistent data storage device. As is the procedure, it is also foreseeable that with each subsequent reading process, the previously read information will be overwritten. In a further development of the procedure, the identification and interpretation of read-in information as executable program code means is achieved by preparatoryly storing or making available and / or reading or calling the executable program code means, in particular instructions and / or sequences of instructions, in a predetermined parameter segment of the device description file. In another embodiment, the time of execution of the program product is determined by readable parameters. It is also foreseeable that the loading of the information will be carried out using a standardized protocol, in particular EtherCAT. In a further advantageous embodiment, it is provided that the information is read in in conjunction with at least one programmable logic controller (PLC). Furthermore, the task is also solved by a corresponding system, which is specifically designed for carrying out the method exemplary according to the invention. The system for setting up control and / or regulating devices, in particular I / O control units and / or field devices, comprises at least one access means for accessing at least one first data storage device, as well as at least one control and / or regulating device, wherein the at least one first data storage device has at least one device description file with program code means executable for the at least one control and / or regulating device, by means of which one or more functions or functionalities and / or at least one predeterminable configuration can be imposed on at least one control and / or regulating device, and wherein, in the interaction of the access means and the at least one first data storage device, the at least one device description file and / or the executable program code means can be loaded into and / or executed in at least one control / regulating device. In a system-compliant design, it is intended that it is designed and equipped for carrying out and / or executing one of the aforementioned procedures. In a further embodiment, it is provided that the access means is designed as a data processing device, in particular as a microprocessor or microcontroller, and / or advantageously includes an input and display device in order to capture and / or adapt the device description file and / or the information contained therein, in particular parameters, as required, and / or to imprint or transfer it to the respective control device. It is also foreseeable that the control / regulating device will include a data storage device, which is designed in particular as persistent (non-volatile) solid-state storage or solid-state storage. In a further advantageous development, it is also foreseeable that within the memory structure e a predetermined memory area is defined for a boot code and / or a runtime system and / or for basic functions. At least one data storage device is also foreseeable, which is implemented in the integrated access means of the control / regulation device designed as a microprocessor or microcontroller, in particular as "embedded flash". Further development of the system includes at least one hardware and / or software interface for data exchange and communication between at least one data storage device and the access means, as well as at least one control / regulation device, such as PCI bus, SCSI, USB, Firewire, RS-232. Alternatively or additionally, data exchange can also be achieved via control and / or fieldbus systems, such as RS-485, CAN, CANopen, DeviceNet, EIB, Fieldbus Foundation, Interbus, LCN (Local Control Network), Modbus, Profibus, SERCOS Interface, TTP, as well as Ethernet or real-time Ethernet, such as EtherCAT, Ethernet Powerlink, Profinet, Ethernet / IP or Industrial Ethernet, and possibly combinations thereof. The control and / or regulating device can be designed as a field device. It is advantageously foreseen that the device description file used has a data structure with at least two parameter segments, wherein at least one segment contains a parameter set for parameterizing the respective control and / or regulating device and at least one segment contains a parameter set with executable program code means, in particular in binary code. The program code resources executable for the respective control and / or regulating device may, in a further development of the system, include not only the actual program, in particular instructions and / or sequences of instructions, but also program data and information regarding the respective input and / or output data. It is also foreseeable that the program code means will include and / or impose functionality, a programming environment and / or a programmable logic controller. In an advantageous embodiment, a real-time operating system is provided and implemented in the respective control and / or regulation device, in particular an I / O control unit and / or a field device, which is responsible for fieldbus communication and / or the execution of the program code means provided by the device description file, in particular cyclically or anticyclically, and / or the correct linking of the input and output data of the program code means with the runtime system and / or the handling of the device parameters, as well as handling them. A device description file for setting up control and / or regulating devices also contributes to solving the task at hand, wherein this device description file has a data structure with at least two parameter segments and wherein at least one segment contains a parameter set for parameterizing the respective control and / or regulating device and at least one segment contains a parameter set with program code means executable for the control and / or regulating device, in particular in binary code. In an advantageous embodiment, it is provided that the executable program code means contain, in addition to the actual program, in particular instructions and / or sequences of instructions, also program data as well as information regarding the respective input and / or output data. The invention, as well as advantageous embodiments and further developments, will be explained in more detail with reference to some figures and exemplary embodiments given below. Figure 1 shows a known field device configuration setup, Figure 2 a known field device configuration setup with an intermediate PLC, Figure 3 an exemplary device description file according to the invention, Figure 4 an exemplary creation of the program code means required for setting up a control unit according to the invention, Figure 5 an exemplary executable program or corresponding program code means imprinted on a field device according to the invention, Figure 6 a cam switch designed in an exemplary manner using a device description file, Figure 7 a communication data link designed in an exemplary manner using a device description file, Figure 8 an exemplary factory automation. Figure 1 shows a conventional field device configuration setup. Device description files 1a, 1b are transferred via a configuration PC 4 to connected field devices 6. Parameter data is set in a combined pressure and temperature sensor 2, for example, regarding pressure range, fieldbus communication speed, etc. The second field device, a decentralized input / output device (I / O device) 8, performs the input and output data parameterization of the individual channels. Such data is often stored in non-volatile memory in the field devices 6 and 8. Communication between the first field device 6 and the second field device 8 takes place via a fieldbus 10. Figure 2 shows a setup similar to Figure 1, except that the field device parameterization and thus configuration is performed indirectly via an intermediate PLC 12. For further details, please refer to the description of Figure 1. Figure 3 shows an exemplary device description file 14 according to the invention, which is structured into individual parameter segments 16, 18, 20 and in which at least a second parameter segment 16 is provided for receiving, in particular storing, a respective executable program 22 – program code means in binary form – which can be processed directly by the respective control device, in particular by its microprocessor. Furthermore, at least one further, first parameter segment 16, 20 is provided in which the associated parameter set for configuring the respective control device is also stored.In combination with a real-time Ethernet protocol variant, such as EtherCAT, and existing slave-to-slave communication, extremely flexible control systems—specifically control loops—can be implemented, in which the respective applications and / or functionalities are loaded into the remote control units or devices and simultaneously parameterized and configured in just one work unit or a single work or process step. The parameters in the second segment n 18 of the device description file 14, which are hexadecimal marked as 0xXX, form an executable program 22 in binary form, which is segmented or broken down into byte fields and which was created or generated in advance on a data processing device, in particular a personal computer (PC). The respective parameters of parameter segment n 18 can be included and / or specified in the device description file either as individual parameters or as an array or matrix – depending on what is supported by the file format of the respective device description file 14. If the device description file only supports individual parameters, means must be provided to ensure that, during the loading of the respective device description file into the field device, these individual parameters are assembled in the correct order and stored in a section of the respective microprocessor memory in such a way that this parameter field, or the executable program, can be executed at the given time. However, the time of program execution can also be determined with sufficient accuracy using 'ordinary' device parameters.This also applies, of course, to parameter arrays; however, in this case, the order in which the parameters are read is predefined or predetermined. A parameter array is a more suitable and / or preferred way to store executable program code, although not all device description types or device description file formats allow or support such a function. Fig. 4 shows an example of the creation of the program code means 22 required for setting up a control unit according to the invention. In order for the program code elements to be executed, in particular executable instructions in a common programming language 26, to be executable in the respective control / regulation device and / or in the respective field device, a memory structure 24 must first be defined and / or provided in which the various data segments of the respective file, in the example shown here parameter segments of a device description file, have been defined and prepared for input 24a as well as output data 24b, program code 24c and, if applicable, program data 24d or program-related data, so that the entry into the program to be executed by the runtime system (LTS) can also be carried out correctly or effected, as illustrated in Fig. 4. Any common programming tool 28, such as GNU, .NET or the like, can be used to generate or create executable program code and / or to compile, link (combine) the respective program code and ultimately convert it into a binary file 30, preferably in ASCII format 32. Figure 5 shows a device description file in ASCII format 54, designed according to the invention and imprinted on a field device 50. This file essentially comprises three parameter segments 54a, b, and c. The first parameter segment 54a includes the parameters a to m, and the third parameter segment 54c includes the parameters r to z. The second parameter segment 54b comprises an exemplary executable program or corresponding executable program code elements in the form of seemingly ordinary parameters 56. The respective real-time operating system 58, which is executed in the field device 50, is responsible for the following functions and functionalities: a) fieldbus communication; b) execution of the embedded program (cyclically or acyclically); c) correct linking of the input and output data in the embedded or imprinted program with the runtime system; d) handling of the device parameters. The parameters a to m of the first segment 24a directly control the respective basic device functions, such as the Basic Input Output System (BIOS), including communication speed, data transmission rate, addressing, and the like. The parameters of the second segment 24b, if any are specified, are used to configure the respective executable program or result in a corresponding configuration of the respective executable program and / or the program code resources. In the method for setting up control and / or regulating devices, in particular an I / O unit and / or a field device, information is read and / or loaded into at least one control and / or regulating device 50 by means of at least one device description file 54, and the loaded information is analyzed for program code means executable for the at least one control and / or regulating device 50, executable program code means are recognized as such and interpreted and / or executed, and at least one demand-dependently predeterminable functionality and / or configuration is imposed on at least one control / regulating device 50, whereby the at least one control / regulating device is set up and / or configured according to requirements. As an example, a field device 50 connected to a fieldbus is to be extended by a predetermined functionality according to the procedure, for example, by that of an electronic cam switch 60. By means of a cam switch, as shown by way of example in Fig. 6, various combinations of data and / or signals present at the inputs of the field device 50 are evaluated by means of a cam switch, as shown by way of example in Fig. 6, and output data and / or signals are determined according to a predefined logic, which can be read out and / or tapped at the outputs of the field device 50 and can also be placed on the fieldbus. The program code elements 52 implementing the desired functionality are transferred to the field device 50's memory via the respective communication options provided by the field device 50 using a device description file 54. These communication options are typically limited to communication via the fieldbus. The device description file 54, intended for transmission to the field device 50 via the fieldbus, has a fixed data or information structure, similar to that found, for example, in GSD files. These files contain fixed areas and / or segments 24a,b,c for parameters that typically only influence / adapt and / or activate or deactivate existing functionalities of a field device 50. To extend the functionality of the respective field device 50, a device description file 54 with a predetermined data structure, in particular with at least two parameter segments 54a, b, c, of which at least one contains corresponding program code elements 56 for implementing the respective functionality, is created and prepared for transmission to one or more field devices 50. This device description file 54 includes, for example, the parameters a to z, where, for example, the parameter n is assigned to a data segment 54b, which contains executable program code elements 56 that extend the field device 50 with the desired functionality.The executable program code or executable program code resources 56 are prepared in advance using, for example, a programming tool such as a compiler from the associated source code and transferred to the desired device description file 54 using a suitable formatting tool together with possible device parameters. The respective device description file 54 is transmitted via the fieldbus to the relevant field device 50 and loaded into its working memory and / or imprinted on the respective field device 50. A central control computer connected to the fieldbus can be used as an access device for this transmission. In this process, a corresponding storage structure of the field device 50 is also used as a basis in order to store the information contained in or provided by the device description file 54 in the desired manner in the memory. This structure includes, for example, predefined memory areas for input data 52a, output data 52b and program code means 52c executable on the respective control and / or regulating device, which are fundamentally identical to the structure of the transmitted device description file 54. Alternatively, a structure-based analysis and selection of executable program code means 56 can be carried out by the control and / or regulating device according to procedure. Depending on the data structure used, an executable program code 56 can also be distributed across a large number of individual parameters and / or stored in the memory of the field device 50 in a consistent order according to a corresponding algorithm. The loaded, executable program code means 56 are usually determined by parameters, which may also be contained in the transferred file 54. The execution of the loaded program code 52 is determined, for example, by a real-time operating system 58a of the field device 50, whereby both cyclic and acyclic execution are conceivable. The parameters for the execution of the program code can also be transmitted as parameters in the same file 54 as the program code 52. In the case of cyclic execution of the electronic cam switch 60 described above, corresponding output variables would be determined at a fixed time interval based on incoming input data or input signals and made available to other fieldbus participants via the fieldbus. In another embodiment of the process, the executable program code elements 56 of the device description file 54 do not represent the actual functionality of a field device 50, but rather selected functionalities of a PLC (Programmable Logic Controller). These functionalities of a PLC enable the field device 50 to execute further loaded program code elements 52 or a corresponding program product, whereby this does not have to be in a directly executable binary form, but rather its instructions are interpreted by the loaded PLC functionality. As an example of an executable program or corresponding program code, a cam switch 60 can be mentioned, which can be loaded into a decentralized input / output module via a device description file 54. Such a function module would thus be implemented in 'hardware'. For each such function module, here exemplified by a cam switch 60, a corresponding function block is provided in the IEC 61131 programming environment used, as shown in Fig. 6: Such a function element or function module can be addressed and controlled directly by the main PLC with very short response times. As a further example, an executable program is mentioned which, based on a data packet sent by the main controller (where transmission can be cyclical or acyclical), logically links predefined inputs and / or outputs. Accordingly, exemplary logic blocks 62 and 64 according to IEC 61131 for communication data linking are shown in Fig. 7. Figure 8 shows an exemplary factory automation system in which valves 65 can be switched via digital output channels according to the rotation angle read by a rotary encoder 63. The executable program or the corresponding program code elements, here exemplified by a cam switch with, in particular, 4 cams per track and 8 tracks, in the two I / O devices 66 and 68 shown, can be programmed, set up, and conditioned very flexibly. If four cams on one track are insufficient, the number of cams per track can be increased very easily by a corresponding program adjustment. Alternatively, instead of simply loading the respective executable program into a sensor or a distributed I / O module via the device description file, as shown in Fig. 5, the binary code of an IEC 61131 programming environment can advantageously be loaded and / or imprinted directly, without first having to generate a binary code parameter list for the device description file using further proprietary programming tools. However, this requires that a corresponding runtime system (LTS) or real-time operating system is also present in a sensor or I / O module, which blurs or renders obsolete the distinction between the main control PLC and the distributed control system. Furthermore, it is advantageously foreseeable that the executable program or application not only includes the generated IEC61131 program, but also additionally represents another PLC which - similar to the main control PLC - is set up to execute IEC61131 programs. The execution times in the sensor or I / O module of the different variants or designs – binary file directly generated with proprietary programming development tools and self-defined memory allocation, or generated binary code via standard IEC61131 development environment and LZS (runtime system) permanently present in the device, or generated binary code via standard IEC61131 development environment plus the LZS in the device description file – differ only slightly. However, the complexity and size of the description file for the last execution variant or alternative would be a significant disadvantage. In an advantageous embodiment, it is further foreseeable that the two remote I / O modules are configured as secondary or tertiary PLCs. This is just one application among a very large number of possible applications. To increase response speed, a real-time bus such as EtherCAT with cross-communication and distributed clocks can be selected. The advantages of the solution according to the invention compared to centralized and decentralized PLC controllers are based, among other things, on the fact that comparatively very complex and very fast application structures are possible, with complexity being very easily scalable. In particular, the immense flexibility combined with a very high execution speed of the respective applications compared to conventional purely decentralized and centralized PLC controllers should be emphasized.

Claims

Method for setting up control and / or regulating devices (50), in particular an I / O unit and / or a field device, wherein information is loaded into at least one control device (50) by means of at least one device description file (14, 54) and the loaded information is analyzed for program code means (22, 52, 56) executable for the at least one control device (50), executable program code means (22, 52, 56) are recognized as such and executed, and wherein at least one control device (50) is assigned at least one demand-dependent predeterminable functionality and / or configuration and the respective control device (50) is configured accordingly, wherein the device description file (14, 54) has a data structure with at least two parameter segments, wherein in at least one segment (16, 20;54a, 54c) a parameter set for parameterizing the respective control device (50) and in at least one further segment (18, 54b) a parameter set with program code means (22, 52, 56) executable for the control device (50) is contained and a real-time operating system is executed in the respective control device (50), wherein the execution of the loaded program code means (22, 52, 56) is determined by the real-time operating system.; Method according to claim 1, characterized in that executable program code means (22, 52, 56) are provided for the respective control device (50) by the loaded information of the device description file (14, 54) and the executable program code means (22, 52, 56) are provided at least partially in binary form (30, 32) and as a file structure (24) with individual parameters or parameter arrays. Method according to one of the preceding claims, characterized in that the read-in information is loaded and / or stored in a data storage device of the control unit (50), wherein the data storage device of the control unit (50) is designed as a persistent solid-state storage device. Method according to one of the preceding claims, characterized in that identification and interpretation of loaded information as executable program code means (22, 52, 56) is effected by storing the executable program code means (22, 52, 56), in particular instructions and / or sequences of instructions, in a predetermined parameter segment (18, 54b) of the device description file (14, 54). Method according to one of the aforementioned claims, characterized in that the time of execution of the program code means (22, 52, 56) is determined by readable parameters. Method according to one of the preceding claims, characterized in that the information is read in conjunction with at least one programmable logic controller and / or is initially read into at least one programmable logic controller. System for setting up control devices (50), in particular I / O control units and / or field devices, comprising at least one access means for accessing at least one first data storage device, and at least one control device (50), in particular a field device, wherein the at least one first data storage device has at least one device description file (14, 54) with program code means (22, 52, 56) executable for at least one control device (50), by which at least one control device can be assigned one or more functionalities and / or at least one predeterminable configuration, and wherein, in the interaction of the access means and the at least one first data storage device, the at least one device description file (14, 54) and its executable program code means (22, 52, 56) can be loaded into and / or executed in at least one control device (50), wherein the device description file (14,54) has a data structure with at least two parameter segments, wherein at least one segment (16, 20; 54a, 54c) contains a parameter set for parameterizing the respective control device (50) and at least one further segment (18, 54b) contains a parameter set with program code means (22, 52, 56) executable for the control device (50) and a real-time operating system is provided and executed in the respective control device (50). System according to claim 7, characterized in that the real-time operating system is responsible for and performs the fieldbus communication, the execution of the program code means (22, 52, 56) provided by the device description file (14, 54), the correct linking of the input and output data of the program code means (22, 52, 56) with the runtime system and the handling of the device parameters. System according to one of claims 7 to 8, characterized in that the control device (50) comprises a data storage device, which is in particular designed as a persistent (non-volatile) solid-state storage device, and within the storage structure a predetermined storage area is defined for a boot code, a runtime system and / or for a basic function. System according to one of claims 7 to 9, characterized in that at least one hardware and / or software interface for data exchange and communication between at least one data storage device and the access means and at least one control device (50) is provided, such as in particular PCI bus, SCSI, USB, Firewire, RS-232. System according to claim 10, characterized in that the data exchange is also effected via control and / or fieldbus systems, such as in particular RS-485, CAN, CANopen, DeviceNet, EIB, Fieldbus Foundation, Interbus, LCN (Local Control Network), Modbus, Profibus, SERCOS Interface, TTP, as well as Ethernet or real-time Ethernet, such as in particular EtherCAT, Ethernet Powerlink, Profinet, Ethernet / IP or Industrial Ethernet and optionally a combination thereof. System according to one of claims 7 to 11 characterized in that the executable program code means (22, 52, 56) contain, in addition to the actual program, instructions and / or sequences of instructions, program data as well as information regarding the respective input (24a) and / or output data (24b). System according to claims 7 to 12, characterized in that it is designed and equipped for carrying out and / or performing a method according to one of claims 1 to 6.

Images