Custom Module Control System, Method, Device and Storage Medium

Abstract

The present application provides a custom module control system, method, device and storage medium, which relates to the field of software frameworks. The system includes: a function module and an executor. The function module is used to transfer the data of the custom module to the executor. Among them, the custom module includes executable files compiled by multiple programming languages. And the executor is used to create a process corresponding to the custom module through an embedded script and run the executable file in the process. Multiple processes are independent of each other and do not interfere with each other, and can support the simultaneous operation of executable files in multiple programming languages, improving the flexibility of development and increasing the universality and generality.

Description

Technical Field

[0001] This application relates to the technical field of software frameworks, and more particularly, to a custom module control system, method, device, and storage medium. Background Art

[0002] With the increase in social labor costs, intelligent devices such as robots are widely used in various industries, and the application scenarios are becoming more and more complex. The customized needs of users are also growing, and there is an urgent need in the market for intelligent device products such as robots that can meet the needs of users for custom development. The existing development processing solutions usually include a basic module for adding or modifying each functional plug-in in the plug-in library module in the form of a script file and communicating instructions and status with the control system of intelligent devices such as robots, and a plug-in library module for providing one or more functional plug-ins for the basic module.

[0003] Currently, the software architecture that combines the basic module and the plug-in library module enhances the flexibility of software development to a certain extent and reduces the development workload. However, since it only supports a certain fixed programming language, it is difficult to meet the universal application between different versions, and has poor generality and scalability. Summary of the Invention

[0004] In view of this, the purpose of the embodiments of this application is to provide a custom module control system, method, device, and storage medium. By setting up functional modules and actuators, and using embedded scripts to create corresponding processes to run executable files compiled by multiple programming languages, the technical problem of "only supporting a certain fixed programming language, being difficult to meet the universal application between different versions, having poor generality, and having poor scalability" is solved.

[0005] In a first aspect, an embodiment of this application provides a custom module control system, where the system includes: a functional module and an actuator, and the functional module is communicatively connected to the actuator; the functional module is used to transfer data of the custom module to the actuator; where the custom module includes executable files compiled by multiple programming languages; and the actuator is used to create a process corresponding to the custom module through an embedded script and run the executable file in the process.

[0006] In the above implementation process, a software architecture of a functional module and an actuator is used to develop a custom module control system. The unified interface of the functional module can be used to realize the interactive communication of custom modules with various functions; by configuring script commands in the actuator to create corresponding processes, the monitoring and display of the running status of custom module files compiled by multiple programming languages can be realized; at the same time, multiple processes are independent of each other and do not interfere with each other, improving the development efficiency and increasing the universality and generality.

[0007] Optionally, the actuator includes: a main process module, configured to create a subprocess corresponding to the custom module, a shared memory space in the actuator, and obtain the running status data of the subprocess from the shared memory space; a subprocess module, configured to run the executable file in the subprocess created by the main process module and output the running status data to the shared memory space; and a shared memory space module, configured to receive the running status data generated when the executable file runs in the subprocess module.

[0008] In the above implementation process, the subprocess module outputs data to or obtains data from the shared memory space module, and at the same time, the main process module of the actuator can obtain the data of the subprocess module running the executable file from the shared memory space module; by creating independent processes, the custom modules implemented by the user in different programming languages are run in separate processes; the development of the software architecture system is simplified, the waste of resource memory space is reduced, and it has good compatibility and is convenient for users to use.

[0009] Optionally, if there are multiple custom modules, the actuator is configured to create a number of subprocesses corresponding to the number of custom modules in the main process module.

[0010] In the above implementation process, by creating independent subprocesses corresponding to each of the multiple custom modules in the main process module of the actuator, custom module files compiled in multiple different programming languages can be run simultaneously. At the same time, when the executable file runs, the multiple processes are independent of each other and do not interfere with each other, improving the development efficiency, universality, and generality.

[0011] Optionally, the functional module includes: a proxy server, configured to receive the data generated on the operation interface of the custom module and transmit the data to the functional interface server through a preset communication protocol; a functional interface server, configured to provide a functional interface to receive the data transmitted by the proxy server and trigger the module manager; and a module manager, configured to access the actuator through the functional interface and transmit the data to the actuator.

[0012] In the above implementation process, through the cooperation of the proxy server, the functional interface server, and the module manager, the operation data of the custom module is transmitted to the actuator, and the actuator creates corresponding subprocesses to run one or more executable files included in the custom module, simplifying the development of the software architecture system, reducing the waste of resource memory space, and improving the development efficiency.

[0013] Optionally, the custom module includes one or more of a custom instruction module, a custom function module, and a custom service module.

[0014] In the above implementation process, the operation of intelligent devices such as robots can be achieved by developing three different types of custom modules, realizing that the control of intelligent devices such as robots is defined by software, the software is defined by users, and the custom modules are plug-and-play, enhancing the flexibility of development.

[0015] Optionally, the number of the executable files is determined by one or more of the number of instructions, the number of functions, and the number of services of the custom module.

[0016] In the above implementation process, one custom instruction is one executable file, one custom function is one executable file, and one custom service is one executable file, so as to realize the independence between instructions, functions, and services during runtime, reduce the development difficulty, and improve the error troubleshooting efficiency when the program makes mistakes.

[0017] Optionally, the multiple programming languages include Python language, C++ language, Java language, and JavaScript language.

[0018] In the above implementation process, the multiple programming languages that the actuator in the custom module control system can handle include multiple common programming languages, and the development method will be more flexible, capable of supporting developers to utilize different programming language ecosystems, thereby improving the compatibility and generality of the system architecture.

[0019] In a second aspect, an embodiment of the present application provides a method for controlling a custom module. The method includes: a function module transfers data of the custom module to an actuator; wherein, the custom module includes executable files compiled by multiple programming languages; and the actuator creates a process corresponding to the custom module through an embedded script and runs the executable file in the process.

[0020] In the above implementation process, the operation data of the custom module is transmitted to the actuator through the function module, and the actuator creates a corresponding child process to run the executable files compiled by multiple programming languages included in the custom module. The multiple processes are independent of each other and do not interfere with each other, simplifying the development of the software architecture system, reducing the waste of resource memory space, improving the development efficiency, and solving the technical problems of poor universality and generality.

[0021] In a third aspect, an embodiment of the present application further provides an electronic device, including: a processor and a memory. The memory stores machine-readable instructions executable by the processor. When the electronic device runs, the machine-readable instructions are executed by the processor to perform the steps of the above method.

[0022] Fourthly, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is run by a processor, it executes the steps of the above method.

[0023] To make the above objects, features, and advantages of the present application more obvious and understandable, specific embodiments are hereinafter given and described in detail in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] To more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings required to be used in the embodiments of the present application. It should be understood that the following drawings only show some embodiments of the present application, and thus should not be regarded as limiting the scope. For those of ordinary skill in the art, other related drawings can be obtained based on these drawings without creative efforts.

[0025] Figure 1 It is a schematic diagram of the function modules of the first custom module control system provided by an embodiment of the present application;

[0026] Figure 2 It is a schematic diagram of the function modules of the second custom module control system provided by an embodiment of the present application;

[0027] Figure 3 It is a schematic diagram of the function modules of the third custom module control system provided by an embodiment of the present application;

[0028] Figure 4 It is a flowchart of a custom module control method provided by an embodiment of the present application; and

[0029] Figure 5 It is a block diagram of an electronic device of a device provided by an embodiment of the present application.

[0030] Icons: 10 - Custom module control system; 12 - Function module; 121 - Proxy server; 122 - Function interface server; 123 - Module manager; 14 - Executor; 141 - Main process module; 142 - Shared memory space module; 143 - Sub-process module; 300 - Electronic device; 311 - Memory; 312 - Storage controller; 313 - Processor; 314 - Peripheral interface; 315 - Input / output unit; 316 - Display unit. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0031] The following will describe the technical solutions in the embodiments of the present application in conjunction with the drawings in the embodiments of the present application.

[0032] It should be noted that similar reference numerals and letters denote similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. At the same time, in the description of the present application, terms such as "first" and "second" are only used for distinguishing descriptions and cannot be construed as indicating or implying relative importance.

[0033] The inventors of the present application have noticed that taking robots as an example, industrial robots generally include three parts: a robot body, a controller, and a teach pendant. The teach pendant is a human-machine interaction device that controls through a developed teach pendant program, monitors the system status, and sends and receives control instructions. The existing common method for the controller is to set up a control system based on Lua scripts and plugins. When configuring the system status and instructions in the script, the status structure of the control system is defined in the script file. After starting the program, the system status is sent to the teach pendant according to the structure defined in the script. After receiving the status, the teach pendant reads the script file to obtain the parsing method of the status and sequentially parses all statuses. However, the script of this solution only supports a certain fixed language and cannot utilize the language ecosystems of different programming languages, making it difficult to meet the universal application between different versions and having poor versatility.

[0034] Based on the above research, an embodiment of the present application provides a custom module control system 10, which includes: a function module 12 and an actuator 14. The function module 12 is used to transfer the data of the custom module to the actuator 14; wherein, the custom module includes executable files compiled by multiple programming languages; and the actuator 14 is used to create a process corresponding to the custom module through an embedded script and run the executable file in the process, which can make full use of the inherent ecosystems of different programming languages, support multiple programming languages, improve the flexibility of development, and increase universality and versatility.

[0035] Please refer to Figure 1 , Figure 1 which is a schematic diagram of the function module 12 of the first custom module control system 10 provided by an embodiment of the present application. The following will elaborate on the Figure 1 system in detail.

[0036] The custom module control system 10 includes: a function module 12 and an actuator 14. The function module 12 is communicatively connected to the actuator 14; the function module 12 is used to transfer the data of the custom module to the actuator 14; wherein, the custom module includes executable files compiled by multiple programming languages; and the actuator 14 is used to create a process corresponding to the custom module through an embedded script and run the executable file in the process.

[0037] Exemplarily, the custom module can be a set of functions defined by the user to control intelligent devices such as robots, implementing corresponding functions such as gripper control, vision guidance, sensor control, communication protocols, and custom instructions; the function module 12 can be a set of functions that store a certain function by encapsulating a function in a file. Since the function module 12 is used to transfer the data of the custom module to the actuator 14, the functions encapsulated in this module are for the functions used in the data transfer process.

[0038] The embedded script can be a shell script. Shell is an interpreted scripting language that can directly call Linux commands for programming. Among them, shell is a command interpreter, which is the user interface of the Unix operating system. The program obtains input information from the user interface. Shell translates the user program and its input into instructions that the operating system kernel can recognize, and the output returned after the operating system kernel finishes execution is presented to the user through shell. Since shell scripts can handle various programming languages, shell scripts are used in the actuator 14 to create processes and run executable files compiled by various programming languages in the custom module, so as to realize the processing and running of custom modules compiled in different programming languages.

[0039] Using the software architecture of the function module 12 and the actuator 14 to develop the custom module control system 10, the unified interface of the function module 12 can be used to realize the interactive communication of custom modules with multiple function applications; by configuring script commands in the actuator 14 and creating corresponding processes, the monitoring and display of the running status of custom module files compiled in multiple programming languages can be realized; at the same time, the resources (CPU, memory, etc.) used by multiple processes are independent of each other and do not interfere with each other, improving the development efficiency and solving the technical problems of poor universality and generality.

[0040] Please refer to Figure 2 , Figure 2 FIG. 12 is a schematic diagram of the function module 12 of the second custom module control system 10 provided by the embodiment of the present application. The following will elaborate on the Figure 2 system in detail.

[0041] The actuator 14 in the custom module control system 10 may specifically include: a main process module 141, a subprocess module 143, and a shared memory space module 142.

[0042] Among them, the main process module 141 is used to create a subprocess corresponding to a custom module and a shared memory space through an embedded script in the executor 14, and obtain the running status data of the subprocess from the shared memory space; the subprocess module 143 is used to run an executable file in the subprocess created by the main process module 141 and output the running status data to the shared memory space; and the shared memory space module 142 is used to receive the running status data generated when the executable file runs in the subprocess module 143.

[0043] Exemplarily, both the main process and the subprocess can be programs created through Linux shell scripts on the executor 14 side; the main process can be the main program necessary for the executor 14 to work; the subprocess can be multiple almost identical processes generated by the Fork (derivation) function in the main program, and each process starts a thread that executes from the same position in the code, implementing a new process, but instead of loading code from disk, it copies a copy from an existing process in memory; data interaction between the main process and the subprocess is carried out through the same shared memory space. The subprocess can output data or obtain data from the shared memory space by calling a pipe created by the pipe() function, and the pipe can be a mechanism that connects the standard input and standard output between two processes, thus providing a method for multiple processes to communicate. When a process creates a pipe, two file descriptors need to be provided to operate the pipe, one for writing to the pipe and the other for reading from the pipe.

[0044] Optionally, when the user operates on a certain custom module to generate relevant data, such as operations like saving, deleting, and setting relevant parameter information, the function module 12 receives these data and can pass these data to the executor 14 in the form of json data by calling relevant interface functions to pass parameters. After receiving these data, the executor 14 first uses the shell script Linux programming in the main process module 141 to create a running main program, and in the main program, it establishes a subprocess corresponding to this custom module through the fork() function. At the same time, it creates a pipe for the subprocess to output data or obtain data from the shared memory space by calling the pipe() function in the fork() function. For reading and writing to the pipe, the write() function can be used to write data and the read() function can be used to read data; then the subprocess module 143 runs these data in the subprocess in the form of an executable file, generates relevant running status data, and outputs the running status data to the shared memory space through the pipe; finally, the shared memory space module 142 receives the running status data output by the subprocess module 143 through the pipe and stores it correspondingly, so that the main process module 141 can obtain the running status data of the subprocess from the shared memory space at any time.

[0045] The actuator 14 creates an independent shared memory space for data interaction. The subprocess outputs data to or obtains data from the shared memory space through a pipeline. At the same time, the main process of the actuator 14 can obtain data such as the running status of the subprocess from the shared memory space. Independent processes are created through the Fork technology at the Linux underlying layer, and the custom modules implemented by users in different programming languages are run within separate processes. This simplifies the development of the software architecture system, reduces the waste of resource memory space, has good compatibility, and is convenient for users to use.

[0046] In one embodiment, the actuator 14 in the custom module control system 10 may specifically include: a main process module 141, a subprocess module 143, and a shared memory space module 142.

[0047] Among them, if there are multiple custom modules, the actuator 14 is configured to create a corresponding number of subprocesses in the main process module 141 for the custom modules.

[0048] Exemplarily, if a user operates on a certain custom module through operations such as saving, deleting, and setting relevant parameter information, the main process module 141 in the actuator 14 will create a first subprocess corresponding to the custom module in the main program, and run one or more executable files included in the custom module in the first subprocess. If operations are simultaneously performed on another or N custom modules, the main process module 141 in the actuator 14 will create a second subprocess or the Nth subprocess corresponding to the custom module in the main program, and run one or more executable files included in the custom module in the second subprocess or the Nth subprocess.

[0049] By using the fork() function in the main process of the actuator 14 to create independent subprocesses corresponding to multiple different custom modules, it is possible to simultaneously run custom module files compiled in multiple different programming languages. At the same time, when the executable files are running, the resources (CPU, memory, etc.) used by multiple processes are independent of each other and do not interfere with each other, improving the development efficiency, universality, and generality.

[0050] Please refer to Figure 3 , Figure 3 which is a schematic diagram of the functional module 12 of the third custom module control system 10 provided by the embodiment of the present application. The following will elaborate on the Figure 3 system in detail.

[0051] The functional module 12 in the custom module control system 10 may specifically include: a proxy server 121, a functional interface server 122, and a module manager 123.

[0052] Among them, the proxy server 121 is used to receive the data generated on the operation interface of the custom module and transmit the data to the function interface server 122 through a preset communication protocol; the function interface server 122 is used to provide a function interface to receive the data transmitted by the proxy server 121 and trigger the module manager 123; and the module manager 123 accesses the actuator 14 through the function interface and transmits the data to the actuator 14.

[0053] Exemplarily, the preset communication protocol can be the Protobuf communication protocol, which is a structured data storage format and can be used for serializing or deserializing structured data. It is a language-independent, platform-independent, and extensible serialized structured data format for fields such as communication protocols and data storage; the operation interface of the custom module can be located at the front end corresponding to the background where the custom module runs. For example, the operation interface of the user-defined module on the APP. On this operation interface, operations such as saving, deleting, and setting relevant parameter information of the custom module can be performed; the proxy server 121 (Addon proxy server) can provide a REST (Representational State Transfer, a software architecture style) API interface protocol for the custom module to conduct communication interactions; the function interface server 122 (Grpc server) can provide multiple function interface protocols including the REST API interface for the custom module to conduct communication interactions; the module manager 123 (Addon manager) can be mainly responsible for the installation, deployment, and operation management of different types of Addon modules.

[0054] Optionally, the user installs the custom module on the APP side through the REST API. After successful installation, the proxy server 121 converts the information operated on the operation interface of the custom module on the APP side into json data, creates a file with the extension ".proto", writes a program, compiles the ".proto" file to generate a Go language file, uses Protobuf in the program and executes the program, forwards the data to the function interface server 122 through the REST API interface. The function interface server 122 performs data transmission according to the corresponding interface protocol and triggers the module manager 123. The module manager 123 accesses the actuator 14, and the actuator 14 creates corresponding child processes in the main process module 141 to run one or more executable files included in the custom module. At the same time, the running status of the custom module can be obtained through the Linux signal.

[0055] Through the cooperation of proxy server 121, functional interface server 122, and module manager 123, the operation data of the custom module is transmitted to actuator 14. Actuator 14 creates corresponding subprocesses to run one or more executable files included in the custom module, simplifying the development of the software architecture system, reducing the waste of resource memory space, and improving development efficiency.

[0056] In one embodiment, the custom modules in the custom module control system 10 include one or more of custom instruction modules, custom function modules, and custom service modules.

[0057] Exemplarily, the custom modules that users can develop and define include three types: custom instruction modules, custom function modules, and custom service modules. For example, application functions such as gripper control, vision guidance, and sensor control can be implemented by custom function modules; communication services such as programming interfaces and communication protocols can be implemented by custom service modules; and operation instructions such as commands and custom instructions can be implemented by custom instruction modules.

[0058] Among them, the custom instruction module can be: other instructions outside the standard operation program instructions developed by users according to the script specifications of intelligent devices such as robots; the custom function module can be: functions developed by users through the REST API provided by the functional module of proxy server 121; the custom service module can be: secondary development interfaces provided by intelligent devices such as robots in multiple different programming languages.

[0059] Complex operations such as gripper control modules, vision guidance modules, sensor control modules, communication protocols, and custom instructions can all be implemented by developing different types of custom modules, enabling the control of intelligent devices such as robots to be defined by software, the software to be defined by users, and the custom modules to be plug-and-play, enhancing the flexibility of development.

[0060] In one embodiment, the number of executable files is determined by one or more of the number of instructions, functions, and services of the custom module.

[0061] Exemplarily, if the type of the custom module developed and defined by the user is a custom instruction module, the number of executable files included in the custom module is determined by the number of instructions, that is, one custom instruction is one executable file; if the type of the custom module developed and defined by the user is a custom function module, the number of executable files included in the custom module is determined by the number of functions, that is, one custom function is one executable file; if the type of the custom module developed and defined by the user is a custom service module, the number of executable files included in the custom module is determined by the number of services, that is, one custom service is one executable file.

[0062] Since a custom instruction is an executable file, a custom function is an executable file, and a custom service is an executable file, it is possible to achieve independence and non - interference among instructions, functions, and services during runtime, reducing the development difficulty and improving the error troubleshooting efficiency when the program encounters errors.

[0063] In one embodiment, the multiple programming languages include Python, C++, Java, and JavaScript.

[0064] Exemplarily, the multiple programming languages that the actuator 14 in the custom module control system 10 can handle include multiple common programming languages. The common programming languages can be divided into two categories: one is compiled languages, such as c / c++ / java, etc., which all need to be compiled by a compiler before running; the other is interpreted languages, such as awk / perl / python / shell, etc., which need to be converted line by line into code by an interpreter when executed. Since shell has been standardized by POSIX, it can be ported on different Linux systems, thus can handle and support various programming languages, making the development method of this application more flexible, capable of supporting developers to utilize different programming language ecosystems, thereby improving the compatibility and universality of the system architecture.

[0065] Please refer to Figure 4 , Figure 4 which is a flowchart of a custom module control method provided by an embodiment of this application. The following will elaborate on the Figure 4 process in detail.

[0066] This method may include: step 100 and step 120.

[0067] Among them, in step 100: the function module 12 transfers the data of the custom module to the actuator 14; where the custom module includes executable files compiled by multiple programming languages; and

[0068] in step 120: the actuator 14 creates a process corresponding to the custom module through an embedded script and runs the executable file in the process.

[0069] Exemplarily, through the cooperation of functional modules 12 such as proxy server 121, functional interface server 122, and module manager 123, the operation data of the custom module is transmitted to actuator 14. Actuator 14 creates corresponding child processes through shell script Linux programming to run one or more executable files compiled by various programming languages included in the custom module, simplifying the development of the software architecture system and reducing the waste of resource memory space; multiple processes are independent of each other and do not interfere with each other, improving the development efficiency and solving the technical problems of poor universality and generality.

[0070] Please refer to Figure 5 , Figure 5 which is a block diagram of an electronic device. The electronic device 300 may include a memory 311, a storage controller 312, a processor 313, a peripheral interface 314, an input / output unit 315, and a display unit 316. Those of ordinary skill in the art can understand that Figure 5 the structure shown is only schematic and does not limit the structure of the electronic device 300. For example, the electronic device 300 may further include more or fewer components than Figure 5 shown in Figure 5 or have a different configuration from

[0071] The above-mentioned memory 311, storage controller 312, processor 313, peripheral interface 314, input / output unit 315, and display unit 316 are electrically connected directly or indirectly to each other to achieve data transmission or interaction. For example, these components may be electrically connected to each other through one or more communication buses or signal lines. The above-mentioned processor 313 is used to execute executable modules stored in the memory.

[0072] Among them, the memory 311 may be, but is not limited to, a random access memory (Random Access Memory, abbreviated as RAM), a read-only memory (Read Only Memory, abbreviated as ROM), a programmable read-only memory (Programmable Read-Only Memory, abbreviated as PROM), an erasable programmable read-only memory (Erasable Programmable Read-Only Memory, abbreviated as EPROM), an electrically erasable programmable read-only memory (Electric Erasable Programmable Read-Only Memory, abbreviated as EEPROM), etc. Among them, the memory 311 is used to store programs, and the processor 313 executes the programs after receiving execution instructions. The methods executed by the electronic device 300 defined by the processes disclosed in any embodiment of the present application can be applied to the processor 313 or implemented by the processor 313.

[0073] The above-mentioned processor 313 may be an integrated circuit chip with signal processing capabilities. The above-mentioned processor 313 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0074] The above-mentioned peripheral interface 314 couples various input / output devices to the processor 313 and the memory 311. In some embodiments, the peripheral interface 314, the processor 313, and the memory controller 312 may be implemented on a single chip. In some other instances, they may be implemented by separate chips respectively.

[0075] The above-mentioned input / output unit 315 is used to provide input data to the user. The input / output unit 315 may be, but is not limited to, a mouse, a keyboard, etc.

[0076] The above-mentioned display unit 316 provides an interaction interface (such as a user operation interface) between the electronic device 300 and the user for the user to refer to. In this embodiment, the display unit 316 may be a liquid crystal display or a touch display. The liquid crystal display or the touch display can display the process of the processor executing the program.

[0077] The electronic device 300 in this embodiment can be used to execute each step in the various methods provided in the embodiments of the present application.

[0078] In addition, the embodiments of the present application further provide a computer-readable storage medium, on which a computer program is stored. When the computer program is run by a processor, it executes the steps in the above method embodiments.

[0079] The computer program product of the above method provided by the embodiments of the present application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the steps in the above method embodiments. For details, please refer to the above method embodiments and will not be elaborated here.

[0080] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are only illustrative. For example, the division of the modules is only a logical function division. In actual implementation, there may be other division methods. For another example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be through some communication interfaces. The indirect coupling or communication connection of devices or units can be in electrical, mechanical or other forms. In the embodiments of this application, each functional module can be integrated together to form an independent part, or each module can exist alone, or two or more modules can be integrated to form an independent part.

[0081] It should be noted that if a function is implemented in the form of a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art or a part of this technical solution can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in each embodiment of this application. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs that can store program codes.

[0082] In this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations.

[0083] The above are only the embodiments of this application and are not used to limit the protection scope of this application. For those skilled in the art, this application can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this application shall be included in the protection scope of this application.

Claims

1. A custom module control system, characterized in that: The system includes: a function module and an executor, wherein the function module is in communication with the executor; the function module is configured to transmit data of a custom module to the executor; wherein the custom module includes an executable file compiled in a plurality of programming languages; and the executor is configured to create a process corresponding to the custom module through an embedded script and run the executable file in the process; The executor includes: a main process module, configured to create a sub-process and a shared memory space corresponding to the custom module in the executor through an embedded script, and obtain the running status data of the sub-process from the shared memory space; a sub-process module, configured to run the executable file in the sub-process created by the main process module and output the running status data to the shared memory space; and a shared memory space module, configured to receive the running status data generated when the executable file runs in the sub-process module; The functional module includes: a proxy server for receiving data generated in the operation interface of the custom module and transmitting the data to a functional interface server via a preset communication protocol; a functional interface server for providing a functional interface to receive data transmitted by the proxy server and triggering a module manager; and a module manager for accessing the actuator via the functional interface and transmitting the data to the actuator; The custom module includes one or more of a custom instruction module, a custom function module, and a custom service module.

2. The system according to claim 1, wherein: in, If there are multiple custom modules, the executor is configured to create multiple sub-processes corresponding to the number of custom modules in the main process module for the custom modules.

3. The system according to claim 1, wherein: in, The number of the executable files is determined by one or more of the number of instructions, the number of functions, and the number of services of the custom module.

4. The system according to any one of claims 1 to 2, characterized in that: The multiple programming languages include Python, C++, Java, and JavaScript.

5. A custom module control method, characterized in that: The method includes: transmitting data of a custom module to an executor by a functional module; wherein the custom module includes an executable file compiled by multiple programming languages; and creating a process corresponding to the custom module by the executor through an embedded script, and running the executable file in the process; The executor includes: a main process module, configured to create a sub-process and a shared memory space corresponding to the custom module in the executor through an embedded script, and obtain the running status data of the sub-process from the shared memory space; a sub-process module, configured to run the executable file in the sub-process created by the main process module and output the running status data to the shared memory space; and a shared memory space module, configured to receive the running status data generated when the executable file runs in the sub-process module; The functional module includes: a proxy server for receiving data generated in the operation interface of the custom module and transmitting the data to a functional interface server via a preset communication protocol; a functional interface server for providing a functional interface to receive data transmitted by the proxy server and trigger a module manager; and a module manager for accessing the actuator via the functional interface and transmitting the data to the actuator; The custom module includes one or more of a custom instruction module, a custom function module, and a custom service module.

6. An electronic device, characterized in that: include: A processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the machine-readable instructions are executed by the processor to perform the steps of the method according to claim 5.

7. A computer-readable storage medium, characterized in that The computer readable storage medium stores a computer program, which, when executed by a processor, performs the steps of the method according to claim 5 .

Images