Vehicle software type data version generation method, electronic device, medium and product
By automatically integrating historical data and compatibility rules, a whole vehicle software data version is generated, solving the problem of maintaining software data versions for different configurations of the same model series, and achieving efficient, accurate unified maintenance and rapid adaptation.
Patent Information
- Application Number
- CN202510662639.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-22
- Publication Date
- 2025-11-25
- Estimated Expiration
- 2045-05-22
AI Technical Summary
In vehicles with different configurations within the same model series, the software data versions of the controller vary and are updated frequently, resulting in a large workload for manual maintenance, low accuracy, and a high risk of errors.
By acquiring historical vehicle software data versions, bills of materials, and optional parts lists, new vehicle software data versions are automatically generated and maintained using compatibility rules to restrict incompatible versions, thus achieving automated and unified maintenance.
It significantly reduces maintenance workload, improves maintenance accuracy and efficiency, ensures the compatibility and reliability of vehicle software data versions, and supports rapid adaptation of multiple vehicle configurations.
Smart Images

Figure CN120492430B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present disclosure relates to a vehicle software class data version generation method, an electronic device, a medium and a product. BACKGROUND
[0002] In the era of software-defined vehicles, as the market's demand for vehicle intelligence continues to increase, the number of controllers integrated in vehicles is increasing, and the frequency of software class data updates for controller flashing is also increasing.
[0003] In related technologies, software class data versions for vehicles with different configurations in the same series are maintained one by one by manual work. However, since the controllers of vehicles with different configurations (such as high-end and standard configurations) in the same series may be different, and the versions of software class data for controller flashing may also be different, the number of software class data versions that need to be maintained for vehicles with different configurations in the same series is large, which consumes a lot of time and effort of maintenance personnel. SUMMARY
[0004] The present disclosure provides a vehicle software class data version generation method, an electronic device, a medium and a product.
[0005] According to one aspect of the present disclosure, a vehicle software class data version generation method is provided, comprising: obtaining historical vehicle software class data versions, a bill of materials and an option list, wherein the historical vehicle software class data versions include version numbers of software class data for controllers of vehicles with different configurations in the same series, the bill of materials at least includes software class data version information of original controllers, and the option list includes software class data version information of replacement controllers; supplementing the software class data version information in the bill of materials according to the option list to obtain a supplemented bill of materials; extracting software class data version information from the supplemented bill of materials to obtain a set of vehicle software class data version information; and generating a new vehicle software class data version according to the historical vehicle software class data versions and the set of vehicle software class data version information.
[0006] According to the technical solution of one aspect, a new vehicle software class data version is generated by automatically integrating software class data version information of historical data, original controllers and replacement controllers, which realizes unified and automatic maintenance of software class data versions for series vehicles, significantly reduces the maintenance workload, improves accuracy and supports rapid adaptation of multiple vehicle configurations.
[0007] The vehicle software class data version generation method according to at least one embodiment of the present disclosure further comprises the following steps after a new vehicle software class data version is generated: determining a software class data version of a maintained controller in the new vehicle software class data version when a maintenance operation for the new vehicle software class data version is detected; judging whether a software class data version of an un-maintained controller in the new vehicle software class data version is compatible with the software class data version of the maintained controller according to the acquired compatibility rules; performing maintenance restriction on incompatible software class data versions, the incompatible software class data versions being software class data versions of un-maintained controllers that are incompatible with the software class data version of the maintained controller; and determining a post-maintenance vehicle software class data version when the maintenance operation is terminated.
[0008] The technical solution according to the embodiments of the present disclosure prevents selection of incompatible software class data versions during maintenance, reduces human errors, improves maintenance efficiency and reliability of the post-maintenance vehicle software class data version, ensures compatibility between software class data versions of different controllers in the post-maintenance vehicle software class data version, and improves coordination and consistency of vehicle software under complex configurations.
[0009] The vehicle software class data version generation method according to at least one embodiment of the present disclosure, the compatibility rules comprise one or more of software and hardware compatibility rules, software compatibility rules, and version compatibility rules, the software and hardware compatibility rules define compatibility between controller versions and software class data versions, the software compatibility rules define compatibility between different software class data, and the version compatibility rules define compatibility between different software class data versions.
[0010] The technical solution according to the embodiments of the present disclosure combines multiple rules to cover compatibility analysis requirements between controllers and software class data, between different software class data, and between different software class data versions, ensures applicability and stability of vehicle software class data versions under different scenarios, and is conducive to improving success rate of software class data upgrade and reliability of post-upgrade vehicle systems.
[0011] The vehicle software class data version generation method according to at least one embodiment of the present disclosure, the maintenance restriction comprises one or more of the following steps: not displaying the incompatible software class data versions; displaying the incompatible software class data versions and compatible software class data versions with different display effects, the compatible software class data versions being software class data versions of un-maintained controllers that are compatible with the software class data version of the maintained controller; disabling selection of the incompatible software class data versions; and performing compatibility alarm prompts when the incompatible software class data versions are selected.
[0012] According to the technical scheme of the embodiment of the present disclosure, the possibility of misoperation is reduced, the maintenance personnel is prevented from selecting incompatible software data version, the maintenance personnel is intuitively guided to select compatible software data version, the user interaction experience is optimized, the efficiency of the maintenance process is improved, and the compatibility and safety of the vehicle software data version after maintenance are enhanced.
[0013] According to the vehicle software data version generation method according to at least one embodiment of the present disclosure, after the vehicle software data version after maintenance is determined, the method further includes: changing the state of the vehicle software data version after maintenance to a draft state; in the case where it is detected that the vehicle software data version after maintenance enters an audit process, changing the state of the vehicle software data version after maintenance to an auditing state; and in the case where it is detected that the vehicle software data version after maintenance is audited and passed, publishing the vehicle software data version after maintenance, and changing the state of the vehicle software data version after maintenance to a published state.
[0014] According to the technical scheme of the embodiment of the present disclosure, the vehicle software data version after maintenance in different states in the audit and publishing process is identified through the draft state, the auditing state and the published state, the standardization of publishing the vehicle software data version after maintenance is improved, and the risk of mispublishing an unapproved version is reduced.
[0015] According to the vehicle software data version generation method according to at least one embodiment of the present disclosure, after the state of the vehicle software data version after maintenance is changed to a draft state, the method further includes: in the case where it is detected that a target series vehicle exists a vehicle software data version in the draft state or the auditing state, prohibiting the generation of a new vehicle software data version for the target series vehicle again.
[0016] According to the technical scheme of the embodiment of the present disclosure, version conflicts and data redundancy are avoided, and the uniqueness and orderliness of vehicle software data version management are enhanced.
[0017] According to the vehicle software data version generation method according to at least one embodiment of the present disclosure, the mutual option list further includes grouping information of the original controller and grouping information of the replacement controller; and the software data version information in the bill of materials is supplemented according to the mutual option list, including: based on the grouping information, judging whether there is a replacement controller in the same group as the original controller in the bill of materials in the mutual option list; and if so, supplementing the software data version information of the replacement controller in the same group to the bill of materials.
[0018] According to the technical scheme of the embodiment of the present disclosure, the software type data version information of the original controller and the replacement controller can be reflected as much as possible in the supplemented BOM, which is beneficial to unified management of the software type data version information of the original controller and the replacement controller through the supplemented BOM and generation of more complete vehicle software type data version, thereby covering the software type data upgrade scene under the condition that the original controller is replaced.
[0019] According to the vehicle software type data version generation method according to at least one embodiment of the present disclosure, the software type data version information of the original controller further includes software type data version application information, and the software type data version application information includes one or more of applicable upgrade scenes, applicable vehicles and applicable controller information; after the software type data version information of the replacement controller in the same group is supplemented into the BOM, the software type data version application information of the original controller is used as the software type data version application information of the replacement controller in the same group of the original controller.
[0020] According to the technical scheme of the embodiment of the present disclosure, the maintenance process of the software type data version application information of the replacement controller is simplified, the data consistency and adaptation efficiency are improved, and the configuration error risk caused by supplier differences is reduced.
[0021] According to the vehicle software type data version generation method according to at least one embodiment of the present disclosure, the software type data version information is extracted from the supplemented BOM, including: based on the part type of the described part, the part description information of the part type of software type data is extracted from the plurality of part description information of the supplemented BOM, and the vehicle software type data version information set is obtained.
[0022] According to the technical scheme of the embodiment of the present disclosure, the vehicle software type data version information set is automatically generated, the workload of manual screening is reduced, the accuracy and efficiency of information extraction are improved, and it is ensured that the vehicle software type data version information set comprehensively covers the software type data requirements of the series vehicle.
[0023] According to the vehicle software type data version generation method according to at least one embodiment of the present disclosure, a new vehicle software type data version is generated according to the historical vehicle software type data version and the vehicle software type data version information set, including: determining the latest version number of a plurality of software type data from the historical vehicle software type data version and the vehicle software type data version information set; and combining the latest version numbers of the plurality of software type data together to obtain the new vehicle software type data version.
[0024] According to the technical solution of the embodiment of the present disclosure, the mechanism of automatically selecting the latest version simplifies the generation process of the vehicle software type data version, improves the maintenance efficiency of the vehicle software type data version of the series vehicle model, and is suitable for the software upgrade scene of rapid iteration.
[0025] According to the vehicle software type data version generation method according to at least one embodiment of the present disclosure, the latest version number of the plurality of software type data is determined, including: for a first software type data in the historical vehicle software type data version and the vehicle software type data version information set, taking the maximum version number of the first software type data as the latest version number of the first software type data, the first software type data being software type data existing at the same time in the historical vehicle software type data version and the vehicle software type data version information set; and for a second software type data in the historical vehicle software type data version and the vehicle software type data version information set, taking the version number of the second software type data directly as the latest version number of the second software type data, the second software type data being software type data not existing at the same time in the historical vehicle software type data version and the vehicle software type data version information set.
[0026] According to the technical solution of the embodiment of the present disclosure, the latest version number of different software type data is accurately determined in different ways, thereby providing data support for generating accurate vehicle software type data version.
[0027] According to another aspect of the present disclosure, an electronic device is provided, including: a memory storing a computer program; and a processor executing the computer program stored by the memory, so that the processor executes the vehicle software type data version generation method of any embodiment of the present disclosure.
[0028] According to still another aspect of the present disclosure, a readable storage medium is provided, the readable storage medium storing a computer program, the computer program being executed by a processor to implement the vehicle software type data version generation method of any embodiment of the present disclosure.
[0029] According to still another aspect of the present disclosure, a computer program product is provided, including a computer program, the computer program being executed by a processor to implement the vehicle software type data version generation method of any embodiment of the present disclosure. BRIEF DESCRIPTION OF DRAWINGS
[0030] The accompanying drawings illustrate exemplary embodiments of the present disclosure and together with the description, explain the principles of the present disclosure, wherein the drawings are included to provide further understanding of the present disclosure and constitute a part of the specification.
[0031] Figure 1is a flowchart of a vehicle software class data version generation method according to an embodiment of the present disclosure.
[0032] Figure 2 is a visualization example of part of a mutual election list according to an embodiment of the present disclosure.
[0033] Figure 3 is a process diagram of determining a vehicle software class data version after maintenance according to an embodiment of the present disclosure.
[0034] Figure 4 is a process diagram of state change according to an embodiment of the present disclosure.
[0035] Figure 5 is a diagram of an audit and release process according to an embodiment of the present disclosure.
[0036] Figure 6 is a process diagram of determining a supplemental bill of materials according to an embodiment of the present disclosure.
[0037] Figure 7 is a process diagram of determining a new vehicle software class data version according to an embodiment of the present disclosure.
[0038] Figure 8 is a process diagram of determining a latest version number according to an embodiment of the present disclosure.
[0039] Figure 9 is a flowchart of a vehicle software class data version generation method according to another embodiment of the present disclosure.
[0040] Figure 10 is a schematic structural block diagram of a vehicle software class data version management system according to an embodiment of the present disclosure.
[0041] Figure 11 is a schematic structural block diagram of a vehicle software class data version generation apparatus according to an embodiment of the present disclosure.
[0042] Figure 12 is a schematic structural block diagram of an electronic device according to an embodiment of the present disclosure. DETAILED DESCRIPTION
[0043] The present disclosure will be further described below in conjunction with the accompanying drawings and examples. It can be understood that the specific examples described herein are only for explanation of the related content, and are not a limitation on the present disclosure. In addition, it should be noted that, for the convenience of description, only parts related to the present disclosure are shown in the drawings.
[0044] It should be noted that the embodiments in the present disclosure and the features in the embodiments can be combined with each other without conflict. The technical solutions of the present disclosure will be described in detail below with reference to the drawings and in combination with the embodiments.
[0045] There can be multiple vehicles with different configurations in the same series of vehicles, such as high-end versions, standard versions, fuel versions, pure electric versions, hybrid versions, domestic versions, foreign versions, etc. The software class data for controller flashing can be different in vehicles with different configurations in the same series, and the software class data for controller flashing and the versions of the software class data can also be different in vehicles with the same configuration, resulting in a large number of types of software class data and frequent updates. If the software class data versions of vehicles with different configurations in a series are completely maintained by manual work, a large amount of time and effort needs to be invested by the maintenance personnel. Moreover, manual operation cannot guarantee the accuracy of data version maintenance, and maintenance can be easily missed or incorrect.
[0046] To this end, the present disclosure proposes the following technical solutions, in which the vehicle software class data version is maintained in combination with historical vehicle software class data versions, a bill of materials, and an option list, automatic maintenance of the vehicle software class data version is achieved, and the drawbacks of manual maintenance are avoided.
[0047] The vehicle software class data version generation method of the present disclosure can be used to automatically generate a new vehicle software class data version when an electronic device obtains historical vehicle software class data versions, a bill of materials, and an option list. In the present disclosure, the electronic device includes but is not limited to a server, a mobile phone, a tablet computer, a notebook computer, a personal computer, a wearable device, a teller machine, etc.
[0048] Figure 1 The overall flowchart of the vehicle software class data version generation method of one embodiment of the present disclosure is shown. As shown in the method includes steps S110 to S140. The method can be executed by a server, a mobile phone, a tablet computer, etc. Figure 1
[0049] In step S110, historical vehicle software class data versions, a bill of materials, and an option list are obtained. The historical vehicle software class data versions include version numbers of software class data for controller flashing in vehicles with different configurations in the same series. The bill of materials (BOM) includes at least software class data version information of original controllers, and the option list includes software class data version information of replacement controllers.
[0050] The software class data includes software and calibration data. The calibration data can be data describing adjustment parameters calibrated for the controller.
[0051] The vehicle software version is at least a set of version numbers of software versions of all controllers of different configurations of vehicles in the same series. Each vehicle software version can have a globally unique version number. The vehicle software version is a baseline version formed by integrating software versions of multiple controllers in the vehicle, which uniquely identifies the combined state of the software of the controllers in the vehicle.
[0052] The historical vehicle software version can be a version of vehicle software generated before the first time, or a version of vehicle software generated last time, or multiple versions of vehicle software generated before the first time. The first time can be set according to actual conditions.
[0053] The original controller can be a controller configured on the vehicle when the vehicle is shipped. The replacement controller can be a controller configured on the vehicle after maintenance of the vehicle to replace the original controller. The replacement controller can be the same supplier as the original controller, or a different supplier.
[0054] The bill of materials is a set of part description information of different configurations of vehicles in the same series (excluding replacement controllers). The bill of materials at least records the software version information of the latest state of the original controller generated by the R&D business. The part description information can include one or more of part basic information, structure information, development state information, and application information. The structure information can maintain the writing relationship between software and controllers, such as describing the software version information of the controller writing. The application information can maintain the writing relationship between calibration data and controllers, such as describing the calibration data version information of the controller writing. The bill of materials can adopt a tree structure, and the calibration data can be hung as a part under the top node of the vehicle tree. The software version information includes but is not limited to the software version number. The parts in the bill of materials include controllers, software, calibration data, etc.
[0055] The inter-select list can be a set of inter-select part basic information and inter-select grouping information of the current production vehicle model in the same series of different configurations of vehicles. The inter-select part is a part in the bill of materials that is pointed to multiple suppliers to meet supply chain security and cost targets, etc. The inter-select part can include the original controller, the replacement controller, the software, etc. The inter-select list at least records the software version information of the latest state of the replacement controller of different configurations of vehicles in the same series. The inter-select list can adopt a multi-tree structure to organize and manage the inter-select part basic information, and maintain the inter-select grouping information for the top node of the tree to reflect the inter-select relationship. The parts in the bill of materials can be A-point parts, and the parts that do not exist in the bill of materials but exist in the inter-select list can be non-A-point parts, denoted as B-point parts, C-point parts, etc.
[0056] Figure 2Part-0010 is an A-point part, and Part-0011 is a B-point part.
[0057] In step S120, according to the mutual selection list, the software class data version information in the bill of materials is supplemented to obtain a supplemented bill of materials.
[0058] The software class data version information of the replacement controller is not present in the bill of materials before the supplement, and the software class data version information of the replacement controller in the mutual selection list is supplemented to the bill of materials, so that the software class data version information of the replacement controller can be present in the supplemented bill of materials, thereby facilitating understanding of the software class data version information of the replacement controller through the supplemented bill of materials.
[0059] In step S130, the software class data version information is extracted from the supplemented bill of materials to obtain a whole vehicle software class data version information set.
[0060] The whole vehicle software class data version information set is a collection of software class data version information of software class data required by all single configuration vehicles in the same series with different configurations, which are currently being researched and produced, and can include software class data version information of original controllers initially researched and produced, software class data version information of controllers of new suppliers added to meet supply chain safety and cost targets and the like after mass production, and software class data version information of replaced controllers.
[0061] The software class data version information can include one or more of software class data version basic information, software class data version application information, software class data mutual selection information, software class data version state information, and software class data version validity information.
[0062] The software class data version basic information is used to describe information related to the software class data version itself, including software class data version number, part number of the software class data, part name, part classification, and the like, where the “part” refers to the software class data.
[0063] The software class data version application information is used to describe how a version of software class data is used, and can include one or more of applicable upgrade scenarios (i.e., application scope), applicable vehicles (i.e., application conditions), and applicable controller information (i.e., flash part). The applicable upgrade scenario describes the upgrade scenarios to which a version of software class data can be applied, such as R&D testing, production line online flashing, after-sales service, OTA (Over The Air), and the like. The applicable vehicle describes the use of a version of software class data in vehicles with what kind of configuration. The applicable controller information describes which version of which controller a version of software class data is specifically used to flash upgrade, and can include controller number, controller version, controller type, and the like.
[0064] The software class data mutual selection information is used to describe which controllers and software class data the controller and software class data can be interchanged with, i.e., controllers within the same mutual selection group can be interchanged with each other, and software class data within the same mutual selection group can be interchanged with each other.
[0065] The software class data version state information is used to describe the state corresponding to a version of software class data, including R&D testing and mass production. “R&D testing” indicates that a version of software class data is still in the R&D stage and is a process test version, and is used to support integration testing of the entire vehicle software. “Mass production” indicates that a version of software class data has passed R&D testing and can be used for flashing upgrade of mass production vehicles.
[0066] The software class data version validity information is used to describe whether the version of software class data is still being used in currently researched and produced configuration vehicles, and includes “valid” and “invalid”. “Valid” indicates that the version of software class data is being used in currently researched and produced configuration vehicles; and “invalid” indicates that the version of software class data is not being used in currently researched and produced configuration vehicles, but there are user vehicles containing the version of software class data in vehicles on the market, and after-sales software upgrade and user OTA upgrade services still need to be provided for the user vehicles.
[0067] Exemplarily, the bill of materials is a tree structure. The bill of materials can be supplemented by recursively processing the tree-shaped bill of materials layer by layer. During the recursive process, if the part has a corresponding alternative grouping in the alternative list, all non-A-point alternative parts in the corresponding alternative grouping are integrated into the bill of materials in the same parent node manner, so as to obtain the supplemented bill of materials. During the integration process, all non-A-point parts in the same alternative grouping use the same application information as the A-point part, and the alternative grouping information corresponding to each part can be set synchronously in the bill of materials according to the alternative list. During the recursive process, the part type in the part basic information can be identified. If the part type of the part is software data, the software data version information of the part is extracted, and the extracted software data version information is combined into a set of whole vehicle software data version information in a flat manner. When the part type of the part is software, the flash part of the part is set as the parent part part number, and the application information is set as the application information of the corresponding first-level part. When the part type of the part is calibration data, the flash part of the part is set as the corresponding flash part in the bill of materials. The validity of the software data version information in the set of whole vehicle software data version information is “valid”.
[0068] Compared with extracting software data version information from the alternative list and the bill of materials respectively to generate the set of whole vehicle software data version information, in the present disclosure, after supplementing the software data version information in the bill of materials according to the alternative list, the software data version information is extracted from the supplemented bill of materials to generate the set of whole vehicle software data version information. This can reduce the lack of context information, reduce the logical complexity, and ensure data consistency. It can be understood that the alternative list lacks context information such as application conditions, and directly extracting software data version information from the alternative list will lead to inaccurate records of the set of whole vehicle software data version information. Moreover, directly extracting software data version information from the alternative list requires designing independent parsing logic for the alternative list, which has high logical complexity and high development and maintenance cost. In addition, the software data version information directly extracted from the alternative list is inconsistent with the record format of the software data version information extracted from the bill of materials, which affects subsequent management.
[0069] In step S140, a new whole vehicle software data version is generated according to the historical whole vehicle software data version and the set of whole vehicle software data version information.
[0070] The new vehicle software class data version is a collection of the latest software class data version information of all controllers in the same series of different configuration vehicles, which can include the software class data version information of the original controller in the initial research and development production, the software class data version information of the controller added by the supplier to meet the requirements of supply chain safety and cost targets after mass production, the software class data version information of the replaced controller, and the software class data version information of the controller on the historical configuration vehicle that has been produced and sold but is currently discontinued. The content related to the software class data version information can refer to the description above, and for the sake of brevity, will not be repeated here.
[0071] Exemplarily, the software class data version information that does not exist in the vehicle software class data version information set but exists in the historical vehicle software class data version has a validity of “invalid” in the new vehicle software class data version. The new vehicle software class data version can be used in various scenarios such as research and development testing, production line flashing, after-sales service, and OTA upgrading. The new vehicle software class data version has a globally unique version number, and the version number is different from the version number of the historical vehicle software class data version.
[0072] Exemplarily, in the case of initially generating the vehicle software class data version, since there is no historical vehicle software class data version yet, and at this time there is no vehicle that has been discontinued in the series of vehicles, the vehicle software class data version information set can be directly used as the new vehicle software class data version.
[0073] The vehicle software type data version generation method of the embodiments of the present disclosure utilizes the mutual option list to supplement the bill of materials, extracts the vehicle software type data version information set from the supplemented bill of materials, and generates a new vehicle software type data version in combination with historical vehicle software type data versions, thereby realizing unified and automatic maintenance of the software type data version of series vehicles. Compared with manually maintaining the software type data version of each configuration vehicle one by one, that is, after maintaining the software type data version of all controllers of one configuration vehicle, the software type data version of all controllers of another configuration vehicle is maintained, the method significantly reduces the maintenance workload, improves the accuracy, and supports rapid adaptation of multiple vehicle configurations. Moreover, since the bill of materials can provide the latest software type data version information of the original controller generated by the R&D business, regardless of the stage of the vehicle, as long as there is new R&D progress in the software type data version of the original controller, subsequent software type data upgrade can be performed according to the vehicle software type data version of the present disclosure. At the same time, although the software type data version information of the replacement controller is not reflected in the bill of materials, the mutual option list can provide the latest software type data version information of the replacement controller, and the vehicle software type data version of the present disclosure is generated according to the mutual option list, so even if the original controller on the vehicle is replaced, subsequent software type data upgrade can still be performed normally. At the same time, since the historical vehicle software type data version can provide the historical software type data version of the controller, the software type data version of the controller of the discontinued and / or discontinued vehicle can still be obtained, thereby providing guarantee for the software type data version maintenance of the discontinued and / or discontinued vehicle, and avoiding the difficulty of software type data upgrade due to the lack of software type data version information of the vehicle.
[0074] In some embodiments of the present disclosure, after step S140, steps S150 to S180 as shown in the following can also be included. Figure 3
[0075] Step S150, in the case where a maintenance operation for the new vehicle software type data version is detected, determining the software type data version of the maintained controller in the new vehicle software type data version.
[0076] The maintenance operation can be triggered by a maintenance personnel. The maintenance personnel can maintain the version number of the software type data in the new vehicle software type data version, including but not limited to adjusting the version number, deleting the software type data, or deleting the version number of the software type data, etc.
[0077] Step S160, according to the obtained compatibility rules, judging whether the software type data version of the un-maintained controller in the new vehicle software type data version is compatible with the software type data version of the maintained controller.
[0078] The compatibility rule can be set according to business requirements. For example, during the development of the controller software, the requirements of each controller for compatibility are designed according to the actual business needs, and the controller software compatibility rule is formed after actual design, development and test verification.
[0079] The compatibility rule can be stored in the local memory of the electronic device, so as to facilitate the electronic device to call quickly. The compatibility rule can be stored in the cloud, and then the electronic device communicates with the cloud when it needs to call the compatibility rule, so as to obtain the compatibility rule.
[0080] Step S170, the incompatible software class data version is maintained, and the incompatible software class data version is the software class data version of the un-maintained controller which is incompatible with the software class data version of the maintained controller in the new vehicle software data version.
[0081] The maintenance limit can be set according to business requirements.
[0082] Step S180, determining the vehicle software class data version after maintenance when detecting the termination of the maintenance operation.
[0083] Exemplarily, when the maintenance personnel click the termination maintenance button, the electronic device can detect the termination of the maintenance operation, and then the vehicle software class data version at this time is taken as the vehicle software class data version after maintenance.
[0084] The vehicle software type data version generation method of the above embodiment determines the software type data version of the maintained controller in real time during the maintenance operation of the new vehicle software type data version, and then performs compatibility analysis on the software type data version of the un-maintained controller in combination with the compatibility rules, and maintains the incompatible software type data version, thereby preventing the selection of incompatible software type data versions during maintenance, reducing human error, improving maintenance efficiency and the reliability of the vehicle software type data version after maintenance, ensuring the compatibility of the software type data version between different controllers in the vehicle software type data version after maintenance, and improving the coordination consistency of the vehicle software under complex configurations. It can be understood that the vehicle development mode in the automotive industry is series development, and different configuration vehicles in the same series share the same controller and software type data. The compatibility between the software and hardware of each controller, different software type data, and different software type data versions is complex. If the software type data version of each configuration vehicle is maintained one by one, compatibility analysis needs to be performed repeatedly, which is time-consuming and prone to errors. In the present disclosure, since the new vehicle software type data version includes the version number of the software type data written by the controller of different configuration vehicles in the same series, the maintenance of the new vehicle software type data version is the maintenance of the version number of the software type data written by the controllers of different configuration vehicles, which can reduce the workload of compatibility analysis, thereby reducing the difficulty of compatibility analysis, improving the accuracy, overall coordination and data consistency of the vehicle software type data version after maintenance, and achieving the effects of reducing the difficulty of compatibility analysis, improving the accuracy, overall coordination and data consistency of the vehicle software type data version after maintenance, and achieving the effects of reducing the difficulty of compatibility analysis, improving the accuracy, overall coordination and data consistency of the vehicle software type data version after maintenance.
[0085] In some embodiments of the present disclosure, the compatibility rules include one or more of the software and hardware compatibility rules, the software compatibility rules, and the version compatibility rules, the software and hardware compatibility rules define the compatibility relationship between the controller version and the software type data version, the software compatibility rules define the compatibility relationship between different software type data, and the version compatibility rules define the compatibility relationship between different software type data versions.
[0086] In one example, the compatibility rules include the software and hardware compatibility rules, the software compatibility rules, and the version compatibility rules.
[0087] In one example, taking software as an example of software type data, the software and hardware compatibility rules are shown in Table 1, which details which software and corresponding software versions are compatible with the controller, how the software versions are compatible, and whether they are backward compatible. For example, the Part-0001 controller with version V001 supports the installation of Soft-0001 software with version S001001 and S001002, and when S001002 is installed, it is compatible with all the functions and interfaces of S001001. The Part-0001 controller with version V002 can only install Soft-0001 software with version S002001, and the S002001 version of the software is no longer backward compatible, i.e., it is no longer fully compatible with the functions and interfaces of S001001 and S001002.
[0088] Table 1
[0089]
[0090] In one example, taking software as an example of software type data, the software and hardware compatibility rules are shown in Table 1, which details which software and corresponding software versions are compatible with the controller, how the software versions are compatible, and whether they are backward compatible. For example, the Part-0001 controller with version V001 supports the installation of Soft-0001 software with version S001001 and S001002, and when S001002 is installed, it is compatible with all the functions and interfaces of S001001. The Part-0001 controller with version V002 can only install Soft-0001 software with version S002001, and the S002001 version of the software is no longer backward compatible, i.e., it is no longer fully compatible with the functions and interfaces of S001001 and S001002.
[0091] Table 2
[0092]
[0093] It should be noted that the specific values mentioned above are only used as examples to illustrate the embodiments of the present disclosure and should not be construed as limiting the present disclosure. In other examples or implementations or embodiments, other values can be selected according to the present disclosure, which are not specifically limited herein.
[0094] The vehicle software type data version generation method of the above embodiments provides comprehensive compatibility verification rules for vehicle software type data version maintenance by defining software and hardware compatibility rules, software compatibility rules, and version compatibility rules. Moreover, the combination of multiple rules can cover the compatibility analysis requirements between the controller and the software type data, different software type data, and different software type data versions, ensuring the applicability and stability of the vehicle software type data version in different scenarios, which is conducive to improving the success rate of software type data upgrade and the reliability of the vehicle system after upgrade.
[0095] In some embodiments of the present disclosure, the maintenance restriction can include one or more of the following steps: not displaying the incompatible software class data version; displaying the incompatible software class data version and the compatible software class data version in different display effects, for example, highlighting and / or bolding the compatible software class data version and displaying the incompatible software class data version normally, or displaying the compatible software class data version normally and displaying the incompatible software class data version weakly by reducing color saturation and / or increasing shadow, the compatible software class data version being the software class data version of the un-maintained controller compatible with the software class data version of the maintained controller; disabling selection of the incompatible software class data version; and giving a compatibility warning prompt when the incompatible software class data version is selected, the content of the compatibility warning prompt being set according to actual conditions.
[0096] The vehicle software class data version generation method of the above embodiments reduces the possibility of misoperation by means of maintenance restriction measures such as non-display, differential display, selection prohibition and warning prompt, avoids maintenance personnel from selecting incompatible software class data versions, intuitively guides maintenance personnel to select compatible software class data versions, optimizes user interaction experience, improves the efficiency of the maintenance process, and at the same time enhances the compatibility and safety of the vehicle software class data version after maintenance.
[0097] In some embodiments of the present disclosure, after step S140, steps S190 to S220 as shown in Figure 4 may also be included.
[0098] Step S190, changing the state of the vehicle software class data version after maintenance to a draft state.
[0099] Exemplarily, after generating the vehicle software class data version after maintenance, the update content of the vehicle software class data version after maintenance compared with the previous vehicle software class data version can also be generated.
[0100] Step S210, in the case where it is detected that the vehicle software class data version after maintenance enters the review process, changing the state of the vehicle software class data version after maintenance to an under review state.
[0101] Step S220, in the case where it is detected that the vehicle software class data version after maintenance passes the review, publishing the vehicle software class data version after maintenance and changing the state of the vehicle software class data version after maintenance to a published state.
[0102] In one example, the data flow process in the review and publishing process is as shown in Figure 5As shown, the demand department proposes to generate a new whole vehicle software class data version; the electronic and electrical department maintains the new whole vehicle software class data version generated by the electronic device to obtain a maintained whole vehicle software class data version, at this time, the state of the maintained whole vehicle software class data version is draft; the professional, marketing, quality and other departments perform offline review on the maintained whole vehicle software class data version, then the R&D director and the project manager perform audit, the project director performs approval, and the product line director performs approval, in this process, the state of the maintained whole vehicle software class data version is under review; if the audit is passed, the initiator can manually release the maintained whole vehicle software class data version, at this time, the state of the maintained whole vehicle software class data version is released.
[0103] The released maintained whole vehicle software class data version can be transmitted to the downstream R&D system, manufacturing execution system, after-sales system and OTA system to support R&D test, online writing on the production line, after-sales software upgrade and user OTA software upgrade and other businesses.
[0104] The whole vehicle software class data version generation method of the above embodiment identifies the maintained whole vehicle software class data version in different states in the review and release process through the draft state, the under review state and the released state, improves the standardization of the release of the maintained whole vehicle software class data version, reduces the risk of misrelease of unapproved versions, provides protection for reliable application of downstream systems such as OTA and production line writing, and at the same time, ensures the traceability and consistency of the maintained whole vehicle software class data version. And by detecting different nodes of the review and release process, the maintained whole vehicle software class data version is tightly coupled with the review and release process, and thus the timely and accurate transmission of data is realized.
[0105] In some embodiments, in the case where it is detected that the new whole vehicle software class data version is not maintained, the new whole vehicle software class data version can be directly used as the maintained whole vehicle software class data version, and then the review and release process of the above embodiment is performed.
[0106] In some embodiments of the present disclosure, after step S190, it can further include: in the case where it is detected that the target series vehicle exists a whole vehicle software class data version in the draft state or the under review state, prohibiting the generation of a new whole vehicle software class data version for the target series vehicle again.
[0107] The target series can be set according to actual conditions, for example, it can be set as any series.
[0108] Exemplarily, if a vehicle series exists a vehicle software data version in a draft state or an under review state, the vehicle series cannot generate a new vehicle software data version again until the vehicle software data version state changes to a released state, but this does not affect the generation of vehicle software data versions of other vehicle series.
[0109] The vehicle software data version generation method of the above embodiment can avoid version conflicts and data redundancy by prohibiting the generation of a new vehicle software data version again when a vehicle software data version in a draft state or an under review state exists, thereby enhancing the uniqueness and orderliness of vehicle software data version management. This constraint mechanism optimizes the maintenance process of vehicle software data versions of a series, improves system resource utilization efficiency, and reduces management complexity.
[0110] Regarding step S120, in some embodiments of the present disclosure, the mutual selection list further includes grouping information of the original controllers and grouping information of the replacement controllers, and accordingly, step S120 can include steps S121 and S122 as shown in Figure 6 .
[0111] Step S121, based on the grouping information, it is determined whether there is a replacement controller in the same group as the original controller in the bill of materials in the mutual selection list.
[0112] Exemplarily, the grouping information can include a group number, and the group number of the original controller in the bill of materials can be obtained from the mutual selection list by the original controller name or the part number of the original controller, and then the replacement controllers in the same group of each original controller in the bill of materials are determined one by one, that is, after determining the replacement controller in the same group of one original controller, the replacement controller in the same group of another original controller is determined. Specifically, the group number of one original controller in the bill of materials is matched with the group number of the replacement controller in the mutual selection list, if the group number of the replacement controller is the same as that of the original controller, it is determined that the replacement controller is in the same group as the original controller in the bill of materials; if the group number of the replacement controller is different from that of the original controller, it is determined that the replacement controller is not in the same group as the original controller in the bill of materials.
[0113] Step S122, if yes, the software data version information of the replacement controller in the same group is supplemented to the bill of materials.
[0114] Exemplarily, for the replacement controller in the same group as the original controller in the bill of materials, the software class data version information of the replacement controller stored in the accessory list is supplemented into the bill of materials. If a replacement controller does not exist in the accessory list for the original controller in the same group, the original controller can not have a replacement controller, and thus the software class data version information of the replacement controller can not be supplemented for the controller represented by the original controller.
[0115] Exemplarily, the bill of materials is a tree structure, and the software class data version information of the replacement controller and the original controller in the same group has the same parent node, that is, the software class data version information of the plurality of replacement controllers in the same group as the original controller is supplemented into the bill of materials in the same way as the software class data version information of the original controller has the same parent node, thereby enhancing the correlation between the information. At the same time, the supplemented software class data version information of the replacement controller can have the same context information as the software class data version information of the original controller under the same parent node, for example, the same software class data version application information.
[0116] The whole vehicle software class data version generation method of the above embodiment accurately supplements the software class data version information of the replacement controller in the same group as the original controller in the bill of materials into the bill of materials based on the grouping information, so that the software class data version information of the original controller and the replacement controller can be reflected as much as possible after the supplement of the bill of materials, which is beneficial to unified management of the software class data version information of the original controller and the replacement controller through the supplemented bill of materials and generation of a more complete whole vehicle software class data version, thereby covering the software class data upgrade scene under the replacement of the original controller.
[0117] In some embodiments of the present disclosure, the software class data version information of the original controller further includes software class data version application information, and the software class data version application information includes one or more of applicable upgrade scenarios, applicable vehicles, and applicable controller information. Accordingly, after step S122, it can further include: taking the software class data version application information of the original controller as the software class data version application information of the replacement controller in the same group as the original controller.
[0118] The software class data version application information is information related to the application of the software class data version, and is used to describe how a version of the software class data is used. The applicable upgrade scenario describes an upgrade scenario in which a version of the software class data can be applied, for example, research and development testing, online writing on a production line, after-sales service, OTA, and the like. The applicable vehicle describes a vehicle with what configuration in which a version of the software class data is used. The applicable controller information describes a version of the software class data that is specifically used to write and upgrade which version of which controller, and can include a controller number, a controller version, a controller type, and the like.
[0119] The whole vehicle software class data version generation method of the above embodiment applies the software class data version application information of the original controller to the replacement controller in the same group, ensuring the equivalence of the replacement controller software in the applicable scenario, vehicle, and controller. This information inheritance mechanism simplifies the maintenance process of the software class data version application information of the replacement controller, improves data consistency and adaptation efficiency, and reduces the risk of configuration errors caused by supplier differences.
[0120] Regarding step S130, in some embodiments of the present disclosure, specifically, the part type of the described part is used to extract part description information of the part type of software class data from the plurality of part description information of the supplemented bill of materials, to obtain the whole vehicle software class data version information set.
[0121] The bill of materials can include part description information of a plurality of different part types, and then the part description information corresponding to the software class data can be accurately extracted from the supplemented bill of materials based on the part type. The part description information corresponding to the software class data includes software class data version information, and the software class data version information of the plurality of original controllers and replacement controllers can be combined in a tiled manner, to obtain the whole vehicle software class data version information set.
[0122] The whole vehicle software class data version generation method of the above embodiment accurately extracts the software class data version information from the supplemented bill of materials based on the part type, automatically generates the whole vehicle software class data version information set, reduces the workload of manual screening, improves the accuracy and efficiency of information extraction, and ensures that the whole vehicle software class data version information set comprehensively covers the software class data requirements of the series of vehicles.
[0123] Regarding step S140, in some embodiments of the present disclosure, steps S141 and S142 as shown in Figure 7 may be included.
[0124] Step S141, from the historical whole vehicle software class data version and the whole vehicle software class data version information set, determine the latest version number of the plurality of software class data.
[0125] Step S142, combine the latest version numbers of the plurality of software class data together to obtain a new vehicle software class data version.
[0126] Exemplarily, the latest version numbers of the plurality of software class data can be combined together in a tiled manner to obtain the new vehicle software class data version.
[0127] The vehicle software class data version generation method of the above embodiment combines the latest version number in the historical vehicle software class data version and the vehicle software class data version information set to generate a new vehicle software class data version, ensuring the timeliness and integrity of the new vehicle software class data version. Moreover, the mechanism of automatically selecting the latest version simplifies the generation process of the vehicle software class data version, improves the maintenance efficiency of the vehicle software class data version of the series vehicle model, and is suitable for the software upgrade scene of rapid iteration.
[0128] Regarding step S141, in some embodiments of the present disclosure, steps S1411 and S1412 as shown in the following can be included. Figure 8
[0129] Step S1411, for the first software class data in the historical vehicle software class data version and the vehicle software class data version information set, taking the maximum version number of the first software class data as the latest version number of the first software class data, the first software class data being the software class data existing simultaneously in the historical vehicle software class data version and the vehicle software class data version information set.
[0130] Step S1412, for the second software class data in the historical vehicle software class data version and the vehicle software class data version information set, taking the version number of the second software class data directly as the latest version number of the second software class data, the second software class data being the software class data not existing simultaneously in the historical vehicle software class data version and the vehicle software class data version information set.
[0131] The vehicle software class data version generation method of the above embodiment accurately determines the latest version number of the software class data existing simultaneously and not existing simultaneously in the historical vehicle software class data version and the vehicle software class data version information set in different ways, thereby providing data support for generating accurate vehicle software class data version, providing guarantee for software class data version maintenance of vehicles in production, on sale, in production and on sale, and expanding the applicable scene of the vehicle software class data version.
[0132] Please refer to Figure 9 In one example, the vehicle software class data version generation method can include steps S301 to S315, and the content related to steps S301 to S315 can refer to the description of the above embodiments. For the sake of brevity, it will not be repeated here.
[0133] In step S301, a historical whole vehicle software type data version, a bill of materials and an option list are acquired.
[0134] In step S302, a part is selected from the bill of materials in a sequence of traversing the tree structure layer by layer.
[0135] In step S303, it is determined whether there is an option in the option list which is in the same group as the part in the bill of materials based on the group information, and if so, step S304 is entered, otherwise step S308 is entered.
[0136] In step S304, the option basic information and the option group information of the option in the same group are supplemented to the bill of materials.
[0137] In step S305, it is determined whether the option is software type data based on the part type, and if so, step S306 is entered, otherwise step S308 is entered.
[0138] In step S306, the software type data version information corresponding to the option is added to the whole vehicle software type data version information set.
[0139] In step S307, the attribute value of the software type data version information in the whole vehicle software type data version information set is set, for example, the validity is set as “valid”.
[0140] In step S308, it is determined whether the part in the bill of materials is traversed, and if so, step S309 is entered, otherwise step S302 is entered.
[0141] In step S309, the whole vehicle software type data version information set is obtained.
[0142] In step S310, a new whole vehicle software type data version is generated according to the historical whole vehicle software type data version and the whole vehicle software type data version information set.
[0143] In step S311, a maintained whole vehicle software type data version is determined according to a maintenance operation for the new whole vehicle software type data version. Specifically, in the case where the maintenance operation for the new whole vehicle software type data version is detected, the software type data version of the maintained controller in the new whole vehicle software type data version is determined; according to the acquired compatibility rule, it is determined whether the software type data version of the un-maintained controller in the new whole vehicle software type data version is compatible with the software type data version of the maintained controller; the un-compatible software type data version is maintained; and in the case where the maintenance operation is detected, the maintained whole vehicle software type data version is determined.
[0144] In step S312, the state of the maintained whole vehicle software type data version is changed to a draft state.
[0145] In step S313, if it is detected that the vehicle software data version after maintenance has entered the review process, the status of the vehicle software data version after maintenance is changed to the review status.
[0146] In step S314, if the maintenance-reviewed vehicle software data version is detected as having passed the review, the status of the maintenance-reviewed vehicle software data version is changed to the published status.
[0147] In step S315, the updated version of the vehicle software data is released.
[0148] In one example, a vehicle software data version management system built based on the above-mentioned method for generating vehicle software data versions is as follows: Figure 10 As shown, the vehicle software data version management system provides limited support for the maintenance and management of vehicle software data and software packages through its basic service layer and business application layer. The basic service layer provides functions such as user management, role management, permission management, log management, process management, and component management. The business application layer provides capabilities such as vehicle model management, project management, software package management, bill of materials management, vehicle software data version information set management, vehicle software data version management, and release and change management. The vehicle software data version management system effectively connects the R&D and application platforms of electronic control software through integration with upstream and downstream systems. The vehicle software data version management system integrates with the ALM (Application Lifecycle Management) system for software under test, with the PDM (Product Data Management) system for software that has completed single-controller testing and been released, and with the BOM system for released bills of materials, achieving centralized collection of upstream product software R&D data. The system also integrates with downstream E-Flash (Embedded Flash) systems, manufacturing execution systems, after-sales systems, and OTA systems through standardized data release interfaces, enabling centralized release of vehicle software data and software packages. In this way, the use of an information system for unified management of vehicle software and integration with upstream and downstream systems avoids the tedious work of manually maintaining data tables, improving the accuracy of data maintenance and the timeliness and consistency of data transmission.
[0149] Based on any of the above embodiments, this disclosure also provides a vehicle software data version generation device.
[0150] Figure 11 This is a schematic block diagram of a vehicle software data version generation device according to one embodiment of the present disclosure.
[0151] likeFigure 11 As shown, the vehicle software class data version generation apparatus comprises: an acquisition module 110, configured to acquire historical vehicle software class data versions, a bill of materials, and an option list, the historical vehicle software class data versions comprising version numbers of software class data written by controllers of vehicles of the same series and different configurations, the bill of materials comprising at least software class data version information of original controllers, and the option list comprising software class data version information of replacement controllers; a supplement module 120, configured to supplement the software class data version information in the bill of materials according to the option list to obtain a supplemented bill of materials; an extraction module 130, configured to extract software class data version information from the supplemented bill of materials to obtain a set of vehicle software class data version information; and a generation module 140, configured to generate a new vehicle software class data version according to the historical vehicle software class data versions and the set of vehicle software class data version information.
[0152] The vehicle software class data version generation apparatus described above can be in the form of computer software, and each module of the vehicle software class data version generation apparatus described above can be implemented by a computer software module.
[0153] In some embodiments of the present disclosure, the vehicle software class data version generation apparatus can further comprise: a first determination module configured to perform the step S150 described above; a judgment module configured to perform the step S160 described above; a maintenance restriction module configured to perform the step S170 described above; and a second determination module configured to perform the step S180 described above.
[0154] In some embodiments of the present disclosure, the vehicle software class data version generation apparatus can further comprise: a first change module configured to perform the step S190 described above; a second change module configured to perform the step S210 described above; and a third change module configured to perform the step S220 described above.
[0155] In some embodiments of the present disclosure, the vehicle software class data version generation apparatus can further comprise: a prohibition module configured to prohibit the generation of a new vehicle software class data version for a target series of vehicles again in the case where it is detected that the target series of vehicles exists in a vehicle software class data version in a draft state or an under review state.
[0156] In some embodiments of the present disclosure, the option list further comprises grouping information of the original controllers and grouping information of the replacement controllers, and the supplement module 120 is configured to perform the steps S121 and S122 described above.
[0157] In some embodiments of the present disclosure, the extraction module 130 is configured to extract, from a plurality of part description information of the supplemented bill of materials, part description information of parts of which the part type is software class data, based on the part type of the described parts, to obtain the set of vehicle software class data version information.
[0158] In some embodiments of the present disclosure, the generating module 140 is configured to perform the above-mentioned steps S141 and S142.
[0159] In some embodiments of the present disclosure, the generating module 140 is configured to perform the above-mentioned steps S1411 and S1412.
[0160] The implementation process of the functions and roles of each module in the above-mentioned apparatus is specifically described in the implementation process of the corresponding steps in the above-mentioned method, which will not be described here again.
[0161] The execution subject of the vehicle software type data version generation method in the specific embodiments of the present disclosure can be a server, a mobile phone, a computer, or other electronic devices.
[0162] Therefore, based on any one of the above-mentioned embodiments, the present disclosure further provides an electronic device which can execute the vehicle software type data version generation method of any one of the above-mentioned embodiments of the present disclosure.
[0163] Figure 12 is a structural schematic block diagram of an electronic device 1000 according to an embodiment of the present disclosure.
[0164] The hardware structure of the electronic device 1000 can be implemented by using a bus architecture. The bus architecture can include any number of interconnected buses and bridges, depending on the particular application of the hardware and overall design constraints. The bus 1100 connects various circuits including one or more processors 1200, memories 1300, and / or hardware modules together. The bus 1100 can also connect various other circuits 1400 such as peripheral devices, voltage regulators, power management circuits, external antennas, etc. The bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one connection line is used in the figure, but it does not mean that there is only one bus or one type of bus.
[0165] For ease of illustration, some steps of the above-mentioned method are described in correspondence with modules. It should be understood that the corresponding module performing one or more steps of the above-mentioned method can be one or more hardware modules specially configured to perform the corresponding steps, or implemented by a processor configured to perform the corresponding steps, or stored in a computer readable medium for implementation by a processor, or implemented by some combination.
[0166] The present disclosure also provides a readable storage medium having stored therein a computer program, which, when executed by a processor, is used to implement the method described above. The "readable storage medium" can be any device that can contain, store, communicate, propagate or transport a program for use by or in connection with an instruction execution system, apparatus or device. More specific examples of the readable storage medium include the following: an electrical connection having one or more wires (electronic device), a portable computer diskette (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CD-ROM), etc.
[0167] The present disclosure also provides a computer program product, and the method of the present disclosure can be implemented wholly or partially by software, hardware, firmware, or any combination thereof. When implemented by software, it can be implemented wholly or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer programs or instructions are loaded and executed, the processes or functions of the present disclosure are wholly or partially executed.
[0168] The computer programs or instructions can be stored in a readable storage medium or transferred from one readable storage medium to another readable storage medium, for example, the computer programs or instructions can be transferred from one website site, computer, server or data center to another website site, computer, server or data center by wired or wireless means. The readable storage medium can be any available medium that can be accessed or a data storage device such as a server, data center, etc. that integrates one or more available media. The available media can be a magnetic medium, such as a floppy disk, a hard disk, a magnetic tape; an optical medium, such as a digital video disc; and a semiconductor medium, such as a solid state disk. The computer readable storage medium can be a volatile or non-volatile storage medium, or can include both volatile and non-volatile storage media.
[0169] Those skilled in the art will appreciate that embodiments of the present disclosure can be provided as methods, devices, or computer program products. Therefore, the present disclosure can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present disclosure can take the form of a computer program product implemented on one or more computer usable storage media (including, but not limited to, magnetic disk storage, CD-ROM, optical storage, etc.) containing computer usable program code.
[0170] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flow or blocks Figure 1 means for functionally implementing the steps listed in the flowchart block or blocks.
[0171] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks. Figure 1 one or more flow or blocks Figure 1 means for functionally implementing the steps listed in the flowchart block or blocks.
[0172] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flow or blocks Figure 1 means for functionally implementing the steps listed in the flowchart block or blocks.
[0173] In the description of the specification, the description of the terms "one embodiment / way", "some embodiments / ways", "example", "specific example", or "some examples" and the like means that the specific features, structures, or characteristics described in connection with the embodiment / way or example are included in at least one embodiment / way or example of the present disclosure. In the specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment / way or example. Also, the specific features, structures, or characteristics described can be combined in any appropriate manner in one or more embodiments / ways or examples. In addition, the person skilled in the art can combine and combine the different embodiments / ways or examples described in the specification and the features of the different embodiments / ways or examples without contradiction.
[0174] Those skilled in the art should understand that the above embodiments are only for clearly illustrating the present disclosure, and are not intended to limit the scope of the present disclosure. Based on the above disclosure, other changes or modifications can be made by those skilled in the art, and these changes or modifications are still within the scope of the present disclosure.
Claims
1. A method for generating a vehicle software class data version, characterized by, The method comprises: acquiring historical vehicle software version, a bill of materials and an option list, the historical vehicle software version comprising version numbers of software versions of controllers of vehicles of the same series and different configurations, the bill of materials comprising at least software version information of original controllers, and the option list comprising software version information of replacement controllers; supplementing the software version information in the bill of materials according to the option list to obtain a supplemented bill of materials; extracting the software version information from the supplemented bill of materials to obtain a set of vehicle software version information; and generating a new vehicle software version according to the historical vehicle software version and the set of vehicle software version information. The option list further comprises grouping information of the original controllers and grouping information of the replacement controllers. The step of supplementing the software version information in the bill of materials according to the option list comprises: judging, based on the grouping information, whether there is a replacement controller in the same group as the original controller in the bill of materials in the option list; and if yes, supplementing the software version information of the replacement controller in the same group to the bill of materials. After the new vehicle software version is generated, the method further comprises: in a case where a maintenance operation is detected for the new vehicle software version, determining a software version of a maintained controller in the new vehicle software version; 2. The method of claim 1, wherein, judging, according to an acquired compatibility rule, whether a software version of an un-maintained controller in the new vehicle software version is compatible with the software version of the maintained controller; performing maintenance restriction on incompatible software versions, the incompatible software versions being software versions of un-maintained controllers that are incompatible with the software version of the maintained controller; and in a case where the maintenance operation is terminated, determining a post-maintenance vehicle software version. The compatibility rule comprises one or more of a hardware-software compatibility rule, a software compatibility rule and a version compatibility rule, the hardware-software compatibility rule defining a compatibility relationship between a controller version and a software version, the software compatibility rule defining a compatibility relationship between different software versions, and the version compatibility rule defining a compatibility relationship between different software versions. The maintenance restriction comprises one or more of the following steps:
3. The method of claim 2, wherein, not displaying the incompatible software versions; 4. The method of claim 2, wherein, displaying the incompatible software versions and compatible software versions in different display effects, the compatible software versions being software versions of un-maintained controllers that are compatible with the software version of the maintained controller; inhibiting selection of the incompatible software versions; and providing a compatibility warning prompt in a case where the incompatible software versions are selected. After the post-maintenance vehicle software version is determined, the method further comprises: changing a state of the post-maintenance vehicle software version to a draft state.
5. The method of claim 2, wherein, In a case where it is detected that the maintenance vehicle software type data version enters an audit process, a state of the maintenance vehicle software type data version is changed to an auditing state; and In a case where it is detected that the maintenance vehicle software type data version passes the audit, the maintenance vehicle software type data version is released, and a state of the maintenance vehicle software type data version is changed to a released state.
6. The vehicle software class data version generation method according to any one of claims 1 to 5, characterized by, According to the historical vehicle software type data version and the vehicle software type data version information set, a new vehicle software type data version is generated, including: From the historical vehicle software type data version and the vehicle software type data version information set, a latest version number of a plurality of software type data is determined; and The latest version numbers of the plurality of software type data are combined together to obtain the new vehicle software type data version.
7. An electronic device, comprising: comprising: a memory storing a computer program; and a processor executing the computer program stored in the memory, so that the processor executes the vehicle software type data version generation method in any one of claims 1 to 6.
8. A readable storage medium, characterized by, The readable storage medium has a computer program stored therein, and the computer program is executed by the processor to implement the vehicle software type data version generation method in any one of claims 1 to 6.
9. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the vehicle software type data version generation method in any one of claims 1 to 6.
Citation Information
Patent Citations
Vehicle software updating method and device, equipment and storage medium
CN118860446A
Vehicle OTA upgrading method, device and equipment and storage medium
CN119718370A