Vehicle software management method, system, device and computer readable storage medium

Abstract

The application discloses a whole vehicle software management method, system, device and computer readable storage medium, and belongs to the technical field of whole vehicle software management. The method comprises the following steps: establishing and maintaining a whole vehicle function baseline, storing and distributing software version packages, and performing data transmission and function management; dividing a whole vehicle function unit into atomic function units and performing version management, and establishing a first dependency relationship between the atomic function units; performing independent testing and gray release of the atomic function units; and supporting dynamic combination and online upgrading of the atomic function units. By disassembling whole vehicle user functions into atomic function units and performing version management on each atomic function unit, the functions and the software are decoupled, the shortcoming of strong coupling between functions and specific ECU software in traditional firmware package version management is overcome, flexible management and upgrading of the functions are realized, and the increasingly complex vehicle function requirements and the rapid iteration software updating requirements are met.

Description

Technical Field

[0001] This invention relates to the field of vehicle software management technology, and in particular to a vehicle software management method, system, device, and computer-readable storage medium. Background Technology

[0002] With the accelerated development of intelligent, connected, and electrified vehicles, software-defined vehicles have become the foundation and core of future vehicle intelligence.

[0003] Against this backdrop, Over-the-Air (OTA) technology for vehicles serves as a crucial channel for automotive software upgrades, its value lying in remotely flashing new software into the vehicle. However, current vehicle software management methods still suffer from the following problems: existing technologies typically employ firmware packages for version management, resulting in strong coupling between functions and specific ECU software, leading to long delivery cycles for new features. Summary of the Invention

[0004] The purpose of this invention is to provide a vehicle software management method, system, device, and computer-readable storage medium to solve the problem of long delivery cycles for new functions caused by strong coupling between functions and specific ECU software.

[0005] To address the aforementioned technical problems, the present invention provides a vehicle software management method, comprising: establishing and maintaining a vehicle functional baseline using a central management platform; storing and distributing software version packages using a cloud server; performing data transmission and function management using an in-vehicle gateway; dividing vehicle functional units into atomic functional units, managing the version of each atomic functional unit, and establishing a first dependency relationship between the atomic functional units; conducting independent testing and canary release of the atomic functional units; and supporting dynamic combination and online upgrades of the atomic functional units.

[0006] This technical solution has at least the following beneficial effects: by decomposing the user functions of the whole vehicle into atomic functional units and performing version management for each atomic functional unit, the functions and software are decoupled, overcoming the shortcomings of strong coupling between functions and specific ECU software in traditional firmware package version management, realizing flexible management and upgrade of functions, and meeting the increasingly complex vehicle function requirements and rapid software update requirements.

[0007] Optionally, the use of an in-vehicle gateway for data transmission and function management includes: Configure the network parameters of the vehicle gateway via serial communication; Set up a data transmission channel to establish a communication connection between the atomic functional unit and the central management platform.

[0008] Optionally, the step of dividing the vehicle's functional units into atomic functional units and performing version management on each atomic functional unit includes: The vehicle user functions are broken down into atomic functional units that can call cross-domain services; Assign an independent version number to each of the atomic functional units; Configure the second dependency relationship between the atomic functional unit and the underlying service.

[0009] Optionally, configuring the second dependency relationship between the atomic functional unit and the underlying service includes: Establish a dependency tree, where the leaf nodes are the atomic functional units and the parent nodes are the functional units that the atomic functional units depend on. The dependency tree is managed using a dependency management tool.

[0010] Optionally, establishing the first dependency relationship between the atomic functional units includes: Establish the calling relationships between the atomic functional units; Define the interface specifications for the atomic functional units; The atomic functional units communicate with each other in a loosely coupled manner.

[0011] Optionally, the independent testing of the atomic functional units includes: Download the test environment configuration file from the cloud server; Unit tests and integration tests of the atomic functional units are performed in a test environment; The test results are fed back to the central management platform through the vehicle gateway.

[0012] Optionally, the method further includes remote start / stop via a function switch, wherein remote start / stop via a function switch includes: Establish a functional switch management system; Configure the function switch status via the cloud server; The status of the function switch is read and updated through the vehicle gateway.

[0013] A second aspect of the present invention provides a vehicle software management system, comprising: The service module is used for: establishing and maintaining the vehicle's functional baseline using a central management platform; storing and distributing software version packages using cloud servers; and using in-vehicle gateways for data transmission and function management. The software upgrade module is used to: divide the vehicle's functional units into atomic functional units, manage the version of each atomic functional unit, and establish the first dependency relationship between the atomic functional units; perform independent testing and canary release of the atomic functional units; and support the dynamic combination and online upgrade of the atomic functional units.

[0014] A third aspect of the present invention provides an apparatus including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform any of the above-described vehicle software management methods.

[0015] A fourth aspect of the present invention provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute any of the above-described vehicle software management methods when run on a computer or processor. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings: Figure 1 This is a flowchart of a vehicle software management method according to an embodiment of the present invention; Figure 2 This is a schematic diagram illustrating the relationship between the cloud and the vehicle in an embodiment of the present invention; Figure 3 This is a structural block diagram of the vehicle software management system according to an embodiment of the present invention. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0019] According to an embodiment of the present invention, an embodiment of a vehicle software management method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system containing at least one set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0020] This method embodiment can also be executed in an electronic system / device containing a memory and a processor, a similar control system, or in the cloud. Taking an electronic system / device as an example, the electronic system / device may include one or more processors and a memory for storing data. Optionally, the aforementioned electronic system / device may also include communication devices for communication functions and display devices. Those skilled in the art will understand that the above structural description is merely illustrative and does not limit the structure of the aforementioned electronic system / device. For example, the electronic system / device may also include more or fewer components than those described above, or have a different configuration than those described above.

[0021] A processor may include one or more processing units. For example, a processor may include a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processing (DSP) chip, a microcontroller unit (MCU), a field-programmable gate array (FPGA), a neural network processing unit (NPU), a tensor processing unit (TPU), and artificial intelligence (AI) type processors, etc. Different processing units may be independent components or integrated into one or more processors. In some instances, an electronic system may also include one or more processors.

[0022] The memory can be used to store computer programs, such as the computer program corresponding to the device control method in the embodiments of the present invention. The processor implements the aforementioned device control method by running the computer program stored in the memory. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the electronic system via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0023] like Figure 1 and Figure 2 As shown, a vehicle software management method includes the following steps: Step S100: Establish and maintain the vehicle's functional baseline using a central management platform; store and distribute software version packages using a cloud server; and use an in-vehicle gateway for data transmission and function management.

[0024] Specifically, when establishing the central management platform, the distributed database MySQL is used as the backend database. The central management platform is used to establish and maintain the vehicle functional baseline. The vehicle functional baseline is a complete and solidified description of the software version, hardware bill of materials (BOM), calibration parameters, communication matrix and functional logic of all electronic control units (ECUs) of the vehicle. It can be used as a design benchmark for engineering development, and also as a version management anchor point for OTA upgrades.

[0025] Cloud servers are used to store and distribute software version packages (tested upgrade packages). Storage space is created on the cloud server, security access permissions are set, and the software version packages are uploaded to the cloud server, which then handles the distribution. Simultaneously, the stability of the cloud server needs to be verified, and a stable network connection must be ensured. For example, when setting up a cloud server, an Alibaba Cloud ECS instance can be used as a virtual server in the cloud, offering high flexibility.

[0026] In one embodiment, the network parameters of the vehicle gateway can be configured via serial communication, data transmission channels can be set, and TCP / IP communication connections can be established between various components, such as atomic functional units, and the central management platform. Serial communication reduces the number of signal lines, saves microcontroller pin resources and PCB (printed circuit board) space, and lowers hardware costs. Simultaneously, the communication function of the vehicle gateway needs to be verified to ensure normal data transmission. For example, when configuring the vehicle gateway, a Linux-based network connection device is used, with the vehicle gateway used for data transmission and function management.

[0027] Step S200: Divide the vehicle functional units into atomic functional units, manage the version of each atomic functional unit, and establish the first dependency relationship between atomic functional units.

[0028] Specifically, the vehicle's user functions are broken down into atomic functional units that can call cross-domain services, such as vehicle electronic equipment (ECU) software, in-vehicle communication software, and driver assistance system software. Each atomic functional unit is assigned an independent version number, such as V1.0.0, V2.0.0, and V3.0.0. A naming convention for version numbers is established, containing a major version number, a minor version number, and a fix version number. For example, in V1.0.0, the first, second, and third digits correspond to the major, minor, and fix version numbers, respectively. The major version number represents significant performance improvements and added features; the minor version number represents functional logic modifications and optimizations; and the fix version number represents problem resolution and bug fixes. Furthermore, an independent version management branch is created for each atomic functional unit, ensuring that version number management is independent between atomic functional units.

[0029] In one embodiment, a second dependency relationship between the atomic functional unit and the underlying service also needs to be configured.

[0030] Specifically, the dependencies between atomic functional units and underlying services are identified, and a dependency tree is built based on these dependencies. For example, in the dependency tree, leaf nodes represent atomic functional units, and parent nodes are the functional units they depend on. Dependency management tools are used to manage these dependencies. For example, Maven can be used, enforcing a standard directory structure, resulting in a clear project structure and lower team collaboration costs. Alternatively, Gradle can be used, offering greater flexibility and allowing for programmable logic in the build scripts.

[0031] Establishing the first dependency relationship between atomic functional units includes: establishing the calling relationship between atomic functional units, defining the interface specifications of atomic functional units, and establishing loosely coupled communication between atomic functional units.

[0032] Specifically, when establishing the calling relationships between atomic functional units, the calling relationships are defined using an Interface Definition Language (IDL), including interface name, method name, parameters, and return value. In addition, a calling relationship database is established to record the calling relationships of each atomic functional unit.

[0033] Specifically, when defining the interface specifications for atomic functional units, the interface specifications for the atomic functional units should be formulated, including data format, communication protocol (such as CAN bus, Ethernet, etc.), and error handling mechanism. In addition, it is necessary to verify the correctness of the interface specifications to ensure that different atomic functional units can communicate correctly.

[0034] Specifically, when atomic functional units communicate loosely, lightweight containerization technology can be used to achieve loosely coupled deployment of atomic functional units, ensuring isolation and resource independence between them. For example, Docker can be used to package the atomic functional unit and all its dependencies and information into a lightweight, independent container, thereby achieving fast and reliable operation in any computing environment. For example, lightweight containerized OTA implementation involves three steps: service decomposition (decoupling monolithic software into independent microservices), container encapsulation (creating each service into a lightweight Docker image and setting resource boundaries), and declarative deployment (differential distribution of incremental packages from the cloud, with the vehicle pulling updates according to the list, and rolling back within seconds in case of failure).

[0035] Step S300: Perform independent testing and grayscale release of atomic functional units.

[0036] In one embodiment, performing independent testing of atomic functional units may include: downloading a test environment configuration file via a cloud server, performing unit testing and integration testing of the atomic functional units in the test environment, and feeding the test results back to the central management platform via an in-vehicle gateway.

[0037] Specifically, when downloading the test environment configuration file from the cloud server, the test environment configuration file, including network configuration, environment variables, and test data, is downloaded from the cloud server; the correctness of the test environment is verified, and the consistency of the test environment is ensured.

[0038] Specifically, when performing unit testing of atomic functional units in a test environment, unit tests and integration tests are performed within the test environment, and test cases are executed using a test framework. For example, the test framework can be JUnit, which features simplified test writing, rich assertions, management of pre- and post-test states, automated execution, and timely feedback, making the testing of atomic functional units simpler, more automated, and reusable. Alternatively, the test framework can be Pytest, which features a very low barrier to entry, powerful failure diagnosis capabilities, and a highly scalable architecture, improving test coverage of atomic functional units. Furthermore, test results and fault information are recorded.

[0039] Specifically, when the test results are fed back to the central management platform via the vehicle-mounted gateway, the test results of the atomic functional units are also fed back to the central management platform via the vehicle-mounted gateway. The test results include test pass rate, fault information, and performance indicators. By analyzing the test results, it can be confirmed that the test pass rate has reached the preset threshold, ensuring the quality, maintainability, and development efficiency of the atomic functional units.

[0040] Gray release refers to a testing process that applies to a small number of vehicles in a small area. Once the pass rate reaches a threshold, the upgraded package or baseline version of the function will be used on a large scale.

[0041] Step S400 supports dynamic combination and online upgrade of atomic functional units.

[0042] During the continuous development and improvement of software, different atomic functional units can be combined into upgrade packages based on vehicle model and functional requirements. Version control tools can then be used to manage the version history of these upgrade packages. For example, Git, a distributed version control system, can be used as the version control tool. Git has advantages such as strong branching capabilities, low network dependency, and extremely fast local operations, enabling it to better manage the versions of atomic functional units that can call cross-domain services.

[0043] After the required upgrade package is created, it is distributed via a cloud server. Download permissions and download limits are set to ensure the compatibility and availability of the upgrade package. Furthermore, the integrity and compliance of the upgrade package need to be verified. Integrity is verified both before and after distribution; it is verified by the cloud server before release and by the vehicle-side during download after release. Compliance is verified after the upgrade package is distributed.

[0044] During online software upgrades, the upgrade package is received and executed via an OTA client, including steps such as version lookup, download, installation, and restart. Additionally, status information and error logs are recorded during the upgrade process; the status information includes a set of version numbers for each atomic functional unit.

[0045] After the software upgrade is complete, the functional baseline version of the central management platform is updated, which includes the vehicle's functional baseline and version information. Furthermore, the functional baseline version is updated at the start of testing; if testing fails, the upgrade package is discarded and not released to users. This includes the addition of new features, bug fixes, and optimizations. The correctness of the baseline version is also verified to ensure version consistency.

[0046] This invention decouples the functions of the entire vehicle user system into atomic functional units and performs version management for each atomic functional unit. This overcomes the shortcomings of traditional firmware package version management, which involves strong coupling between functions and specific ECU software. It enables flexible management and upgrades of functions, meeting the increasingly complex vehicle functional requirements and the need for rapid software updates.

[0047] In one embodiment, the vehicle software management method further includes remote start / stop via a function switch.

[0048] Remote start / stop via function switches includes: establishing a function switch management system, configuring function switch status via a cloud server, and reading and updating function switch status via an in-vehicle gateway.

[0049] Specifically, when establishing a function switch management system, a distributed lock mechanism is used to achieve mutual exclusion access; default function switch states and access control rules are set. Specifically, when configuring function switch states via a cloud server, these states include active, disabled, and standby states. This allows for remote enabling or disabling of functions or adjustment of configuration parameters without modifying code or redeploying the application. This can be used for canary releases, rapid troubleshooting of online issues, and simplified operation and configuration; the response speed and stability of function switches are verified. Specifically, when reading and updating function switch states via an in-vehicle gateway, operations such as status query, modification, and reset are performed; the real-time performance and reliability of function switches are verified.

[0050] Remote start and stop of functions can be achieved through function switches, supporting on-demand delivery and personalized subscription of functions, overcoming the shortcomings of traditional technologies that cannot support function-level subscription.

[0051] This invention decouples functionality from software, supports on-demand delivery of functionality and personalized subscriptions, greatly reduces OTA risks, and enhances the agility and commercial value of software iteration.

[0052] By breaking down the vehicle user functions into atomic functional units that can call cross-domain services and assigning an independent version number to each atomic functional unit, the decoupling of functions and software is achieved, overcoming the shortcomings of strong coupling between functions and specific ECU software in traditional firmware package version management.

[0053] Furthermore, the independent versioning management mechanism based on atomic functional units enables flexible management and rapid iteration of software versions, effectively solving the problems of complex software version management and low OTA efficiency in existing technologies. By dividing the vehicle's functions into atomic functional units that can call cross-domain services, flexible management and upgrades of functions are achieved, meeting the increasingly complex vehicle functional requirements and the need for rapid software updates.

[0054] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0055] This embodiment also provides a vehicle software management system for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" refers to a combination of software and / or hardware capable of performing a predetermined function. Although the systems described in the following embodiments are preferably implemented in software, hardware implementations, or combinations of software and hardware, are also possible and contemplated.

[0056] according to Figure 3 As shown, a vehicle software management system includes a service module 500 and a software upgrade module 600.

[0057] Service module 500 is used to perform the above steps S100: establish and maintain the vehicle functional baseline using a central management platform; store and distribute software version packages using a cloud server; and perform data transmission and function management using an in-vehicle gateway.

[0058] The software upgrade module 600 is used to perform the above steps S200, S300 and S400: dividing the vehicle functional units into atomic functional units, managing the version of each atomic functional unit, and establishing the first dependency relationship between atomic functional units; performing independent testing and canary release of atomic functional units; and supporting dynamic combination and online upgrade of atomic functional units.

[0059] When establishing the central management platform, the distributed database MySQL is used as the backend database. The central management platform is used to establish and maintain the vehicle functional baseline. The vehicle functional baseline is a complete and solidified description of the software version, hardware bill of materials (BOM), calibration parameters, communication matrix and functional logic of all electronic control units (ECUs) of the vehicle. It can be used as a design benchmark for engineering development, and also as a version management anchor point for OTA upgrades.

[0060] Cloud servers are used to store and distribute software version packages (tested upgrade packages). Storage space is created on the cloud server, security access permissions are set, and the software version packages are uploaded to the cloud server, which then handles the distribution. Simultaneously, the stability of the cloud server needs to be verified, and a stable network connection must be ensured. For example, when setting up a cloud server, an Alibaba Cloud ECS instance can be used as a virtual server in the cloud, offering high flexibility.

[0061] In one embodiment, the network parameters of the vehicle gateway can be configured via serial communication, data transmission channels can be set, and TCP / IP communication connections can be established between various components, such as atomic functional units, and the central management platform. Serial communication reduces the number of signal lines, saves microcontroller pin resources and PCB (printed circuit board) space, and lowers hardware costs. Simultaneously, the communication function of the vehicle gateway needs to be verified to ensure normal data transmission. For example, when configuring the vehicle gateway, a Linux-based network connection device is used, with the vehicle gateway used for data transmission and function management.

[0062] Specifically, the vehicle's user functions are broken down into atomic functional units that can call cross-domain services, such as vehicle electronic equipment (ECU) software, in-vehicle communication software, and driver assistance system software. Each atomic functional unit is assigned an independent version number, such as V1.0.0, V2.0.0, and V3.0.0. A naming convention for version numbers is established, containing a major version number, a minor version number, and a fix version number. For example, in V1.0.0, the first, second, and third digits correspond to the major, minor, and fix version numbers, respectively. The major version number represents significant performance improvements and added features; the minor version number represents functional logic modifications and optimizations; and the fix version number represents problem resolution and bug fixes. Furthermore, an independent version management branch is created for each atomic functional unit, ensuring that version number management is independent between atomic functional units.

[0063] In one embodiment, a second dependency relationship between the atomic functional unit and the underlying service also needs to be configured.

[0064] Specifically, the dependencies between atomic functional units and underlying services are identified, and a dependency tree is built based on these dependencies. For example, in the dependency tree, leaf nodes represent atomic functional units, and parent nodes are the functional units they depend on. Dependency management tools are used to manage these dependencies. For example, Maven can be used, enforcing a standard directory structure, resulting in a clear project structure and lower team collaboration costs. Alternatively, Gradle can be used, offering greater flexibility and allowing for programmable logic in the build scripts.

[0065] Establishing the first dependency relationship between atomic functional units includes: establishing the calling relationship between atomic functional units, defining the interface specifications of atomic functional units, and establishing loosely coupled communication between atomic functional units.

[0066] Specifically, when establishing the calling relationships between atomic functional units, the calling relationships are defined using an Interface Definition Language (IDL), including interface name, method name, parameters, and return value. In addition, a calling relationship database is established to record the calling relationships of each atomic functional unit.

[0067] Specifically, when defining the interface specifications for atomic functional units, the interface specifications for the atomic functional units should be formulated, including data format, communication protocol (such as CAN bus, Ethernet, etc.), and error handling mechanism. In addition, it is necessary to verify the correctness of the interface specifications to ensure that different atomic functional units can communicate correctly.

[0068] Specifically, when atomic functional units communicate loosely, lightweight containerization technology can be used to achieve loosely coupled deployment of atomic functional units, ensuring isolation and resource independence between them. For example, Docker can be used to package the atomic functional unit and all its dependencies and information into a lightweight, independent container, thereby achieving fast and reliable operation in any computing environment. For example, lightweight containerized OTA implementation involves three steps: service decomposition (decoupling monolithic software into independent microservices), container encapsulation (creating each service into a lightweight Docker image and setting resource boundaries), and declarative deployment (differential distribution of incremental packages from the cloud, with the vehicle pulling updates according to the list, and rolling back within seconds in case of failure).

[0069] In one embodiment, performing independent testing of atomic functional units may include: downloading a test environment configuration file via a cloud server, performing unit testing and integration testing of the atomic functional units in the test environment, and feeding the test results back to the central management platform via an in-vehicle gateway.

[0070] Specifically, when downloading the test environment configuration file from the cloud server, the test environment configuration file, including network configuration, environment variables, and test data, is downloaded from the cloud server; the correctness of the test environment is verified, and the consistency of the test environment is ensured.

[0071] Specifically, when performing unit testing of atomic functional units in a test environment, unit tests and integration tests are performed within the test environment, and test cases are executed using a test framework. For example, the test framework can be JUnit, which features simplified test writing, rich assertions, management of pre- and post-test states, automated execution, and timely feedback, making the testing of atomic functional units simpler, more automated, and reusable. Alternatively, the test framework can be Pytest, which features a very low barrier to entry, powerful failure diagnosis capabilities, and a highly scalable architecture, improving test coverage of atomic functional units. Furthermore, test results and fault information are recorded.

[0072] Specifically, when the test results are fed back to the central management platform via the vehicle-mounted gateway, the test results of the atomic functional units are also fed back to the central management platform via the vehicle-mounted gateway. The test results include test pass rate, fault information, and performance indicators. By analyzing the test results, it can be confirmed that the test pass rate has reached the preset threshold, ensuring the quality, maintainability, and development efficiency of the atomic functional units.

[0073] Gray release refers to a testing process that applies to a small number of vehicles in a small area. Once the pass rate reaches a threshold, the upgraded package or baseline version of the function will be used on a large scale.

[0074] During the continuous development and improvement of software, different atomic functional units can be combined into upgrade packages based on vehicle model and functional requirements. Version control tools can then be used to manage the version history of these upgrade packages. For example, Git, a distributed version control system, can be used as the version control tool. Git has advantages such as strong branching capabilities, low network dependency, and extremely fast local operations, enabling it to better manage the versions of atomic functional units that can call cross-domain services.

[0075] After the required upgrade package is created, it is distributed via a cloud server. Download permissions and download limits are set to ensure the compatibility and availability of the upgrade package. Furthermore, the integrity and compliance of the upgrade package need to be verified. Integrity is verified both before and after distribution; it is verified by the cloud server before release and by the vehicle-side during download after release. Compliance is verified after the upgrade package is distributed.

[0076] During online software upgrades, the upgrade package is received and executed via an OTA client, including steps such as version lookup, download, installation, and restart. Additionally, status information and error logs are recorded during the upgrade process; the status information includes a set of version numbers for each atomic functional unit.

[0077] After the software upgrade is complete, the functional baseline version of the central management platform is updated, which includes the vehicle's functional baseline and version information. Furthermore, the functional baseline version is updated at the start of testing; if testing fails, the upgrade package is discarded and not released to users. This includes the addition of new features, bug fixes, and optimizations. The correctness of the baseline version is also verified to ensure version consistency.

[0078] Optionally, the software upgrade module 600 is also used to perform the following steps: remote start / stop via function switches. Specifically, the software upgrade module is also used to perform the following steps: establishing a function switch management system, configuring function switch status via a cloud server, and reading and updating function switch status via the vehicle gateway.

[0079] Specifically, when establishing a function switch management system, a distributed lock mechanism is used to achieve mutual exclusion access; default function switch states and access control rules are set. Specifically, when configuring function switch states via a cloud server, these states include active, disabled, and standby states. This allows for remote enabling or disabling of functions or adjustment of configuration parameters without modifying code or redeploying the application. This can be used for canary releases, rapid troubleshooting of online issues, and simplified operation and configuration; the response speed and stability of function switches are verified. Specifically, when reading and updating function switch states via an in-vehicle gateway, operations such as status query, modification, and reset are performed; the real-time performance and reliability of function switches are verified.

[0080] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0081] Embodiments of the present invention also provide an apparatus including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to execute a vehicle software management method as described in any of the above embodiments.

[0082] Optionally, in this embodiment, the processor in the above-described device may be configured to run a computer program to execute the steps of the control method in the foregoing embodiments: Step S100: Establish and maintain the vehicle's functional baseline using a central management platform; store and distribute software version packages using a cloud server; and use an in-vehicle gateway for data transmission and function management. Step S200: Divide the vehicle functional units into atomic functional units, manage the version of each atomic functional unit, and establish the first dependency relationship between atomic functional units. Step S300: Perform independent testing and grayscale release of atomic functional units; Step S400: Support dynamic combination and online upgrade of atomic functional units.

[0083] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0084] Embodiments of the present invention also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute a vehicle software management method according to any of the above embodiments when run on a computer or processor.

[0085] Optionally, in this embodiment, the computer program described above may be configured to store a computer program for performing the control method steps in the foregoing embodiments: Step S100: Establish and maintain the vehicle's functional baseline using a central management platform; store and distribute software version packages using a cloud server; and use an in-vehicle gateway for data transmission and function management. Step S200: Divide the vehicle functional units into atomic functional units, manage the version of each atomic functional unit, and establish the first dependency relationship between atomic functional units. Step S300: Perform independent testing and grayscale release of atomic functional units; Step S400: Support dynamic combination and online upgrade of atomic functional units.

[0086] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0087] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0088] In some embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The system embodiments described above are merely illustrative; for example, the division of modules can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between modules may be electrical or other forms.

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

[0090] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0091] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or 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 described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0092] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A vehicle software management method, characterized in that, include: A central management platform is used to establish and maintain the functional baseline of the entire vehicle; Software version packages are stored and distributed using cloud servers; A vehicle-mounted gateway is used for data transmission and function management. The vehicle's functional units are divided into atomic functional units, each atomic functional unit is version managed, and a first dependency relationship is established between the atomic functional units. Perform independent testing and grayscale release of the aforementioned atomic functional units; It supports the dynamic combination and online upgrade of the atomic functional units.

2. The vehicle software management method according to claim 1, characterized in that, The use of an in-vehicle gateway for data transmission and function management includes: Configure the network parameters of the vehicle gateway via serial communication; Set up a data transmission channel to establish a communication connection between the atomic functional unit and the central management platform.

3. The vehicle software management method according to claim 1, characterized in that, The process of dividing the vehicle's functional units into atomic functional units and managing the version of each atomic functional unit includes: The vehicle user functions are broken down into atomic functional units that can call cross-domain services; Assign an independent version number to each of the atomic functional units; Configure the second dependency relationship between the atomic functional unit and the underlying service.

4. The vehicle software management method according to claim 3, characterized in that, The configuration of the second dependency relationship between the atomic functional unit and the underlying service includes: Establish a dependency tree, where the leaf nodes are the atomic functional units and the parent nodes are the functional units that the atomic functional units depend on. The dependency tree is managed using a dependency management tool.

5. The vehicle software management method according to claim 1, characterized in that, Establishing the first dependency relationship between the atomic functional units includes: Establish the calling relationships between the atomic functional units; Define the interface specifications for the atomic functional units; The atomic functional units communicate with each other in a loosely coupled manner.

6. The vehicle software management method according to claim 1, characterized in that, The independent testing of the atomic functional units includes: Download the test environment configuration file from the cloud server; Unit tests and integration tests of the atomic functional units are performed in a test environment; The test results are fed back to the central management platform through the vehicle gateway.

7. The vehicle software management method according to claim 1, characterized in that, The method further includes remote start / stop via a function switch, wherein remote start / stop via a function switch includes: Establish a functional switch management system; Configure the function switch status via the cloud server; The status of the function switch is read and updated through the vehicle gateway.

8. A vehicle software management system, characterized in that, include: The service module is used for: establishing and maintaining the vehicle's functional baseline using a central management platform; and storing and distributing software version packages using cloud servers. A vehicle-mounted gateway is used for data transmission and function management. The software upgrade module is used to: divide the vehicle's functional units into atomic functional units, manage the version of each atomic functional unit, and establish a first dependency relationship between the atomic functional units; Perform independent testing and grayscale release of the aforementioned atomic functional units; It supports the dynamic combination and online upgrade of the atomic functional units.

9. A device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the vehicle software management method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the vehicle software management method according to any one of claims 1 to 7 when running on a computer or processor.

Images