A method, apparatus, device and storage medium for running a function module

Abstract

The application relates to a function module operation method, device and equipment and a storage medium, the method comprising the following steps: a first function module class corresponding to a first function module is created; the first function module class inherits a base class provided by a preset function module development framework; a data service interface for data interaction between modules and an execution interface for executing business logic in a module are arranged in the base class; first output data corresponding to a second function module relied on by the first function module is acquired through the data service interface in the first function module class; the first output data is data provided externally to the second function module through the data service interface in the base class; the execution interface in the first function module class is called, the first function module is operated based on the first output data according to preset business logic. The application reduces the complexity of control logic, reduces resource consumption and improves the decoupling degree between modules through a data driving mode.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software development, and particularly relates to a function module running method and device, equipment and a storage medium. BACKGROUND

[0002] In modern software systems, especially in complex application scenarios such as automatic driving, efficient running and flexible management of function modules become one of the key technologies. Such systems are usually composed of multiple interdependent function modules. In the process of software development, the configuration process of the modules is relatively cumbersome, and the coupling degree between the modules is high.

[0003] In addition, in the existing scheme, the start-stop and switching of the modules depend on complex business logic control, lack flexible running mechanism, limit the expansibility and adaptability of the system, and the flexibility and scalability are low. SUMMARY

[0004] In order to solve the technical problems of the related art that the configuration process of the modules is cumbersome, the coupling degree between the modules is high, and the flexibility and scalability of the system are low in the process of software development, the embodiments of the present application provide a function module running method, device, equipment and storage medium.

[0005] In a first aspect, the embodiments of the present application provide a function module running method, comprising:

[0006] A first function module class corresponding to a first function module is created; the first function module class inherits a base class provided by a preset function module development framework; the base class is provided with a data service interface for data interaction between modules and an execution interface for executing business logic in the module;

[0007] First output data corresponding to a second function module relied on by the first function module is obtained through the data service interface in the first function module class; the first output data is data provided externally by the second function module through the data service interface in the base class;

[0008] The execution interface in the first function module class is called, and the first function module is run based on the first output data according to a preset business logic.

[0009] Based on the aforementioned technical methods, firstly, a first functional module class corresponding to the first functional module is created and inherits from the base class, thereby obtaining unified thread management, task distribution, and data-driven capabilities. Secondly, data from dependent modules is obtained through a data service interface, avoiding direct dependence on specific implementations and improving module decoupling. Finally, the execution interface is called to run the business logic, allowing developers to focus only on the core logic itself without having to handle underlying threads or complex control flows. In this way, on the one hand, the standardized base class design simplifies the development process of functional modules and improves development efficiency; on the other hand, communication between modules through the data service interface reduces the coupling between modules, improving the maintainability and scalability of the system.

[0010] Furthermore, the base class includes a main thread and a thread pool for business logic processing; creating a first functional module class corresponding to the first functional module includes: before obtaining the first output data corresponding to the second functional module that the first functional module depends on through the data service interface in the first functional module class, the method also includes: setting the first input data and second output data corresponding to the first functional module through the data service interface in the first functional module class; accordingly, calling the execution interface in the first functional module class, and running the first functional module based on the first output data according to the preset business logic, including: in response to finding target data matching the first input data from the first output data, using the main thread, converting the obtained target data into a task to be executed, and placing the task to be executed into a task queue; using the main thread, distributing the tasks to be executed in the task queue to the worker threads corresponding to the thread pool, processing them according to the business logic corresponding to the target data in the preset business logic, obtaining the task processing result, and determining the task processing result as the second output data.

[0011] Based on the aforementioned technical methods, after acquiring input data, the main thread converts the data into tasks and places them in a task queue, which are then distributed by the main thread to worker threads in the thread pool for processing. In this way, on the one hand, the collaborative mechanism between the main thread and the thread pool achieves efficient task distribution and concurrent execution; on the other hand, triggering task execution through data-driven methods avoids the complexity of traditional control logic, further improving system performance and stability.

[0012] Furthermore, the execution interface in the first functional module class is invoked to run the first functional module based on the first output data according to the preset business logic. This includes: in response to the failure to find the target data in the first output data, stopping the execution of the business logic task corresponding to the target data in the first functional module; obtaining the third output data corresponding to the third functional module that the first functional module depends on through the data service interface in the functional module class; the third output data is the data provided externally for the third functional module through the data service interface in the base class; and invoking the execution interface in the first functional module class to run the first functional module based on the third output data according to the preset business logic.

[0013] Based on the aforementioned technical methods, when the required data cannot be found, the relevant business logic tasks are automatically stopped to avoid unnecessary consumption of computing resources; simultaneously, data is retrieved from other dependent modules, and subsequent logic continues to be executed. In this way, on the one hand, the system's fault tolerance capability is improved when data is unavailable; on the other hand, by starting business logic on demand, unnecessary computing resource consumption is effectively reduced, improving the system's energy efficiency ratio.

[0014] Furthermore, after determining the task processing result as the second output data, the method also includes: using the main thread to provide the second output data to other functional modules through the data service interface in the base class.

[0015] Based on the aforementioned technical methods, the main thread publishes the processing results as output data through a data service interface for use by other modules. This ensures, on the one hand, the standardization and consistency of data transfer between modules; and on the other hand, enhances the decoupling between modules through a unified interface mechanism, thereby improving the overall coordination and scalability of the system.

[0016] Furthermore, the method also includes: in response to the existence of target output data in the second output data corresponding to the first functional module that is not dependent on by other modules, stopping the execution of the business logic task corresponding to the target output data in the first functional module.

[0017] Based on the aforementioned technical means, when the output data of a module is no longer depended on by any downstream module, that module will proactively stop its related business logic tasks. This avoids resource waste and improves system efficiency; furthermore, through a data-driven start / stop mechanism, it enables adaptive adjustments to business logic, enhancing the system's flexibility and intelligence.

[0018] Furthermore, the method also includes: in response to detecting that the connection status between the first functional module and the second functional module is disconnected, running the first functional module based on a preset callback function mechanism; in response to detecting that the connection status changes from disconnected to connected, continuing to obtain the first output data through the data service interface in the functional module class.

[0019] Based on the aforementioned technical methods, a callback function mechanism enables functional modules to sense changes in connection status and react accordingly. This improves the system's fault tolerance, ensuring normal module operation even if the data source is temporarily unavailable. Furthermore, once the connection is restored, the module can automatically re-establish the connection and resume data processing, enhancing the system's reliability and continuity.

[0020] Furthermore, before obtaining the first output data corresponding to the second functional module that the first functional module depends on through the data service interface in the first functional module class, the method further includes: setting the input data and output data corresponding to the target functional module through the data service interface in the target functional module class; the target functional module class is a functional module class created for the target functional module; the target functional module is the second functional module or the third functional module.

[0021] Based on the above technical means, the input and output data structures are set by the corresponding functional module classes, ensuring the standardization and compatibility of the data interface.

[0022] Furthermore, the base class includes a start interface for initializing the module; creating a first functional module class corresponding to the first functional module includes: defining the runtime environment corresponding to the first functional module through the start interface in the first functional module class; correspondingly, calling the execution interface in the first functional module class to run the first functional module according to the preset business logic and based on the first output data, before the method further includes: calling the start interface to initialize the runtime environment corresponding to the first functional module; wherein, the runtime environment includes at least one or more of the following: module parameters, data receiving queue, and objects in the data service interface.

[0023] Based on the above technical means, the module's initial configuration, such as loading the model, setting parameters, and initializing data structures, is completed through the start interface, ensuring that the module has complete operating conditions before formal operation.

[0024] Furthermore, the base class includes an exit interface for releasing module resources; a first functional module class corresponding to the first functional module is created, including: defining the system resources corresponding to the first functional module through the exit interface in the first functional module class; in response to the exit of the first functional module, calling the exit interface to release the system resources of the first functional module; wherein, the system resources include at least one or more of the following: module parameters, module memory space, and objects in the data service interface.

[0025] Based on the above technical means, the system resources occupied by the module are released through the exit interface, ensuring that no residual resources are left when the module exits. Through a unified resource release mechanism, the standardization of module lifecycle management is improved and the robustness of the system is enhanced.

[0026] Secondly, embodiments of this application provide an operating device for a functional module, the operating device for the functional module including:

[0027] Create a module to create the first functional module class corresponding to the first functional module; the first functional module class inherits from the base class provided by the preset functional module development framework; the base class sets up the data service interface for data interaction between modules, as well as the execution interface for executing business logic within the module;

[0028] The acquisition module is used to acquire the first output data corresponding to the second functional module that the first functional module depends on through the data service interface in the first functional module class; the first output data is the data provided externally by the second functional module through the data service interface in the base class.

[0029] The calling module is used to call the execution interface in the first functional module class, and run the first functional module according to the preset business logic and based on the first output data.

[0030] Thirdly, embodiments of this application provide a device for running a functional module, which includes a processor, a memory, and a communication bus; the processor executes a program stored in the memory to implement the above-mentioned method for running the functional module.

[0031] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described method for operating the functional modules.

[0032] The beneficial effects of this application are:

[0033] (1) First, create the first functional module class corresponding to the first functional module and inherit the base class to obtain unified thread management, task distribution and data-driven capabilities; second, obtain the data of dependent modules through the data service interface to avoid direct dependence on specific implementations and improve module decoupling; finally, call the execution interface to run the business logic, so that developers only need to focus on the core logic itself and do not need to deal with the underlying threads or complex control flow. In this way, on the one hand, the development process of functional modules is simplified and the development efficiency is improved through the standardized base class design; on the other hand, the communication between modules through the data service interface reduces the coupling between modules and improves the maintainability and extensibility of the modules.

[0034] (2) When a module cannot find the required data, it automatically stops the relevant business logic tasks to avoid unnecessary consumption of computing resources; at the same time, it switches to other dependent modules to obtain data and continues to execute subsequent logic. In this way, on the one hand, by dynamically switching data sources, the fault tolerance capability of the system in the case of data unavailability is improved; on the other hand, by starting business logic on demand, unnecessary computing resource occupation is effectively reduced and the energy efficiency ratio is improved.

[0035] (3) The main thread publishes the processing results as output data through the data service interface for use by other modules. In this way, on the one hand, the standardization and consistency of data transmission between modules are ensured; on the other hand, the decoupling between modules is enhanced through a unified interface mechanism, thereby improving the overall coordination capability and scalability.

[0036] (4) When the output data of a module is no longer depended on by any downstream module, the module will actively stop its related business logic tasks. In this way, on the one hand, resource waste is avoided and the operating efficiency of the module is improved; on the other hand, through the data-driven start-stop mechanism, the adaptive adjustment of business logic is realized, enhancing flexibility and intelligence.

[0037] (5) Release the system resources occupied by the module through the exit interface to ensure that no residual resources are left when the module exits. In this way, on the one hand, the resource leakage problem is prevented and the stability of the functional module is guaranteed; on the other hand, the unified resource release mechanism improves the standardization of module life cycle management and enhances the robustness of the functional module operation. Attached Figure Description

[0038] Figure 1 A flowchart illustrating a method for operating a functional module as provided in an embodiment of this application;

[0039] Figure 2 This application provides a schematic diagram of the structure of an exemplary data processing method.

[0040] Figure 3 A schematic diagram illustrating an exemplary software development framework provided for embodiments of this application;

[0041] Figure 4 A flowchart illustrating an exemplary operation of a first functional module is provided for embodiments of this application. Figure 1 ;

[0042] Figure 5 This application provides an exemplary schematic diagram of the structure for module data interaction.

[0043] Figure 6 A flowchart illustrating an exemplary operation of a first functional module is provided for embodiments of this application. Figure 2 ;

[0044] Figure 7 This is an exemplary flowchart illustrating the development of functional modules based on a framework, provided for an embodiment of this application.

[0045] Figure 8 A schematic diagram of the structure of a functional module operating device provided in an embodiment of this application;

[0046] Figure 9 This is a schematic diagram of the structure of a functional module operating device provided in an embodiment of this application. Detailed Implementation

[0047] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0048] This application provides a method for operating a functional module, implemented by a device for operating the functional module. Figure 1 A flowchart illustrating a method for operating a functional module provided in an embodiment of this application is shown below. Figure 1 As shown, the process includes the following steps S101 to S103:

[0049] Step S101: Create a first functional module class corresponding to the first functional module; the first functional module class inherits from the base class provided by the preset functional module development framework; the base class sets up a data service interface for data interaction between modules, and an execution interface for executing business logic within the module.

[0050] In the embodiments of this application, the first functional module refers to a specific functional module built by the developer according to specific business needs, such as image recognition, object detection, or path planning modules. To ensure the standardization and reusability of the module, the first functional module needs to inherit the base class provided by the preset functional module development framework. The base class of the preset functional module development framework is provided with data service interfaces required for inter-module communication and execution interfaces for handling the internal business logic of the module. Thus, after creating the first functional module class corresponding to the first functional module, and making it inherit the base class provided by the preset functional module development framework, the first functional module class can automatically obtain the core functions of the preset functional module development framework. That is, by inheriting the base class, the first functional module class can automatically obtain the support of data service interfaces and execution interfaces, thereby having the ability to interact with other modules and execute the internal business logic of the module.

[0051] In the embodiments of this application, a data service interface refers to a set of interface functions defined in a base class, used for data input and output operations between modules. The data service interface allows a first functional module to obtain data from other dependent functional modules, and also allows the first functional module to provide data to other functional modules. The design purpose of the data service interface is to achieve loosely coupled communication between modules, enabling modules to exchange data only through standard interfaces without directly referencing each other's code. The design of the data service interface improves flexibility and maintainability, and also facilitates the rapid replacement and expansion of functional modules.

[0052] In the embodiments of this application, the execution interface is another key interface in the base class, used to trigger the business logic processing within the module. When the first functional module receives input data, the execution interface processes the data according to preset business logic and generates output data. The execution interface is designed to support dynamic start and stop; that is, the business logic is only started when input data is available, and automatically stops when there is no input data or the downstream module has not subscribed to output data, thereby reducing resource consumption.

[0053] In the embodiments of this application, the creation of the corresponding first functional module class of the first functional module will be based on the data service interface and execution interface of the base class in the preset functional module development framework to implement the first functional module class.

[0054] For example: Define a VisualDetection class (the first functional module class corresponding to the first functional module) that inherits from the base class Agent (the base class provided by the default functional module development framework):

[0055] First, create a class named VisualDetection and make it inherit from the base class Agent provided by the framework. After inheriting the base class, the VisualDetection class will automatically acquire the core functionality of the Agent framework, thus laying the foundation for subsequent feature development.

[0056] Secondly, the specific business logic is implemented in the VisualDetection class, such as image acquisition, implementation of target detection algorithms, and output of detection results. The VisualDetection module (the first functional module) needs to obtain information such as images, locations, data preprocessing or feature extraction results through AgentConsumerInf (data service interface), and provide services or data to the outside world through AgentProviderInf (data service interface), such as sending the detected target information to other functional modules.

[0057] Finally, the base class interface Work() (execution interface) is called to begin work: the VisualDetection module is started by calling the Work() interface provided by the base class Agent. Through the Work() interface, the module can start running according to preset logic and automatically manage the start and stop of tasks in a data-driven manner.

[0058] In the embodiments of this application, by inheriting the base class and implementing the data service interface and execution interface, developers can quickly build functional modules that conform to the framework specifications, ensuring that the modules can run efficiently under a unified development framework.

[0059] Step S102: Obtain the first output data corresponding to the second functional module that the first functional module depends on through the data service interface in the first functional module class; the first output data is the data provided externally for the second functional module through the data service interface in the base class.

[0060] In the embodiments of this application, the first functional module may depend on data input from other functional modules. For example, the image recognition module may depend on image data from the camera acquisition module. In this case, the first functional module needs to call the corresponding AgentConsumerInf interface through the data service interface in the base class inherited by the first functional module to obtain the required data from the second functional module. The data output by the first functional module is the data published externally by the second functional module through the AgentProviderInf interface implemented by the second functional module itself, such as image frames, sensor data, or feature extraction results.

[0061] For example, taking an autonomous driving system as an example, suppose the first functional module is a visual detection module, which relies on image data from a camera acquisition module. The camera acquisition module, as a second functional module, publishes image data externally through the AgentProviderInf interface. The visual detection module subscribes to and receives this image data through the AgentConsumerInf interface. Data-driven, decoupled communication is implemented between the visual detection module and the camera acquisition module, ensuring that even if one module is temporarily unavailable, it will not affect the normal operation of the other module.

[0062] In the embodiments of this application, even if the acquisition parameters corresponding to the camera acquisition module are adjusted, as long as the final output data is image data, the calling and operation of the first functional module will not be affected, thus reducing the coupling between models.

[0063] In the embodiments of this application, the data service interface not only simplifies the data interaction process between modules, but also effectively reduces the overall coupling and improves the independence and reusability of the modules. Furthermore, since the modules only focus on data input and output and do not need to concern themselves with the specific implementation methods of other modules, the application of the data service interface greatly reduces the workload of configuration and debugging, thus improving development efficiency.

[0064] Step S103: Call the execution interface in the first functional module class, and run the first functional module according to the preset business logic and based on the first output data.

[0065] In the embodiments of this application, once the first functional module successfully obtains the required input data through the data service interface, it will call the execution interface and begin data processing according to the preset business logic.

[0066] In the embodiments of this application, the preset business logic can be the specific business logic implemented in the first functional module class, and it can be in the form of a function. Then, when the execution interface is called to run the first functional module, the business logic function (preset business logic) in the first functional module class can be called to process the data.

[0067] Thus, the first functional module class is constructed by inheriting from the base class, enabling it to have standard data interaction and execution interfaces, thereby achieving a standardized development process. Secondly, output data from dependent modules is obtained through a data service interface, eliminating the need for manual configuration or debugging of inter-module communication, simplifying the development and maintenance process. Finally, execution is based on preset business logic, improving maintainability and flexibility. Compared to existing technologies, this solution reduces control logic complexity, lowers resource consumption, and improves the decoupling between modules through a data-driven approach.

[0068] In some embodiments, the base class includes a main thread and a thread pool for business logic processing; when the device running the functional module executes step S101 above, such as Figure 2 As shown, the following step S201 can also be performed:

[0069] Step S201: Set the first input data and second output data corresponding to the first functional module through the data service interface in the first functional module class.

[0070] In the embodiments of this application, during the creation of the first functional module class, the running device of the functional module can set the first input data and the second output data corresponding to the first functional module through the data service interface in the first functional module class.

[0071] In the embodiments of this application, each functional module provides a standardized data service interface for receiving input data and generating output data. The first input data is the data required when the functional module starts, such as image data; the second output data is the result data generated after internal processing by the module, for use by downstream modules, such as target detection results. The input and output data are encapsulated in a structured manner to ensure the efficiency and consistency of communication between modules.

[0072] For example, specific business logic needs to be implemented in the VisualDetection class (the first functional module class), such as image acquisition, implementation of target detection algorithms, and output of detection results. The VisualDetection module (the first functional module) needs to obtain information such as image, location, data preprocessing or feature extraction results (first input data) through AgentConsumerInf, and provide services or data to the outside world through AgentProviderInf, such as providing the detected target information to other functional modules (second output data).

[0073] In the embodiments of this application, the base class includes a main thread and a thread pool used for business logic processing. The main thread is the only thread in the Agent framework (pre-defined functional module development framework) responsible for handling I / O events, maintaining state, and distributing tasks. The main thread does not directly execute complex computational tasks; instead, it distributes tasks to worker threads in the thread pool set up in the base class for business logic processing. The thread pool consists of multiple worker threads, which are responsible for executing computationally intensive tasks to avoid blocking the main thread. This design simplifies the complexity of multithreaded development and improves response speed and resource utilization.

[0074] In the embodiments of this application, the main thread for business logic processing and the thread pool set in the base class together constitute a lightweight thread model, eliminating the need for developers to manually manage thread lifecycles and reducing development difficulty. Furthermore, the thread pool for business logic processing set in the base class has dynamic adjustment capabilities; this capability can increase or decrease the number of worker threads according to actual load conditions, thereby optimizing performance.

[0075] For example, such as Figure 3 As shown, an exemplary software development framework diagram is provided. Figure 3As shown, the Agent framework contains four basic modules: Agent30 (main framework, with main thread 31), TaskLoop (task queue management module) 32, ThreadPool (thread pool) 33, and AgentInf (data service interface) 34. The thread pool 33 includes multiple worker threads 331. The two Agent frameworks communicate with each other through the data service interface 34, and the data service interfaces 34 are connected to each other through inter-process communication (IPC).

[0076] Agent30 employs a concise and efficient thread management mechanism, using only a main thread and a thread pool to simplify the complexity of multi-threaded application development. For example, the thread that creates the Agent entity is the main thread, whose primary responsibilities are handling I / O events, maintaining the application logic state, distributing tasks, and executing simple computational tasks. The thread pool is dynamically created by the main thread based on the actual needs of the business logic, responsible for running tasks requiring significant computation. This avoids the frequent creation and management of raw threads in traditional development, reducing the complexity and resource consumption of multi-threaded development. Through this design, developers of functional modules do not need to directly manipulate the underlying threads, allowing them to focus more on implementing the business logic, further improving development efficiency and code quality. Furthermore, this thread management mechanism reduces the performance overhead of thread switching, optimizing overall performance.

[0077] TaskLoop32 is the task queue management module. Each thread can only have one TaskLoop instance, ensuring efficient and consistent task processing. In the main thread, TaskLoop is responsible for interacting with other functional modules, converting received data or service requests into specific tasks, and placing them in the task queue. Subsequently, TaskLoop distributes these tasks to the corresponding worker threads in the thread pool for processing. Through TaskLoop's task queue management mechanism, the task processing flow of each thread is standardized. TaskLoop not only ensures the orderly distribution and processing of tasks but also avoids task loss or chaotic processing.

[0078] ThreadPool33 is a key component of the framework. Created by the main thread during Agent initialization, it consists of one or more raw threads, the exact number of which can be dynamically adjusted based on the actual needs of the business logic. Through this thread pool design, the framework achieves efficient reuse of thread resources, avoiding the performance overhead and resource waste caused by frequent thread creation and destruction in traditional multithreaded applications. Furthermore, ThreadPool's standardized management mechanism not only reduces the complexity of multithreaded development but also provides a unified perspective for problem analysis and debugging, facilitating the rapid location and resolution of potential issues. After tasks are distributed to the ThreadPool via TaskLoop, they can be quickly assigned to idle worker threads for execution, ensuring efficient and orderly task processing and providing a more efficient and reliable solution for developing multithreaded applications in complex scenarios.

[0079] Accordingly, when the operating device of the functional module performs the above step S103, such as Figure 2 As shown, the following steps S202 and S203 can also be performed:

[0080] Step S202: In response to finding target data that matches the first input data from the first output data, the main thread is used to convert the obtained target data into a task to be executed and place the task to be executed into the task queue.

[0081] In the embodiments of this application, the data service interface in the first functional module class is called to obtain the first output data. The input data required by the first functional module is matched from the first output data, which is the target data. Then, the main thread is used to convert the obtained target data into a task to be executed. Each input data corresponds to a task to be executed, and then it is placed in the task queue. For example, if the input data is image data, the image data is converted into an image processing task and placed in the task queue.

[0082] In the embodiments of this application, the main thread configured in the base class of the running device of the functional module for business logic processing detects the target data required by the first functional module output by the second functional module. The main thread encapsulates the target data into a task and puts it into the task queue (part of the TaskLoop module). The task queue (part of the TaskLoop module) temporarily stores tasks to be executed, and ensures that tasks can be processed in order.

[0083] In the embodiments of this application, the main thread is only responsible for task creation and scheduling at this stage, and will not participate in specific business logic operations. The fact that the main thread does not participate in specific business logic operations can prevent the main thread from being occupied for a long time, thereby improving the overall response efficiency.

[0084] Step S203: Using the main thread, distribute the tasks to be executed in the task queue to the corresponding worker threads in the thread pool, process them according to the business logic corresponding to the target data in the preset business logic, obtain the task processing result, and determine the task processing result as the second output data.

[0085] In the embodiments of this application, the running device of the functional module uses the main thread to distribute the tasks to be executed in the task queue (part of the TaskLoop module) to the worker threads corresponding to the thread pool for business logic processing set in the base class. The worker threads process the tasks according to the business logic corresponding to the target data in the preset business logic, generate task processing results, and then determine the task processing results as the output data of the second module.

[0086] In the embodiments of this application, tasks in the task queue (part of the TaskLoop module) are sequentially retrieved by the TaskLoop and assigned to idle worker threads in the thread pool for business logic processing set in the base class for processing. Each worker thread executes its task independently without interference, thereby achieving parallel computing. Preset business logic determines how each task is processed, such as executing a specific algorithm or performing data transformation. After task processing is complete, the output result is returned as the output data of the second module to the caller or other modules for use.

[0087] In the embodiments of this application, through a data-driven approach, the module can automatically start and stop its internal business logic based on the presence or absence of data, thereby reducing unnecessary resource consumption. For example, when there is no data available for processing, the module will enter a sleep state until new data arrives, at which point the module will resume operation.

[0088] In the embodiments of this application, the main thread, thread pool, and task queue (part of the TaskLoop module) for business logic processing set in the base class have a close collaborative relationship. Therefore, the first functional module class inheriting from the base class also correspondingly possesses a main thread, thread pool, and task queue. The main thread is responsible for task initialization and scheduling, the task queue (part of the TaskLoop module) serves as an intermediate buffer for storing task information to be processed, and the thread pool is responsible for the parallel execution of specific tasks. This clearly defined architecture achieves higher scalability and stability, making it particularly suitable for large-scale, high-performance software systems.

[0089] In this way, by setting up a main thread and thread pool for handling business logic, and by executing input / output data settings and task distribution operations through the data service interface in the first functional module class, modular business logic processing can be achieved. Due to this modular design approach, the coupling between modules is reduced, flexibility and resource utilization are improved, ultimately resulting in a significant improvement in software development efficiency and runtime performance.

[0090] In some embodiments, when the device operating the functional module performs step S103 as described above, such as Figure 4 As shown, the following steps S401 to S403 can also be performed:

[0091] Step S401: In response to the fact that the target data is not found in the first output data, stop running the business logic task corresponding to the target data in the first functional module.

[0092] In the embodiments of this application, if there is a problem or error in the processing of some business logic in the first output data, resulting in the absence of the target data required by the first functional module in the first output data, then the business logic task corresponding to the target data in the first functional module can be stopped.

[0093] In the embodiments of this application, when the operating device of a functional module attempts to find the target data (e.g., data collected by sensors, intermediate calculation results, etc.) required by the first functional module from the output data of the first module, if the target data cannot be successfully retrieved, it indicates that the preconditions required by the current business logic are not met. At this time, the business logic tasks related to the target data in the first functional module will be actively stopped to avoid invalid calculations and resource waste. The aforementioned method can effectively improve response efficiency and reduce unnecessary computational load.

[0094] In this way, by automatically stopping the relevant logical tasks when the required data cannot be obtained, unnecessary computational overhead can be reduced, overall operating efficiency can be improved, and resource utilization can be optimized and stability enhanced.

[0095] Step S402: Obtain the third output data corresponding to the third functional module that the first functional module depends on through the data service interface in the functional module class; the third output data is the data provided externally by the third functional module through the data service interface in the base class.

[0096] In the embodiments of this application, the operating device of the functional module can obtain the third output data corresponding to the third functional module that the first functional module depends on through the data service interface in the functional module class. The third output data is the data provided externally for the third functional module through the data service interface in the base class. That is, the first functional module not only depends on the output data of the first functional module, but also on the output data of other functional modules, such as the third functional module. Therefore, if the second functional module fails, the first functional module can continue to obtain the output data of other modules. In this way, even if its dependent module fails, the functional module can still operate normally.

[0097] In the embodiments of this application, by using a standard data service interface to obtain data from dependent modules, a loosely coupled communication mechanism between modules is achieved, which improves its maintainability and scalability, speeds up development, and reduces debugging complexity.

[0098] like Figure 5 As shown, a flowchart illustrating the interaction between two functional modules is provided. Figure 5 As shown, AgentA301 and AgentB302 are connected via AgentInf34. AgentInf34 is the core module of the pre-defined functional module development framework for implementing data-driven functionality. It exists as two shared libraries: AgentConsumerInf341 and AgentProviderInf342. In complex systems, each functional module needs to use services or data provided by other functional modules while also providing services or data externally. The design of AgentInf34 fully considers this bidirectional interaction requirement, achieving efficient communication and decoupling between functional modules through standardized data interfaces.

[0099] Among them, AgentConsumerInf341: Other functional modules can easily obtain the services or data provided by this functional module by calling the standardized interface in AgentConsumerInf341. This design makes the dependency between functional modules limited to the data level, avoiding the maintenance complexity and poor scalability problems caused by code coupling in traditional frameworks.

[0100] AgentProviderInf342: When processing data logic, functional modules provide services or data to the outside world through the interface in AgentProviderInf342. This design ensures that functional modules can expose services or data in a unified way, making it easy for other functional modules to call them, while maintaining a high degree of decoupling between service providers and consumers. Figure 5The diagram only shows the interaction between two functional modules, but in reality, it can be the interaction between N functional modules. Each of the N functional modules may interact with any of the other N-1 functional modules, or there may be no interaction at all.

[0101] In the embodiments of this application, AgentInf achieves a high degree of decoupling between functional modules through a data-driven approach. Even if a functional module depends on data provided by other modules, the dependent module will not be blocked when the dependent module is not started or temporarily unavailable, but will continue to operate normally.

[0102] Step S403: Call the execution interface in the first functional module class, and run the first functional module based on the third output data according to the preset business logic.

[0103] In the embodiments of this application, after successfully obtaining the required third output data, the running device of the functional module will call the execution interface in the first functional module class and start the operation of the first functional module based on the third output data according to the preset business logic. Correspondingly, the third output module also contains the data required by the first functional module. If the data is obtained, the business logic related to the data in the preset business logic will be executed.

[0104] In the embodiments of this application, by dynamically calling the module's execution interface based on external data, data-driven module operation control can be achieved, thereby reducing manual intervention and hard-coded logic, and thus improving the intelligence level and adaptability to complex scenarios of the method of dynamically calling the module's execution interface based on external data.

[0105] Thus, the system first determines whether the critical data required for operation is available. If not, the corresponding logical task is stopped to prevent invalid operations. Then, the system obtains the dependent data through a standard interface to ensure the security and consistency of communication between modules. Finally, the control system calls the execution interface based on the obtained data and starts the module operation. The application of step-by-step control not only improves stability and operating efficiency but also enhances scalability and maintainability.

[0106] In some embodiments, after the running device of the functional module performs the above step S203 of "determining the task processing result as the second output data", it may also perform the following steps: using the main thread, the second output data is provided to other functional modules through the data service interface in the base class.

[0107] In the embodiments of this application, the data service interface is a standard interface in the base class used to provide services or data to the outside world. It mainly includes two interfaces: AgentProviderInf and AgentConsumerInf. The running device of a functional module provides AgentConsumerInf to other functional modules through the AgentProviderInf interface. The data service interface realizes data communication and decoupling between modules, ensuring that a module to which the data service interface belongs can use the data or services of another module without depending on specific implementation details. The design approach adopted by the data service interface reduces the coupling between modules and improves flexibility and maintainability. That is, regardless of the logic used to obtain the second output data in the first functional module, other functional modules do not care. Or, if the preset business logic of the first functional module changes, as long as the output data remains unchanged, it will not affect other functional modules, thus reducing the coupling between modules.

[0108] In the embodiments of this application, after a module completes data processing, the main thread is responsible for passing the output data to other functional modules that subscribe to the second output data through a data service interface. The main thread's method of calling the data service interface not only ensures efficient data transfer but also avoids module dependency issues caused by direct calls.

[0109] In the embodiments of this application, it is assumed that a certain functional module completes an image recognition task and uses the image recognition result as the output data of the second module. The main thread publishes the output data of the second module through the data service interface in the base class, allowing other modules, such as the path planning module or the user interface module, to subscribe to and use it. The process of the main thread publishing the output data of the second module through the data service interface in the base class does not require manual intervention; the framework automatically manages this process, which improves the overall automation level and response speed.

[0110] Thus, by calling the data service interface in the base class in the main thread to transmit the second output data, efficient communication and loose coupling between modules can be achieved, thereby improving stability and scalability, and supporting more flexible and complex business scenario requirements.

[0111] In some embodiments, the device running the functional module may also perform the following steps: in response to the existence of target output data in the second output data corresponding to the first functional module that is not dependent on by other modules, stop running the business logic task corresponding to the target output data in the first functional module.

[0112] In the embodiments of this application, when it is detected that there is target output data in the second functional output data corresponding to the first functional module that is not dependent on by other functional modules, the business logic task corresponding to the target output data in the first functional module can be stopped. The mechanism of responding to the existence of target output data in the second functional output data corresponding to the first functional module that is not dependent on by other functional modules is based on a data-driven model, realizing intelligent control of resource usage.

[0113] In the embodiments of this application, the target output data refers to the data generated and output by the second functional module, but the target output data is not subscribed to or used by any other functional module. In other words, no downstream functional module depends on the target output data, so continuing to generate and process the target output data would result in a waste of resources. Therefore, the business logic task corresponding to the target output data in the first functional module can be stopped, which can effectively reduce unnecessary computational overhead and improve overall operating efficiency and resource utilization.

[0114] For example, AgentInf can implement data-driven business logic. When there is data input, the relevant functional modules will automatically start and execute the business logic. Conversely, if there is no data input or no other functional modules call services or data through AgentConsumerInf, AgentInf can also monitor this, and the business logic will automatically pause and no longer occupy resources, thereby effectively reducing performance consumption.

[0115] For example, in an autonomous driving software system, a sensor module (such as LiDAR) sends point cloud data to an image recognition module for obstacle detection. If no subsequent functional module uses the obstacle detection results (such as the path planning module, obstacle avoidance decision module, etc.), the image recognition module can determine that its output data is not relied upon by other modules, and based on this determination, it can stop its own business logic tasks, thereby avoiding resource waste caused by its continuous operation.

[0116] Thus, stopping related business logic tasks when the output data is detected to be independent can reduce unnecessary consumption of computing resources, thereby improving operational efficiency and further enhancing overall performance and sustainability.

[0117] In some embodiments, such as Figure 6 As shown, the device operating the functional module can also perform the following step S601:

[0118] Step S601: In response to the detection that the connection between the first functional module and the second functional module is disconnected, the first functional module is run based on the preset callback function mechanism.

[0119] In the embodiments of this application, AgentInf implements real-time detection of the connection status between modules (such as connection, disconnection, etc.). If the connection status between the first functional module and the second functional module is detected as disconnected, the first functional module is run based on the preset callback function mechanism.

[0120] In the embodiments of this application, when the connection between the first functional module and the second functional module is detected as disconnected, the running device of the functional module can automatically trigger a preset callback function. The callback function is used to control the running logic of the first functional module. The callback function is a programming pattern that allows the first functional module to perform specific operations to maintain the stability of the function of the first functional module or to perform error handling when the external resources on which the first functional module depends are unavailable or the connection is interrupted.

[0121] In the embodiments of this application, the callback function mechanism is designed to ensure that even if the connection is broken, the first functional module can still run independently and continue to execute its business logic. For example, if an image recognition module depends on the data input of another data preprocessing module, and the data preprocessing module is temporarily unable to provide data due to network problems, the image recognition module can enter a self-running mode and continue to perform some computational tasks using local cache or default parameters to avoid being halted due to a single module failure.

[0122] Thus, by introducing a callback function mechanism, the system can intelligently adjust its operating strategy when the connection is broken, giving the first functional module a certain degree of fault tolerance and independence, thereby improving the overall system stability and reliability.

[0123] Accordingly, such as Figure 6 As shown, the device operating the functional module can also perform the following step S602:

[0124] Step S602: In response to the detection that the connection status has changed from disconnected to connected, continue to obtain the first output data through the data service interface in the functional module class.

[0125] In the embodiments of this application, when the connection status changes from disconnected to connected, the original data interaction process will be restored. At this time, the first functional module will resend a request to the second functional module through the data service interface in the functional module class to which the first functional module belongs, in order to obtain the required output data.

[0126] In the embodiments of this application, the fault-tolerant processing mechanism not only restores normal communication between modules but also ensures the continuity of data flow, enabling rapid response to changes in connection status and restoration of normal business logic execution paths. For example, in an autonomous driving system, when the perception module is unable to receive location data due to communication interruption, once communication is restored, the perception module can immediately resubscribe and obtain the latest location information to continue executing subsequent decision-making and control logic.

[0127] In the embodiments of this application, by detecting changes in connection status and dynamically restoring the data interaction process, the continuity and real-time nature of the data flow can be maintained, thereby improving the overall response speed and collaborative efficiency, and enhancing robustness and availability.

[0128] In this way, by detecting changes in connection status and combining them with callback function mechanisms, the automatic start and stop of functional modules and the dynamic recovery of data interaction can be achieved, thereby improving fault tolerance and reducing the risk of runtime crashes caused by module anomalies. This, in turn, can enhance the reliability and flexibility of the software development framework.

[0129] In some embodiments, before performing step S102, the device running the functional module may also perform the following steps: setting the input data and output data corresponding to the target functional module through the data service interface in the target functional module class; the target functional module class is a functional module class created for the target functional module; the target functional module is a second functional module or a third functional module.

[0130] In the embodiments of this application, the target functional module class is a functional module class created for the target functional module. Like the first functional module class mentioned above, the target module class also inherits the base class provided by the preset functional module development framework. The base class is provided with a data service interface for data interaction between modules. Then, the input data and output data corresponding to the target functional module are set through the data service interface in the target functional module class.

[0131] In the embodiments of this application, the data service interface is a set of standardized interfaces provided in the target functional module class, which are used to receive external input data and publish processed output data to the outside world.

[0132] In the embodiments of this application, there is a close relationship between the target functional module class and the data service interface. As part of the target functional module class, the data service interface bears the core responsibility of data exchange between modules, while input and output data are exchanged between modules through the data service interface. Therefore, developers' clear definition of interfaces and data flows during the design phase helps improve overall collaboration efficiency and stability.

[0133] In the embodiments of this application, by adding a step of setting module input and output data before step S102, the data interface of the functional module can be clearly defined during the functional module initialization stage, thereby ensuring smooth communication between modules. Adding a step of setting module input and output data before step S102 can reduce data transmission errors between modules and improve overall stability. Separating the configuration of input and output data from the module class allows developers to focus more on implementing core business logic, improving development efficiency and code reusability. This separation of input and output data configuration from the module class reduces complexity, enhances module independence and replaceability, and further optimizes the software development process.

[0134] In this way, through the cooperation of the target functional module classes and their data service interfaces, standardized management of input and output data is achieved. This design approach not only improves the interoperability between modules but also enhances flexibility and maintainability.

[0135] In some embodiments, the base class is provided with a start interface for initializing modules; when the running device of the functional module performs the above step S101, it can perform the following steps: define the running environment corresponding to the first functional module through the start interface in the first functional module class.

[0136] In the embodiments of this application, the runtime environment includes at least one or more of the following: module parameters, a data receiving queue, and objects in the data service interface. For example, defining the implementation of the runtime environment corresponding to the first functional module could involve implementing the OnBegin() interface in the base class: In the VisualDetection class, developers need to reimplement the OnBegin() interface provided by the base class Agent. The OnBegin() interface is used to initialize the module's runtime environment, such as configuring camera parameters, loading the target detection model, initializing the data receiving queue, initializing its own AgentProviderInf, and AgentConsumerInf objects of other functional modules.

[0137] Accordingly, before executing step S103 above, the device running the functional module may also execute the following steps: call the start interface to initialize the running environment corresponding to the first functional module.

[0138] In the embodiments of this application, calling the start interface refers to actively triggering the execution of the start interface at an appropriate time according to the lifecycle management mechanism of the first functional module, thereby completing the initialization work of the first functional module. The first functional module can ensure that all necessary initialization operations have been completed before entering the main task processing flow, thereby improving reliability and efficiency.

[0139] In the embodiments of this application, by introducing a start interface and defining and initializing the runtime environment before the first functional module starts, it can be ensured that each first functional module has the necessary resources and configuration before running, thereby reducing runtime errors and resource conflicts, and thus improving stability and running efficiency.

[0140] In this way, by defining and initializing the runtime environment through the start interface in the custom framework, the first functional module is equipped with complete running conditions. This design approach can reduce resource conflicts and abnormal situations during operation, and further improve stability and running efficiency.

[0141] In some embodiments, the base class is provided with an exit interface for releasing module resources; when the running device of the functional module performs the above step S101, it can perform the following steps: define the system resources corresponding to the first functional module through the exit interface in the first functional module class.

[0142] In the embodiments of this application, the exit interface refers to a set of methods defined in the base class for cleaning up and releasing system resources occupied during module operation. The exit interface typically includes functions such as shutting down the device, releasing memory, and disconnecting. Through a unified exit interface design, it can be ensured that each functional module can perform resource reclamation operations in a standardized manner upon exiting, avoiding resource leaks or abnormal residues.

[0143] In the embodiments of this application, an exit interface is set in the base class to uniformly manage the exit behavior of various functional modules. This approach reduces the need for developers to repeatedly write resource release logic, thereby improving development efficiency and code maintainability, and further reducing the risk of performance problems or system crashes caused by improper resource release during software operation.

[0144] For example, system resources refer to various computer resources used during the operation of a functional module, including but not limited to module parameters (such as configuration items), module memory space (such as dynamically allocated memory areas), and objects in data service interfaces (such as database connections, network communication objects, etc.). For instance, during the initialization phase of module development, developers may declare and register system resources by calling the exit interface so that system resources can be automatically released when the module exits.

[0145] For example, the implementation of the system resources corresponding to the first functional module can be defined as follows: Implement the exit interface OnEnd() in the base class: In the VisualDetection class, the developer needs to reimplement the OnEnd() provided by the base class Agent. The OnEnd() interface is used to release the resources occupied by the module, such as turning off the camera, clearing memory space, and releasing AgentProviderInf and AgentConsumerInf objects, to ensure that system resources can be properly managed when the module exits.

[0146] In the embodiments of this application, by binding the first functional module class to the exit interface and defining specific system resources inside the first functional module class, explicit management and lifecycle control of module resources can be achieved. This can avoid memory leaks or other potential problems caused by resources not being properly released when the module exits, thereby improving system stability and resource utilization, and thus enhancing overall operating efficiency and security.

[0147] Accordingly, the device running the functional module can also perform the following steps: in response to the exit of the first functional module, call the exit interface to release the system resources of the first functional module.

[0148] In the embodiments of this application, when the first functional module receives an exit instruction (e.g., application termination, user-initiated module closure, automatic exit after task completion), it can trigger an exit process and call the previously defined exit interface to release the system resources occupied by the module in sequence, such as turning off the camera, destroying memory objects, and disconnecting the database connection. The process of the first functional module triggering the exit process and calling the exit interface to release system resources after receiving the exit instruction is usually executed automatically without manual intervention.

[0149] In the embodiments of this application, by calling the exit interface when a module exits, it can be ensured that all registered system resources are released in a timely and orderly manner. Calling the exit interface when a module exits avoids wasting system resources, thereby reducing unnecessary resource consumption and performance overhead, and further improving the overall operational efficiency and stability of the framework.

[0150] In this way, an exit interface is set in the base class as a unified entry point for resource release. The first functional module class defines the system resources required by the module through the exit interface, and automatically calls the exit interface to release resources when the first functional module exits. The exit interface in the base class, the exit interface definition in the first functional module class, and the process of calling the exit interface to release resources when the first functional module exits work together to form a complete resource management mechanism. This mechanism not only improves the standardization and automation of resource management, but also enhances the stability and scalability of the system.

[0151] For example, such as Figure 7 As shown, a flowchart for developing functional modules based on a base class framework is provided, including steps S701 to S704:

[0152] Step S701: Define the VisualDetection class, which inherits from the base class Agent.

[0153] Here, developers need to create a class named VisualDetection and make it inherit from the base class Agent provided by the framework. After inheriting the base class, the VisualDetection class will automatically acquire the core functionalities of the Agent framework, including basic capabilities such as thread management, task distribution, and data-driven logic, thus laying the foundation for subsequent feature development.

[0154] Step S702: The VisualDetection class reimplements the start interface OnBegin() and the exit interface OnEnd() in the base class.

[0155] Here, in the VisualDetection class, developers need to reimplement two key interfaces provided by the base class Agent: OnBegin() and OnEnd(). The OnBegin() interface is used to initialize the module's runtime environment; the OnEnd() interface is used to release the resources occupied by the module.

[0156] Step S703: The VisualDetection class implements its own business logic and actually provides the AgentInf to the outside world, referencing the AgentInf of the external functional module.

[0157] Here, developers need to implement specific business logic in the VisualDetection class. The VisualDetection module needs to obtain data through AgentConsumerInf and provide services or data to the outside world through AgentProviderInf.

[0158] Step S704: The VisualDetection class calls the base class interface Work() to begin working.

[0159] Here, the base class interface `Work()` is called to begin work: Developers start the VisualDetection module by calling the `Work()` interface provided by the base class `Agent`. The `Work()` interface is responsible for initializing the task loop and distributing the module's business logic tasks to the main thread or thread pool for execution. Through the `Work()` interface, the module can start running according to preset logic and automatically manage the start and stop of tasks in a data-driven manner.

[0160] Based on the software development framework (pre-defined functional module development framework) provided in this application embodiment, functional modules can be developed according to a predefined fixed process, ensuring consistency and standardization in development. The inputs and outputs of each functional module are separated into independent library files (output data and input data), simplifying interaction between modules and improving module independence and reusability. Internal business logic automatically starts and stops based on the availability of input data; conversely, if no downstream module uses the output data, the business logic also stops running, further enhancing flexibility and efficiency.

[0161] In the embodiments of this application, a templated development process standardizes the structure and interface of each functional module, simplifying the development process. Independent input and output library files make data transfer clearer and more efficient, reducing coupling between modules. Internal business logic automatically starts and stops based on the validity of input data and whether output data is being used. For example, when data from a certain sensor is temporarily unavailable, the relevant processing module can automatically enter a sleep state; when no downstream module subscribes to process the output data of this module, this module automatically stops related logical operations. This reduces unnecessary computation and resource consumption, improving not only response speed but also overall computational resource consumption and energy efficiency.

[0162] This application provides a method for running a functional module. The method includes: creating a first functional module class corresponding to a first functional module; the first functional module class inheriting from a base class provided by a preset functional module development framework; the base class setting a data service interface for data interaction between modules and an execution interface for executing business logic within the module; obtaining first output data corresponding to a second functional module that the first functional module depends on through the data service interface in the first functional module class; the first output data being data provided externally for the second functional module through the data service interface in the base class; and calling the execution interface in the first functional module class to run the first functional module according to preset business logic based on the first output data. The method provided in this application first constructs a first functional module class by inheriting from a base class, enabling it to have standard data interaction and execution interfaces, thereby achieving a standardized development process. Second, obtaining the output data of dependent modules through the data service interface eliminates the need for manual configuration or debugging of inter-module communication, simplifying the development and maintenance process. Finally, execution based on preset business logic improves maintainability and flexibility. Compared to existing technologies, this solution reduces control logic complexity, lowers resource consumption, and improves the decoupling degree between modules through a data-driven approach.

[0163] This application provides an embodiment of a functional module operating device 8, such as... Figure 8 As shown, it includes:

[0164] Create module 81, which is used to create the first functional module class corresponding to the first functional module; the first functional module class inherits from the base class provided by the preset functional module development framework; the base class sets up the data service interface for data interaction between modules, as well as the execution interface for executing business logic within the module;

[0165] The acquisition module 82 is used to acquire the first output data corresponding to the second functional module that the first functional module depends on through the data service interface in the first functional module class; the first output data is the data provided externally for the second functional module through the data service interface in the base class.

[0166] Module 83 is used to call the execution interface in the first functional module class and run the first functional module according to the preset business logic and based on the first output data.

[0167] In one embodiment of this application, the base class is configured with a main thread and a thread pool for business logic processing; the creation module 81 is further configured to set the first input data and the second output data corresponding to the first functional module through the data service interface in the first functional module class; the calling module 83 is further configured to respond to finding target data matching the first input data from the first output data, using the main thread to convert the obtained target data into a task to be executed, and placing the task to be executed into a task queue; using the main thread to distribute the task to be executed in the task queue to the worker thread corresponding to the thread pool, process it according to the business logic corresponding to the target data in the preset business logic, obtain the task processing result, and determine the task processing result as the second output data.

[0168] In one embodiment of this application, the calling module 83 is further configured to, in response to the failure to find the target data in the first output data, stop running the business logic task corresponding to the target data in the first functional module; obtain the third output data corresponding to the third functional module on which the first functional module depends through the data service interface in the functional module class; the third output data is the data provided externally for the third functional module through the data service interface in the base class; and call the execution interface in the first functional module class to run the first functional module based on the third output data according to the preset business logic.

[0169] In one embodiment of this application, the acquisition module 82 is further configured to use the main thread to provide the second output data to other functional modules through the data service interface in the base class.

[0170] In one embodiment of this application, the acquisition module 82 is further configured to stop running the business logic task corresponding to the target output data in the first functional module in response to the existence of target output data that is not depended on by other modules in the second output data corresponding to the first functional module.

[0171] In one embodiment of this application, the acquisition module 82 is further configured to, in response to detecting that the connection status between the first functional module and the second functional module is disconnected, run the first functional module based on a preset callback function mechanism; and in response to detecting that the connection status changes from disconnected to connected, continue to acquire the first output data through the data service interface in the functional module class.

[0172] In one embodiment of this application, the acquisition module 82 is further configured to set the input data and output data corresponding to the target functional module through the data service interface in the target functional module class; the target functional module class is a functional module class created for the target functional module; the target functional module is a second functional module or a third functional module.

[0173] In one embodiment of this application, the base class is provided with a start interface for initializing the module; the creation module 81 is also used to define the running environment corresponding to the first functional module through the start interface in the first functional module class; the calling module 83 is also used to call the start interface to initialize the running environment corresponding to the first functional module; wherein, the running environment includes at least one or more of the following: module parameters, data receiving queue, and objects in the data service interface.

[0174] In one embodiment of this application, the base class is provided with an exit interface for releasing module resources; the creation module 81 is also used to define the system resources corresponding to the first functional module through the exit interface in the first functional module class; the calling module 83 is also used to call the exit interface in response to the exit of the first functional module to release the system resources of the first functional module; wherein, the system resources include at least one or more of the following: module parameters, module memory space, and objects in the data service interface.

[0175] Figure 9 This is a schematic diagram of the structure of a functional module operating device 9 provided in an embodiment of this application. In practical applications, based on the same disclosed concept of the above embodiments, such as... Figure 9 As shown, the operating device 9 of the functional module in this embodiment includes: a processor 91, a memory 92, and a communication bus 93.

[0176] Communication bus 93 is used to realize the communication connection between processor 91 and memory 92;

[0177] The processor 91 is used to execute the computer program stored in the memory 92 to implement the operation method of the above-mentioned functional modules.

[0178] This application provides a computer-readable storage medium storing a computer program thereon. The computer-readable storage medium stores one or more programs, which can be executed by one or more processors and applied in a parking space positioning device in a parking scenario. The computer program implements the data processing method described above.

[0179] This application provides a computer program product, including a computer program or instructions, which, when executed by a processor 91, implement the data processing method described above.

[0180] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0181] This application is described with reference to flowchart illustrations and block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and block diagrams, as well as combinations of blocks in the flowchart illustrations and block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0182] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and boxes Figure 1 The function specified in one or more boxes.

[0183] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and boxes Figure 1 The steps of the function specified in one or more boxes.

[0184] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of protection.

Claims

1. A method for operating a functional module, characterized in that, The method includes: Create a first functional module class corresponding to the first functional module; the first functional module class inherits from the base class provided by the preset functional module development framework; the base class is provided with a data service interface for data interaction between modules, and an execution interface for executing business logic within the module; The data service interface in the first functional module class is used to obtain the first output data corresponding to the second functional module that the first functional module depends on. The first output data is the data provided to the outside by the second functional module through the data service interface in the base class. The data service interface is used for data input and output operations between modules, allowing the first functional module to obtain data from other dependent functional modules, and the first functional module to provide data to other functional modules, so that the modules can exchange data through the data service interface. Call the execution interface in the first functional module class, and run the first functional module based on the first output data according to the preset business logic; In response to the existence of target output data in the second output data corresponding to the first functional module that is not dependent on by other modules, the business logic task corresponding to the target output data in the first functional module is stopped.

2. The method for operating the functional module according to claim 1, characterized in that, The base class includes a main thread and a thread pool for processing business logic; the first functional module class corresponding to the creation of the first functional module includes: The first input data and the second output data corresponding to the first functional module are set through the data service interface in the first functional module class. Accordingly, the step of calling the execution interface in the first functional module class and running the first functional module based on the first output data according to preset business logic includes: In response to finding target data matching the first input data from the first output data, the main thread is used to convert the acquired target data into a task to be executed and place the task to be executed into a task queue. Using the main thread, the tasks to be executed in the task queue are distributed to the worker threads corresponding to the thread pool, and processed according to the business logic corresponding to the target data in the preset business logic to obtain the task processing result, and the task processing result is determined as the second output data.

3. The method for operating the functional module according to claim 2, characterized in that, The step of calling the execution interface in the first functional module class and running the first functional module based on the first output data according to the preset business logic includes: In response to the fact that the target data is not found in the first output data, the business logic task corresponding to the target data in the first functional module is stopped from running; The third output data corresponding to the third functional module that the first functional module depends on is obtained through the data service interface in the functional module class; the third output data is the data provided externally for the third functional module through the data service interface in the base class. The execution interface in the first functional module class is invoked, and the first functional module is run according to the preset business logic and based on the third output data.

4. The method for operating the functional module according to claim 2, characterized in that, After determining the task processing result as the second output data, the method further includes: Using the main thread, the second output data is provided to other functional modules through the data service interface in the base class.

5. The method for operating the functional module according to claim 1, characterized in that, The method further includes: In response to the detection that the connection between the first functional module and the second functional module is disconnected, the first functional module is run based on a preset callback function mechanism; In response to detecting that the connection status has changed from disconnected to connected, the first output data is obtained through the data service interface in the functional module class.

6. The method for operating the functional module according to any one of claims 1 to 5, characterized in that, Before obtaining the first output data corresponding to the second functional module that the first functional module depends on through the data service interface in the first functional module class, the method further includes: The input and output data corresponding to the target functional module are set through the data service interface in the target functional module class; the target functional module class is a functional module class created for the target functional module; the target functional module is a second functional module or a third functional module.

7. The method for operating the functional module according to any one of claims 1 to 5, characterized in that, The base class includes a start interface for initializing modules; the first functional module class corresponding to the creation of the first functional module includes: The runtime environment corresponding to the first functional module is defined through the start interface in the first functional module class; Accordingly, before calling the execution interface in the first functional module class and running the first functional module based on the first output data according to preset business logic, the method further includes: Call the start interface to initialize the runtime environment corresponding to the first functional module; The operating environment includes at least one or more of the following: module parameters, data receiving queue, and objects in the data service interface.

8. The method for operating the functional module according to any one of claims 1 to 5, characterized in that, The base class includes an exit interface for releasing module resources; the first functional module class corresponding to the creation of the first functional module includes: The system resources corresponding to the first functional module are defined through the exit interface in the first functional module class; Accordingly, the method further includes: In response to the exit of the first functional module, the exit interface is invoked to release the system resources of the first functional module; The system resources include at least one or more of the following: module parameters, module memory space, and objects in the data service interface.

9. A device for operating a functional module, characterized in that, The operating device for the functional module includes: A module is created to create a first functional module class corresponding to the first functional module; the first functional module class inherits from a base class provided by a preset functional module development framework; the base class is provided with a data service interface for data interaction between modules and an execution interface for executing business logic within the module; The acquisition module is used to acquire first output data corresponding to the second functional module that the first functional module depends on through the data service interface in the first functional module class; the first output data is data provided externally for the second functional module through the data service interface in the base class; the data service interface is used for data input and output operations between modules, allowing the first functional module to acquire data from other dependent functional modules, and the first functional module to provide data to other functional modules, so that the modules can exchange data through the data service interface; The calling module is used to call the execution interface in the first functional module class and run the first functional module according to the preset business logic and based on the first output data; In response to the existence of target output data in the second output data corresponding to the first functional module that is not dependent on by other modules, the business logic task corresponding to the target output data in the first functional module is stopped.

10. A device for operating a functional module, characterized in that, The device for operating the functional module includes a processor, a memory, and a communication bus; when the processor executes the running program stored in the memory, it implements the method for operating the functional module as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more computer programs, which are executed by one or more processors to implement the method of operating the functional module according to any one of claims 1 to 8.

Images