Vehicle controller software management system and method

Abstract

The invention provides a vehicle controller software management system and method. Relates to the technical field of vehicles. The vehicle controller software management system comprises an order management subsystem, a production management subsystem, an electric detection subsystem and a product life cycle management subsystem. The order management subsystem is used for generating a software order of the vehicle controller in response to a configuration operation of a user; the production management subsystem is used for obtaining a software version and a first storage address of first software from the product life cycle management subsystem in response to the software order; and the electric detection subsystem is used for acquiring the first software according to the first storage address when the software version of the first software is inconsistent with the software version of initial software pre-written in the vehicle controller, and updating the initial software in the vehicle controller. According to the system, the software versions corresponding to the orders are accurately matched, and full-amount flashing is replaced by difference updating, so that invalid operation in a production link can be reduced, and the vehicle production efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a vehicle controller software management system and method. Background Technology

[0002] With the rapid development of new energy vehicles and intelligent connected vehicles, the number of controllers in vehicles has increased significantly. These controllers are responsible for controlling key functions such as the vehicle's engine, transmission, braking system, and infotainment system. Each controller requires specific software to run, and with the iteration of vehicle models, the development of software and hardware technologies, and the increasing personalized needs of users, the controller software is iterating faster and faster, making its management extremely complex.

[0003] In related technologies, a standardized software flashing operation is typically performed on the controllers of vehicles awaiting delivery during the vehicle production stage. However, this standardized software flashing operation indiscriminately overwrites the initial software pre-installed in the controller and conforms to user requirements, reducing vehicle production efficiency. Summary of the Invention

[0004] This application provides a vehicle controller software management system and method for identifying the compatibility of initial software, realizing differentiated software management, reducing unnecessary flashing operations, and improving vehicle production efficiency.

[0005] In a first aspect, this application provides a vehicle controller software management system, which includes: an order management subsystem, a production management subsystem, an electrical inspection subsystem, and a product lifecycle management subsystem;

[0006] The order management subsystem is used to generate a software order for the vehicle controller in response to the user's configuration operation.

[0007] The production management subsystem is used to, in response to the software order, obtain the software version and first storage address of the first software from the product lifecycle management subsystem;

[0008] The electronic testing subsystem is used to, when the software version of the first software is inconsistent with the software version of the initial software pre-written in the vehicle controller, retrieve the first software according to the first storage address, and update the initial software to the first software in the vehicle controller.

[0009] In one possible implementation, the software order includes software configuration information, and the step of obtaining the software version and first storage address of the first software from the product lifecycle management subsystem in response to the software order includes:

[0010] In response to the software order, a bill of materials is obtained from the product lifecycle management subsystem, and at least one software material for the vehicle controller is identified in the bill of materials;

[0011] Based on the software configuration information, a target software material is determined from the at least one software material, and the software version and first storage address of the first software are determined from the target software material.

[0012] In one possible implementation, the production management subsystem is further configured to generate a vehicle graphic code based on the software version of the first software and the first storage address.

[0013] The electronic inspection subsystem is also used to read the vehicle graphic code to obtain the software version of the first software.

[0014] The electrical inspection subsystem is also used to obtain the software version of the initial software in the vehicle controller.

[0015] In one possible implementation, the vehicle controller software management system further includes an after-sales management subsystem, which is used to receive software version records uploaded by the electrical inspection subsystem, the software version records including the current software version of the vehicle controller.

[0016] In one possible implementation, the after-sales management subsystem is further configured to, when the vehicle controller is replaced with a new vehicle controller, obtain the software version of the software already installed in the new vehicle controller through a vehicle networking terminal, verify the software version of the installed software through the software version record, and determine whether to update the software of the new vehicle controller.

[0017] In one possible implementation, the software version record further includes the storage address of the current software; the step of verifying the software version of the installed software through the software version record to determine whether to update the software of the new vehicle controller includes:

[0018] If the current software version included in the software version record is inconsistent with the software version of the installed software, then the current software is obtained according to the storage address of the current software version, and the installed software is updated to the current software in the new vehicle controller.

[0019] In one possible implementation, the vehicle controller software management system further includes a software development management subsystem, which is used to generate at least one initial software material according to the software development requirements of the vehicle controller, and send the at least one initial software material to the product lifecycle management subsystem. The initial software material includes the software version and the software program.

[0020] The product lifecycle management subsystem is also used to standardize and encapsulate the received at least one initial software material to generate at least one software material corresponding to the vehicle controller, and generate the bill of materials based on the at least one software material, wherein the software material includes the software version and the storage address generated by storing the software program.

[0021] In one possible implementation, the production management subsystem is further configured to, when the software order is updated, retrieve the software version and second storage address of the second software from the product lifecycle management subsystem in response to the updated software order.

[0022] The production management subsystem is also used to update the vehicle graphic code based on the software version and the second storage address of the second software.

[0023] In one possible implementation, the electrical inspection subsystem is an end-of-line electrical inspection device.

[0024] Secondly, this application provides a vehicle controller software management method, the method being applied to the vehicle controller software management system described in any one of the first aspects; the method includes:

[0025] In response to the user's configuration operation, a software order for the vehicle controller is generated;

[0026] In response to the software order, obtain the software version and first storage address of the first software;

[0027] When the software version of the first software is inconsistent with the software version of the initial software pre-written in the vehicle controller, the first software is retrieved according to the first storage address, and the initial software is updated to the first software in the vehicle controller.

[0028] Thirdly, this application provides a vehicle controller software management device, including the vehicle controller software management system as described in the first aspect above.

[0029] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the vehicle controller software management method described in the second aspect.

[0030] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, is used to implement the vehicle controller software management method described in the second aspect.

[0031] This application provides a vehicle controller software management system and method. The vehicle controller software management system may include an order management subsystem, a production management subsystem, an electrical inspection subsystem, and a product lifecycle management subsystem. The order management subsystem can generate a software order in response to a user's configuration operation. The production management subsystem can obtain the software version and first storage address of the first software from the product lifecycle management subsystem based on the software order. The electrical inspection subsystem obtains the software version of the initial software pre-written in the vehicle controller and compares it with the software version of the first software. If they are inconsistent, the first software is obtained based on the first storage address, and the initial software is updated to the first software. In the above process, the vehicle controller software management system can effectively avoid indiscriminate flashing operations and reduce unnecessary working hours through collaborative management of software order triggering, version verification, and differentiated updates, thereby improving vehicle production efficiency. Attached Figure Description

[0032] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0033] Figure 1 A schematic diagram illustrating the application scenarios provided in the embodiments of this application;

[0034] Figure 2 This is a schematic diagram of the structure of a first embodiment of the vehicle controller software management system provided in this application;

[0035] Figure 3 This is a schematic diagram of the structure of Embodiment 2 of the vehicle controller software management system provided in this application;

[0036] Figure 4 A system architecture diagram of the vehicle controller software management system provided in the embodiments of this application;

[0037] Figure 5 A schematic diagram illustrating the implementation principle of the vehicle controller software management system provided in this application embodiment;

[0038] Figure 6 This is a flowchart illustrating the vehicle controller software management method provided in an embodiment of this application.

[0039] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0040] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0041] With the rapid development of new energy vehicles and intelligent connected vehicles, vehicle electrical architecture is gradually upgrading towards domain control and integration. The number of vehicle controllers has increased significantly compared to traditional vehicles, covering core components such as battery management systems, motor controllers, vehicle controllers, intelligent braking controllers, infotainment controllers, and autonomous driving domain controllers. These vehicle controllers are responsible for key functions such as power output, energy management, driving safety, and intelligent interaction, and each type of vehicle controller requires dedicated control software. However, with the accelerated pace of vehicle model iteration, the differentiation of power modes, and the increasing personalized configuration requirements of users for range and energy consumption, coupled with stricter industry regulations on emissions and safety, the iteration frequency of vehicle controller software continues to accelerate, and the number and combination of software versions have increased dramatically, making their management extremely complex.

[0042] In related technologies, a standardized software flashing model is still commonly used in the vehicle production stage: all vehicle controllers on the production line, regardless of whether their factory-installed initial software matches the order configuration requirements, must undergo a full software overwrite flash. However, many vehicle controllers come pre-installed with basic adaptation software, and the configuration requirements of some orders are completely consistent with the initial software. This standardized software flashing operation will indiscriminately overwrite the pre-installed initial software in the controller that meets the user's needs, reducing vehicle production efficiency.

[0043] To address the aforementioned issues, the inventors proposed a vehicle controller software management system that avoids invalid write operations and improves production efficiency through differentiated software update logic. This vehicle controller software management system includes an order management subsystem, a production management subsystem, an electrical inspection subsystem, and a product lifecycle management subsystem. These subsystems work together to achieve precise software control. Specifically, the order management subsystem generates a software order for the vehicle controller in response to user configuration operations. The production management subsystem interfaces with the product lifecycle management subsystem, retrieving the software version and storage address of the first software from the product lifecycle management subsystem in response to the software order. The electrical inspection subsystem performs the core functions of version verification and update execution. It first obtains the software version of the pre-written initial software in the vehicle controller, compares it with the software version of the first software, and if they are inconsistent, retrieves the first software based on the first storage address and updates the initial software in the vehicle controller to this first software. Through the end-to-end design of order triggering, information matching, version verification, and differentiated updates, the system avoids indiscriminate overwriting of the initial software that meets user needs by uniform write operations, reducing invalid write operations and improving vehicle production efficiency.

[0044] Figure 1 This is a schematic diagram illustrating an application scenario provided in an embodiment of this application. Please refer to [link / reference]. Figure 1 The vehicle controller software management system can generate a software order based on the user's configuration operation. In response to the software order, it obtains the software version V2 corresponding to the target software. Then, it performs version verification between the software version V2 and the software version V1 of the initial software pre-written in the vehicle controller. Finally, when it is determined that an update is needed, it updates the initial software in the vehicle controller to the target software.

[0045] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0046] Figure 2 This is a schematic diagram of the structure of an embodiment of the vehicle controller software management system provided in this application. Please refer to [link / reference]. Figure 2 The vehicle controller software management system 10 may include an order management subsystem 11, a production management subsystem 12, an electrical inspection subsystem 13, and a product lifecycle management subsystem 14; among which,

[0047] The order management subsystem 11 is used to generate software orders for vehicle controllers in response to user configuration operations.

[0048] Specifically, users who have a need to purchase a vehicle can, with the assistance of vehicle sales personnel, perform personalized configuration operations in the order management subsystem 11. The order management subsystem 11 can then respond to the user's configuration operations and generate a software order for the vehicle controller. This software order may include the vehicle controller's software configuration information.

[0049] Optionally, the software configuration information can be specifically the configuration options that the user selects in the order management subsystem 11, which are directly bound to the vehicle controller hardware model and hardware function. The user clarifies their own needs by selecting these options, and the selection results directly correspond to the exclusive software configuration required for specific hardware.

[0050] For example, the order management subsystem can provide options for selecting different levels of driver assistance functions, including Basic Assistance, Advanced Assistance, and High-Level Assistance. The corresponding vehicle controller is the Advanced Driver Assistance Systems (ADAS) controller. Different options selected by the user correspond to different versions of dedicated software configurations. For example, selecting "Basic Assistance" corresponds to "ADAS Control Software V1.0," which includes cruise control and lane departure warning functions; selecting "Advanced Assistance" corresponds to "ADAS Control Software V2.0," which adds adaptive cruise control and lane centering assist functions; and selecting "High-Level Assistance" corresponds to "ADAS Control Software V3.0," which further adds automatic lane change assist and traffic jam assist functions.

[0051] For example, the order management subsystem can provide engine operating mode selection options, including basic energy-saving version, power performance version, and intelligent hybrid version. The corresponding vehicle controller is the engine control unit (ECU). If "basic energy-saving version" is selected, it corresponds to "engine control software V1.0", which includes basic fuel injection optimization and idle speed energy-saving control basic adaptation functions; if "power performance version" is selected, it corresponds to "engine control software V2.0", which adds turbocharger dynamic adjustment, throttle response acceleration algorithm, and high-speed power output optimization functions; if "intelligent hybrid version" is selected, it corresponds to "engine control software V3.0", which further adds oil-electric collaborative start-stop control, high-efficiency power generation mode adjustment, and hybrid system energy distribution logic functions.

[0052] In one alternative implementation, dedicated software precisely adapted to various types of vehicle hardware is often centrally stored in the software repository of the Product Lifecycle Management (PLM) subsystem for easy unified management, rapid retrieval, and version tracking. Therefore, it can be uniformly represented as standardized software materials within the system architecture. Each software material is clearly associated with the core information of the corresponding software, including a specific version and a unique storage address. Furthermore, each software material can also include software function adaptation instructions, providing a reliable data foundation for the subsequent production management subsystem to accurately match and retrieve the target software based on order requirements.

[0053] The production management subsystem 12 is used to obtain the software version and first storage address of the first software from the product lifecycle management subsystem 14 in response to a software order.

[0054] Optionally, the PLM subsystem 14 is connected to the order management subsystem 11. The PLM subsystem 14 pre-stores a bill of materials for the vehicle controller. The physical bill of materials includes the vehicle controller hardware and at least one software component compatible with the vehicle controller. Each software component has a clear mapping relationship, which is associated with specific software configuration options and includes the corresponding software version and storage address. The software configuration options associated with this mapping relationship can be synchronously provided to the order management subsystem 11 for users to select configuration options, so that the order management subsystem 11 can generate software orders based on the user's selections.

[0055] For example, through a preset mapping relationship, the software configuration options of the ADAS controller, such as the basic auxiliary version, the advanced auxiliary version and the high-level auxiliary version, can be clearly pointed to their respective software materials, and each software material includes the corresponding software and storage address.

[0056] In one specific implementation, the production management subsystem 12 can respond to the order management subsystem 11 generating a software order based on the user's selection result, obtain a bill of materials from the product lifecycle management subsystem 14, and determine at least one software material for the vehicle controller in the bill of materials; furthermore, it can determine a target software material among the at least one software material based on software configuration information, and determine the software version and first storage address of the first software in the target software material.

[0057] For example, if a user selects the "Advanced Assistance Version" software configuration option for the ADAS controller in the order management subsystem, the subsystem can generate a software order containing the core software configuration information of "ADAS Controller - Advanced Assistance Version". After responding to this software order, the production management subsystem first retrieves the bill of materials (BOM) for the ADAS controller from the PLM subsystem. This BOM contains three software materials bound to the "Basic Assistance Version", "Advanced Assistance Version", and "High-Level Assistance Version" software configuration options, respectively. Subsequently, the production management subsystem can accurately locate the target software material among these three materials based on the "Advanced Assistance Version" software configuration information in the software order, and finally extract the corresponding first software version (i.e., ADAS control software V2.0) and first storage address from the target software material.

[0058] In an alternative implementation, the production management subsystem 12 is further configured to generate a vehicle graphic code based on the software version of the first software and the first storage address.

[0059] The electrical inspection subsystem 13 is used to retrieve the first software based on a first storage address and update the initial software to the first software in the vehicle controller when the software version of the first software is inconsistent with the software version of the initial software pre-written in the vehicle controller. The electrical inspection subsystem 13 can be an end-of-line (EOL) electrical inspection device.

[0060] In one alternative implementation, the EOL electrical inspection equipment can read the vehicle graphic code generated by the production management subsystem 12 to obtain the software version of the first software.

[0061] In one specific implementation, when writing the initial software into the vehicle controller, the software version of the initial software can be embedded into the software program and the writing can be completed by using specific rules; the EOL electrical testing equipment can establish a connection with the vehicle, obtain the software version of the initial software from the vehicle controller, and then perform a consistency check with the first software version.

[0062] Optionally, specific rules can be defined as follows: a version identifier field (such as version number or version code) is preset in the program code of the initial software, and the version identifier is bound to the core program logic of the initial software and written together into the designated storage area of ​​the vehicle controller.

[0063] For example, for ADAS controllers, a "V0.0" version identifier field is preset in the program code of its initial software, and this field is bound to the minimum functional program that meets the basic hardware operation and written into the designated storage area of ​​the vehicle controller; subsequently, electrical tests and equipment can establish communication with the vehicle and directly read the version identifier field of the designated storage area to quickly obtain the software version of the initial software.

[0064] In one optional implementation, the EOL (Electronic Online Detection) device establishes a communication connection with the vehicle by establishing a wireless communication link with the vehicle's vehicle networking terminal T-BOX. Using the T-BOX's communication relay function, it sends a version read command to the vehicle controller, triggering the controller to read the version identifier field bound to the core program logic within a specified storage area. The controller then feeds back the initial software version read by the T-BOX to the EOL device. After receiving the initial software version, the EOL device can perform a consistency check with the first software version obtained from the vehicle's graphic code.

[0065] For example, the EOL (Electronic Online Detection) equipment can first read the vehicle graphic code generated by the production management subsystem to obtain the first software version as ADAS control software V2.0. Subsequently, the EOL equipment establishes a wireless communication link with the vehicle's vehicle networking terminal T-BOX, and reads the initial software version pre-written in the ADAS controller through the T-BOX. The reading result is ADAS control software V1.0. Then, the initial software version V1.0 can be checked for consistency with the first software version V2.0 obtained from the graphic code. After confirming that the two versions are inconsistent, the EOL equipment can retrieve the complete installation package of ADAS control software V2.0 from the software resource library of the PLM subsystem according to the obtained first storage address / PLM / ADAS / V2.0, and then transmit the installation package to the vehicle's ADAS controller through the communication link to perform a software update operation, replacing the original initial software V1.0 in the controller with the first software V2.0. Specifically, the software resource library of the PLM subsystem can be a standardized digital warehouse built into the PLM subsystem for centralized storage and management of dedicated software resources for all types of vehicle controllers.

[0066] The vehicle controller software management system provided in this application may include: an order management subsystem, a production management subsystem, an electronic inspection subsystem, and a product lifecycle management subsystem. The order management subsystem can generate a software order for the vehicle controller in response to user configuration operations. The production management subsystem can retrieve the software version and first storage address of the first software from the product lifecycle management subsystem in response to the software order. When the software version of the first software is inconsistent with the software version of the initial software pre-written in the vehicle controller, the electronic inspection subsystem can retrieve the first software based on the first storage address and update the initial software to the first software in the vehicle controller. This system, by using version verification-based differential updates through the electronic inspection subsystem to replace traditional full-scale flashing, can significantly reduce production resource waste and time costs, and improve vehicle production efficiency.

[0067] Figure 3This is a schematic diagram of the structure of Embodiment 2 of the vehicle controller software management system provided in this application. Please refer to [link / reference]. Figure 3 ,exist Figure 2 Based on the embodiment shown, the vehicle controller software management system 10 also includes an after-sales management subsystem 15, which is used to receive software version records uploaded by the electrical inspection subsystem. The software version records include the current software version of the vehicle controller.

[0068] In one specific implementation, after the electronic inspection subsystem 13 updates the initial software in the vehicle controller to the first software, it can generate a software version record that shows the current software version of the vehicle controller and upload it to the after-sales management subsystem 15. Furthermore, if the software version of the first software matches the software version of the initial software pre-written in the vehicle controller, a software version record that shows the current software version of the vehicle controller can also be generated. This allows the after-sales management subsystem 15 to quickly retrieve and verify the record in subsequent vehicle repairs, controller replacements, and other after-sales scenarios. Simultaneously, it enables full lifecycle traceability of the vehicle controller software version, providing accurate historical data support for quality control, software iteration optimization, fault diagnosis, and compliance auditing in the production process, ensuring the traceability, standardization, and accuracy of the vehicle software configuration management.

[0069] The after-sales management subsystem 15 is also used to obtain the software version record of the software installed in the new vehicle controller through the vehicle network terminal when the vehicle controller is replaced with a new vehicle controller, and to verify the software version of the installed software through the software version record to determine whether to update the software of the new vehicle controller.

[0070] For example, when a vehicle controller experiences a hardware failure and is replaced, the initial software pre-installed in the new controller is typically a generic version that meets the basic hardware requirements (such as ADAS control software V0.0), which often differs from the target software version configured in the original vehicle order (i.e., the first software version corresponding to the original software order, such as ADAS control software V2.0). Direct use of the new controller could lead to the inability to implement the exclusive functions agreed upon in the original order (such as advanced driver assistance), or problems such as software incompatibility with other vehicle systems and functional failures. Therefore, the after-sales management subsystem can establish a communication connection with the newly replaced vehicle controller via the T-BOX to read the software version of the initial software already installed within it. Simultaneously, the after-sales management subsystem can retrieve the vehicle's software version record (which is associated with the software configuration information of the original order and the corresponding target software version), and perform a consistency check between the read initial software version and the target software version in the software version record to determine whether a software update is needed for the new vehicle controller.

[0071] In one specific implementation, the software version record also includes the storage address of the current software. If the current software version included in the software version record is inconsistent with the software version of the installed software, the current software can be obtained according to the storage address of the current software, and the installed software can be updated to the current software in the new vehicle controller.

[0072] For example, the target software (i.e., the first software) of the ADAS controller configured in the original vehicle order is version V2.0. During the electrical inspection phase, the electrical inspection subsystem has entered this version information and the corresponding storage address " / PLM / ADAS / V2.0" into the software version record and uploaded it to the after-sales management subsystem. Subsequently, the vehicle's ADAS controller is replaced with a new device due to hardware failure. The initial software version pre-installed in the new controller is the general basic version V0.0. The after-sales management subsystem establishes a communication connection with the newly replaced ADAS controller through the T-BOX and reads that its installed software version is V0.0. Then, it retrieves the vehicle's software version record. When it finds that the current software version (V2.0) in the record is inconsistent with the installed version (V0.0) of the new controller, it can extract the associated storage address " / PLM / ADAS / V2.0" in the record and retrieve the complete installation package of ADAS control software V2.0 from the software resource library of the PLM subsystem. After the installation package is transferred to the new ADAS controller via T-BOX, the after-sales management subsystem triggers the software update process, replacing the initial software V0.0 in the new controller with the target software V2.0.

[0073] Furthermore, after the update is completed, the after-sales management subsystem 15 can synchronously update the vehicle's software version record to ensure that the record is consistent with the actual software version of the controller, ensuring that the advanced driving assistance functions agreed upon in the original vehicle order are in normal working order, while maintaining the integrity of the software version's full lifecycle traceability.

[0074] In one possible implementation, the vehicle controller software management system 10 further includes a software development management subsystem 16, which is used to generate at least one initial software material according to the software development requirements of the vehicle controller, and send the at least one initial software material to the product lifecycle management subsystem 14. The initial software material includes the software version and the software program.

[0075] Specifically, the software development management subsystem 16 may include functions such as requirements submission, software development, software testing, software release, software update, and code management, and can generate an initial software material when the software is released.

[0076] The product lifecycle management subsystem 14 is also used to standardize and encapsulate at least one initial software material received, generate at least one software material corresponding to the vehicle controller, and generate a bill of materials based on at least one software material, wherein the software material includes the software version and the storage address generated by storing the software program.

[0077] Specifically, the PLM subsystem 14 can be connected to the product lifecycle management subsystem 14 to send at least one initial software material corresponding to the vehicle controller to the PLM subsystem 14. For any initial software material, the PLM subsystem 14 can store the software program in the initial software material in the software resource library, generate a unique storage address, and generate the corresponding software material based on the unique storage address and the corresponding software version.

[0078] Furthermore, the PLM subsystem 14 can obtain the Engineering Bill of Material (EBOM), which is associated with at least one software material and linked to the vehicle controller, as part of the host EBOM, thereby decoupling the hardware vehicle controller materials. In this case, the EBOM can include both the hardware materials of the engine controller and the corresponding software material, but the hardware and software materials can maintain independent identification and management logic.

[0079] For example, the engine controller corresponding to the vehicle engine assembly (main unit) has a hardware bill of materials (BOM) that includes the ECU hardware itself. The software development management subsystem can generate two initial software materials (including engine control software version V3.0 and the complete control program) based on the engine controller's power control requirements and send them to the PLM subsystem 14. Upon receiving the initial software material, the PLM subsystem 14 can store the complete control program in the software resource library, generating a unique storage address " / PLM / EngineECU / V3.0". It then associates and binds the "software version V3.0" with the "storage address / PLM / EngineECU / V3.0" to generate the corresponding standardized software material. Subsequently, the PLM subsystem 14 can add this software material to the engine controller's hardware EBOM, forming the engine controller's BOM.

[0080] In one possible implementation, the production management subsystem 12 is further configured to, in response to an updated software order, obtain the software version and second storage address of the second software from the product lifecycle management subsystem.

[0081] The production management subsystem 12 can monitor the order status changes of the order management subsystem 11 in real time. When the software order is updated (such as when the user adjusts the configuration options or the software iteration causes a change in requirements), it can receive the order update notification, extract the updated software configuration information, and clarify the core requirements of the order update.

[0082] For example, a user previously selected the "Advanced Assistance Version" (corresponding to software version V2.0) of the ADAS controller through the order management subsystem. After generating a software order, the user contacted marketing personnel to adjust the configuration to the "Advanced Assistance Version" due to an upgrade requirement. After the order management subsystem updates the software order, it can send an order update notification to the production management subsystem. Upon receiving the notification, the production management subsystem extracts the updated core software configuration information as "ADAS Controller - Advanced Assistance Version".

[0083] Furthermore, the production management subsystem 12 can initiate a target software query request to the PLM subsystem 14 based on the extracted updated software configuration information. The request explicitly carries key information about the updated software configuration options to ensure that the PLM subsystem accurately matches the target software. After receiving the query request, the PLM subsystem 14 can filter software materials in the software resource library that are fully compatible with the updated configuration information based on the mapping relationship between software materials and configuration options, extract the second software version and second storage address corresponding to the software material, and feed it back to the production management subsystem 12.

[0084] The production management subsystem 12 is also used to update the vehicle graphic code based on the software version of the second software and the second storage address.

[0085] Specifically, after the production management subsystem 12 obtains the second software version and the second storage address fed back by the PLM subsystem 14, it can load the original vehicle graphic code, replace the first software version and the first storage address recorded therein, and generate a new vehicle graphic code.

[0086] For example, the production management subsystem 12 previously generated a vehicle graphic code for the "ADAS controller - advanced auxiliary version", which included the software version "V2.0" and the storage address " / PLM / ADAS / V2.0". After obtaining the second software information of "ADAS control software V3.0" and " / PLM / ADAS / V3.0", the software version can be updated to "V3.0" and the storage address can be updated to " / PLM / ADAS / V3.0" based on the original graphic code, thus generating a new vehicle graphic code.

[0087] The vehicle controller software management system provided in this application may also include an after-sales management subsystem, responsible for receiving and storing the vehicle controller software version records uploaded by the electrical inspection subsystem. In after-sales vehicle controller replacement scenarios, the system obtains the pre-installed software version of the new controller through the vehicle network terminal and performs consistency verification with the historical version records. If the versions are inconsistent, the system retrieves the target software from the PLM subsystem based on the storage address in the record to complete the update and simultaneously updates the version records, achieving accurate adaptation of software configuration and data traceability in the after-sales process. This effectively ensures accurate matching between after-sales software and the original order configuration, avoids the risk of functional failure, achieves full lifecycle traceability of software versions, reduces after-sales maintenance costs, and improves the closed-loop system management.

[0088] In addition, the vehicle controller software management system provided in this application may also include a software development subsystem. The software development subsystem can complete the entire process management from requirements analysis, development testing to release archiving according to the specific software development requirements of the vehicle controller, generate initial software materials containing software version information and complete software programs, and push them to the product lifecycle management subsystem. This provides reliable resources for subsequent standardized software packaging, bill of materials construction and full-process retrieval, effectively supporting the system's full-scenario software configuration requirements.

[0089] Figure 4 This is a system architecture diagram of the vehicle controller software management system provided in an embodiment of this application. Please refer to [link / reference]. Figure 4 It includes a software development management subsystem, a PLM subsystem, a production management subsystem, an electrical inspection subsystem, an after-sales management subsystem, and an order management subsystem. The electrical inspection subsystem can specifically refer to EOL electrical inspection equipment.

[0090] The software development management subsystem can be used to develop the vehicle controller software. When the software is released, an initial software material is generated and transferred to the PLM subsystem.

[0091] The PLM subsystem can standardize and encapsulate at least one initial software material received, generating at least one software material corresponding to the vehicle controller, and generating a bill of materials based on at least one software material. The PLM subsystem can attach the software material to the hardware EBOM as part of the host EBOM. Different configurations and personalized requirements can be treated as attributes, and rules can be used to constrain and associate these attributes with the corresponding software.

[0092] Optionally, when the PLM subsystem converts the EBOM into the host EBOM, verification rules can be set to check the software materials of the vehicle controller in the EBOM. If the software materials are missing, the next step of the process cannot be carried out to prevent software omission.

[0093] Optionally, the vehicle controller software management system may also include a cost subsystem. In the PLM subsystem, the software materials of the vehicle controller may be assigned a valueless attribute to avoid the cost subsystem identifying software materials as generating costs and affecting cost accounting.

[0094] Specifically, the cost logic of software and hardware materials is completely different: hardware is a physical component, with clear material costs incurred during production and procurement, and each piece of hardware corresponds to an independent expenditure; while software is a digital resource that can be reused infinitely after one-time development, and does not generate additional incremental costs when subsequently installed in a vehicle. If a "no-value" attribute is not set for software materials, the cost subsystem may mistakenly equate them with hardware materials, either by double-counting costs or by adding an unnecessary expenditure, resulting in distorted overall vehicle cost data. Setting a "no-value" attribute allows cost accounting to focus only on the actual expenditure stages such as hardware procurement and production processing, ensuring the accuracy and reliability of the accounting results and providing an accurate basis for enterprise pricing, cost control, and other decisions.

[0095] The order management subsystem is connected to the PLM subsystem. Different configurations and personalized requirements in the PLM can be used as options when marketing personnel place orders. After configuring and personalizing the order, marketing personnel send the software order to the production management subsystem. The production management subsystem can generate an order BOM containing the corresponding software materials, which can be printed out as a vehicle delivery note.

[0096] The EOT electrical inspection equipment can read the vehicle's accompanying documents to obtain the software version of the first software. At the same time, the EOT electrical inspection equipment can establish a communication connection with the vehicle and read the software version of the initial software pre-written in the vehicle controller through the vehicle network terminal. When the software version of the first software is inconsistent with the software version of the initial software pre-written in the vehicle controller, the initial software in the vehicle controller is updated.

[0097] The after-sales management subsystem can be connected to the electronic inspection subsystem to receive software version records uploaded by the electronic inspection subsystem. The software version records include the current software version of the vehicle controller. In addition, the after-sales management subsystem can also use T-BOX to obtain the software version that was written into the initial software of the vehicle controller according to specific rules.

[0098] When after-sales maintenance occurs, such as when the vehicle controller has been replaced, the after-sales management subsystem can verify the software version record (including the current software version and the current software storage address) obtained from the electrical inspection subsystem and the software version of the installed software uploaded via T-BOX (i.e., the software version of the initial software in the replaced vehicle controller). If the verification is inconsistent, the current software can be obtained based on the current software storage address, and the installed software in the new vehicle controller can be updated to the current software. After the update is completed, the after-sales management subsystem can generate a software update record to ensure that the software information is controllable throughout the vehicle's entire life cycle.

[0099] The vehicle controller software management system provided in this application integrates software development management, PLM, order management, production, EOL (End-of-Life) electrical inspection, after-sales service, and optional cost subsystems to form a closed-loop control system for the entire process. The software development management subsystem generates initial software materials, which are then standardized and packaged by the PLM subsystem and added to the hardware EBOM (Entity Back Order). It can also set verification rules for converting the hardware EBOM to the host EBOM to prevent software omissions and assign non-value attributes to the software to ensure accurate cost accounting. The order management subsystem connects to the PLM configuration options to generate software orders. The production management subsystem generates the order BOM and accompanying documents. The EOL electrical inspection equipment verifies the vehicle controller version against the accompanying documents and updates the software accordingly. The after-sales management subsystem, relying on version records and T-BOX, completes software verification and updates when the vehicle controller is replaced, achieving controllable software information throughout the vehicle's entire lifecycle.

[0100] Figure 5 This is a schematic diagram illustrating the implementation principle of the vehicle controller software management system provided in this application embodiment. Please refer to [link / reference]. Figure 5 The implementation principle of the vehicle controller software management system can include software development and packaging, order and production flow, electrical inspection and software update, and after-sales traceability.

[0101] The software development and packaging process can include: the software development management subsystem can generate initial software materials based on the development requirements of different software configurations, standardize and package the initial software materials to obtain software materials, and integrate the software materials and hardware controller materials into the host EBOM.

[0102] For example, the software development management subsystem can generate initial software materials for configuration A based on the development requirements of ADAS controller A's configuration software; and it can generate initial software materials for configuration B based on the development requirements of ADAS controller B's configuration software. The initial software materials for configuration A can include the A software program and its software version, while the initial software materials for configuration B can include the B software program and its software version.

[0103] Furthermore, the initial software material for configuration A can be standardized and packaged to obtain the software material for configuration A, and the initial software material for configuration B can be standardized and packaged to obtain the software material for configuration B. The software material for configuration A can be bound with "configuration attribute A", and the software material for configuration B can be bound with "configuration attribute B", thus realizing the logical association between configuration and software. Subsequently, the software materials for configuration A and configuration B can be integrated with the ADAS controller into the host EBOM (Get Bill of Materials).

[0104] The order and production flow process can include: order placement and BOM generation.

[0105] For example, the order management subsystem can convert configuration attributes A and B in the PLM into selectable configuration options. After the user or marketing personnel completes the configuration selection, the software order is sent to the production management subsystem. If the user selects the ADAS advanced assistance version, the software order will be sent with the "A configuration" identifier.

[0106] Furthermore, the production management subsystem can generate an A configuration order BOM based on the order configuration (A configuration), including hardware ADAS controller materials and A configuration software materials, and output the accompanying vehicle manifest.

[0107] In addition, when converting hardware EBOM and software materials into host EBOM in the PLM subsystem, verification rules can be set to check the controller software materials in the hardware EBOM. If there are no software materials, they cannot be transferred to the next level to prevent software omission. At the same time, software materials are assigned a valueless attribute to avoid the financial system recognizing software materials as incurring costs or being unable to transfer to the next level, which would affect financial settlement.

[0108] The electrical inspection and software update process may include: information reading and version comparison.

[0109] For example, the EOL electrical inspection equipment can read the A configuration software information (version V2.0, storage address) in the vehicle order, and at the same time read the initial software version (such as V0.0) pre-written in the actual vehicle through the vehicle T-BOX; if the actual vehicle version (V0.0) is inconsistent with the order software version (V2.0), the EOL equipment retrieves the A configuration software through the storage address, performs a software flashing operation, and updates the actual vehicle software to V2.0; if they are consistent, it directly reports "software matching, vehicle off the line".

[0110] After-sales traceability can include: version records and after-sales verification.

[0111] For example, after the actual vehicle software is updated, the version information (V2.0) can be uploaded to the after-sales management subsystem via T-BOX to generate a software version record. If the vehicle's ADAS controller is subsequently replaced, the after-sales management subsystem can read the initial software version of the new controller (such as V0.0) via T-BOX and compare it with the historical record (V2.0). If they are inconsistent, the A configuration software (V2.0) in the storage address is retrieved to complete the update, ensuring that the after-sales software is consistent with the original order configuration.

[0112] Regarding after-sales inspection, in one specific implementation, if the actual vehicle software version obtained by the after-sales management subsystem through T-BOX is inconsistent with the generated software version record, the after-sales management subsystem can automatically provide a flag prompt, and then the service personnel can intervene to handle the issue and retrieve the A configuration software (V2.0) from the storage address to complete the update.

[0113] The implementation principle, execution process and beneficial effects of the vehicle controller software management system provided in this application embodiment can be referred to the technical solution of the above system embodiment, and will not be repeated here.

[0114] Figure 6 This is a flowchart illustrating the vehicle controller software management method provided in an embodiment of this application. Please refer to [link / reference]. Figure 6 The vehicle controller software management method is applied to a vehicle controller software management system, which includes: an order management subsystem, a production management subsystem, an electrical inspection subsystem, and a product lifecycle management subsystem; the vehicle controller software management method may include:

[0115] S601, in response to the user's configuration operation, generates a software order for the vehicle controller.

[0116] Specifically, the order management subsystem can generate software orders for vehicle controllers in response to user configuration operations.

[0117] S602, In response to a software order, obtain the software version and the first storage address of the first software.

[0118] Specifically, the production management subsystem can respond to a software order by obtaining the software version and first storage address of the first software from the product lifecycle management subsystem.

[0119] In one alternative implementation, the production management subsystem may, in response to a software order, obtain a bill of materials from the product lifecycle management subsystem and identify at least one software material for the vehicle controller in the bill of materials; determine a target software material among the at least one software material based on the software configuration information included in the software order, and determine the software version and first storage address of the first software in the target software material.

[0120] Optionally, the production management subsystem can also generate vehicle graphic codes based on the software version and storage address of the first software.

[0121] S603. When the software version of the first software is inconsistent with the software version of the initial software pre-written in the vehicle controller, the first software is obtained according to the first storage address, and the initial software is updated to the first software in the vehicle controller.

[0122] Specifically, when the software version of the first software is inconsistent with the software version of the initial software pre-written in the vehicle controller, the electronic inspection subsystem can retrieve the first software based on the first storage address and update the initial software to the first software in the vehicle controller.

[0123] Optionally, before comparing the software version of the first software with the software version of the initial software pre-written in the vehicle controller, the electronic inspection subsystem can also read the vehicle graphic code to obtain the software version of the first software; and obtain the software version of the initial software in the vehicle controller.

[0124] The vehicle controller software management method provided in this application embodiment can be referred to the technical solution shown in the above system embodiment in terms of its execution process. The implementation principle and beneficial effects are similar, and will not be repeated here.

[0125] In one optional implementation, the vehicle controller software management system further includes an after-sales management subsystem, and the vehicle controller software management method may further include:

[0126] The after-sales management subsystem can receive software version records uploaded by the electrical inspection subsystem, which include the current software version of the vehicle controller.

[0127] In one alternative implementation, the after-sales management subsystem can also obtain the software version of the software already installed in the new vehicle controller through the vehicle network terminal when the vehicle controller is replaced with a new vehicle controller, and verify the software version of the installed software through the software version record to determine whether to update the software of the new vehicle controller.

[0128] In practice, the software version record also includes the storage address of the current software. The software version record is used to verify the software version of the installed software to determine whether to update the software of the new vehicle controller. Specifically, if the current software version included in the software version record is inconsistent with the software version of the installed software, the current software is obtained according to the storage address of the current software version, and the installed software is updated to the current software in the new vehicle controller.

[0129] In one optional implementation, the vehicle controller software management system further includes a software development management subsystem, and the vehicle controller software management method may further include:

[0130] The development management subsystem can generate at least one initial software material based on the software development requirements of the vehicle controller, and send at least one initial software material to the product lifecycle management subsystem. The initial software material includes the software version and the software program.

[0131] The product lifecycle management subsystem can also standardize and encapsulate at least one initial software material received, generate at least one software material corresponding to the vehicle controller, and generate a bill of materials based on at least one software material. The software material includes the software version and the storage address generated by storing the software program.

[0132] In an alternative implementation, the production management subsystem may also, in response to an updated software order, obtain the software version and second storage address of the second software from the product lifecycle management subsystem.

[0133] The production management subsystem can also update the vehicle graphic code based on the software version and second storage address of the second software.

[0134] In one alternative implementation, the electrical inspection subsystem is an end-of-line electrical inspection device.

[0135] The vehicle controller software management method provided in this application embodiment can be referred to the technical solution shown in the above system embodiment in terms of its execution process. The implementation principle and beneficial effects are similar, and will not be repeated here.

[0136] This application also provides a vehicle controller software management device, wherein the vehicle controller software management device runs a program such as... Figure 2 or Figure 3 The vehicle controller software management system shown is used to implement the vehicle controller software management method described in the above embodiments.

[0137] It should be noted that when the electrical inspection subsystem in the vehicle controller software management system is an EOL electrical inspection device, this vehicle controller software management device can integrate the core functional modules of the order management subsystem, production management subsystem, PLM subsystem, software development subsystem, and after-sales management subsystem, running the complete vehicle controller software management system on the hardware device. As a key execution terminal of the system, the EOL electrical inspection device directly undertakes core operations such as reading the vehicle image code (accompanying document), reading the initial software version of the vehicle controller, and software differentiation updates. Through communication and linkage with the T-BOX, it achieves precise adaptation of software version verification in the production process and after-sales replacement scenarios.

[0138] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the vehicle controller software management method described above.

[0139] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described vehicle controller software management method.

[0140] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0141] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0142] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0143] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0144] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0145] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part 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 of the various embodiments of this invention. 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.

[0146] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0147] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A vehicle controller software management system, characterized in that, The vehicle controller software management system includes: an order management subsystem, a production management subsystem, an electrical inspection subsystem, and a product lifecycle management subsystem; The order management subsystem is used to generate a software order for the vehicle controller in response to the user's configuration operation. The production management subsystem is used to, in response to the software order, obtain the software version and first storage address of the first software from the product lifecycle management subsystem; The electrical testing subsystem is used to, when the software version of the first software is inconsistent with the software version of the initial software pre-written in the vehicle controller, retrieve the first software according to the first storage address, and update the initial software to the first software in the vehicle controller.

2. The vehicle controller software management system according to claim 1, characterized in that, The software order includes software configuration information. The step of obtaining the software version and first storage address of the first software from the product lifecycle management subsystem in response to the software order includes: In response to the software order, a bill of materials is obtained from the product lifecycle management subsystem, and at least one software material for the vehicle controller is identified in the bill of materials; Based on the software configuration information, a target software material is determined from the at least one software material, and the software version and first storage address of the first software are determined from the target software material.

3. The vehicle controller software management system according to claim 1 or 2, characterized in that, The production management subsystem is also used to generate a vehicle graphic code based on the software version and the first storage address of the first software. The electronic inspection subsystem is also used to read the vehicle graphic code to obtain the software version of the first software. The electrical inspection subsystem is also used to obtain the software version of the initial software in the vehicle controller.

4. The vehicle controller software management system according to claim 1 or 2, characterized in that, The vehicle controller software management system also includes an after-sales management subsystem, which is used to receive software version records uploaded by the electrical inspection subsystem. The software version records include the current software version of the vehicle controller.

5. The vehicle controller software management system according to claim 4, characterized in that, The after-sales management subsystem is also used to, when the vehicle controller is replaced with a new vehicle controller, obtain the software version of the software already installed in the new vehicle controller through the vehicle network terminal, verify the software version of the installed software through the software version record, and determine whether to update the software of the new vehicle controller.

6. The vehicle controller software management system according to claim 5, characterized in that, The software version record also includes the storage address of the current software; the step of verifying the software version of the installed software through the software version record to determine whether to update the software of the new vehicle controller includes: If the current software version included in the software version record is inconsistent with the software version of the installed software, then the current software is obtained according to the storage address of the current software version, and the installed software is updated to the current software in the new vehicle controller.

7. The vehicle controller software management system according to claim 2, characterized in that, The vehicle controller software management system further includes a software development management subsystem, which is used to generate at least one initial software material according to the software development requirements of the vehicle controller, and send the at least one initial software material to the product lifecycle management subsystem. The initial software material includes the software version and the software program. The product lifecycle management subsystem is also used to standardize and encapsulate the received at least one initial software material to generate at least one software material corresponding to the vehicle controller, and generate the bill of materials based on the at least one software material, wherein the software material includes the software version and the storage address generated by storing the software program.

8. The vehicle controller software management system according to claim 1 or 2, characterized in that, The production management subsystem is also used to, when the software order is updated, retrieve the software version and the second storage address of the second software from the product lifecycle management subsystem in response to the updated software order; The production management subsystem is also used to update the vehicle graphic code based on the software version and the second storage address of the second software.

9. The vehicle controller software management system according to claim 8, characterized in that, The electrical inspection subsystem is an electrical inspection device at the end of the production line.

10. A vehicle controller software management method, characterized in that, The method is applied to the vehicle controller software management system according to any one of claims 1-9; the method includes: In response to the user's configuration operation, a software order for the vehicle controller is generated; In response to the software order, obtain the software version and first storage address of the first software; When the software version of the first software is inconsistent with the software version of the initial software pre-written in the vehicle controller, the first software is retrieved according to the first storage address, and the initial software is updated to the first software in the vehicle controller.

Images