Industrial drive platform implementation method and system

Abstract

The present invention provides a method and system for implementing industrial drive platformization, including: Step 1: Standardizing industrial drive configuration parameters, inputting the standardized parameters into an interface configuration file, and generating a drive parameter input page; Step 2: Standardizing the drive data exchange interface and format, and monitoring and controlling the standardized data exchange interface; Step 3: Compiling the driver program for multiple target platforms, packaging and storing it in a standardized format, and then uploading and storing it to a drive center; Step 4: The drive center distributes the driver program and industrial driver to a remote terminal via the network; Step 5: Starting the driver program to configure and control the industrial driver, analyzing the detailed operating status of the driver through the platform, and realizing remote drive debugging. The present invention solves the problem of industrial drivers being scattered across different terminal devices, lacking unified management, and difficult to control versions.

Description

Technical Field

[0001] The present invention relates to the technical field of drive platformization, and in particular to a method and system for implementing industrial drive platformization. Background Art

[0002] Currently, there is no platform-based management solution for device drivers in the industrial field. Various drivers are scattered across different terminal storages, making driver version management difficult. Each terminal driver needs to be installed independently, and debugging driver issues requires on-site debugging at the terminal deployment site, which is inefficient.

[0003] Patent document CN112698843A (application number: CN202011585923.X) discloses an industrial control software installation method, apparatus, storage medium, and industrial control equipment. The patent focuses on how to obtain and install drivers, but does not mention a platform-based management solution. It also does not provide standardized definitions for driver configuration, driver data format, driver control interface, or driver log upload. It also does not explain how to monitor the driver's operation after installation or how to remotely maintain it.

[0004] Patent document CN110510394B (application number: CN201910816166.3) discloses a cloud-based industrial process optimization system, which includes a raw material identification module, a transportation module, a processing module, a product identification module, a comparison module, and a configuration module. By identifying raw materials and products, processing information is calculated, and a configuration file is generated for network sharing, enabling fast and efficient configuration of equipment, ensuring the yield rate of processing or shortening unit processing time. However, the patent does not describe how to platformize the driver. Summary of the Invention

[0005] In view of the defects in the prior art, the purpose of the present invention is to provide a method and system for realizing industrial drive platformization.

[0006] The method for realizing industrial drive platformization provided by the present invention includes:

[0007] Step 1: Standardize the industrial drive configuration parameters, input the standardized parameters into the interface configuration file, and generate the drive parameter input page;

[0008] Step 2: Standardize the drive data exchange interface and format, and monitor and control the standardized data exchange interface;

[0009] Step 3: Compile the driver for multiple target platforms, package and store it in a standardized format, and then upload it to the driver center for storage;

[0010] Step 4: The driver center sends the driver and industrial driver to the remote terminal through the network;

[0011] Step 5: Start the driver to configure and control the industrial drive, upload standardized format data through the data exchange interface, upload logs online through the log upload interface, analyze the detailed operation status of the drive through the platform, and realize remote drive debugging.

[0012] Preferably, the step 1 comprises:

[0013] The types of the driving parameters include static parameters and dynamic parameters;

[0014] The driving parameters are stored in XML and JSON file formats;

[0015] Driver types are classified based on the physical communication type between the driver and the device, including serial port, network port and CAN;

[0016] Generate a dynamic parameter input page by predefining dynamic input forms in the configuration file, including text boxes, drop-down boxes, and selection boxes.

[0017] Preferably, the step 2 comprises:

[0018] Step 2.1: Standardize the data format output by the driver, add a data header before the format of the data sent by the driver, generate a standardized data exchange interface and upload it to the platform, which will be called by the platform driver monitoring program;

[0019] Step 2.2: Set up a monitoring interface on the platform to obtain driver operation information and manage the driver according to platform instructions or the driver's own operating status.

[0020] Preferably, step 4 includes:

[0021] Step 4.1: Install a receiving program capable of receiving driver data from the platform on the terminal device connected to the platform. Also install a driver-operated monitoring program. Register the monitoring program as a system service or daemon process. If the monitoring program exits, it will be automatically triggered to start again by the operating system.

[0022] Step 4.2: The driver receiving program and the driver monitoring program automatically run after the terminal is powered on. The driver receiving program automatically reports the current terminal information to the platform based on the built-in platform information. The platform establishes communication with the terminal based on this information.

[0023] Step 4.3: The user selects the driver to be sent to the terminal in the driver center, fills in the required driver parameters in the driver parameter configuration page, selects the terminal to receive the driver in the platform, and sends the driver by issuing a command;

[0024] Step 4.4: The driver receiving program in the terminal receives the driver package issued by the platform, then decompresses the driver according to the preset process and completes the driver configuration according to the configuration parameters, and then passes the control to the driver monitoring program.

[0025] Preferably, the step 5 comprises:

[0026] Step 5.1: The driver monitoring program checks the terminal system status. If it determines that the operating environment meets the requirements, it will start the issued driver and begin to monitor its status. If the driver operating status is abnormal, it will restart the driver and report the driver operating status to the platform.

[0027] Step 5.2: After the driver is running normally, it communicates with the device it controls, uploads relevant device data and status information to the platform through standardized data formats and interfaces, and supports online viewing of driver anomalies.

[0028] The industrial drive platform implementation system provided by the present invention includes:

[0029] Module M1: Standardizes industrial drive configuration parameters, inputs the standardized parameters into the interface configuration file, and generates a drive parameter input page;

[0030] Module M2: Standardizes the drive data exchange interface and format, and monitors and controls the standardized data exchange interface;

[0031] Module M3: compiles the driver for multiple target platforms, packages it into a standardized format, and then uploads it to the driver center for storage;

[0032] Module M4: Sends drivers and industrial drivers to remote terminals via the network in the drive center;

[0033] Module M5: Starts the driver to configure and control the industrial drive, uploads standardized format data through the data exchange interface, uploads logs online through the log upload interface, analyzes the detailed operation status of the drive through the platform, and realizes remote drive debugging.

[0034] Preferably, the module M1 includes:

[0035] The types of the driving parameters include static parameters and dynamic parameters;

[0036] The driving parameters are stored in XML and JSON file formats;

[0037] Driver types are classified based on the physical communication type between the driver and the device, including serial port, network port and CAN;

[0038] Generate a dynamic parameter input page by predefining dynamic input forms in the configuration file, including text boxes, drop-down boxes, and selection boxes.

[0039] Preferably, the module M2 includes:

[0040] Module M2.1: Standardizes the data format output by the driver, adds a data header before the format of the data sent by the driver, generates a standardized data exchange interface and uploads it to the platform, which is called by the platform driver monitoring program;

[0041] Module M2.2: Set up a monitoring interface on the platform to obtain driver operation information and manage the driver according to platform instructions or the driver's own operating status.

[0042] Preferably, the module M4 includes:

[0043] Module M4.1: Install a receiving program capable of receiving driver data from the platform in the terminal device connected to the platform. Also install a driver-operation monitoring program. Register the monitoring program as a system service or daemon process. If the program exits, it will be automatically triggered to start again by the operating system.

[0044] Module M4.2: The driver receiving program and the driver monitoring program automatically run after the terminal is powered on. The driver receiving program automatically reports the current terminal information to the platform based on the built-in platform information. The platform establishes communication with the terminal based on this information.

[0045] Module M4.3: The user selects the driver to be sent to the terminal in the driver center, fills in the required driver parameters in the driver parameter configuration page, selects the terminal to receive the driver in the platform, and sends the driver by issuing a command;

[0046] Module M4.4: The driver receiving program in the terminal receives the driver package issued by the platform, then decompresses the driver according to the preset process and completes the driver configuration according to the configuration parameters, and then passes the control to the driver monitoring program.

[0047] Preferably, the module M5 includes:

[0048] Module M5.1: The driver monitoring program checks the terminal system status. Once it determines that the operating environment meets the requirements, it starts the issued driver and begins to monitor its status. If the driver operating status is abnormal, it restarts the driver and reports the driver operating status to the platform.

[0049] Module M5.2: After the driver is operating normally, it communicates with the device it controls, uploads relevant device data and status information to the platform through standardized data formats and interfaces, and supports online viewing of driver anomalies.

[0050] Compared with the prior art, the present invention has the following beneficial effects:

[0051] By standardizing driver configuration parameters, driver data exchange formats, driver packaging, compression, and decompression processes, driver status control interfaces, and driver log upload interfaces, this invention allows industrial device drivers developed in different programming languages ​​and suitable for different terminals to be uniformly registered, stored, and distributed on the platform. This invention addresses the problem of industrial drivers being scattered across different terminal devices, lacking unified management and making version control difficult. It also addresses the inefficiency of the existing independent installation requirements for each industrial terminal driver, and the need to debug each industrial terminal driver at the terminal deployment site. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Other features, objects and advantages of the present invention will become more apparent upon reading the detailed description of non-limiting embodiments with reference to the following drawings:

[0053] Figure 1 This is the platform module block diagram;

[0054] Figure 2 To drive the upload platform process;

[0055] Figure 3 Issue driver processes to the platform;

[0056] Figure 4 The terminal receives the running driver and returns the log process. DETAILED DESCRIPTION

[0057] The present invention will be described in detail below with reference to specific embodiments. The following examples will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those skilled in the art, several changes and improvements can be made without departing from the scope of the present invention. These all fall within the scope of protection of the present invention.

[0058] Example:

[0059] like Figure 1 The platform of the present invention includes a driver center module, a driver configuration input interface generation module, a log online analysis module and a driver distribution module; the terminal device includes a log return module, a driver receiving module, a driver monitoring module and a device driver;

[0060] The log return module returns the log to the log online analysis module; the driver sending module sends the driver to the driver receiving module.

[0061] like Figure 2 According to the industrial drive platform implementation method provided by the present invention, the following steps are included:

[0062] Step 1: Standardize the industrial drive configuration parameters and input the interface configuration file in the standardized format. The platform dynamically generates the drive parameter input page through the parameter input interface configuration file.

[0063] Step 2: Standardize the driver data exchange interface and format to generate standardized data exchange API and monitoring control API

[0064] Step 3: Compile the driver for multiple target platforms, package and store it in a standardized format, and upload it to the driver center storage

[0065] Step 4: The terminal deploys and sends the receiving program. The drive center sends the drive control program and industrial drive to the remote terminal through the network.

[0066] Step 5: The driver control program starts issuing the driver program, uploads standardized format data through the data exchange API, and uploads logs online through the log upload interface.

[0067] The step 1 includes: the industrial drive R&D unit develops and standardizes the drive parameter receiving form according to the platform drive configuration parameter standard. The parameter part received by each type of drive is set as a static part and a dynamic part. The drive parameter configuration information can be stored in XML and JSON file formats to record the type of drive. The drive type is mainly classified according to the physical communication type of the drive and the device, including serial port, network port, CAN, etc. Each drive has different static and dynamic configurations in the configuration information according to the type. The purpose of this information is to dynamically generate a drive configuration page for inputting the actual drive parameters when the drive is used. The serial port includes the serial port number, baud rate, check bit, data bit, stop bit; the network port includes the network type, IP address, port number; CAN includes clock selection, working mode, baud rate, filter group. The dynamic configuration part is provided in the XML or JSON configuration file. The configuration file predefines dynamic input forms: text box, drop-down box, selection box, etc., and the generation of the drive dynamic parameter input page is realized through this type of dynamic input box.

[0068] The step 2 includes: the industrial drive R&D unit develops and standardizes the output data format of the driver according to the platform driver data exchange format. The platform supports standard formats such as MQTT format, Tag-Value format, JSON format, binary stream format, etc. The platform adds a data header before the format of the driver sending data, and then forwards the data to the platform. The driver will generate a standardized data exchange API according to the above protocol, which will be called by the platform driver monitoring program. The driver exchange data is filled into the selected standard format data field, and the corresponding information in the data header that must be filled in by the driver is filled in. The industrial drive R&D unit develops and designs a monitoring API based on the platform driver control interface. The main purpose of this monitoring API is to manage the driver program. The monitoring API provides at least four interfaces for driver startup, kill, and restart functions, and obtains operating information including the current status of the driver, memory usage, port and other resource conditions. The monitoring API is used for the monitoring program to control according to platform instructions or the driver's own operating status.

[0069] Step 3 includes: the industrial drive R&D unit compiles the driver for multiple target platforms. Currently, terminals connected to this platform run on the X86 and ARM platforms, supporting Windows, Linux, and UNIX operating systems. The driver program must compile executable programs for Windows, Linux, and UNIX corresponding to the X86 and ARM platforms. The compiled executable driver program is packaged in a specified format, using the cross-platform tarball format. The packaged file contains directories that distinguish executable files for different platforms. The industrial drive R&D unit logs into the platform's driver center and enters the newly added driver information, including the driver name, driver type, current driver version, and driver developer information. The packaged driver is then uploaded to the driver center storage center. An administrator with driver management privileges reviews the uploaded driver to ensure it meets the upload standards and, if not, requires revisions. The driver storage center manages driver versions, displaying the latest version by default. Driver users can switch to the current version based on their needs. The platform extracts the driver parameter input page configuration file in XML or JSON format from the driver package. The platform automatically identifies the configuration file information and generates the configuration input page for the driver.

[0070] like Figure 3Step 4 includes installing a receiving program capable of receiving drivers from the platform in a terminal device connected to the platform, along with a driver operation monitoring program. This monitoring program is registered as a system service or daemon process and will be reactivated by the operating system if it exits. The driver receiving program and driver monitoring program automatically run after the terminal is powered on. The driver receiving program automatically reports the current terminal information to the platform based on the built-in platform information, and the platform establishes communication with the terminal based on this information. The user selects the driver to be distributed to the terminal in the driver center and enters the required driver parameters on the driver parameter configuration page. The user selects the terminal to receive the driver in the platform and issues a command to distribute the driver. The platform can distribute the driver uniformly to all terminals connected to the platform or select specific terminals to distribute the driver. For a specific terminal, the driver center can switch the driver version and distribute a specific version. The driver receiving program in the terminal receives the driver package distributed by the platform, decompresses the driver according to a pre-configured process, and completes the driver configuration based on the configuration parameters. Control is then transferred to the driver monitoring program.

[0071] like Figure 4 , step 5 includes: the driver monitoring program checks the terminal system status, determines that the operating environment meets the requirements, starts the issued driver to run, and begins to monitor its status. If the driver operation status is abnormal, such as stuck, consuming too many resources, or abnormal exit, the monitoring program restarts the driver and reports the driver operation status to the platform. After the driver operates normally, it communicates with the device it controls and uploads the relevant device data and status information to the platform through standardized data formats and interfaces. In addition, this design has the ability to upload the driver log to the platform after standardization. During the driver operation process, the driver log upload capability can be turned on as needed, and the running driver can be uploaded to the platform, which can support online viewing of driver anomalies.

[0072] The present invention aggregates the industrial drivers originally scattered in terminal devices into a platform management, realizes the rapid deployment and upgrade of terminal device drivers placed in different physical spaces, and controls the driver versions in different terminals. By standardizing the driver exchange data format, status control interface, and log upload interface, remote monitoring of the driver status is achieved, and remote operation and maintenance debugging of the driver is realized through online log transmission.

[0073] The industrial drive platform implementation system provided by the present invention includes: module M1: standardizing industrial drive configuration parameters, inputting the standardized parameters into an interface configuration file, and generating a drive parameter input page; module M2: standardizing the drive data exchange interface and format, and monitoring and controlling the standardized data exchange interface; module M3: compiling the driver program for multiple target platforms, packaging and storing it in a standardized format, and then uploading it to a drive center for storage; module M4: issuing the driver program and industrial driver to the remote terminal via the network at the drive center; module M5: starting the driver program to configure and control the industrial drive, uploading standardized format data through the data exchange interface, uploading logs online through the log upload interface, analyzing the detailed operating status of the driver through the platform, and realizing remote drive debugging.

[0074] The module M1 includes: the types of the drive parameters include static parameters and dynamic parameters; the drive parameters are stored in XML and JSON file formats; the drive type is classified according to the physical communication type of the drive and the device, including serial port, network port and CAN; in the configuration file, a dynamic parameter input page is generated through predefined dynamic input forms, including text boxes, drop-down boxes and selection boxes.

[0075] The module M2 includes: module M2.1: standardizing the data format of the driver output, adding a data header before the format of the driver sending data, generating a standardized data exchange interface and uploading it to the platform, which is called by the platform driver monitoring program; module M2.2: setting a monitoring interface on the platform, obtaining driver operation information, and managing the driver according to platform instructions or the driver's own operating status.

[0076] The module M4 includes: Module M4.1: Installing a receiving program with the function of receiving drivers from the platform in the terminal device within the access platform, and installing a driver operation monitoring program at the same time, registering the monitoring program as a system service or daemon process, and automatically triggering it to start again by the operating system if it exits; Module M4.2: The driver receiving program and the driver monitoring program automatically run after the terminal is powered on, and the driver receiving program automatically reports the current terminal information to the platform based on the built-in platform information, and the platform establishes communication with the terminal based on the information; Module M4.3: The user selects the driver that needs to be sent to the terminal in the driver center, fills in the required parameters for the driver in the driver parameter configuration page, and the user selects the terminal that needs to receive the driver in the platform, and sends the driver by issuing a command; Module M4.4: The driver receiving program in the terminal receives the driver package sent by the platform, then decompresses the driver according to the preset process and completes the driver configuration according to the configuration parameters, and then transfers control to the driver monitoring program.

[0077] The module M5 includes: Module M5.1: The driver monitoring program checks the terminal system status. After determining that the operating environment meets the requirements, it starts the issued driver and begins to monitor its status. If the driver operating status is abnormal, the driver is restarted and the driver operating status is reported to the platform; Module M5.2: After the driver operates normally, it communicates with the device it controls, uploads relevant device data and status information to the platform through a standardized data format and interface, and supports online viewing of driver anomalies.

[0078] Those skilled in the art will appreciate that, in addition to implementing the system, device, and various modules provided by the present invention in purely computer-readable program code, it is entirely possible to implement the same program in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, embedded microcontrollers, and the like by logically programming the method steps. Therefore, the system, device, and various modules provided by the present invention can be considered a hardware component, and the modules included therein for implementing various programs can also be considered structures within the hardware component; the modules for implementing various functions can also be considered both software programs for implementing the method and structures within the hardware component.

[0079] The above describes specific embodiments of the present invention. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art may make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. The embodiments of this application and the features in the embodiments may be combined with each other in any manner unless there is a conflict.

Claims

1. A method for realizing industrial drive platformization, characterized in that: include: Step 1: Standardize the industrial drive configuration parameters, input the standardized parameters into the interface configuration file, and generate the drive parameter input page; Step 2: Standardize the drive data exchange interface and format, and monitor and control the standardized data exchange interface; Step 3: Compile the driver for multiple target platforms, package and store it in a standardized format, and then upload it to the driver center for storage; Step 4: The terminal deploys and sends the receiving program, and the drive center sends the drive control program and industrial drive to the remote terminal through the network; Step 5: The driver control program starts issuing the driver program, uploads standardized format data through the data exchange API, and uploads logs online through the log upload interface.

2. The method for realizing industrial drive platformization according to claim 1, characterized in that: The step 1 comprises: The types of the driving parameters include static parameters and dynamic parameters; The driving parameters are stored in XML and JSON file formats; Driver types are classified based on the physical communication type between the driver and the device, including serial port, network port and CAN; Generate a dynamic parameter input page by predefining dynamic input forms in the configuration file, including text boxes, drop-down boxes, and selection boxes.

3. The method for realizing industrial drive platformization according to claim 1, characterized in that: The step 2 includes: Step 2.1: Standardize the data format output by the driver, add a data header before the format of the data sent by the driver, generate a standardized data exchange interface and upload it to the platform, which will be called by the platform driver monitoring program; Step 2.2: Set up a monitoring interface on the platform to obtain driver operation information and manage the driver according to platform instructions or the driver's own operating status.

4. The method for realizing industrial drive platformization according to claim 1, characterized in that: The step 4 comprises: Step 4.1: Install a receiving program capable of receiving driver data from the platform on the terminal device connected to the platform. Also install a driver-operated monitoring program. Register the monitoring program as a system service or daemon process. If the monitoring program exits, it will be automatically triggered to start again by the operating system. Step 4.2: The driver receiving program and the driver monitoring program automatically run after the terminal is powered on. The driver receiving program automatically reports the current terminal information to the platform based on the built-in platform information. The platform establishes communication with the terminal based on this information. Step 4.3: The user selects the driver to be sent to the terminal in the driver center, fills in the required driver parameters in the driver parameter configuration page, selects the terminal to receive the driver in the platform, and sends the driver by issuing a command; Step 4.4: The driver receiving program in the terminal receives the driver package issued by the platform, then decompresses the driver according to the preset process and completes the driver configuration according to the configuration parameters, and then passes the control to the driver monitoring program.

5. The method for realizing industrial drive platformization according to claim 4, characterized in that: The step 5 comprises: Step 5.1: The driver monitoring program checks the terminal system status. If it determines that the operating environment meets the requirements, it will start the issued driver and begin to monitor its status. If the driver operating status is abnormal, it will restart the driver and report the driver operating status to the platform. Step 5.2: After the driver is running normally, it communicates with the device it controls, uploads relevant device data and status information to the platform through standardized data formats and interfaces, and supports online viewing of driver anomalies.

6. An industrial drive platform implementation system, characterized in that: include: Module M1: Standardizes industrial drive configuration parameters, inputs the standardized parameters into the interface configuration file, and generates a drive parameter input page; Module M2: Standardizes the drive data exchange interface and format, and monitors and controls the standardized data exchange interface; Module M3: compiles the driver for multiple target platforms, packages it into a standardized format, and then uploads it to the driver center for storage; Module M4: The terminal deploys and sends the receiving program. The drive center sends the drive control program and industrial drive to the remote terminal through the network. Module M5: The driver control program starts issuing the driver program, uploads standardized format data through the data exchange API, and uploads logs online through the log upload interface.

7. The industrial drive platform implementation system according to claim 6, characterized in that: The module M1 includes: The types of the driving parameters include static parameters and dynamic parameters; The driving parameters are stored in XML and JSON file formats; Driver types are classified based on the physical communication type between the driver and the device, including serial port, network port and CAN; Generate a dynamic parameter input page by predefining dynamic input forms in the configuration file, including text boxes, drop-down boxes, and selection boxes.

8. The industrial drive platform implementation system according to claim 6, characterized in that: The module M2 includes: Module M2.1: Standardizes the data format output by the driver, adds a data header before the format of the data sent by the driver, generates a standardized data exchange interface and uploads it to the platform, which is called by the platform driver monitoring program; Module M2.2: Set up a monitoring interface on the platform to obtain driver operation information and manage the driver according to platform instructions or the driver's own operating status.

9. The industrial drive platform implementation system according to claim 6, characterized in that: The module M4 includes: Module M4.1: Install a receiving program capable of receiving driver data from the platform in the terminal device connected to the platform. Also install a driver-operation monitoring program. Register the monitoring program as a system service or daemon process. If the program exits, it will be automatically triggered to start again by the operating system. Module M4.2: The driver receiving program and the driver monitoring program automatically run after the terminal is powered on. The driver receiving program automatically reports the current terminal information to the platform based on the built-in platform information. The platform establishes communication with the terminal based on this information. Module M4.3: The user selects the driver to be sent to the terminal in the driver center, fills in the required driver parameters in the driver parameter configuration page, selects the terminal to receive the driver in the platform, and sends the driver by issuing a command; Module M4.4: The driver receiving program in the terminal receives the driver package issued by the platform, then decompresses the driver according to the preset process and completes the driver configuration according to the configuration parameters, and then passes the control to the driver monitoring program.

10. The industrial drive platform implementation system according to claim 9, characterized in that: The module M5 includes: Module M5.1: The driver monitoring program checks the terminal system status. Once it determines that the operating environment meets the requirements, it starts the issued driver and begins to monitor its status. If the driver operating status is abnormal, it restarts the driver and reports the driver operating status to the platform. Module M5.2: After the driver is operating normally, it communicates with the device it controls, uploads relevant device data and status information to the platform through standardized data formats and interfaces, and supports online viewing of driver anomalies.

Images