IO drive control method and system based on LRPC communication

Abstract

The invention provides an IO drive control method and system based on LRPC communication. The method comprises the steps that a lightweight protocol format is self-defined in an LRPC communication layer, and the format of an IO Server end is defined in a service layer; the service layer receives a request message of a client, converts the request message into a self-defined lightweight protocol format through the LRPC communication layer, and analyzes and verifies the format; the service layer calls an interface adjustment protocol parameter of the IO driving layer, and the driving layer performs driving configuration on hardware equipment through an XML document and a visual tool; and the IO equipment executes IO operation corresponding to the request message, and calls a callback function of the LRPC communication layer to process an error when the error occurs. According to the system, the lightweight protocol format and the standard interface of the driving layer are self-defined, efficient and stable IO equipment control, efficient data processing and optimized utilization of resources are achieved, the reliability and development efficiency of the system are improved, the system structure is clear, and the maintenance cost is greatly reduced.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to an IO drive control method and system based on LRPC communication. Background Art

[0002] In modern industrial automation control systems, the control of input and output (IO) devices is a basic and critical link. Traditional IO control methods usually adopt direct reading and writing. Although this method is simple to implement, it often has problems such as communication delays, data asynchrony, lack of a unified data format, and difficulty in operation between different devices in complex industrial environments. In addition, the error handling mechanism for IO devices has low reliability, and the expansion of new functions often requires underlying code, resulting in high system maintenance costs.

[0003] The IO control methods based on industrial fieldbus, such as Modbus, Profibus and other protocols, are standardized and unified, but the complex protocols make development difficult, have high hardware requirements, and require higher costs for system development and maintenance. The closed protocols are difficult to copy according to actual needs, and the system response speed is limited by the bus bandwidth.

[0004] Another IO control method - TCP / IP-based Socket communication has good versatility, but has high communication overhead and low efficiency. It needs to process data packaging and unpacking by itself, the management of interface connection is relatively complex, and there is a lack of a unified error handling mechanism.

[0005] Most IO control solutions on the market use proprietary protocols, which have the disadvantages of poor compatibility and low scalability. With the increasing requirements of industrial automation, a more reliable and efficient IO control method is needed.

[0006] In response to the above problems, the present application proposes an IO drive control method and system based on LRPC communication. Summary of the invention

[0007] This application proposes the following technical solutions to address one or more technical deficiencies in the above-mentioned prior art.

[0008] Based on the first aspect of the present application, an IO drive control system based on LRPC communication is proposed, including an application layer, an LRPC communication layer, an IO drive layer and a device layer;

[0009] The application layer provides a user interface for processing the business logic requested by the client;

[0010] The LRPC communication layer is connected to the application layer to process remote procedure calls and convert client requests into a custom lightweight protocol;

[0011] The IO driver layer is connected to the LRPC communication layer and is used to control hardware devices;

[0012] The device layer is connected to the IO driver layer, and is used to place IO devices and exchange data with the hardware devices.

[0013] Furthermore, a lightweight protocol is customized in the LRPC communication layer, and the customized lightweight protocol is composed of an API interface of the LRPC communication layer and an LRPC service header;

[0014] The LRPC service header consists of the LRPC service header identifier, data type, IO device operation, data length, and the index of the current instruction.

[0015] The customized lightweight protocol can make data processing more efficient, optimize resource utilization, and improve system performance and development efficiency.

[0016] Furthermore, the API interface of the LRPC communication layer responds to the read request and write request defined by the service layer IO Server, wherein:

[0017] The basic format of the write request defined by the IO Server is: IO name + data type + data length + data value + (0);

[0018] The basic format of the read request defined by the IO Server is: IO name + IO accessible options.

[0019] Furthermore, different data type values ​​are set to represent different data types, and the data types include int, double and string, which correspond to different data lengths respectively.

[0020] Furthermore, setting different values ​​represents different IO operations, including: reading a single IO stream, reading multiple IO streams, writing a single IO stream, obtaining the type of IO operation, obtaining all dynamic IO list streams, and deleting unused dynamic variable streams.

[0021] Furthermore, the control of the hardware device at the IO driver layer includes:

[0022] When the IO service loads the driver, it establishes network communication, opens the serial port, or calls the start method of the hardware API int drv_start(char*param);

[0023] When the IO service is closed, the serial port and network communication are closed, or the stop method Intdrv_stop(char*param) of the driver hardware API is called;

[0024] Methods to read or write IO variables of different data types.

[0025] By defining IO variables of different data types, the communication interfaces of different IO devices can be unified, making IO device control more efficient and providing a standard interface for the service layer to call, which is conducive to the development of the service layer.

[0026] Based on the second aspect of the present application, a method for performing IO drive control according to any of the above-mentioned systems is also proposed, comprising:

[0027] S1: Customize the lightweight protocol format in the LRPC communication layer, and define the format of the IO Server in the service layer;

[0028] S2: The client initiates a request, and the service layer receives the request message initiated by the client through the user interface of the application layer, converts the request message into a custom lightweight protocol format through the LRPC communication layer and parses it to verify the format of the request message;

[0029] S3: In response to the request message of the client, the service layer calls the interface of the IO driver layer to adjust the parameters of the custom lightweight protocol, and the driver layer performs driver configuration on the hardware device;

[0030] S4: driving the IO device of the device layer to execute the IO operation corresponding to the request message.

[0031] Furthermore, when an error occurs when calling a service, the LRPC communication layer disconnects the communication with the service layer and registers a callback function to handle the error.

[0032] Furthermore, the IO driver layer configures the hardware device drivers through XML documents and visualization tools.

[0033] Based on the third aspect of the present application, a computer program product is also proposed, which has one or more computer programs thereon, and when the computer programs are executed by a computer processor, the above method is implemented.

[0034] The technical effect of the present application is that the present application realizes efficient and stable IO device control through a customized standard driver layer interface and an IO driver control method based on a lightweight remote procedure call (LRPC) through a unified communication interface and data format, and provides a new solution for industrial automation control. The modular design of the system of the present application makes the system expansion convenient and fast, which is conducive to data processing between different devices, and can modify the protocol according to actual needs, thereby reducing maintenance costs while optimizing system performance and improving system development efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Other features, objects and advantages of the present application will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings.

[0036] Figure 1 It is a framework diagram of an IO drive control system based on LRPC communication provided according to an embodiment of the present application.

[0037] Figure 2 It is a flowchart of an IO drive control method based on LRPC communication provided according to an embodiment of the present application.

[0038] Figure 3 This is one of the driving configuration example diagrams provided according to the embodiments of the present application.

[0039] Figure 4 This is a second example diagram of a drive configuration provided according to an embodiment of the present application.

[0040] Figure 5 It is a structural diagram of a computer system suitable for implementing an electronic device of an embodiment of the present application. DETAILED DESCRIPTION

[0041] The present application will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the relevant invention, rather than to limit the invention. It should also be noted that, for ease of description, only the parts related to the relevant invention are shown in the accompanying drawings.

[0042] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0043] Figure 1 An IO drive control system based on LRPC communication of the present application is shown, including an application layer a, an LRPC communication layer b, an IO drive layer c and a device layer d.

[0044] In a specific embodiment, the application layer a provides a user interface for processing the business logic requested by the client.

[0045] In a specific embodiment, the LRPC communication layer b is connected to the application layer a to process remote procedure calls and convert client requests into a custom lightweight protocol.

[0046] In a specific embodiment, the IO driver layer c is connected to the LRPC communication layer b for controlling hardware devices.

[0047] In a specific embodiment, the device layer d is connected to the IO driver layer c, is used to place IO devices, and exchanges data with the hardware devices.

[0048] It should be noted that a custom lightweight protocol is defined in the LRPC communication layer, and the custom lightweight protocol is composed of an API interface of the LRPC communication layer and an LRPC service header;

[0049] The LRPC service header consists of the LRPC service header identifier, data type, IO device operation, data length, and the index of the current instruction.

[0050] It should be noted that the API interface of the LRPC communication layer responds to the read request and write request defined by the IO Server of the service layer, where:

[0051] The basic format of the write request defined by the IO Server is: IO name + data type + data length + data value + (0);

[0052] The basic format of the read request defined by the IO Server is: IO name + IO accessible options.

[0053] It should be noted that setting different data type values ​​represents different data types, and the data types include int, double and string, which correspond to different data lengths respectively.

[0054] It should be noted that setting different values ​​represents different IO operations, including: reading a single IO stream, reading multiple IO streams, writing a single IO stream, obtaining the type of IO operation, obtaining all dynamic IO list streams, and deleting unused dynamic variable streams.

[0055] It should be noted that the control of the hardware device at the IO driver layer includes:

[0056] When the IO service loads the driver, it establishes network communication, opens the serial port, or calls the start method of the hardware API int drv_start(char*param);

[0057] When the IO service is closed, the serial port and network communication are closed, or the stop method Intdrv_stop(char*param) of the driver hardware API is called;

[0058] Methods to read or write IO variables of different data types.

[0059] In a specific embodiment, the format of the custom lightweight protocol in the LRPC communication layer is:

[0060] LrpcHeader+LrpcDataStream;

[0061] Among them, LrpcDataStream is the API interface of the LRPC communication layer, and LrpcHeader is the LRPC service header, the format is:

[0062] Lrpc_Header_sign+Type+CallID+DataLength+Trans ID;

[0063] Among them, Lrpc_Header_sign indicates the identifier of the LRPC service header, which occupies 2 bytes; Type indicates the type of data, which occupies 1 byte; Call ID indicates the operation performed on the IO device, which occupies 1 byte; DataLength indicates the length of the data, which occupies 4 bytes; Trans ID indicates the index of the current instruction, which occupies 4 bytes.

[0064] In a specific embodiment, the LrpcDataStream responds to the read request and write request defined by the service layer IO Server, wherein:

[0065] The basic format of the write request LrpcDataStreamWrite defined by the IO Server is:

[0066] IoName+Type+DataLength+Value+(0);

[0067] The basic format of the read request LrpcDataStreamRead defined by the IO Server is:

[0068] IoName+IoAccessOption;

[0069] Among them, IoName indicates the IO name, Type indicates the data type, DataLength indicates the length of the data, Value indicates the value of the data, and IoAccessOption indicates the IO accessible option, with a placeholder size of 0-8 bytes.

[0070] In a specific embodiment, the data type Type represents different data types according to different values, corresponding to different data lengths, for example,

[0071] When Type=2, it indicates int type, and the corresponding data length DataLength=4;

[0072] When Type=3, it indicates double type, and the corresponding data length DataLength=8;

[0073] When Type=4, it indicates String type, and the corresponding data length

[0074] DataLength=Value.toBytes.length+1.

[0075] In a specific embodiment, different Call ID values ​​represent different IO operations. Specifically,

[0076] When Call ID=1, a single IO stream is read and the format of the returned result is: 0+type+length+value;

[0077] When Call ID=2, multiple IO streams are read and the format of the returned result is: 0+type+value+0+type+value+…;

[0078] When Call ID=3, a single IO stream is written and the return result is 0;

[0079] When Call ID=4, get the type of IO operation, and the format of the returned result is: 0+type(Uint);

[0080] When Call ID=5, get all dynamic IO list flows, and the returned result format is: 0+name(string)+Type(Uint)+name+Type…;

[0081] When Call ID=6, the unused dynamic variable flow is deleted and the returned result is 0.

[0082] In a specific embodiment, a method for reading or writing IO variables of different data types includes:

[0083] Define the method to read IO variables of int data type Int drv_read_int(const char*param,int*value),

[0084] Method for writing IO variables of int data type Int drv_write_int(const char*param,intvalue),

[0085] Method to read IO variables of double data type Int drv_read_double(const char*param,double*value),

[0086] Method for writing IO variables of double data type Int drv_write_double(const char*param,int value),

[0087] Method to read IO variables of string data type Int drv_read_string(const char*param,char*data_buf,int bug_size),

[0088] And the method to write IO variables of string data type Int drv_write_string(const char*param,char*data);

[0089] Among them, param is the parameter for configuring the IO variable, value is the value returned after reading / the value written, data_buf is the character buffer, buf_size is the buffer size, and data is the value written.

[0090] Reference below Figure 2 , Figure 2 An IO drive control method based on LRPC communication of the present application is shown, comprising:

[0091] S1: Customize the lightweight protocol format in the LRPC communication layer, and define the format of the IO Server in the service layer;

[0092] S2: The client initiates a request, and the service layer receives the request message initiated by the client through the user interface of the application layer, converts the request message into a custom lightweight protocol format through the LRPC communication layer and parses it to verify the format of the request message;

[0093] S3: In response to the request message of the client, the service layer calls the interface of the IO driver layer to adjust the parameters of the custom lightweight protocol, and the driver layer performs driver configuration on the hardware device;

[0094] S4: driving the IO device of the device layer to execute the IO operation corresponding to the request message.

[0095] It should be noted that when an error occurs when calling a service, the LRPC communication layer disconnects the communication with the service layer and registers a callback function to handle the error.

[0096] It should be noted that the IO driver layer configures the hardware device through XML documents and visualization tools.

[0097] It should be noted that asynchronous calls, interface monitoring and custom services can be implemented in the service layer. The implementation code is:

[0098] "virtual int CallHandler(UInt32 callId,LrpcDataStreamRead inParam,refLrpcDataStreamWrite outParam) / / Client call processing function, can be overridden

[0099] bool IsCallAsync(uint callId) / / Whether to call asynchronously

[0100] void RemoveConnection(int key) / / Delete the temporarily stored connection

[0101] void SetCallAsync(uint callId) / / Set the callId of the asynchronous call

[0102] virtual int Start() / / Start the service

[0103] virtual int Stop() / / Stop service".

[0104] It should be noted that the IO driver layer, as a further abstraction of the hardware, provides a standard interface for the service layer to call. The service layer does not need to pay attention to the underlying content such as the hardware source, IO configuration information, and driver information. The IO driver layer set up in this application makes the development of the service layer more standardized and friendly.

[0105] In a specific embodiment, the driver layer configures the hardware device through XML documents and visualization tools, and uses two methods to configure the hardware device driver respectively as follows: Figure 3 and Figure 4As shown, including configuration driver name, driver file, starting parameters, etc.

[0106] It should be noted that the custom lightweight protocol supports callback functions, and the LrpcClient of the LRPC communication layer has an automatic reconnection function. The code of the callback function is as follows:

[0107] "LrpcErrorCode Call (Byte callId, LrpcDataStreamWrite inParam, refLrpcDataStreamRead outParam, int timeout) calls the server service

[0108] LrpcErrorCode Connect(string ip,UInt16 port,UInt32 timeout) connect to the server

[0109] void Disconnect()Disconnects the communication with the server

[0110] bool IsConnect() Is the communication connected?

[0111] void RegisterCallbackHandler(CallBackHandler func) registers callback function

[0112] public delegate void CallBackHandler(LrpcHeader header,byte[]data); callback function definition

[0113] public enum LrpcErrorCode

[0114] {

[0115] LrpcSuccess=0,

[0116] LrpcError=-1,

[0117] LrpcUndefinedCall=-2,

[0118] LrpcConnectionLost=-3,

[0119] LrpcConnServerFailed=-4,

[0120] LrpcTimeout=-5,

[0121] LrpcDataError=-6,

[0122] LrpcConfigError=-7,

[0123] }".

[0124] It should be noted that the present application realizes efficient and stable IO device control, unifies the communication interfaces of different IO devices, and provides a reliable error handling mechanism, which enables convenient system expansion, solves the problems of lack of unified data format and difficulty in data synchronization in traditional IO control methods, and reduces the maintenance cost of the system. The custom lightweight protocol can be customized according to actual needs to achieve faster response speed.

[0125] Reference below Figure 5 , which shows a schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application. Figure 5 The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0126] like Figure 5 As shown, the computer system includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 502 or the program loaded from the storage part 508 to the random access memory (RAM) 503. In the RAM 503, various programs and data required for system operation are also stored. The CPU 501, the ROM 502, and the RAM 503 are connected to each other through a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0127] The following components are connected to the I / O interface 505: an input section 506 including a keyboard, a mouse, etc.; an output section 507 including a liquid crystal display (LCD), etc. and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, a modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the I / O interface 505 as needed. A removable medium 511, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 510 as needed, so that a computer program read therefrom is installed into the storage section 508 as needed.

[0128] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable storage medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 509, and / or installed from the removable medium 511. When the computer program is executed by the central processing unit (CPU) 501, the above functions defined in the method of the present application are executed. It should be noted that the computer-readable storage medium of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, - but not limited to - an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection with one or more conductors, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device, or device. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable storage medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, device, or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wireless, wireline, optical cable, RF, etc., or any suitable combination of the foregoing.

[0129] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0130] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0131] The modules involved in the embodiments of the present application may be implemented by software or by hardware.

[0132] As another aspect, the present application also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiment; or it may exist independently and not be assembled into the electronic device. The above computer-readable storage medium carries one or more programs. When the above one or more programs are executed by the electronic device, the electronic device: customizes the lightweight protocol format in the LRPC communication layer, and defines the format of the IO Server in the service layer; the client initiates a request, the service layer receives the request message initiated by the client through the user interface of the application layer, converts the request message into a customized lightweight protocol format and parses it through the LRPC communication layer, and verifies the format of the request message; in response to the client's request message, the service layer calls the interface of the IO driver layer to adjust the parameters of the customized lightweight protocol, and the driver layer configures the driver for the hardware device; drives the IO device of the device layer to perform the IO operation corresponding to the request message.

[0133] The above description is only a preferred embodiment of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in the present application is not limited to the technical solution formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above invention concept. For example, the above features are replaced with the technical features with similar functions disclosed in this application (but not limited to) by each other to form a technical solution.

[0134] Finally, it should be noted that the above embodiments are only intended to illustrate rather than limit the technical solutions of the present application. Although the present application has been described in detail with reference to the above embodiments, a person of ordinary skill in the art should understand that the present application can still be modified or replaced by equivalents. Any modification or partial replacement that does not depart from the spirit and scope of the present application should be included in the scope of the claims of the present application.

Claims

1. An IO drive control system based on LRPC communication, characterized in that: Includes application layer, LRPC communication layer, IO driver layer and device layer; The application layer provides a user interface for processing the business logic requested by the client; The LRPC communication layer is connected to the application layer to process remote procedure calls and convert client requests into a custom lightweight protocol; The IO driver layer is connected to the LRPC communication layer and is used to control hardware devices; The device layer is connected to the IO driver layer, and is used to place IO devices and exchange data with the hardware devices.

2. The system according to claim 1, characterized in that A customized lightweight protocol is defined in the LRPC communication layer, wherein the customized lightweight protocol is composed of an API interface of the LRPC communication layer and an LRPC service header; The LRPC service header consists of the LRPC service header identifier, data type, IO device operation, data length, and the index of the current instruction.

3. The system according to claim 2, characterized in that The API interface of the LRPC communication layer responds to the read request and write request defined by the service layer IO Server, where: The basic format of the write request defined by the IO Server is: IO name + data type + data length + data value + (0); The basic format of the read request defined by the IO Server is: IO name + IO accessible options.

4. The system according to claim 3, characterized in that Setting different data type values ​​represents different data types, and the data types include int, double and string, which correspond to different data lengths respectively.

5. The system according to claim 2, characterized in that Setting different values ​​represents different IO operations, including: reading a single IO stream, reading multiple IO streams, writing a single IO stream, getting the type of IO operation, getting all dynamic IO list streams, and deleting unused dynamic variable streams.

6. The system according to claim 1, characterized in that The control of hardware devices at the IO driver layer includes: When the IO service loads the driver, it establishes network communication, opens the serial port, or calls the start method intdrv_start(char*param) of the hardware API; When the IO service is closed, close the serial port and network communication, or call the stop method of the driver hardware API Int drv_stop(char*param); Methods to read or write IO variables of different data types.

7. A method for IO drive control, characterized in that: The system according to any one of claims 1 to 6 performs IO drive control, comprising: S1: Customize the lightweight protocol format in the LRPC communication layer, and define the format of the IO Server in the service layer; S2: The client initiates a request, and the service layer receives the request message initiated by the client through the user interface of the application layer, converts the request message into a custom lightweight protocol format through the LRPC communication layer and parses it to verify the format of the request message; S3: In response to the request message of the client, the service layer calls the interface of the IO driver layer to adjust the parameters of the custom lightweight protocol, and the driver layer performs driver configuration on the hardware device; S4: driving the IO device of the device layer to execute the IO operation corresponding to the request message.

8. The method according to claim 7, characterized in that When an error occurs when calling a service, the LRPC communication layer disconnects the communication with the service layer and registers a callback function to handle the error.

9. The method according to claim 7, characterized in that: The IO driver layer configures the hardware devices through XML documents and visualization tools.

10. A computer program product having one or more computer programs thereon, characterized in that: When the computer program is executed by a computer processor, the method according to claims 7 to 9 is implemented.

Images