Automatic driving control system and control method thereof

Abstract

The invention provides an automatic driving control system and a control method thereof. The system comprises a calling interface for abstracting an external service function through a service interface set, a service implementation module provides a multi-platform adaptation instance, and a service locator module dynamically binds the adaptation instance, an interface and a platform type, so that an automatic driving service module is implemented only by depending on a virtual interface instead of a specific platform. And decoupling of the business logic and the platform service is effectively realized.

Description

Technical Field

[0001] This disclosure relates to the field of autonomous driving technology, and in particular to an autonomous driving control system and control method thereof. Background Technology

[0002] Autonomous driving systems rely on numerous software modules to achieve perception, decision-making, and control. These modules typically run on different hardware platforms and operating systems; for example, vehicles use Linux during road testing, while mass-produced vehicles use the QNX safety system. Different systems require different implementation services from their modules, leading to strong coupling between modules and their corresponding implementation services, which hinders system migration and compatibility. Summary of the Invention

[0003] In view of this, the purpose of this disclosure is to provide an autonomous driving control system and control method thereof to solve the problem of poor portability caused by the strong coupling between various intelligent modules and external service functions in existing autonomous driving systems.

[0004] In a first aspect, embodiments of this disclosure provide an autonomous driving control system, including: A set of service interfaces, used to call external service functions related to the platform during autonomous driving control; The service implementation module includes several adaptation implementation examples, which are used to define the functions of the service interface set according to the target platform or target operating mode. The service locator module stores the binding relationship between each adaptation implementation instance and the sum of the service interface set and the platform type. The binding relationship is obtained by extracting access records of external service functions from the historical control data of autonomous driving to construct adaptation implementation instances, and binding the constructed adaptation implementation instances with the service interface set and the platform type. The autonomous driving business module is used to trigger the service locator module to match the target adaptation implementation example by calling the service interface set, and to call the matched external service functions to control each intelligent module to complete the autonomous driving task.

[0005] Secondly, embodiments of this disclosure provide a control method based on the above-described automated driving control system, the method comprising: When starting autonomous driving control, the platform type of the current platform is identified, and the target adaptive implementation instance is determined based on the binding relationship between the adaptive implementation instance and the sum of the service interface set and the platform type. The target adaptation implementation example is analyzed to adjust the calling protocol relationship between each intelligent module and each virtual interface in the service interface set; It controls the operation of each intelligent module and calls external service functions based on the adjusted calling protocol relationship to work with each intelligent module to complete the autonomous driving task.

[0006] Thirdly, embodiments of this disclosure provide a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are invoked and executed by a processor, the computer-executable instructions cause the processor to implement the control method provided above.

[0007] The embodiments disclosed herein bring the following beneficial effects: The aforementioned autonomous driving control system and its control method abstract the calling interface of external service functions through a service interface set. The service implementation module provides multi-platform adaptation instances, and the service locator module dynamically binds the adaptation instances with interfaces and platform types. This enables the autonomous driving business module to rely only on virtual interfaces rather than specific platform implementations, effectively decoupling business logic from platform services.

[0008] Meanwhile, the binding relationship built through historical control data ensures accurate matching between the adapted instance and the platform requirements, significantly improves the portability of the system across different platforms, reduces the code modification cost of cross-platform deployment, and supports seamless connection when switching platforms, ensuring the continuity and stability of autonomous driving control tasks.

[0009] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objects and other advantages of this disclosure are realized and obtained through the structures particularly pointed out in the description, claims and drawings.

[0010] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the specific embodiments of this disclosure or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of one embodiment of the autonomous driving control system in this disclosure; Figure 2 A flowchart illustrating one embodiment of a control method based on an autonomous driving control system provided in this disclosure; Figure 3This is a schematic diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0014] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure, claims, and accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” or “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0015] For ease of understanding, the specific structure of the embodiments of this disclosure is described below. The embodiments of this disclosure are applied to autonomous vehicles, which can be equipped with at least two platforms, such as the common Linux platform and the QNX platform. The existence of two different types of platforms is mainly because development, testing and mass production are implemented using different platforms. Although the autonomous driving framework can be ported to the platform used for mass production after successful development and testing, they are still two different platforms, and problems such as lack of support for certain services or incompatibility are inevitable. To solve these problems, additional plugins or adaptation settings need to be set up separately, which greatly improves the subsequent mass production process.

[0016] Therefore, this application provides an autonomous driving control system that can be applied to both development and testing, and directly to mass production, avoiding the problem of binding and coupling between intelligent modules and the platform's external service functions. Please refer to... Figure 1 One embodiment of the autonomous driving control system disclosed herein includes: Service interface set 110 is used as an interface for calling external service functions related to the platform during autonomous driving control; The service implementation module 120 includes several adaptation implementation examples, which are used to define the functions of the service interface set according to the target platform or target operating mode. The service locator module 130 stores the binding relationship between each adaptation implementation instance and the sum of the service interface set and the platform type. The binding relationship is obtained by extracting access records of external service functions from the historical control data of autonomous driving to construct adaptation implementation instances, and binding the constructed adaptation implementation instances with the service interface set and the platform type. The autonomous driving business module 140 is used to trigger the service locator module to match the target adaptation implementation example by calling the service interface set, and to call the matched external service functions to control each intelligent module to complete the autonomous driving task.

[0017] It should be noted that the service interface set 110 is actually composed of multiple virtual interfaces. Each virtual interface corresponds to an external service function, which includes log service function, time service function, error reporting service function and performance analysis service function. The corresponding virtual interface is constructed for each service function using the abstract definition method.

[0018] In one implementation, the service interface set 110 consists of multiple virtual interfaces that are abstracted from external service functions and have no concrete implementation code. These virtual interfaces include, but are not limited to, the following types of interfaces: The log service virtual interface 111 is obtained by extracting the log access protocols of the log service function for different platforms and abstracting and defining a log writing method. The virtual interface 112 for time service is obtained by extracting the time service function for different platforms' time synchronization protocols and abstracting a method to get the current time. Error reporting service virtual interface 113 is obtained by extracting the exception reporting protocol for different platforms from the exception feedback service function and abstracting and defining an exception reporting method. The performance analysis service virtual interface 114 is obtained by extracting the analysis rules of the performance analysis service function for different platforms and abstracting and defining a method for recording time consumption.

[0019] In practical applications, the number and type of external functional services required by each intelligent module during control vary depending on the task. This application mainly targets autonomous driving scenarios. Specifically, it first collects a list of external service functions that need to be called in autonomous driving tasks, such as logging, time synchronization, error reporting, and performance analysis. Then, it analyzes the specific requirements of each service function on different platforms (Linux, QNX, simulation) (such as log storage permissions, time accuracy requirements, and exception reporting priority).

[0020] Furthermore, after extracting the required external service functions, the virtual interface is set up using the abstract definition method. Its core principle is to abstract the specific implementation protocols of different platforms for the same external service into a unified interface without platform dependence through the three-step method of "protocol commonality extraction - difference isolation - interface method design". This allows business modules to call services only through the interface definition without having to pay attention to the implementation details of specific platforms.

[0021] Specifically, the protocol extraction for the log service function, time service function, error reporting service function, and performance analysis service function is as follows: Log service functions: extract Linux's syslog interface (path: / var / log), QNX's controlled audit interface (security partition: / secure / logs), and simulated memory queue storage protocol; Time service function: Extracts Linux's CLOCK_REALTIME clock (precision: milliseconds), QNX's kernel clock (precision: microseconds), and the simulation's virtual time step (step size: 100ms configurable). Error reporting service function: Extract the Linux DBus message format ({code: "ERR_001", detail: "timeout"}), QNX message passing protocol (including security check fields), and simulation interface marking rules (red highlighting of abnormal modules); Performance analysis service functions: extracting Linux's perf tool interface (statistics the time difference from start to end), QNX's Momentics tracing interface (recording module ID and time consumption), and simulation framework time consumption statistics rules (traversing module execution timestamps).

[0022] For the protocols extracted from each of the above service functions, we perform commonality extraction, difference isolation, and interface method design to obtain the corresponding virtual interfaces. The following example illustrates this using the virtual interface abstraction of the log service function: Step 1, Platform Protocol Analysis; Linux platform: Write log files (path: / var / log / syslog) through the syslog interface. You need to specify the log level (such as LOG_INFO), content (string), and context (such as module name). QNX Platform: Write to the security log partition (path: / secure / logs / control.log) through the controlled audit interface. The log level (e.g., SECURITY), content (including anti-tampering checksum), and context (e.g., task ID) must be recorded. Simulation platform: Stores log content into an in-memory queue (such as std::queue). <std::string>It is necessary to record the level (e.g., SIM_DEBUG), content (e.g., "5th frame point cloud data"), and context (e.g., simulation time step).

[0023] Step 2, commonality extraction; All platforms' log services must support the following features: Record the "severity" (level) of the log; Record the "core content" of the log (such as data volume and exception details); Record the "associated context" of the log (such as module name and time step).

[0024] Step 3, Interface method design; Define the write_log method of the virtual interface, with parameters including the common elements mentioned above.

[0025] Step 4, differential isolation; The QNX platform-compatible instance calls the controlled audit interface in write_log and automatically adds anti-tampering verification codes; The Linux platform-compatible instance calls the syslog interface to write content to the / var / log directory; The simulation platform's adapted instance pushes the content into a memory queue for subsequent playback verification.

[0026] In one implementation, the service implementation module 120 includes: Linux platform adaptation implementation example 121, QNX platform adaptation implementation example 122, and simulation platform adaptation implementation example 123.

[0027] Understandably, each platform adaptation implementation example is obtained through the following steps: Step 1: Identify the target platform type; Determine the platform types (e.g., Linux_standard, QNX_safety, Simulation) and operating modes (e.g., real vehicle, simulation) that need to be supported. Collect technical documentation for each platform (such as QNX's "Secure Operating System Development Guide" and Linux's syslog interface specification) to clarify the access methods for external services.

[0028] Step 2: Adaptation and implementation example development; Step 3: Adaptation instance compatibility testing; Verify that the adapted implementation instance fully implements all methods of the virtual interface; Verify the functionality of the adaptation instance, such as whether the logs written by the QNX instance are stored in the security partition, and whether the logs of the simulation instance are stored in the memory queue. Verify performance metrics, such as the log write latency of the QNX instance being ≤10ms, to meet the real-time requirements of autonomous driving.

[0029] Step 4: Register the adapted instance.

[0030] The tested and compatible instances are encapsulated into a dynamic link library; Register instance metadata in the service implementation module, which includes supported platform types, service interface types, and dynamic library paths.

[0031] After the above steps, the Linux platform adaptation implementation example records at least one external service access instance that writes to the system log file via the syslog interface, obtains real-time time by calling clock_gettime, sends it to the system monitoring process via DBus, and records the time-consuming external service access by calling the perf tool interface; the QNX platform adaptation implementation example records at least one external service access instance that writes to the security log partition via the QNX controlled audit interface, obtains real-time time based on the QNX kernel clock, sends it to the security monitoring module via the QNX message passing mechanism, and records the time-consuming external service access by calling the tracing interface of the QNX Momentics toolchain; the simulation platform adaptation implementation example records at least one external service access instance that stores content in a memory queue, generates virtual timestamps in configurable steps, marks and displays abnormal processes on the simulation monitoring interface, and records the time-consuming external service access by statistically analyzing the execution time of modules within the simulation framework.

[0032] In practical applications, the various adaptation implementations of the service implementation module 120 can also be modularly encapsulated. Specifically, each adaptation implementation is independently compiled into a dynamic link library (.so or .dll), exposing only the concrete implementations of the abstract methods defined in the service interface set. The module supports dynamic loading and unloading: during loading, the module is loaded into memory through the operating system's dynamic link library loading function (such as dlopen in Linux and ldload in QNX) and registered to the service locator module; during unloading, resources are released through dlclose or ldunload and removed from the mapping table of the service locator module. Through this encapsulation method, adaptation implementations for different platforms can be independently developed, tested, and upgraded without modifying the code of other modules.

[0033] In one implementation, the binding relationships in the service locator module 130 are stored as a structured mapping table, which includes the following fields: Service interface type, such as "log service interface" or "time service interface"; Platform / mode identifiers, such as "linux_standard", "qnx_safety", and "simulation"; An adapter instance pointer, used to point to a specific instance of the corresponding service implementation module; The mapping table is generated during the system initialization phase by parsing a configuration file, which is in JSON format.

[0034] Furthermore, the matching logic of the service locator module 130 is as follows: When the autonomous driving business module calls the service interface, it first obtains the identifier of the current target platform or operating mode, such as "qnx_safety" through system environment variables or external instructions; Then, based on the service interface type (such as "log service interface") and platform / mode identifier (such as "qnx_safety"), the corresponding adapter implementation instance pointer (such as "QnxSafeLogImpl" instance) is found in the mapping table. If the search is successful, the corresponding adaptation implementation instance is returned for the business module to call; if the search fails, the default processing logic is triggered, such as falling back to the general adaptation implementation instance or reporting an error.

[0035] In one implementation, the binding relationship in the service locator module 130, in addition to the platform type-based setting mentioned above, also includes a setting based on the operating mode. The operating modes include real-vehicle deployment, simulation testing, and software-in-the-loop simulation. The logic for implementing the binding of the adaptation example based on each operating mode is as follows: Real-vehicle deployment mode: The platform is identified as "qnx_safety" or "linux_standard", and the service locator module matches the corresponding platform's adaptation implementation example, such as QNX security log implementation or Linux real-time time implementation; Simulation test mode: The platform is identified as "simulation" and matches simulation adaptation implementation examples, such as simulated logs and virtual time; Software-in-the-loop simulation mode: The platform is identified as "sil_test" and matches a dedicated SIL adaptation example, such as a time service based on sensor data playback and a log service that supports offline analysis; Mode switching is achieved by modifying system environment variables or sending mode switching commands. The service locator module 130 automatically matches the corresponding adaptation implementation example based on the new identifier.

[0036] In one embodiment, the intelligent module includes a perception module, a prediction module, a decision-making module, and a control module; The autonomous driving service module 140 is specifically used for: Identify the platform currently running the autonomous driving task, and match the target adaptation implementation example based on the platform control service locator module 130; Based on the example in the target adaptation implementation example, the control perception module calls the time service virtual interface in the service interface set to obtain the receiving timestamp of the LiDAR point cloud data, and calls the log service virtual interface to record the quantity and quality information of the perception data. Based on the example in the target adaptation implementation example, the control prediction module calls the performance analysis service virtual interface to record the execution time of the traffic participant behavior prediction algorithm, and calls the error reporting service virtual interface to report prediction failure exceptions. Based on the example in the target adaptation implementation example, the control decision module calls the time service virtual interface to synchronize the timestamps of multiple sensors, and calls the log service interface to record the path planning results; Based on the example in the target adaptation implementation example, the control module calls the error reporting service virtual interface to report executor control command exceptions, and calls the performance analysis service virtual interface to record the time taken to generate control commands.

[0037] Understandably, the autonomous driving business module 140 triggers the service locator module 130 to match and adapt instances by calling the service interface set, thereby controlling the intelligent module to complete the task. The specific implementation steps are as follows: Step 1: Determine the platform type; After the system starts up, the current platform type, such as "QNX_safety", can be obtained through the vehicle operating system, such as the get_platform_type() function of QNX. If the platform type changes dynamically, such as switching from Linux to QNX, the system receives the platform change command and updates the current platform type.

[0038] Step 2: Service interface call triggered; Based on the requirements of the autonomous driving task, the virtual interfaces in service interface set 110 are called. For example, when the perception module needs to record logs, LogService::write_log() is called. When making the call, only the parameters defined by the interface are passed, such as log level, content, and context, without involving the specific platform implementation.

[0039] Step 3: Service locator module matching and instance invocation; Based on the current platform type and service interface type, such as LogService, find the appropriate instance from the binding relationship mapping table, such as QnxSafeLogImpl; If multiple compatible instances exist, such as redundant backups, select the primary instance according to priority, such as QnxSafeLogImpl with priority 1. Call the specific methods of the adapted instance, such as QnxSafeLogImpl::write_log(), to complete the execution of external service functions.

[0040] Step 4: Task execution monitoring and exception handling.

[0041] Monitor the task execution status of the intelligent module, such as whether the sensing module has successfully obtained the timestamp; If the service call fails, such as when the adaptation instance crashes, the following processing logic will be triggered: The service locator module is switched to a standby instance, such as LinuxBackupLogImpl with priority 2. The business module reports "service instance error" through the error reporting service virtual interface; If all instances fail, degrade the operation, such as pausing high-precision tasks and maintaining only basic control.

[0042] The autonomous driving control system provided by the above implementation method, by abstracting service interfaces, defining multi-platform adaptation implementation examples, and dynamically binding service interfaces and platform adaptation instances, enables autonomous driving business modules to rely only on abstract interfaces without directly associating with specific platform services, thereby reducing the code modification cost of cross-platform deployment and improving the system's portability, maintainability, and multi-scenario adaptability.

[0043] Corresponding to the embodiments of the above-described automatic driving control system, this application also provides a corresponding control method, such as... Figure 2 As shown, the method includes: S210, when starting autonomous driving control, identify the platform type of the current platform, and determine the target adapter implementation instance based on the platform type from the binding relationship between the adapter implementation instance and the sum of the service interface set and the platform type; Understandably, platform type identification is a prerequisite for matching and adapting instances. It requires a comprehensive assessment of the currently running platform type through hardware identifiers, software characteristics, and environmental variables. Among these, hardware characteristics are determined by reading the hardware information of the onboard computing unit. For example, NVIDIA Orin chips are typically used in real-world autonomous driving domain controllers and may correspond to the QNX_safety or Linux_standard platform; the hardware information of the simulation server contains the keyword "simulation," corresponding to the Simulation platform.

[0044] Software characteristics identify platform types through operating system kernel identifiers, process lists, or file system characteristics; for example, the kernel version of a QNX system contains the QNX Neutrino field, has a / proc / partitions security partition file, and critical processes run in microkernel mode; the kernel version of a Linux system contains the Linux field, has a / var / log / syslog log file, and critical processes are managed by systemd; the simulation platform has a simulation framework process, and the environment variable contains SIMULATION_MODE=1.

[0045] The configuration file identifier is obtained by reading the platform configuration file in the vehicle's non-volatile memory during system startup and directly obtaining the predefined platform type.

[0046] In this embodiment, the binding relationship between the adaptation implementation instance and the service interface and platform type is stored in a structured manner. Based on this, when matching a target adaptation implementation instance, the service locator module queries based on the identified platform type and the type of the service interface being called. Specifically: First, match the service interface with the platform type; Find the binding entries in service_bindings where interface equals the target interface and platform equals the current platform.

[0047] Then, select available instances according to priority; Iterate through the list of implementations for the bound entries, filtering instances in ascending order of priority that are active. If the primary instance is in a down state, then select a backup instance as the fallback.

[0048] S220, Analyze the target adaptation implementation example and adjust the calling protocol relationship between each intelligent module and each virtual interface in the service interface set; Understandably, by parsing the metadata of the target adaptation instance, such as parameter constraints, data formats, and exception code mappings, the protocol details of the intelligent module's call to the virtual interface, such as parameter type conversion, data encapsulation rules, and exception handling logic, are dynamically adjusted to ensure that the intelligent module's calling behavior is fully matched with the implementation requirements of the adaptation instance, ultimately achieving the correctness and reliability of cross-platform service calls.

[0049] When parsing the target instance, the metadata file of the target instance is first loaded, then the metadata is parsed and the protocol rules are stored. Finally, based on the parsed protocol rules, the behavior of the module calling the virtual interface is dynamically adjusted to ensure that it meets the requirements of the target instance.

[0050] S230 controls the operation of each intelligent module and, based on the adjusted calling protocol, calls external service functions to work with each intelligent module to complete the autonomous driving task.

[0051] Specifically, through a hybrid scheduling mechanism of "time-triggered + event-triggered", priorities are allocated and execution cycles or triggering conditions are set according to the dependencies and real-time requirements of module functional levels (perception, localization, decision-making, and control) to ensure that modules run in sequence. During task execution, from the initialization phase, which completes module loading, service binding (matching platform adaptation instances), and call protocol adjustment (based on adaptation instance metadata constraint parameters, exception mapping, etc.), to the cyclic execution phase, the perception layer is driven to acquire sensor data and call the time service to synchronize timestamps, and the localization layer is driven to fuse data and call the performance analysis service to monitor the time consumption. The decision-making layer generates trajectories and verifies time alignment; the control layer outputs instructions and calls error reporting services to handle executor anomalies. Each module transfers data through shared memory / message queues, while simultaneously calling external services such as logs, time, and error reporting based on the adjusted protocol. During the process, safety is ensured through multi-level fault tolerance mechanisms such as cache degradation for module timeouts / output anomalies, instance switching for service call failures, and system-level emergency braking. Real-time performance is ensured by measures such as dedicated resource allocation, asynchronous service calls, and performance monitoring and optimization. Ultimately, a closed loop from module control to service collaboration is formed, enabling the safe and reliable execution of autonomous driving tasks.

[0052] In one implementation, when a vehicle achieves autonomous driving control, it can be achieved through a Linux+QNX dual-platform collaboration. In this case, after determining which platform to control, the system also includes real-time detection of whether the platform type of the current platform has changed. If so, the system clears the calling protocol relationships between each intelligent module and each virtual interface in the service interface set, and determines a new target adaptation implementation example based on the changed platform type. Without interrupting the autonomous driving task, the system defines the calling protocol relationships between each intelligent module and each virtual interface in the service interface set based on the new target adaptation implementation example, and continues to complete the autonomous driving task.

[0053] Understandably, hot swapping is triggered when a platform switching instruction is received, such as switching from "linux_standard" to "qnx_safety" or when an adaptation implementation exception is notified. First, pause receiving new service call requests and cache currently incomplete calls; Then, uninstall the old adapter implementation instance, which means releasing memory resources and removing the binding relationship from the mapping table; Next, load the new adaptation implementation instance, which can be generated by loading the target platform's dynamic link library from a local or remote service library; Finally, update the binding relationships in the mapping table and resume processing cached call requests; The entire process requires no system restart and is completely unnoticed by the autonomous driving module.

[0054] The control method provided in the above embodiments solves the problem of strong coupling between business modules and service functions caused by platform differences in existing autonomous driving systems by abstracting service interfaces, defining multi-platform adaptation implementation examples, and dynamically binding service interfaces and platform adaptation instances, thereby improving the portability, maintainability and cross-platform deployment efficiency of the system.

[0055] This embodiment also provides an electronic device, including a processor and a memory. The memory stores machine-executable instructions that can be executed by the processor, and the processor executes the machine-executable instructions to implement the above-described control method. This electronic device can be a server or a terminal device.

[0056] See Figure 3 As shown, the electronic device includes a processor 300 and a memory 301. The memory 301 stores machine-executable instructions that can be executed by the processor 300. The processor 300 executes the machine-executable instructions to implement the control method described above.

[0057] Furthermore, Figure 3 The electronic device shown also includes a bus 302 and a communication interface 303. The processor 300, the communication interface 303 and the memory 301 are connected via the bus 302.

[0058] The memory 301 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 303 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 302 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0059] The processor 300 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 300 or by instructions in software form. The processor 300 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a readily available storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 301. The processor 300 reads the information from memory 301 and, in conjunction with its hardware, completes the steps of the control method described in the foregoing embodiments.

[0060] This embodiment also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are invoked and executed by a processor, the computer-executable instructions cause the processor to implement the above-described control method.

[0061] The computer program products of the control method, apparatus, electronic device and storage medium provided in the embodiments of this disclosure include a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0062] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0063] Furthermore, in the description of the embodiments of this disclosure, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this disclosure based on the specific circumstances.

[0064] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0065] In the description of this disclosure, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this disclosure and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this disclosure. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0066] Finally, it should be noted that the above embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.< / std::string>

Claims

1. An automatic driving control system, characterized in that, include: A set of service interfaces, used to call external service functions related to the platform during autonomous driving control; The service implementation module includes several adaptation implementation examples, which are used to define the functions of the service interface set according to the target platform or target operating mode. The service locator module stores the binding relationship between each adaptation implementation instance and the sum of the service interface set and the platform type. The binding relationship is obtained by extracting access records of external service functions from the historical control data of autonomous driving to construct adaptation implementation instances, and binding the constructed adaptation implementation instances with the service interface set and the platform type. The autonomous driving business module is used to trigger the service locator module to match the target adaptation implementation example by calling the service interface set, and to call the matched external service functions to control each intelligent module to complete the autonomous driving task.

2. The automatic driving control system according to claim 1, characterized in that, The service interface set consists of multiple virtual interfaces that are abstracted from external service functions and have no concrete implementation code. These virtual interfaces include: The log service virtual interface is obtained by extracting the log access protocols of the log service function for different platforms and abstracting and defining a log writing method. The virtual interface for time services extracts the time synchronization protocols for different platforms from the time service function and abstracts a method to obtain the current time. The error reporting service virtual interface is obtained by extracting the exception reporting protocol for different platforms from the exception feedback service function and abstracting and defining an exception reporting method. The performance analysis service virtual interface is obtained by extracting the analysis rules of the performance analysis service function for different platforms and abstracting and defining a method for recording time consumption.

3. The automatic driving control system according to claim 1, characterized in that, The service implementation modules include: Linux platform adaptation implementation example, QNX platform adaptation implementation example, and simulation platform adaptation implementation example.

4. The automatic driving control system according to claim 3, characterized in that, The Linux platform adaptation implementation example records at least one instance of external service access that writes to the system log file via the syslog interface, obtains the real-time time by calling clock_gettime, sends the data to the system monitoring process via DBus, and records the time consumption by calling the perf tool interface.

5. The automatic driving control system according to claim 3, characterized in that, The QNX platform adaptation implementation example records at least one instance of external service access that is written to the security log partition through the QNX controlled audit interface, obtains real-time time based on the QNX kernel clock, sends it to the security monitoring module through the QNX message passing mechanism, and calls the QNX Momentics toolchain's tracing interface to record the time-consuming external service access.

6. The automatic driving control system according to claim 3, characterized in that, The simulation platform adaptation implementation example records at least one external service access instance that stores content in a memory queue, generates virtual timestamps in configurable steps, marks and displays abnormal processes on the simulation monitoring interface, and records the execution time of modules within the simulation framework as the time consumed.

7. The automatic driving control system according to any one of claims 1-6, characterized in that, The intelligent module includes a perception module, a prediction module, a decision-making module, and a control module; The autonomous driving service module is specifically used for: Identify the platform currently running the autonomous driving task, and match the target adaptation implementation example based on the platform control service locator module; Based on the example in the target adaptation implementation example, the control perception module calls the time service virtual interface in the service interface set to obtain the receiving timestamp of the LiDAR point cloud data, and calls the log service virtual interface to record the quantity and quality information of the perception data. Based on the example in the target adaptation implementation example, the control prediction module calls the performance analysis service virtual interface to record the execution time of the traffic participant behavior prediction algorithm, and calls the error reporting service virtual interface to report prediction failure exceptions. Based on the example in the target adaptation implementation example, the control decision module calls the time service virtual interface to synchronize the timestamps of multiple sensors, and calls the log service interface to record the path planning results; Based on the example in the target adaptation implementation example, the control module calls the error reporting service virtual interface to report executor control command exceptions, and calls the performance analysis service virtual interface to record the time taken to generate control commands.

8. A control method based on the automatic driving control system according to any one of claims 1-7, characterized in that, The method includes: When starting autonomous driving control, the platform type of the current platform is identified, and the target adaptive implementation instance is determined based on the binding relationship between the adaptive implementation instance and the sum of the service interface set and the platform type. The target adaptation implementation example is analyzed to adjust the calling protocol relationship between each intelligent module and each virtual interface in the service interface set; It controls the operation of each intelligent module and calls external service functions based on the adjusted calling protocol relationship to work with each intelligent module to complete the autonomous driving task.

9. The method according to claim 8, characterized in that, The method further includes: Detect whether the platform type of the current platform has changed; If so, then clear the calling protocol of each virtual interface in each intelligent module and service interface group, and determine the new target adaptation implementation example based on the changed platform type; Without interrupting the autonomous driving task, the calling protocol relationship between each intelligent module and each virtual interface in the service interface set is defined based on the new target adaptation implementation example, and the autonomous driving task continues to be completed.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when invoked and executed by a processor, cause the processor to implement the control method of claim 8 or 9.

Images