Multi-vehicle shared automatic driving software design method, system and medium

Abstract

The application relates to a multi-vehicle shared automatic driving software design method, a system and a medium, the method comprising defining a standardized vehicle configuration file, the vehicle configuration file being used for representing vehicle information and configuration information, wherein the vehicle configuration file comprises a plurality of bytes, different bits in each byte correspond to different vehicles, different hardware configurations, different function switches or different parameter configurations; in a vehicle offline stage, a diagnostic instrument is used to write the vehicle configuration file corresponding to the vehicle into a non-volatile storage area of a controller; after the vehicle is powered on, the vehicle configuration file in the controller is read by underlying software; vehicle and configuration information in the vehicle configuration file is transmitted to an application layer through a middleware interface; and the application layer executes differentiated logic according to the vehicle and configuration information, wherein the differentiated logic comprises at least one of function switch judgment, parameter selection and display logic control.

Description

Technical Field

[0001] This invention relates to the fields of autonomous driving software development and vehicle software architecture design, and in particular to a method, system and medium for designing autonomous driving software shared by multiple vehicle models. Background Technology

[0002] As the automotive industry moves towards intelligence and connectivity, autonomous driving software has become an integral part of vehicle intelligence capabilities. For automakers, autonomous driving functions are no longer deployed only in a single model, but are being mass-produced and implemented across different vehicle categories, price points, hardware configurations, and levels of driver assistance. Different models typically have different sensor configurations, chassis parameters, control interfaces, function switches, human-machine interface display requirements, and driver assistance level requirements. Traditional multi-model autonomous driving software development usually adopts a "one vehicle, one solution" model, where each model has its own software framework and code branches based on its number of sensors, sensor types, computing platform, chassis interfaces, and functional requirements. Correspondingly, traditional version management typically adopts a "one vehicle, one branch" model, with each model branch being developed, tested, and released independently.

[0003] However, the aforementioned traditional solutions have some shortcomings when mass-producing multiple vehicle models in parallel. First, as the number of vehicle platforms increases, modules such as general perception, planning, control, and human-machine interaction are often repeatedly developed and maintained, resulting in low software resource utilization. Second, when upgrading core algorithms, fixing general defects, or optimizing control logic, developers are prone to problems such as code inconsistencies, missing patches, inconsistent test results, and recurring compatibility failures when operating synchronously across multiple branches. Especially in scenarios where L2 and L3 models coexist, L3 models generally reuse a large number of L2 basic capabilities while adding higher-level functions; if L2 and L3 software are managed completely independently, upgrades to L2 basic functions are difficult to reliably transfer to L3 models, or additional manual synchronization and verification are required. Furthermore, as sedans, SUVs, MPVs, and various high- and low-end models are successively equipped with autonomous driving functions, the number of software branches will increase linearly with the number of models. During version iteration, developers will perform code modification, compilation, unit testing, integration testing, and deployment verification on each branch. If there is a lack of a unified collaboration mechanism between branches, problems such as code conflicts, inconsistent functions, configuration omissions, duplicate defects, and long maintenance cycles are likely to occur. Summary of the Invention

[0004] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide a design method, system and medium for autonomous driving software shared by multiple vehicle models. By establishing a unified software architecture and version management mechanism, it realizes the efficient reuse and collaborative maintenance of autonomous driving function modules among different vehicle models, effectively reduces the repetitive workload of parallel development of multiple vehicle models, and improves code consistency and version iteration efficiency.

[0005] To achieve the above objectives, the present invention adopts the following technical solution.

[0006] Firstly, the present invention provides a method for designing shared autonomous driving software for multiple vehicle models, which adopts the following technical solution: Define a standardized vehicle configuration file, which is used to represent vehicle information and configuration information. The vehicle configuration file includes multiple bytes, and different bits in each byte correspond to different vehicle models, different hardware configurations, different function switches, or different parameter configurations. During the vehicle off-line phase, the vehicle model configuration file corresponding to the vehicle is written into the non-volatile storage area of ​​the controller using a diagnostic tool; After the vehicle is powered on, the underlying software reads the vehicle model configuration file from the controller; The vehicle model and configuration information in the vehicle model configuration file are transmitted to the application layer via a middleware interface; and The application layer executes differentiated logic based on the vehicle model and configuration information, wherein the differentiated logic includes at least one of function switch judgment, parameter selection, and display logic control.

[0007] Furthermore, in the above method, the application layer includes a unified core function layer and a differentiated adaptation layer. The unified core function layer is used to carry general function modules that can be reused across vehicle models, and the differentiated adaptation layer is used to carry exclusive adaptation modules for different vehicle models.

[0008] Furthermore, in the above method, the general functional module includes at least one of a general positioning algorithm module, a general planning algorithm module, a general perception module, and a general planning and control algorithm module.

[0009] Furthermore, in the above method, the differentiated adaptation layer includes at least one of vehicle-specific parameters, sensor driver adaptation, chassis interface adaptation, and human-machine interaction-specific display logic.

[0010] Furthermore, in the above method, the step of the application layer executing differentiated logic based on the vehicle model and configuration information includes: The functional state machine module determines whether the current vehicle model supports the corresponding autonomous driving function based on the vehicle model and configuration information. If it does not support the function, the activation path of the function is suppressed.

[0011] Furthermore, in the above method, the step of the application layer executing differentiated logic based on the vehicle model and configuration information includes: The planning and control module loads the parameter file corresponding to the vehicle model from the differentiated adaptation layer based on the vehicle model and configuration information, and outputs vehicle control commands based on the parameter file.

[0012] Furthermore, in the above method, the step of the application layer executing differentiated logic based on the vehicle model and configuration information includes: The human-computer interaction display module determines the display method based on the vehicle model and configuration information, and outputs the corresponding display content according to the vehicle model and function level.

[0013] Furthermore, the above method also includes: Establish a shared branch management mechanism to maintain the core functions shared by multiple vehicle models in the core main branch, and maintain the differentiated adaptation content of each vehicle model in the corresponding adaptation branch or configuration layer.

[0014] Furthermore, in the above method, the common branch management mechanism includes: When performing core function upgrades or bug fixes, modifications are made on the core main branch and then synchronized to the adaptation branches for each vehicle model; and When performing a dedicated adaptation for a specific car model, only the content of the adaptation layer corresponding to that car model is modified.

[0015] Furthermore, the above method also includes: A unified data entry point is provided to the application layer through a standardized interface layer, which includes at least one of the following: vehicle body parameter information interface, image information interface, lidar information interface, millimeter-wave radar information interface, and configuration file interface.

[0016] Furthermore, in the above method, the vehicle information includes L2-level assisted driving vehicles and L3-level conditional autonomous driving vehicles. The L3-level conditional autonomous driving vehicles reuse the basic functions of the L2-level assisted driving vehicles and add higher-level functions.

[0017] Secondly, the present invention provides a multi-vehicle shared autonomous driving software management system, which adopts the following technical solution: The configuration file definition module is used to define a standardized vehicle configuration file. The vehicle configuration file is used to represent vehicle information and configuration information. The vehicle configuration file includes multiple bytes, and different bits in each byte correspond to different vehicle models, different hardware configurations, different function switches, or different parameter configurations. The configuration writing module is used to write the vehicle model configuration file of the corresponding vehicle into the non-volatile storage area of ​​the controller through a diagnostic tool during the vehicle off-line stage. The underlying software module is used to read the vehicle model configuration file in the controller after the vehicle is powered on; The middleware interface module is used to transmit the vehicle model and configuration information from the vehicle model configuration file to the application layer; and The application layer module is used to execute differentiated logic based on the vehicle model and configuration information, wherein the differentiated logic includes at least one of function switch judgment, parameter selection and display logic control.

[0018] Thirdly, the present invention provides a readable storage medium, which adopts the following technical solution: A readable storage medium storing computer instructions that, when executed by a processor, implement the method as described in any one of the first aspects above.

[0019] In summary, compared with the prior art, the present invention has at least one of the following beneficial technical effects: The multi-vehicle shared autonomous driving software design method disclosed herein defines standardized vehicle configuration files and combines them with a layered software architecture. This allows the same set of software code to be adapted to vehicles with different models, hardware configurations, and functional levels, thereby avoiding the problem of redundant development in the traditional "one vehicle, one solution" model and significantly improving the reusability and development efficiency of software modules. At the same time, by writing configuration files during the vehicle's off-line production stage and dynamically reading them at runtime, the software and hardware configurations are decoupled. This allows the application layer to automatically execute differentiated logic based on the configuration information, without the need to compile and maintain separate code branches for each vehicle model. This reduces version management complexity, reduces the risk of code conflicts and configuration omissions, and improves software consistency and maintenance efficiency in multi-vehicle parallel mass production scenarios. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 An embodiment of the structural block diagram of the multi-vehicle shared autonomous driving software management system disclosed herein is shown.

[0022] Figure 2 An embodiment of the layered architecture of autonomous driving software disclosed herein is shown.

[0023] Figure 3 This illustration shows an embodiment of the logic flow for writing, reading, and applying the vehicle configuration file of this disclosure.

[0024] Figure 4 An embodiment of the flowchart of the multi-vehicle shared autonomous driving software design method of this disclosure is shown.

[0025] Figure 5 An embodiment of the application layer differentiated logic execution flow diagram of this disclosure is shown.

[0026] Figure 6 An embodiment of the flowchart of the common branch management mechanism of this disclosure is shown. Detailed Implementation

[0027] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Furthermore, it should be understood that the specific embodiments described herein are only for illustration and explanation of this application and are not intended to limit this application.

[0028] It should be noted that the order of description of the following embodiments is not intended to limit the preferred order of the embodiments of this application. Furthermore, the descriptions of each embodiment in the following embodiments have their own emphasis; for parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0029] The method steps described in this embodiment of the invention can be executed in the order described in the specific implementation, or the execution order of each step can be adjusted according to actual needs, provided that the technical problem can be solved. These are not listed one by one here.

[0030] The present invention will be further described in detail below with reference to the accompanying drawings.

[0031] Figure 1 A structural block diagram of a multi-vehicle shared autonomous driving software management system 600 is shown. The multi-vehicle shared autonomous driving software management system 600 includes a configuration file definition module 602, a configuration writing module 604, a low-level software module 606, a middleware interface module 608, and an application layer module 610. This system 600 is suitable for mass production projects of autonomous driving such as S12L / P12L, and is also suitable for software platforms that simultaneously support L2 and L3 vehicle functions.

[0032] The configuration file definition module 602 is used to define standardized vehicle configuration files. The vehicle configuration file represents vehicle information and configuration information. The vehicle configuration file includes multiple bytes, with different bits in each byte corresponding to different vehicle models, hardware configurations, function switches, or parameter configurations. In some implementations, vehicle information includes identifiers for different vehicle categories such as sedans, SUVs, and MPVs, while configuration information includes sensor configurations, chassis parameters, control interface parameters, etc. By encoding vehicle model and configuration information into different bits of bytes, the configuration file definition module 602 achieves a unified representation of multiple vehicle models and multiple configuration combinations.

[0033] The configuration writing module 604 is used to write the corresponding vehicle model configuration file to the controller's non-volatile storage area via a diagnostic tool during the vehicle's off-line production phase. The non-volatile storage area retains data even after the vehicle is powered off, ensuring the model configuration file remains valid throughout the vehicle's lifecycle. The configuration writing module 604 collaborates with the configuration file definition module 602 to ensure that each off-line vehicle has a model configuration file written that matches its hardware configuration and functional level.

[0034] The underlying software module 606 is used to read the vehicle model configuration file from the controller after the vehicle is powered on. During the vehicle startup process, the underlying software module 606 retrieves the contents of the vehicle model configuration file from the non-volatile memory area and passes the read data to the middleware interface module 608.

[0035] The middleware interface module 608 is used to pass the vehicle model and configuration information in the vehicle model configuration file to the application layer. As a bridge between the underlying software module 606 and the application layer module 610, the middleware interface module 608 provides a unified data access interface to the application layer module 610, so that the application layer module 610 can obtain the vehicle model and configuration information without having to worry about the underlying hardware and storage details.

[0036] The application layer module 610 executes differentiated logic based on vehicle model and configuration information. This differentiated logic includes at least one of function switch judgment, parameter selection, and display logic control. Regarding function switch judgment, the application layer module 610 determines whether the current vehicle model supports the corresponding autonomous driving function based on the vehicle model and configuration information, and accordingly decides whether to activate the function. Regarding parameter selection, the application layer module 610 loads the parameter file for the corresponding vehicle model based on the vehicle model and configuration information to adapt to the chassis characteristics and control requirements of different vehicle models. Regarding display logic control, the application layer module 610 determines the display method and content of the human-machine interface based on the vehicle model and function level.

[0037] The multi-vehicle autonomous driving software management system 600 achieves the goal of sharing the same version of autonomous driving software across multiple vehicle models through the collaboration of the aforementioned five modules. The configuration file definition module 602 establishes a unified configuration file format; the configuration writing module 604 completes the configuration writing when the vehicle is off-line; the underlying software module 606 reads the configuration during vehicle operation; the middleware interface module 608 completes data transmission; and the application layer module 610 executes differentiated logic based on the configuration. This system 600 enables the same set of software code to adapt to vehicles of different models, hardware configurations, and functional levels, avoiding the need to compile and maintain separate code branches for each vehicle model.

[0038] To achieve the goal of sharing autonomous driving software across multiple vehicle models, this disclosure adopts a layered software architecture to organize the autonomous driving software. Figure 2 This diagram illustrates the layered architecture of autonomous driving software. The layered architecture comprises three levels: a core general-purpose function layer (also known as the unified core function layer), a differentiated adaptation layer, and a standardized interface layer. The application layer includes the unified core function layer and the differentiated adaptation layer. The unified core function layer carries general-purpose function modules that can be reused across different vehicle models, while the differentiated adaptation layer carries dedicated adaptation modules for different vehicle models.

[0039] The unified core functional layer integrates common core modules that can be reused across vehicle models in autonomous driving. These common functional modules include at least one of a common localization algorithm module, a common planning algorithm module, a common perception module, and a common control algorithm module. The unified core functional layer also includes other common modules, which may include general functions such as data processing and safety verification. The common localization algorithm module can be used for vehicle localization or pose estimation. The common control algorithm module can be used for path planning, behavior decision-making, and vehicle control. The common perception module can be used for environmental obstacle perception or target recognition, including algorithmic logic such as point cloud noise reduction, target detection, and multi-sensor fusion. These modules are stripped of vehicle-specific information, retaining core logic that can be reused across vehicle models. In some implementations, the basic vehicle speed control algorithm or basic steering control algorithm, after stripping vehicle model parameters, can be shared by multiple vehicle models, including basic PID control.

[0040] The differentiation adaptation layer is located between the core general function layer and the specific vehicle model, and is used to carry adaptation content such as modules specific to vehicle model A, modules specific to vehicle model B, and modules specific to vehicle model C. The differentiation adaptation layer includes at least one of the following: vehicle-specific parameters, sensor driver adaptation, chassis interface adaptation, and human-machine interaction-specific display logic. In some implementations, the differentiation adaptation layer may also include function switch strategies or other logic strongly related to the vehicle model. The core function layer obtains the information required by the current vehicle model or outputs corresponding commands by calling the interfaces provided by the differentiation adaptation layer, thereby avoiding the core function layer being directly bound to a specific vehicle model.

[0041] The standardized interface layer provides a unified data entry point to the application layer. This standardized interface layer includes at least one of the following: a vehicle parameter information interface, an image information interface, a LiDAR information interface, a millimeter-wave radar information interface, and a configuration file interface. In some implementations, the standardized interface layer may also include other interfaces. Through the standardized interface layer, even if different vehicle models use different sensor models, different numbers of LiDAR sensors, or different chassis signal formats, the data can be converted by the adaptation layer into a unified data format recognizable by the core functional layer. The standardized interface layer enables the core functional layer to obtain data through standard interfaces without directly relying on specific vehicle model hardware.

[0042] In module division, this disclosure adopts two judgment criteria. If a module is applicable to all target vehicle models, and its algorithm logic is not strongly bound to the specific vehicle model's hardware or parameters, then the module is classified into the unified core function layer. In some implementations, multi-sensor fusion algorithms, path planning algorithms, general target detection logic, basic vehicle speed control algorithms, or basic steering control algorithms can be shared by multiple vehicle models after removing vehicle model parameters. If a module is strongly related to the hardware, parameters, or display requirements of a specific vehicle model, then the module is classified into the differentiated adaptation layer. In some implementations, specific LiDAR drivers, specific millimeter-wave radar drivers, vehicle model wheelbase / track parameters, chassis interface mapping, and human-machine interaction-specific display logic are all considered vehicle model adaptation content.

[0043] The overall architecture shields the differences in underlying hardware through a standardized interface layer, enabling the core general-purpose function layer to maintain cross-vehicle commonality. At the same time, it handles the specific needs of each vehicle model through a differentiated adaptation layer, thereby achieving the goal of multiple vehicle models sharing the same version of autonomous driving software.

[0044] The operation of the aforementioned layered software architecture depends on the writing and reading of vehicle configuration files and the processing of application layer differentiated logic. Figure 3 This diagram illustrates the logic flow for writing and reading vehicle model configuration files and the differentiated logic at the application layer.

[0045] Vehicle configuration files are used to record vehicle and configuration information. Vehicle information includes model identifiers such as Model A, Model B, and Model C, while configuration information includes hardware or functional configuration identifiers such as Configuration a, Configuration b, and Configuration c. Vehicle information includes Level 2 assisted driving vehicles and Level 3 conditional automated driving vehicles. Level 2 assisted driving vehicles typically include lane keeping assist, adaptive cruise control, and assisted parking. Level 3 conditional automated driving vehicles reuse the basic functions of Level 2 assisted driving vehicles and add more advanced functions; under designed operating conditions, the system can undertake some dynamic driving tasks.

[0046] The vehicle configuration file uses a combination of bytes and bits to represent different information. In some implementations, bits 0 to 7 of Byte 1 are used to represent the vehicle type or function level, bits 0 to 7 of Byte 2 are used to represent sensor configuration or control interface configuration, and bits 0 to 7 of Byte 3 are used to represent HMI configuration, function switches, or other extended configurations. By combining bytes and bits, the configuration file can express multiple vehicle types and multiple configuration combinations in a limited storage space.

[0047] When a vehicle rolls off the production line, the production line uses a UDS diagnostic tool to write the corresponding vehicle model configuration file into the non-volatile storage area of ​​the autonomous driving controller. UDS stands for Unified Diagnostic Services, a commonly used diagnostic communication service for vehicle controllers. The non-volatile storage area ensures that the configuration file is retained even after the vehicle is powered on and off. After writing, the configuration file stored in the controller becomes the basis for software identification of the vehicle. For the same version of autonomous driving software, the software no longer distinguishes vehicles by model-specific software versions, but instead identifies the current vehicle model, hardware, enabled functions, and required parameters by reading the configuration file in the controller.

[0048] After the vehicle is powered on, the underlying software reads the vehicle model configuration file from the controller's non-volatile memory area and parses the read vehicle model and configuration information into a data structure recognizable by the application layer. The underlying software then transmits this data to the application layer through a middleware interface. The middleware acts as a unified interface, allowing application layer modules such as the PNC planning and control module, HMI display module, and functional state machine module to read the vehicle model and configuration data through a unified interface without needing to directly access the underlying storage address or be concerned with the specific storage method of the configuration file at the underlying level.

[0049] During the initialization phase, the application layer reads the vehicle configuration data and executes differentiated logic based on the vehicle model and configuration information. This differentiated logic includes function switch judgment, parameter selection, and display logic control.

[0050] For function on / off determination, the function state machine module determines whether the current vehicle model supports the corresponding autonomous driving function based on the read vehicle model and configuration information. In some implementations, for vehicles that only support L2 functions, the state machine suppresses L3 function-related state transitions after reading the vehicle model configuration, preventing L3 functions from entering the active state; for vehicles that support L3 functions, the state machine allows L2 basic functions and L3 new functions to transition according to preset conditions. In this way, the same software version can automatically control functions to be turned on or off based on the configuration. In some implementations, if it is determined that the current vehicle configuration does not support a certain autonomous driving function, the activation path of that function is suppressed in the state machine logic, keeping the function off or unavailable; if it is determined that the current vehicle supports the function, the state machine is allowed to enter the corresponding function state when conditions such as sensor readings, vehicle speed, road conditions, and driver confirmation are met.

[0051] For parameter selection, the application layer selects the corresponding parameter file or parameter set after reading the vehicle configuration. Different vehicle models differ in wheelbase, track width, vehicle weight, steering response, braking response, sensor mounting locations, and chassis control interfaces. These differences affect control accuracy and algorithm thresholds. After obtaining vehicle information, the PNC planning and control module calls the body parameters and control parameters matching the current vehicle model and outputs vehicle control commands based on these parameters. The general control algorithm remains consistent, while vehicle model differences are absorbed by the parameter layer. In some implementations, vehicle model A uses parameter file A, vehicle model B uses parameter file B, and vehicle model C uses parameter file C. The core control algorithm calls a unified interface to obtain parameters, avoiding writing numerous vehicle model judgment branches within the algorithm, thus maintaining the simplicity and maintainability of the core algorithm.

[0052] For display logic control, the HMI display module determines the display method based on the vehicle model configuration file. In some implementations, certain vehicle models have L3 function indicator areas, while others only display L2 function status; some vehicle models have specific function icons, prompts, or display layouts. By reading the same configuration file, the HMI module outputs the corresponding display content according to the vehicle model and function level, without needing to maintain a complete set of HMI software for each vehicle model.

[0053] In some implementations, vehicle model A uses LiDAR A, vehicle model B uses LiDAR B, and vehicle model C does not have LiDAR but is equipped with millimeter-wave radar. Common perception logic such as point cloud noise reduction, target detection, and multi-sensor fusion is retained in a unified core functional layer; hardware-related content such as LiDAR A driver, LiDAR B driver, and millimeter-wave radar interface conversion are placed in a differentiated adaptation layer. Even if the sensor hardware differs, the core perception algorithm can still be reused, and the hardware differences are handled by the adaptation layer.

[0054] By writing and reading the vehicle configuration files and processing application-layer differentiated logic, the same version of autonomous driving software presents different combinations of functions and control logic on different vehicle models, achieving the goal of sharing software across multiple vehicle models.

[0055] Based on the above-mentioned vehicle configuration file writing, reading, and application layer differentiated logic processing flow, Figure 4 A flowchart of a multi-vehicle shared autonomous driving software design method 300 is shown. Method 300 includes steps 302, 304, 306, 308, and 310.

[0056] In step 302, a standardized vehicle model configuration file is defined. The vehicle model configuration file is used to represent vehicle model information and configuration information. As mentioned above, the vehicle model configuration file includes multiple bytes, with different bits in each byte corresponding to different vehicle models, different hardware configurations, different function switches, or different parameter configurations. In some embodiments, vehicle model information includes vehicle category identifiers such as sedans, SUVs, and MPVs, and configuration information includes sensor type, sensor quantity, chassis parameters, control interface parameters, etc. In some embodiments, bits 0 to 7 of Byte 1 are used to represent the vehicle model category or function level, bits 0 to 7 of Byte 2 are used to represent sensor configuration or control interface configuration, and bits 0 to 7 of Byte 3 are used to represent HMI configuration, function switches, or other extended configurations. Through the combination of bytes and bits, the vehicle model configuration file expresses multiple vehicle models and multiple configuration combinations in a limited storage space.

[0057] During the vehicle off-line phase, step 304 is executed, where the corresponding vehicle model configuration file is written to the controller's non-volatile storage area using a diagnostic tool. In some implementations, the configuration file writing operation is performed on the production line using a UDS diagnostic tool. The non-volatile storage area retains data even after the vehicle is powered off, ensuring the model configuration file remains valid throughout the vehicle's entire lifecycle. After writing is complete, the configuration file stored in the controller becomes the basis for the vehicle's software identification. The software reads the configuration file from the controller to identify the current vehicle's model, hardware specifications, enabled functions, and applicable parameters.

[0058] Step 306 is executed after the vehicle is powered on, whereby the underlying software reads the vehicle model configuration file from the controller. The underlying software retrieves the contents of the vehicle model configuration file from the non-volatile storage area and parses the read vehicle model and configuration information into a data structure that the application layer can recognize.

[0059] In step 308, the vehicle model and configuration information in the vehicle model configuration file are transmitted to the application layer via the middleware interface. The middleware interface acts as a bridge between the underlying software and the application layer, providing a unified data access interface to the application layer. Through the middleware interface, application layer modules such as the PNC planning and control module, HMI display module, and functional state machine module do not need to directly access the underlying storage address, nor do they need to concern themselves with the specific storage method of the configuration file at the underlying level. Instead, they read the vehicle model and configuration data through a unified interface.

[0060] In step 310, the application layer executes differentiated logic based on the vehicle model and configuration information. The differentiated logic includes at least one of function switch judgment, parameter selection, and display logic control. For function switch judgment, the function state machine module determines whether the current vehicle model supports the corresponding autonomous driving function based on the vehicle model and configuration information. If not, it suppresses the activation path of the function, keeping the function closed or unavailable. For parameter selection, the planning control module loads the parameter file for the corresponding vehicle model from the differentiated adaptation layer based on the vehicle model and configuration information, and outputs vehicle control commands based on the parameter file. For display logic control, the human-machine interaction display module determines the display method based on the vehicle model and configuration information, and outputs corresponding display content according to the vehicle model and function level.

[0061] With Method 300, the same version of autonomous driving software can present different combinations of functions and control logic on different vehicle models based on the configuration file, without the need to compile and maintain separate code branches for each vehicle model.

[0062] Step 310 in the above method 300 describes the process by which the application layer executes differentiated logic based on vehicle model and configuration information. Figure 5 A schematic diagram of the differential logic execution flow 400 is shown, which elaborates on the specific process of executing differential logic at the application layer. The differential logic execution flow 400 includes steps 402, 404, 406, 408, 410, 412, and 414.

[0063] In step 402, the application layer receives vehicle model and configuration information from the middleware interface. As mentioned above, the middleware interface acts as a bridge between the underlying software and the application layer, providing a unified data access interface to the application layer. After obtaining the vehicle model and configuration information through the middleware interface during the initialization phase, the application layer performs three types of differentiated processing in parallel based on this information. These three types of differentiated processing correspond to function switch judgment, parameter selection, and display logic control, respectively.

[0064] The function switch determination consists of steps 404 and 406. In step 404, the function state machine module determines whether the current vehicle model supports the corresponding autonomous driving function based on the vehicle model and configuration information. The function state machine module reads the function level information and function switch identifier in the vehicle model configuration file and compares the read information with the preset function support conditions. In some embodiments, for vehicles that only support L2 functions, the function state machine module determines that the current vehicle model does not support L3 functions after reading the vehicle model configuration; for vehicles that support L3 functions, the function state machine module determines that the current vehicle model supports both L2 basic functions and L3 new functions. In step 406, if the function state machine module determines that the current vehicle model does not support the corresponding autonomous driving function, it suppresses the activation path of the function, keeping the function closed or unavailable. In some embodiments, the function state machine module suppresses L3 function-related state transitions, preventing the L3 function from entering the activation state; if it determines that the current vehicle supports the function, it allows the state machine to enter the corresponding function state when conditions such as sensor, vehicle speed, road, and driver confirmation are met.

[0065] Parameter selection consists of steps 408 and 410. In step 408, the planning control module loads the parameter file corresponding to the vehicle model from the differentiation adaptation layer based on the vehicle model and configuration information. Different vehicle models have differences in wheelbase, track width, vehicle weight, steering response, braking response, sensor mounting location, and chassis control interface, which can affect control accuracy and algorithm thresholds. After obtaining the vehicle model information, the planning control module calls the body parameters and control parameters that match the current vehicle model. In some implementations, vehicle model A uses parameter file A, vehicle model B uses parameter file B, and vehicle model C uses parameter file C. The planning control module determines the current vehicle model by reading the vehicle model identifier in the vehicle model configuration file and loads the parameter file corresponding to that model from the differentiation adaptation layer. In step 410, the planning control module outputs vehicle control commands based on the parameter file. The general control algorithm remains consistent, while vehicle model differences are absorbed by the parameter layer. The core control algorithm calls a unified interface to obtain parameters, instead of writing a large number of vehicle model judgment branches inside the algorithm, thus keeping the core algorithm simple and maintainable.

[0066] The display logic control consists of steps 412 and 414. In step 412, the human-machine interface (HMI) display module determines the display method based on the vehicle model and configuration information. The HMI display module reads the HMI configuration information and function level information from the vehicle model configuration file, and determines the display layout, function icons, and prompts for the HMI interface based on the read information. In some implementations, certain vehicle models have an L3 function indicator area, while others only display L2 function status; some vehicle models have specific function icons, prompts, or display layouts. In step 414, the HMI display module outputs the corresponding display content based on the vehicle model and function level. By reading the same configuration file, the HMI display module outputs the corresponding display content based on the vehicle model and function level, eliminating the need to maintain a separate complete HMI software for each vehicle model.

[0067] Through the differentiated logic execution process 400, after receiving vehicle model and configuration information, the application layer performs corresponding differentiated processing by the functional state machine module, planning and control module, and human-machine interaction display module, so that the same version of autonomous driving software presents different functional combinations, control logic, and display content on different vehicle models.

[0068] As described above, the application layer includes a unified core function layer and a differentiated adaptation layer. The unified core function layer carries common function modules that can be reused across vehicle models, while the differentiated adaptation layer carries exclusive adaptation modules for different vehicle models. To achieve consistency, traceability, and synchronous update capabilities across multiple vehicle models, this disclosure establishes a shared branch management mechanism. Core functions shared by multiple vehicle models are uniformly maintained in the core main branch, while differentiated adaptation content for each vehicle model is maintained in the corresponding adaptation branch or configuration layer. Figure 6 A flowchart of the common branch management mechanism 500 is shown. The common branch management mechanism 500 includes steps 502, 504, 506, 508, and 510.

[0069] In step 502, a change request for the autonomous driving software is received. The change request may include at least one of the following: core function upgrade, vulnerability fix, general algorithm optimization, or vehicle-specific adaptation.

[0070] In step 504, the change type is determined. The common branch management mechanism 500 determines whether the change is a core function change or a vehicle-specific adaptation change based on the content of the change request. Core function changes include core function upgrades, vulnerability fixes, and general algorithm optimizations; vehicle-specific adaptation changes include vehicle-specific configuration modifications, vehicle-specific parameter adjustments, and vehicle-specific display logic modifications.

[0071] When performing core function upgrades or vulnerability fixes, execute step 506 to complete the modifications on the core main branch. The core main branch is used to carry the core common functional layer code shared by all target models, including modules such as general perception, planning, decision-making, control, data processing, and security verification. After completing core function upgrades, vulnerability fixes, or common algorithm optimizations on the core main branch, developers verify the correctness of the modifications through unified testing.

[0072] In step 508, modifications on the core main branch are synchronized to the adaptation branches for each vehicle model. Since all vehicle models share the core main branch, the same core issue does not need to be repeatedly modified across multiple vehicle model branches, thus reducing the risk of missed synchronizations and version inconsistencies. In some implementations, if the core path planning algorithm is optimized, after developers modify the general planning algorithm module in the core main branch, vehicle models A, B, and C all obtain this optimized capability through synchronization via the shared branch.

[0073] When performing a specific adaptation for a particular vehicle model, step 510 is executed, modifying only the adaptation layer content corresponding to that model. The vehicle model adaptation branch or directory is used to hold the differentiated adaptation layer content for each vehicle model, including modules specific to vehicle A, vehicle B, and vehicle C, along with corresponding parameter configurations. Developers only modify the adaptation layer content corresponding to that vehicle model, without affecting the core functions of other models. In some implementations, if only vehicle C adds L3-related HMI prompts, developers only add or modify the HMI display logic in the differentiated adaptation layer for vehicle C, without affecting the L2 functions of vehicle A and vehicle B.

[0074] The common branch management mechanism 500 also includes a version traceability and recording mechanism. Each time a core main branch or vehicle adaptation branch is released, the corresponding software version number, configuration file version number, vehicle adaptation version number, and feature on / off status are recorded. If a software problem occurs in a particular vehicle model, the current vehicle model and configuration are determined based on the configuration file, and then the core main branch version and vehicle adaptation layer version used are located based on the version record, thus determining whether the problem belongs to a core general module, a vehicle adaptation module, or a configuration file error.

[0075] The common branch management mechanism 500 also includes a layered testing and verification method. Testing is divided into core function testing and vehicle model adaptation testing. Core function testing verifies the correctness of general positioning, perception, planning, and control modules under standard interface inputs. Vehicle model adaptation testing verifies the correctness of configuration files, hardware interfaces, parameter files, HMI displays, and function switches for different vehicle models. Layered testing reduces repetitive testing work and makes problem localization clearer.

[0076] The shared branch management mechanism 500 also supports extended adaptation for new vehicle models. If a new vehicle model D or configuration d is added later, while keeping the core software architecture unchanged, the byte or bit definitions in the vehicle model configuration file are extended, and corresponding parameters and interface adaptation modules for vehicle model D are added to the differentiated adaptation layer. The core general function layer does not need to be rebuilt, and the core main branch does not need to be copied into a complete new software; adaptation content is added on the existing shared architecture. Thus, new vehicle model adaptation changes from development from scratch to marginal adaptation based on existing core capabilities.

[0077] Through the shared branch management mechanism 500, core function upgrades, vulnerability fixes, and general algorithm optimizations are synchronized to the adaptation branches of each vehicle model after the core main branch is completed. Vehicle-specific configurations and logic are maintained within the adaptation layer, thereby avoiding repeated copying and deviation of the core code in multiple branches and ensuring unified iteration of the core code and consistency across multiple vehicle models.

[0078] This invention also discloses a readable storage medium.

[0079] A computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any of the above embodiments. The computer-readable storage medium may include any entity or device capable of carrying a computer program, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), and a software distribution medium, etc. The computer program includes computer program code. The computer program code may be in the form of source code, object code, an executable file, or some intermediate form, etc. The computer-readable storage medium may include any entity or device capable of carrying computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), and a software distribution medium, etc.

[0080] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0081] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a system including a processing module or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0082] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications 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 the present invention.

Claims

1. A method for designing autonomous driving software shared by multiple vehicle models, characterized in that, include: Define a standardized vehicle configuration file, which is used to represent vehicle information and configuration information. The vehicle configuration file includes multiple bytes, and different bits in each byte correspond to different vehicle models, different hardware configurations, different function switches, or different parameter configurations. During the vehicle off-line phase, the vehicle model configuration file corresponding to the vehicle is written into the non-volatile storage area of ​​the controller using a diagnostic tool; After the vehicle is powered on, the underlying software reads the vehicle model configuration file from the controller; The vehicle model and configuration information in the vehicle model configuration file are transmitted to the application layer through the middleware interface; as well as The application layer executes differentiated logic based on the vehicle model and configuration information, wherein the differentiated logic includes at least one of function switch judgment, parameter selection, and display logic control.

2. The method according to claim 1, characterized in that, The application layer includes a unified core function layer and a differentiated adaptation layer. The unified core function layer is used to carry general function modules that can be reused across vehicle models, and the differentiated adaptation layer is used to carry exclusive adaptation modules for different vehicle models.

3. The method according to claim 2, characterized in that, The general functional modules include at least one of the following: a general positioning algorithm module, a general planning algorithm module, a general sensing module, and a general planning and control algorithm module.

4. The method according to claim 2, characterized in that, The differentiated adaptation layer includes at least one of the following: vehicle-specific parameters, sensor driver adaptation, chassis interface adaptation, and human-machine interaction-specific display logic.

5. The method according to claim 1, characterized in that, The execution of differentiated logic by the application layer based on the vehicle model and configuration information includes: The functional state machine module determines whether the current vehicle model supports the corresponding autonomous driving function based on the vehicle model and configuration information. If it does not support the function, the activation path of the function is suppressed.

6. The method according to claim 1, characterized in that, The execution of differentiated logic by the application layer based on the vehicle model and configuration information includes: The planning and control module loads the parameter file corresponding to the vehicle model from the differentiated adaptation layer based on the vehicle model and configuration information, and outputs vehicle control commands based on the parameter file.

7. The method according to claim 1, characterized in that, The execution of differentiated logic by the application layer based on the vehicle model and configuration information includes: The human-computer interaction display module determines the display method based on the vehicle model and configuration information, and outputs the corresponding display content according to the vehicle model and function level.

8. The method according to claim 2, characterized in that, Also includes: Establish a shared branch management mechanism to maintain the core functions shared by multiple vehicle models in the core main branch, and maintain the differentiated adaptation content of each vehicle model in the corresponding adaptation branch or configuration layer.

9. The method according to claim 8, characterized in that, The shared branch management mechanism includes: When performing core function upgrades or bug fixes, modifications are made on the core main branch and then synchronized to the adaptation branches for each vehicle model; and When performing a dedicated adaptation for a specific car model, only the content of the adaptation layer corresponding to that car model is modified.

10. The method according to claim 1, characterized in that, Also includes: A unified data entry point is provided to the application layer through a standardized interface layer, which includes at least one of the following: vehicle body parameter information interface, image information interface, lidar information interface, millimeter-wave radar information interface, and configuration file interface.

11. The method according to claim 1, characterized in that, The vehicle information includes Level 2 assisted driving vehicles and Level 3 conditional autonomous driving vehicles. The Level 3 conditional autonomous driving vehicles reuse the basic functions of the Level 2 assisted driving vehicles and add higher-level functions.

12. A shared autonomous driving software management system for multiple vehicle models, characterized in that, include: The configuration file definition module is used to define a standardized vehicle configuration file. The vehicle configuration file is used to represent vehicle information and configuration information. The vehicle configuration file includes multiple bytes, and different bits in each byte correspond to different vehicle models, different hardware configurations, different function switches, or different parameter configurations. The configuration writing module is used to write the vehicle model configuration file of the corresponding vehicle into the non-volatile storage area of ​​the controller through a diagnostic tool during the vehicle off-line stage. The underlying software module is used to read the vehicle model configuration file in the controller after the vehicle is powered on; The middleware interface module is used to transmit the vehicle model and configuration information in the vehicle model configuration file to the application layer; as well as The application layer module is used to execute differentiated logic based on the vehicle model and configuration information, wherein the differentiated logic includes at least one of function switch judgment, parameter selection and display logic control.

13. A readable storage medium, characterized in that, The readable storage medium stores computer instructions that, when executed by a processor, implement the method as described in any one of claims 1-11.

Images