Implementation method and equipment for self-contained IO of programmable logic controller, and medium

By abstracting the I/O module into a software function block using the IEC61499 standard and implementing dynamic loading using XML configuration files, the tight coupling problem of the PLC's built-in I/O module is solved, enabling flexible configuration and efficient maintenance of the PLC during runtime.

CN121956784APending Publication Date: 2026-05-01CHENGDU SHUZI AUTOMATION TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
CHENGDU SHUZI AUTOMATION TECH CO LTD
Filing Date
2026-02-05
Publication Date
2026-05-01

AI Technical Summary

Technical Problem

In existing technologies, the built-in I/O modules of PLCs cannot be dynamically changed, resulting in tight coupling issues, long development cycles, and difficult maintenance.

Method used

Adopting the IEC61499 standard, the IO module is abstracted into a software functional block and dynamically loaded and managed through XML configuration files. This decouples the PLC core from the IO hardware, supports one-time compilation and multiple configurations, and only requires providing configuration files and driver libraries to change the IO module.

Benefits of technology

It enables PLCs to run without recompilation, IO modules to be easily changed, improves system flexibility and maintainability, reduces technical barriers and failure risks, and supports a fully reconfigurable open control system.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121956784A_ABST
    Figure CN121956784A_ABST
Patent Text Reader

Abstract

The invention discloses an implementation method, equipment and medium for a programmable logic controller (IO) with an IO, an IEC 61499 event-driven and functional block network model is deeply applied to control of an IO module with a PLC, a PLC core is completely decoupled from specific IO hardware during operation, and driving codes of the specific IO module do not need to be included during operation; identification, drive loading, resource allocation and function integration of a new IO module can be completed by modifying an external and standard configuration file; each IO module and a channel thereof are abstracted and packaged into a software function block conforming to the IEC61499 standard, so that an IO access interface is standardized and unified, and an automatic conversion chain from static XML configuration to dynamic drive library loading to standardized IEC61499 function block instantiation can seamlessly convert a hardware entity into a software programmable component.
Need to check novelty before this filing date? Find Prior Art

Description

A method, device, and medium for implementing built-in I / O in a programmable logic controller. Technical Field

[0001] This invention relates to the field of industrial automation control technology, and specifically to a method, device, and medium for implementing built-in I / O in a programmable logic controller. Background Technology

[0002] Currently, there are several ways to control the built-in I / O modules of programmable logic controllers (PLCs) in industrial automation systems, all of which have significant drawbacks:

[0003] Traditional hard-coding and static compilation methods: In an integrated development environment (IDE), I / O modules are added as fixed devices to the project's hardware tree by adding specific device description files, and program variables are hard-mapped to specific I / O channels. Any change in I / O module model, increase or decrease in the number of channels, or address adjustment requires modifying the program and recompiling the entire project code, followed by downloading the complete program containing the new I / O drive logic back to the PLC. This process is cumbersome, time-consuming, and cannot be dynamically adjusted at runtime, severely violating the requirements of flexible production and rapid changeover.

[0004] Distributed Control Based on IEC 61499: The IEC 61499 standard provides a function block-based modeling approach for distributed industrial control applications. Existing technologies have explored its use in building reconfigurable systems or web-based configuration servers. These solutions address the deployment and reconfiguration of function blocks at the network communication and application logic levels. However, this approach does not fundamentally solve the tight coupling problem of PLC's built-in I / O modules. Local I / O is treated as a device, and its access interfaces must be pre-compiled to runtime, which increases the development cycle due to frequent compilations. Summary of the Invention

[0005] The technical problem this invention aims to solve is that IO modules cannot be dynamically changed, and the built-in IO modules of PLCs are tightly coupled. The purpose is to provide a method, device, and medium for implementing built-in IO in a programmable logic controller (PLC). This aims to deeply apply the event-driven, function block network model of IEC 61499 to the control of PLC built-in IO modules, completely decoupling the PLC core runtime from specific IO hardware, eliminating the need for driver code for specific IO modules during runtime. By modifying external, standard configuration files, the identification, driver loading, resource allocation, and functional integration of new IO modules can be completed. Each IO module and its channels are abstracted and encapsulated into a software function block conforming to the IEC 61499 standard, thus standardizing and unifying the IO access interface.

[0006] This invention is achieved through the following technical solution:

[0007] The first aspect of this invention provides a method for implementing built-in I / O in a programmable logic controller, comprising the following specific steps:

[0008] Obtain PLC model identification information, I / O module type information, and input / output point configuration information, and generate an XML configuration file;

[0009] A driver library is generated based on the PLC model identification information. The driver library is used to implement the IO driver interface structure and a function to obtain the structure. The function returns the structure.

[0010] Real-time monitoring of trigger events; when any trigger event is detected, the IO driver performs dynamic loading and abstract configuration of the driver library.

[0011] A standard IO function block is constructed, which maps the IO driver capabilities of the abstract configuration to an IEC61499 standard executable entity, and performs abstract interaction configuration, enabling the upper-layer control application to access the underlying IO driver through the function block.

[0012] Furthermore, the generation of the XML configuration file specifically includes:

[0013] Receive user input of PLC model identification information, I / O module type information, and input / output point configuration information, and initialize the XML configuration file structure;

[0014] Based on the initialized XML configuration file structure and combined with the preset mapping rules between I / O module types and driver modules, the driver information corresponding to the I / O module type is determined.

[0015] The configured driver information data structure is serialized into an XML configuration file that conforms to the semantics of IEC 61499.

[0016] Furthermore, the initialization of the XML configuration file structure specifically includes:

[0017] Create the root node for the device type;

[0018] Configure device architecture information;

[0019] Set the device type annotation to controller;

[0020] Specify redundancy configuration;

[0021] Write the device type identifier sub-element;

[0022] Declare device manager identifier variables;

[0023] Create a hardware configuration node.

[0024] Furthermore, determining the driver information corresponding to the I / O module type specifically includes:

[0025] Instantiate the first driver module, assign the first driver identifier and the first module name, and configure the first input parameters and the first output parameters;

[0026] Instantiate the second driver module, assign a second driver identifier and a second module name, and configure the second input parameters and the second output parameters;

[0027] The first driver module and the second driver module are of the same type, forming a multi-instance deployment of the same type of driver.

[0028] Furthermore, the structure includes:

[0029] An initialization function pointer is used to initialize based on the device ID and returns a driver handle;

[0030] The uninitialization function pointer is used to release and clean up resources occupied by the driver.

[0031] Output data function pointer, used to send output data to the device;

[0032] The input data function pointer is used to read input data from the device; the data length is returned via the pointer.

[0033] Write parameter function pointer, used to write configuration parameters to the device;

[0034] The function pointer for reading parameters is used to read configuration parameters from the device;

[0035] A driver handle is used to identify a specific device instance.

[0036] Furthermore, the dynamic loading and abstract configuration of the IO driver execution driver library specifically includes:

[0037] Extract hardware configuration information from the XML configuration file, create input / output channels, and set default configuration values;

[0038] Obtain the driver name, open the dynamic link library corresponding to the driver name, and dynamically load the driver.

[0039] Use the dlsym function to find the function of the structure in the loaded dynamic link library and get the function entry address;

[0040] Call the function to create and return a pointer to the driver interface structure.

[0041] Furthermore, the functions of the standard I / O function block include:

[0042] Specify the I / O driver module;

[0043] Specifies the offset of the data to be read in the IO driver;

[0044] Specifies the offset of the data to be written in the IO driver.

[0045] Furthermore, the abstract interaction configuration specifically includes:

[0046] The configuration function block includes abstract interaction parameters, which at least include the driver name and device identifier ID;

[0047] When the function block responds to the initialization trigger signal, it searches for the corresponding structure pointer in the virtual device tree according to the driver name;

[0048] Call the initialization function pointer, pass in the device identifier ID, perform initialization operation on the target hardware interface, and obtain the private handle returned by the driver layer;

[0049] After initialization, the output data function pointer is called with the private handle as a parameter to send the function block operation result to the target hardware interface; and / or the input data function pointer is called with the private handle as a parameter to read the field data from the target hardware interface, thus completing the abstract data interaction between the function block and the I / O module.

[0050] A second aspect of the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements a method for implementing built-in I / O of a programmable logic controller.

[0051] A third aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a method for implementing built-in I / O of a programmable logic controller.

[0052] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0053] Completely eliminates the need for recompilation: It achieves one-time compilation and multiple configurations. The core runtime program of the PLC only needs to be compiled once. Subsequent changes and expansions of the IO module only require providing the configuration file and the corresponding driver library, without the need for runtime compilation, which greatly shortens the project iteration and on-site debugging time.

[0054] Achieving true hardware-software decoupling: The user program only interacts with standard function blocks, completely isolated from the physical hardware. Even with changes to the I / O module model, only configuration changes are needed, without modifying the user program.

[0055] Improved system flexibility and maintainability: On-site maintenance personnel can easily replace hardware or remap channel functions by changing configuration files, reducing technical barriers and maintenance costs.

[0056] Leveraging the advantages of the IEC 61499 standard: Local I / O resources are uniformly incorporated into the modeling, management, and scheduling of IEC 61499, achieving a unified modeling language from the field layer to the control layer. This provides a key technological foundation for building a fully reconfigurable, highly interoperable next-generation open control system.

[0057] Enhanced system reliability: Since the core runtime remains stable, only the peripheral I / O driver modules are variable, reducing the risk of introducing global software failures due to system upgrades. Simultaneously, standardized function block interfaces facilitate more thorough simulation testing. Attached Figure Description

[0058] To more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be considered as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort. In the drawings:

[0059] Figure 1 is a diagram of the standardized function block FB_IO in an embodiment of the present invention;

[0060] Figure 2 is an internal logic diagram of the IO function block in an embodiment of the present invention;

[0061] Figure 3 is the second internal logic diagram of the IO function block in an embodiment of the present invention. Detailed Implementation

[0062] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the embodiments and accompanying drawings. The illustrative embodiments and descriptions of the present invention are only used to explain the present invention and are not intended to limit the present invention.

[0063] As one possible implementation method, as shown in Figure 1, this embodiment provides a method for implementing built-in I / O of a programmable logic controller (PLC). Specifically, it describes a system and method based on the IEC 61499 standard that implements control of the built-in (local) I / O module of a PLC through pure configuration, without recompiling or modifying the runtime program. This embodiment proposes and implements for the first time an automated conversion chain from static XML configuration to dynamic driver library loading, and then to the instantiation of standardized IEC 61499 function blocks. This seamlessly transforms hardware entities into software programmable components. The PLC's IEC 61499 runtime does not need to include any specific I / O function block implementations at startup. All I / O function block instances are dynamically created and injected into the runtime resources after startup according to the configuration, achieving runtime purity and universality. By utilizing the management model and XML format commands defined in the IEC 61499 standard, dynamic reconfiguration (addition, deletion, modification) of the I / O hardware subsystem is achieved, making the process standardized and interoperable, rather than a proprietary operation.

[0064] This embodiment runs on a PLC processor (e.g., a Linux-based platform), and its core architecture includes: a configuration description layer, a dynamic loading and management layer, a standardized function block layer, and an IEC 61499 runtime environment. The specific implementation steps are as follows:

[0065] Step A: Configuration Description.

[0066] After determining the I / O modules, PLC manufacturers need to manually create a separate XML configuration description file for each PLC model, based on the different numbers of input / output points. Alternatively, a small plugin can be implemented to automatically generate this XML file based on user input. This file must conform to the semantics of IEC 61499 device management. An XML configuration file can contain multiple driver information entries, or it can contain one driver information entry with multiple instances.

[0067] The XML configuration file must define the following content:

[0068] 1. Module unique identifier ID;

[0069] 2. Detailed information for each IO channel, such as channel type (e.g., DI / DO), electrical characteristics (e.g., range, filter parameters, etc.), data format, number of channels, etc.;

[0070] 3. Specify the underlying driver name.

[0071] An example of an XML configuration file is as follows:

[0072] <?xml version="1.0" encoding="UTF-8"?>

[0073] <devicetype type="DeviceType" arch="Armv8_Linux" comment="控制器" redundancy="0">

[0074] <identification Standard="61499 ITA" / >

[0075] <vardeclaration Name="MGR_ID" Type="WSTRING" InitialValue="10.10.10.10:61499" / >

[0076] <hwconfig>

[0077] <driver id="1" modulename="Hello">

[0078] <input DI="8" AI="1" Filter="10">

[0079] <output DO="16" AO="1">< / output>

[0080] < / driver>

[0081] <driver id="2" modulename="Hello">

[0082] <input DI="8" AI="1" Filter="10">

[0083] <output DO="16" AO="1">< / output>

[0084] < / driver>

[0085] < / hwconfig>

[0086] < / devicetype>

[0087] Step B: Generate the driver library.

[0088] For PLCs from different manufacturers, the driver library needs to be implemented by the manufacturer. The driver library should implement an IO driver interface structure IODriverInterface, and a function to retrieve this structure, which returns the driver structure.

[0089] The function is declared as: IODriverInterface * CreateIOInterface().

[0090] The contents of the IODriverInterface structure are as follows:

[0091] typedef struct __IODriverInterface__

[0092] {

[0093] / / initialization

[0094] void * (*init)(unsigned int ID);

[0095] / / Deinitialization

[0096] void (*deinit)(void *handle);

[0097] / / Read and write process data

[0098] int (*set_output)(void *handle, const unsigned char *pOut, intlen);

[0099] int (*get_input)(void *handle, unsigned char *pIn, int *len);

[0100] / / Read and write parameters

[0101] int (*write_param)(void *handle,const unsigned char *pParam, intlen);

[0102] int (*read_param)(void *handle, unsigned char *pParam, int *len);

[0103] / / The pointer returned by the driver through the INIT interface

[0104] void *mHandle;

[0105] }IODriverInterface;

[0106] Step C: Dynamic loading and abstraction.

[0107] After the PLC powers on or receives a reconfiguration command, the I / O driver manager within the system starts. The I / O driver locates the aforementioned XML file, extracts the corresponding hardware configuration information from the XML, creates the corresponding input / output channels, and sets the default configuration values. The I / O manager locates the driver name, opens the corresponding dynamic link library through the system interface `dlopen`, uses the `dlsym` function to find the `CreateIOInterface` function defined in step B, calls this function, and obtains a structure pointer called `IODriver`. At runtime, a virtual device tree is created. The device tree contains the driver name, the corresponding structure pointer (e.g., `IODriver`), the initialized handle `mHandle`, and the encapsulated read / write interface. By calling the interface of the device tree at runtime, the problem of calling the underlying driver from multiple places during runtime is solved without driver conflicts.

[0108] Step D: Instantiation and deployment of the functional block.

[0109] Function blocks are a crucial concept in IEC 61499. All interactions with the drive interface must be implemented through function blocks. Designing a standard function block for a PLC's built-in I / O requires implementing the following: 1. Specifying the I / O driver module; 2. Specifying the offset of the read data within the I / O driver; 3. Specifying the offset of the write data within the I / O driver. Our implemented standard I / O function block (FB_IO), as shown in Figure 1, represents reading and writing data of type WORD. The input parameter CONFIG is a string containing the driver module and the input / output offsets. A usable string structure is: $driver;$ID;$input_offset;$output_offset, where driver is the driver name, ID is the corresponding driver ID, input_offset identifies the input offset, and output_offset identifies the output offset. Place the standard I / O function block in the IDE's resource canvas. After connecting the PLC, click "Deploy" to deploy the function block to the PLC. The execution logic of the function block is as follows:

[0110] After receiving the INIT event, the function block locates the driver instance IODriver from step C using the driver name and ID parameters in CONFIG. It then calls the init function through IODriver to initialize the hardware interface, returning a void* handle mHandle, which is used only at the driver layer. After initialization, the REQ event is executed to read and write data. At runtime, read and write operations on the IO module are implemented by calling the set_output and get_input functions of IODriver. The internal logic of the IO function block is shown in Figures 2 and 3.

[0111] Step E: Running and Interacting.

[0112] Once deployed, the IO function block becomes a member of the IEC61499 function block network and is subject to unified scheduling during IEC61499 runtime.

[0113] In some possible implementations, in step A, the configuration description file should include the following: 1. A unique identifier for the module; 2. The physical layer interface of the module; 3. Detailed information for each IO channel, such as channel type (e.g., DI / DO), electrical characteristics (e.g., range, filter parameters, etc.), data format, number of channels, etc.

[0114] Step B involves implementing the IODriverInterface structure and the function IODriverInterface *CreateIOInterface(). Since the driver library is operated using the dlopen function family, which directly searches for function symbols, this function should be exported using C language syntax.

[0115] In step C, the runtime handles the parsing of the configuration and the loading of the interfaces. The libxml2 library could be considered for parsing the XML files.

[0116] In step D, the internal logic of the standard I / O function block is implemented at runtime. Note the need to verify the validity of the CONFIG parameter;

[0117] In step E, the OUT data of the FB_IO function block can be written and the IN data can be read through other function blocks to complete the data reading and writing of the entire IO module.

[0118] In some possible implementations, the driver needs to assign a value to the void* pointer in the driver-level initialization interface. It is recommended not to use global variables to ensure the reentrancy of the interface.

[0119] There may be multiple instances of a function block, but there is only one driver. Therefore, a driver manager needs to be implemented so that multiple function blocks can only call a unified driver interface.

[0120] There is only one runtime environment. For the built-in I / O drivers of different manufacturers, the manufacturers need to implement the driver program and write the configuration description file themselves.

[0121] As one possible implementation, this embodiment provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements a programmable logic controller with built-in I / O implementation method.

[0122] As one possible implementation, this embodiment provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements a method for implementing built-in I / O of a programmable logic controller.

[0123] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for implementing built-in I / O in a programmable logic controller, characterized in that, The specific steps include: obtaining PLC model identification information, I / O module type information, and input / output point configuration information, and generating an XML configuration file; generating a driver library based on the PLC model identification information, wherein the driver library is used to implement the IO driver interface structure and a function to obtain the structure, the function returning a value used to drive the structure; real-time monitoring of trigger events, and when any trigger event is detected, the IO driver executes the dynamic loading and abstract configuration of the driver library; A standard IO function block is constructed, which maps the IO driver capabilities of the abstract configuration to an IEC61499 standard executable entity, and performs abstract interaction configuration, enabling the upper-layer control application to access the underlying IO driver through the function block.

2. The method for implementing built-in I / O of a programmable logic controller according to claim 1, characterized in that, The generation of the XML configuration file specifically includes: receiving PLC model identification information, I / O module type information, and input / output point configuration information input by the user; initializing the XML configuration file structure; determining the drive information corresponding to the I / O module type based on the initialized XML configuration file structure and in conjunction with the preset mapping rules between I / O module types and drive modules; and serializing the configured drive information data structure into an XML configuration file that conforms to the semantics of IEC 61499.

3. The method for implementing built-in I / O of a programmable logic controller according to claim 2, characterized in that, The initialization XML configuration file structure specifically includes: creating a device type root node; configuring device architecture information; setting the device type annotation to controller; specifying redundant configuration; writing device type identifier sub-elements; declaring device manager identifier variables; and creating hardware configuration nodes.

4. The method for implementing built-in I / O of a programmable logic controller according to claim 2, characterized in that, The determination of driver information corresponding to the I / O module type specifically includes: instantiating a first driver module, assigning a first driver identifier and a first module name, and configuring a first input parameter and a first output parameter; instantiating a second driver module, assigning a second driver identifier and a second module name, and configuring a second input parameter and a second output parameter; wherein the first driver module and the second driver module are drivers of the same type, forming a multi-instance deployment of drivers of the same type.

5. The method for implementing built-in I / O of a programmable logic controller according to claim 1, characterized in that, The structure includes: an initialization function pointer, used to initialize based on the device ID and return a driver handle; an uninitialization function pointer, used to release and clean up resources occupied by the driver; an output data function pointer, used to send output data to the device; an input data function pointer, used to read input data from the device, with the data length returned by the pointer; a write parameter function pointer, used to write configuration parameters to the device; a read parameter function pointer, used to read configuration parameters from the device; and a driver handle, used to identify a specific device instance.

6. The method for implementing built-in I / O of a programmable logic controller according to claim 1, characterized in that, The dynamic loading and abstract configuration of the IO driver execution driver library specifically includes: extracting hardware configuration information from the XML configuration file, creating input / output channels, and setting default configuration values; obtaining the driver name, opening the dynamic link library corresponding to the driver name for dynamic loading of the driver; using the dlsym function to find the function of the structure in the loaded dynamic link library and obtaining the function entry address; calling the function to create and return a pointer to the driver interface structure.

7. The method for implementing built-in I / O of a programmable logic controller according to claim 1, characterized in that, The functions of the standard IO function block include: specifying the IO driver module; specifying the offset of the read data in the IO driver; and specifying the offset of the write data in the IO driver.

8. The method for implementing built-in I / O of a programmable logic controller according to claim 5, characterized in that, The abstract interaction configuration specifically includes: configuring abstract interaction parameters for the function block, wherein the abstract interaction parameters include at least a driver name and a device identifier ID; when the function block responds to an initialization trigger signal, searching for the corresponding structure pointer in the virtual device tree based on the driver name; calling the initialization function pointer, passing in the device identifier ID, performing an initialization operation on the target hardware interface, and obtaining the private handle returned by the driver layer; after initialization, calling the output data function pointer, using the private handle as a parameter, sending the function block's calculation result to the target hardware interface; and / or calling the input data function pointer, using the private handle as a parameter, reading field data from the target hardware interface, and completing the abstract data interaction between the function block and the I / O module.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the programmable logic controller built-in I / O implementation method as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the programmable logic controller built-in I / O implementation method as described in any one of claims 1 to 8.