CN114428634B - Vehicle-mounted software version management and control method and system based on large software version - Google Patents
Vehicle-mounted software version management and control method and system based on large software version Download PDFInfo
- Publication number
- CN114428634B CN114428634B CN202210111296.9A CN202210111296A CN114428634B CN 114428634 B CN114428634 B CN 114428634B CN 202210111296 A CN202210111296 A CN 202210111296A CN 114428634 B CN114428634 B CN 114428634B
- Authority
- CN
- China
- Prior art keywords
- software
- task
- version
- vehicle
- configuration group
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 25
- 238000001514 detection method Methods 0.000 claims description 29
- 238000010276 construction Methods 0.000 claims description 8
- 230000004913 activation Effects 0.000 claims description 5
- 238000011895 specific detection Methods 0.000 claims description 5
- 230000001502 supplementing effect Effects 0.000 claims description 5
- 230000001174 ascending effect Effects 0.000 abstract description 4
- 238000010586 diagram Methods 0.000 description 6
- 238000009434 installation Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
Abstract
The invention relates to a vehicle-mounted software version management and control method and a system based on a large software version, wherein the method comprises the following steps: creating a large software version and a specific software version based on the train and vehicle type configuration group; constructing an upgrade task based on the large software version; and detecting upgrading tasks based on the large software version. In the invention, the vehicle upgradeable software is managed in a centralized way, and by constructing a large version of the vehicle upgradeable software, on one hand, the version state of the vehicle upgradeable software is unified, so that the software state of vehicles with the same vehicle type in the market is not disordered, and on the other hand, the concept of the large version of the software is provided, so that the manager can control the same ascending and descending and the upgrading sequence among a plurality of software in the software set easily, and the compatibility among the software is ensured. The large software version is used as granularity to issue the upgrade task and issue the upgrade task, so that a vehicle factory can conveniently and uniformly manage the version characteristics of a certain upgrade task, and a foundation is laid for the sale of subsequent functions.
Description
Technical Field
The invention relates to the technical field of remote upgrading of vehicle-mounted software, in particular to a vehicle-mounted software version management and control technology based on a large software version.
Background
With the development of the internet-based vehicle technology, in order to reduce the recall of the problem vehicles, each large vehicle factory processes the after-sale problem in time, iteratively updates the market vehicle functions, improves the user experience, and is deeply researched and applied to the remote upgrading technology of the vehicle-mounted device software, but at present, each software of the vehicle is respectively upgraded according to single software, or all the software of the vehicle is made into a whole package for upgrading. Because a vehicle often has more upgradeable software, the consistency of vehicle software versions cannot be ensured when each vehicle software is upgraded according to a single software, so that the state of the vehicle software version in the market is disordered, the vehicle software versions often depend on each other, and the compatibility problem among the software is unavoidable. If the vehicle upgrades according to the whole package of software, the files of the upgrade software are too large, the upgrade time is long, a special whole vehicle software architecture is required, most of software which is not updated can appear, and the upgrade is required.
Disclosure of Invention
The invention aims to provide a vehicle-mounted software version management and control method and system based on a large software version, which solve the technical problems that: the current upgrading modes of the vehicle software are two, namely, upgrading the vehicle software according to single software respectively, and upgrading all the vehicle software into a whole package; for the former, since a vehicle often has more upgradeable software, such as upgrading according to single software, consistency of vehicle software version cannot be ensured, and the vehicle software is often mutually dependent and incompatible. For the latter, the files of the updated software are too large, the updating is time-consuming, a special whole vehicle software architecture is required, and most of the software which is not updated is required to be updated.
In order to solve the technical problems, the invention adopts the following technical scheme: a vehicle-mounted software version management and control method based on a large software version comprises the following steps:
s01: creating a large software version and a specific software version based on the train and vehicle type configuration group;
S02: constructing an upgrade task based on the large software version;
S03: and detecting upgrading tasks based on the large software version.
Preferably, the method comprises the steps of,
In the S01, the specific creation flow of the large software version and the specific software version based on the train-vehicle type configuration group is as follows:
s011: configuring a complete set of vehicle software;
S012: creating a vehicle type configuration group;
S013: setting the vehicle type configuration contained under the vehicle type configuration group;
s014: setting a software set of a vehicle type configuration group;
S015: creating a large software version of the vehicle type configuration group;
S016: and setting each specific software version under the large version according to the software set.
Preferably, the method comprises the steps of,
In S02, the specific construction flow of the upgrade task is as follows:
S021: creating an upgrade task for vehicle version distribution;
s022: setting to which configuration group the task is issued;
S023: selecting a large version of the release configuration group;
s024: setting other task configurations;
s025: setting a task release range;
S026: task enablement.
Preferably, the method comprises the steps of,
In S03, the specific detection flow based on the upgrade task of the software large version is:
S031: receiving an upgrade task detection request sent by a terminal;
s032: checking and supplementing software and hardware information;
S033: judging whether the uploaded information is qualified or not, if so, executing the next step;
s034: acquiring a train and a model configuration of a vehicle;
S035: finding out the affiliated vehicle type configuration group through vehicle type configuration;
s036: judging whether the configuration group belongs to the configuration group or not, if so, executing the next step;
S037: acquiring a software list of a vehicle type configuration group;
s038: judging whether the software information uploaded by the terminal is matched with the software list, if so, executing the next step;
S039: acquiring tasks of the activation states associated with the configuration groups;
S040: judging whether task information exists, if so, executing the next step;
s041: the task list is larger than the terminal version according to the large version and is ordered from low to high;
s042: checking whether the upgrading ranges are matched or not according to the task sequence, and whether update package information exists or not;
s043: judging whether the task is matched or not, if so, executing the next step;
S044: the vehicle related information, the large version and the software package information are assembled into the task.
Preferably, the method comprises the steps of,
In the step S033, if not, the jump is performed in step S031;
in the step S036, if not, the jump is performed in step S031;
in the step S038, if not, the jump is performed in step S031;
in the step S040, if not, jump execution S031;
in S043, if not, the jump is performed S031.
The invention also provides a vehicle-mounted software version management and control system based on the large software version, which comprises the following steps:
the creation module is used for creating a large software version and a specific software version thereof based on the train and vehicle type configuration group;
the construction module is used for constructing an upgrade task based on the large software version;
and the detection module is used for detecting the upgrade task based on the large software version.
Preferably, the method comprises the steps of,
In the creation module, the specific creation flow of the large software version and the specific software version based on the train-vehicle type configuration group is as follows: configuring a complete set of vehicle software; creating a vehicle type configuration group; setting the vehicle type configuration contained under the vehicle type configuration group; setting a software set of a vehicle type configuration group; creating a large software version of the vehicle type configuration group; and setting each specific software version under the large version according to the software set.
Preferably, the method comprises the steps of,
In the construction module, the specific construction flow of the upgrade task is as follows: creating an upgrade task for vehicle version distribution; setting to which configuration group the task is issued; selecting a large version of the release configuration group; setting other task configurations; setting a task release range; task enablement.
Preferably, the method comprises the steps of,
In the detection module, the specific detection flow based on the upgrade task of the large software version is as follows: receiving an upgrade task detection request sent by a terminal; checking and supplementing software and hardware information; judging whether the uploaded information is qualified or not, if so, executing the next step; acquiring a train and a model configuration of a vehicle; finding out the affiliated vehicle type configuration group through vehicle type configuration; judging whether the configuration group belongs to the configuration group or not, if so, executing the next step; acquiring a software list of a vehicle type configuration group; judging whether the software information uploaded by the terminal is matched with the software list, if so, executing the next step; acquiring tasks of the activation states associated with the configuration groups; judging whether task information exists, if so, executing the next step; the task list is larger than the terminal version according to the large version and is ordered from low to high; checking whether the upgrading ranges are matched or not according to the task sequence, and whether update package information exists or not; judging whether the task is matched or not, if so, executing the next step; the vehicle related information, the large version and the software package information are assembled into the task.
Preferably, the method comprises the steps of,
If the uploading information is unqualified, executing a task of an upgrade task detection request sent by the receiving terminal;
if the task does not belong to one configuration group, executing the task of the upgrade task detection request sent by the receiving terminal;
If the uploaded software information of the terminal is not matched with the software list, executing a task of receiving an upgrade task detection request sent by the terminal;
If the task information does not exist, executing the task of the upgrade task detection request sent by the receiving terminal;
and if the task is not matched, executing the task of the upgrade task detection request sent by the receiving terminal.
By adopting the technical scheme, the invention has the following beneficial technical effects: the consistency of managing the vehicle software version based on the large version is realized by constructing the software large version of the vehicle type configuration group to which the vehicle belongs, configuring the specific software version of the following software of the software large version according to the software set, configuring the upgrading task and detecting the vehicle upgrading task. In the invention, the vehicle upgradeable software is managed in a centralized way, and by constructing a large version of the vehicle upgradeable software, on one hand, the version state of the vehicle upgradeable software is unified, so that the software state of vehicles with the same vehicle type in the market is not disordered, and on the other hand, the concept of the large version of the software is provided, so that the manager can control the same ascending and descending and the upgrading sequence among a plurality of software in the software set easily, and the compatibility among the software is ensured. The large software version is used as granularity to issue the upgrade task and issue the upgrade task, so that a vehicle factory can conveniently and uniformly manage the version characteristics of a certain upgrade task, and a foundation is laid for the sale of subsequent functions.
Drawings
FIG. 1 is a general logic flow diagram of the present invention;
FIG. 2 is a sub-logic flow diagram of a software large version and related software information for constructing a vehicle model configuration group to which a vehicle belongs;
FIG. 3 is a schematic diagram of a train software set;
FIG. 4 is a schematic diagram of a vehicle train, a vehicle model configuration group and a vehicle model software set relationship;
FIG. 5 is a schematic diagram of a large version of the vehicle model configuration group setup software and a specific software version thereof;
FIG. 6 is a sub-logic flow diagram of an upgrade task build based on a large version of software;
FIG. 7 is a flow chart of a software large version based vehicle upgrade task detection sub-logic.
Detailed Description
The invention is further described below with reference to the accompanying drawings.
The invention provides a vehicle-mounted software version management and control method based on a large software version, which comprises the following steps:
first, creating a large software version and a specific software version based on a train and vehicle type configuration group.
Specifically, an administrator logs in an OTA cloud system, enters a train OTA configuration page provided by the system, and distinguishes a certain class of vehicles according to the train, and the OTA behaviors of the class of vehicles are consistent. Firstly, a train is required to be selected, all upgradeable software under the train is configured for the train, and usually, a plurality of different vehicle types exist under the train, each vehicle type upgradeable software may be different, some vehicle types are more upgradeable software, some vehicle types are less, different vehicle types are the same upgrade object, and the corresponding software may be different. Different vehicle types are grouped by creating a vehicle type configuration group, and a plurality of vehicle types with the same upgrade software set are distributed to the same vehicle type configuration group for unified management. An upgrade software set for the model configuration group may then be set, which is a subset of the above-configured vehicle software set. The software of the vehicles of all the vehicles under the vehicle type configuration group must be all in the upgrade software set configured by the vehicle type configuration group. Then, a large software version needs to be created for the vehicle type configuration group, a base line version is created first, the base line version is an initial version, namely, the version when the vehicle leaves the factory, and then a large software version with a higher version is created according to iteration or software updating conditions. When a large software version is created, a specific version of each piece of software in the software collection needs to be set for each large software version, and when a specific version is set, the version of a specific piece of software under the large software version which needs to be currently configured should be between the version of the piece of software in the large software version and the version of the piece of software in the large software version. After the specific version of all the software under a certain large software version is set, a large software version of a vehicle type configuration group of a vehicle system is successfully created, and then an upgrading task can be created.
And secondly, constructing an upgrade task based on the large software version.
An administrator logs in an OTA cloud system and enters a vehicle task management page provided by the system, and certain types of vehicles are distinguished according to the vehicle, and OTA behaviors of the vehicles are consistent. Firstly, a train is required to be selected, an upgrading task of the train is created, the task is set to be released to a certain configuration group created in the prior art, a certain large version of the configuration group to be released by the task is selected, and then other task information such as upgrading estimated time consumption, maximum deployment times, maximum installation times, maximum rollback times, upgrading modes and the like can be set. Then, the issuing scope of the task is set, the issuing scope of the task is mainly used for setting which vehicles in the train can detect a certain upgrading task, the task can be issued to a single vehicle, or a vehicle can be grouped, the task can be issued to a vehicle configured by a certain vehicle type in a vehicle type configuration group, the task can be issued to a vehicle configured by the vehicle type configuration group in a certain region, and the like, and the flexible issuing scope is set, so that upgrading operation scenes such as internal test, public test and the like are met. After the task release scope is set, the upgrade task can be started. At this point, the vehicle meeting the upgrade scope condition may detect that the upgrade is being performed.
And thirdly, detecting the vehicle upgrading task based on the large software version.
After the upgrade task based on the large software version is built, the vehicle can detect the upgrade task. When an upgrade task detection request of a vehicle reaches an OTA cloud system, the system firstly needs to check whether software and hardware information is in accordance with specifications, then supplements related information such as tenant, frame number and current position information of the vehicle, returns error information if the uploaded information is out of specification, otherwise, acquires the information of the train and the vehicle type of the vehicle from a train factory system, and can find a configuration group of the vehicle through the vehicle type, at the moment, needs to check whether a software collection list of the configuration group is matched with a software list of the vehicle, if not, needs to record the vehicle and the software and hardware information thereof, marks the vehicle as a software abnormal vehicle, and processes the vehicle for a subsequent administrator. When the software listing information of the vehicle is a subset of the software collection of the vehicle model configuration group, the vehicle software information is considered to be compliant. Pulling all upgrade tasks in the starting state of the current release configuration group, removing the upgrade tasks of which the task release large version is not higher than the current vehicle large version, then carrying out ascending sorting according to the large version released by the upgrade tasks, sequentially checking whether the upgrade scope of each task contains the vehicle or not, and checking sequentially to ensure that the vehicle does not jump to the large version for upgrade, checking whether the software with the higher version in the software set is provided with an update package once the vehicle is found to meet the upgrade scope, if the software with the higher version is not provided with the update package, continuing the judgment of the next task, otherwise, judging that the current task is the detected upgrade task requiring the vehicle upgrade. And finally, the vehicle system related configuration information, the large version information and the software package information which needs to be updated are assembled into task information and returned to the vehicle, and the vehicle starts to upgrade the task.
The above steps are described in detail with reference to the accompanying drawings.
As shown in fig. 1, the above steps mainly operate in an OTA cloud system, and also relate to a vehicle-mounted terminal. The method is completed cooperatively through the steps of constructing a large software version and related software information thereof, constructing an upgrade task based on the large software version and detecting a vehicle upgrade task based on the large software version.
In the first step, as shown in fig. 2, the system logs in to the OTA cloud system, and enters a system-provided train OTA configuration page, which already provides all the train information of the train factory, and selects a train, such as a train P90. The maximum supported OTA software corpus of the train P90 is configured, as shown in FIG. 3, all software needing OTA upgrade of the train P90 is added into a list, and is distinguished according to upgrade objects and software piece numbers, such as upgrade objects APA, corresponding software numbers 9111115-PO21, and if the same upgrade object software of different vehicle types is possibly incompatible, software of two different software piece numbers needs to be added, such as two kinds of software of 9111782-M52 and 9111782-M49 of upgrade objects THU_OS in FIG. 3 respectively.
In order to solve the problem that different vehicle types have different software on the same upgrading object under the vehicle system, the vehicle type configuration groups are created to group the different vehicle types, namely, a plurality of vehicle types with the same upgrading software set are distributed to the same vehicle type configuration group to be managed in a unified mode. An upgrade software set of the vehicle model configuration group is then set, which is a subset of the above-configured vehicle system software set. The software of the vehicles of all the vehicles under the vehicle type configuration group must be all in the upgrade software set configured by the vehicle type configuration group. Otherwise, the upgrade cannot be performed. As shown in fig. 4, two vehicle type configuration groups p90_conf_g_01 and p90_conf_g_02 are created under the vehicle system P90, the software of the tha_os of the two configuration groups is different, and the software that p90_conf_g_02 can be upgraded is less than p90_conf_g_01, but the software sets of the two are both subsets of the vehicle system P90 software combination. Under each configuration group there are multiple vehicle types, such as p90_conf_g_01 having vehicle types p90_model_01, p90_model_02 and p90_model_03, and the same software list of p90_model_01, p90_model_02 and p90_model_03 is also a subset of p90_conf_g_01 and also a subset of the software set of the vehicle system P90.
After the vehicle type configuration groups are set, each vehicle type configuration group can manage own software states according to the large software version. The naming convention of large version can be uniformly regulated, and large version setting is carried out according to the vehicle system_main version number, the secondary version number_date is used for setting such as P90_V001.01_20210120, and a base line version is set, wherein the base line version is an initial version, namely, the version when the vehicle leaves the factory, and the base line version is the minimum version such as P90_V000.00_00000000. A larger version of the software, such as p90_v008.01_20210521, may then be created based on the iteration or software update conditions.
After the large software version of the vehicle type configuration group is created, a specific version of each piece of software in the software set needs to be set for each large software version, and when the specific version is set, the version of a specific piece of software under the large software version of the current vehicle type configuration group is required to be between the version of the software in the higher large software version and the version of the software in the lower large software version. As shown in fig. 5, some large versions of software are created under the vehicle model configuration group p90_conf_g_02, including a baseline version p90_v000.00_0000, other iterated versions p90_v001.01_20210608, p90_v002.01_20210909, etc., wherein each version of software in the large software version p90_v001.01_20210608 should be greater than or equal to the version of the corresponding software in p90_v000.00_00000000 and less than or equal to the version of the corresponding software in p90_v002.01_20210909, and each version of software in the large software version p90_v002.01 _20209p90_v001.01_20210608 should be greater than or equal to the version of the corresponding software in p90_v001.01_20210608, such as the versions of software in three large software versions of software 9111733-BH01, respectively: the software versions in three software major editions of V0001.0001< V0021.0001< V0025.0001, software 9211601-CR01 are respectively: v0001.0001< V0008.6001 = V0008.6001.
After the specific version of all the software under a certain large software version is set, a large software version of a vehicle type configuration group of a vehicle system is successfully created, and then an upgrading task can be created.
In the second step, as shown in fig. 6, the system logs in to the OTA cloud system, and enters a system-provided train OTA upgrade task configuration page, which already provides all the train information of the train factory, and selects a train, such as a train P90. An upgrade task of the train P90 is created, the task is set to be released to a certain configuration group created before, a certain large version of the configuration group to be released by the task is selected, and then other task information such as upgrade estimated time consumption, maximum deployment times, maximum installation times, maximum rollback times, upgrade modes and the like can be set. If the upgrade task name is created as upgrade task A, the upgrade task name is issued to the vehicle type configuration group P90_CONF_G_02, and the large version of the issued software is P90_V001.01_20210608. The set upgrade is expected to take 28 minutes, the maximum deployment times, the maximum installation times and the maximum rollback times are all set to 2 times, and the upgrade mode is selected for upgrade. To illustrate, an upgrade task B is configured and issued to the vehicle model configuration group P90_CONF_G_02, and the large version of software issued is P90_V002.01_20210909. The set upgrade is expected to take 20 minutes, the maximum deployment times, the maximum installation times and the maximum rollback times are all set to 2 times, and the upgrade mode is selected for upgrade.
Then, the issuing ranges of the upgrading task A and the upgrading task B are set, the issuing ranges of the tasks are mainly used for setting which vehicles under the train can detect the upgrading task, the tasks can be issued to a single vehicle or a vehicle group, the tasks can be issued to vehicles of a certain vehicle type in a vehicle type configuration group, the tasks can be issued to vehicles of the vehicle type configuration group in a certain region, and the like, and the flexible issuing range is set, so that upgrading operation scenes such as internal test, public test and the like are met. If the upgrade task A and the upgrade task B are set, the upgrade task A and the upgrade task B are issued to the vehicle Model P90_Model_06. And after the task release range is set, enabling the upgrading task. At this point, the vehicle meeting the upgrade scope condition may detect that the upgrade is being performed. I.e., a vehicle of type p90_model_06 may be matched to the upgrade mission.
In the third step, as shown in fig. 7, when an upgrade task detection request of a vehicle p90_model_06_0001 arrives at the OTA cloud system, it is assumed that the current state of the vehicle p90_model_06_0001 is that the software is P90_v001.01_20210608, each software case is software 9111782-M49 version V0012.3401, software 9211601-CR01 version V0008.6001, software 9111733-bh01 version V0021.0001, software 9111711-bh05 version V0001.0001, software 9111715-AI01 version V0061.0001, and software reported by the vehicle p90_model_06_0001 are all accurate. The OTA cloud system obtains the vehicle system P90, the vehicle Model 06 and the vehicle Model 06 from the vehicle factory system, the vehicle Model P90 Model 06 finds the configuration group P90 CONF G02 of the vehicle through the vehicle Model P90 Model 06, then checks whether the software collection list of the configuration group is matched with the software list of the vehicle, and finds that the software list reported by the vehicle P90 Model 06_0001 is a subset of the software collection of the configuration group P90 CONF G02, so that the vehicle can be normally detected. If the information is not matched, the information such as the current software of the vehicle P90_model_06_0001 needs to be recorded, and the information is identified as a software abnormal vehicle and is processed by a subsequent manager.
The OTA cloud system discovers that the configuration group P90_CONF_G_02 has two enabled upgrading tasks, namely an upgrading task A and an upgrading task B, removes the upgrading task A of which the task release large version is not higher than the current vehicle large version, and then carries out ascending sorting according to the large version released by the upgrading task, and only the upgrading task B and the release software large version P90_V002.01_20210909 thereof are not sorted. The vehicle P90_Model_06_0001 meets the upgrade scope of each task, and the order check is to ensure that the vehicle does not jump to upgrade, the vehicle Model of the vehicle P90_Model_06_0001 is found to be P90_Model_06, the upgrade scope set by upgrade task B is met, software versions reported by the vehicle P90_V002.01_20210909 and the vehicle P90_Model_06_0001 released by the upgrade task are compared, whether higher versions of software exist or not is checked, and the higher versions of software are found to be the software 9111782-M49 version V0015.6091, the software 9111733-BH01 version V0025.0001, the software 9111711-BH05 version V0002.0001 and the software 9111715-AI01 version V0062.0001 respectively, namely the upgrade task B is the upgrade task of the vehicle P90_Model_06_0001, which needs to be upgraded. And finally, the vehicle system related configuration information, the large version information and the software package information which needs to be updated are assembled into task information and returned to the vehicle, and the vehicle starts to upgrade the task.
The invention also provides a vehicle-mounted software version management and control system based on the large software version, which comprises the following steps:
the creation module is used for creating a large software version and a specific software version thereof based on the train and vehicle type configuration group;
the construction module is used for constructing an upgrade task based on a large software version;
And the detection module is used for detecting the upgrade task based on the large software version.
In particular, the method comprises the steps of,
In the creation module, the specific creation flow of the large software version and the specific software version based on the train and vehicle type configuration group is as follows: configuring a complete set of vehicle software; creating a vehicle type configuration group; setting the vehicle type configuration contained under the vehicle type configuration group; setting a software set of a vehicle type configuration group; creating a large software version of the vehicle type configuration group; and setting each specific software version under the large version according to the software set.
In particular, the method comprises the steps of,
In the construction module, the specific construction flow of the upgrade task is as follows: creating an upgrade task for vehicle version distribution; setting to which configuration group the task is issued; selecting a large version of the release configuration group; setting other task configurations; setting a task release range; task enablement.
In particular, the method comprises the steps of,
In the detection module, the specific detection flow based on the upgrade task of the large software version is as follows: receiving an upgrade task detection request sent by a terminal; checking and supplementing software and hardware information; judging whether the uploaded information is qualified or not, if so, executing the next step; acquiring a train and a model configuration of a vehicle; finding out the affiliated vehicle type configuration group through vehicle type configuration; judging whether the configuration group belongs to the configuration group or not, if so, executing the next step; acquiring a software list of a vehicle type configuration group; judging whether the software information uploaded by the terminal is matched with the software list, if so, executing the next step; acquiring tasks of the activation states associated with the configuration groups; judging whether task information exists, if so, executing the next step; the task list is larger than the terminal version according to the large version and is ordered from low to high; checking whether the upgrading ranges are matched or not according to the task sequence, and whether update package information exists or not; judging whether the task is matched or not, if so, executing the next step; the vehicle related information, the large version and the software package information are assembled into the task.
In particular, the method comprises the steps of,
If the uploading information is unqualified, executing a task of an upgrade task detection request sent by the receiving terminal;
if the task does not belong to one configuration group, executing the task of the upgrade task detection request sent by the receiving terminal;
If the uploaded software information of the terminal is not matched with the software list, executing a task of receiving an upgrade task detection request sent by the terminal;
If the task information does not exist, executing the task of the upgrade task detection request sent by the receiving terminal;
and if the task is not matched, executing the task of the upgrade task detection request sent by the receiving terminal.
Claims (6)
1. The vehicle-mounted software version control method based on the large software version is characterized by comprising the following steps of:
S01: creating a large software version and a specific software version thereof based on a train and vehicle type configuration group comprises the following steps:
s011: configuring a complete set of vehicle software;
S012: creating a vehicle type configuration group;
S013: setting the vehicle type configuration contained under the vehicle type configuration group;
s014: setting a software set of a vehicle type configuration group;
S015: creating a large software version of the vehicle type configuration group;
s016: setting each specific software version under the large version according to the software set;
S02: constructing an upgrade task based on the large software version, comprising:
S021: creating an upgrade task for vehicle version distribution;
s022: setting to which configuration group the task is issued;
S023: selecting a large version of the release configuration group;
s024: setting other task configurations;
s025: setting a task release range;
S026: task starting;
S03: and detecting upgrading tasks based on the large software version.
2. The method for managing and controlling large version of vehicle-mounted software according to claim 1, wherein,
In S03, the specific detection flow based on the upgrade task of the software large version is:
S031: receiving an upgrade task detection request sent by a terminal;
s032: checking and supplementing software and hardware information;
S033: judging whether the uploaded information is qualified or not, if so, executing the next step;
s034: acquiring a train and a model configuration of a vehicle;
S035: finding out the affiliated vehicle type configuration group through vehicle type configuration;
s036: judging whether the configuration group belongs to the configuration group or not, if so, executing the next step;
S037: acquiring a software list of a vehicle type configuration group;
s038: judging whether the software information uploaded by the terminal is matched with the software list, if so, executing the next step;
S039: acquiring tasks of the activation states associated with the configuration groups;
S040: judging whether task information exists, if so, executing the next step;
s041: the task list is larger than the terminal version according to the large version and is ordered from low to high;
s042: checking whether the upgrading ranges are matched or not according to the task sequence, and whether update package information exists or not;
s043: judging whether the task is matched or not, if so, executing the next step;
S044: the vehicle related information, the large version and the software package information are assembled into the task.
3. The method for managing and controlling large version of vehicle-mounted software according to claim 2, wherein,
In the step S033, if not, the jump is performed in step S031;
in the step S036, if not, the jump is performed in step S031;
in the step S038, if not, the jump is performed in step S031;
in the step S040, if not, jump execution S031;
in S043, if not, the jump is performed S031.
4. A vehicle software version management and control system based on a large software version, comprising:
The creation module is used for creating a large software version and a specific software version thereof based on the train and vehicle type configuration group, and comprises the following steps: configuring a complete set of vehicle software; creating a vehicle type configuration group; setting the vehicle type configuration contained under the vehicle type configuration group; setting a software set of a vehicle type configuration group; creating a large software version of the vehicle type configuration group; setting each specific software version under the large version according to the software set;
the construction module is used for constructing upgrade tasks based on the large software version, and comprises the step of creating upgrade tasks distributed by the train version; setting to which configuration group the task is issued; selecting a large version of the release configuration group; setting other task configurations; setting a task release range; task starting;
and the detection module is used for detecting the upgrade task based on the large software version.
5. The large software version control system according to claim 4 wherein,
In the detection module, the specific detection flow based on the upgrade task of the large software version is as follows: receiving an upgrade task detection request sent by a terminal; checking and supplementing software and hardware information; judging whether the uploaded information is qualified or not, if so, executing the next step; acquiring a train and a model configuration of a vehicle; finding out the affiliated vehicle type configuration group through vehicle type configuration; judging whether the configuration group belongs to the configuration group or not, if so, executing the next step; acquiring a software list of a vehicle type configuration group; judging whether the software information uploaded by the terminal is matched with the software list, if so, executing the next step; acquiring tasks of the activation states associated with the configuration groups; judging whether task information exists, if so, executing the next step; the task list is larger than the terminal version according to the large version and is ordered from low to high; checking whether the upgrading ranges are matched or not according to the task sequence, and whether update package information exists or not; judging whether the task is matched or not, if so, executing the next step; the vehicle related information, the large version and the software package information are assembled into the task.
6. The large software version control system according to claim 5, wherein,
If the uploading information is unqualified, executing a task of an upgrade task detection request sent by the receiving terminal;
if the task does not belong to one configuration group, executing the task of the upgrade task detection request sent by the receiving terminal;
If the uploaded software information of the terminal is not matched with the software list, executing a task of receiving an upgrade task detection request sent by the terminal;
If the task information does not exist, executing the task of the upgrade task detection request sent by the receiving terminal;
and if the task is not matched, executing the task of the upgrade task detection request sent by the receiving terminal.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210111296.9A CN114428634B (en) | 2022-01-29 | 2022-01-29 | Vehicle-mounted software version management and control method and system based on large software version |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210111296.9A CN114428634B (en) | 2022-01-29 | 2022-01-29 | Vehicle-mounted software version management and control method and system based on large software version |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114428634A CN114428634A (en) | 2022-05-03 |
| CN114428634B true CN114428634B (en) | 2024-09-17 |
Family
ID=81313656
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210111296.9A Active CN114428634B (en) | 2022-01-29 | 2022-01-29 | Vehicle-mounted software version management and control method and system based on large software version |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114428634B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1567843A (en) * | 2003-06-22 | 2005-01-19 | 华为技术有限公司 | Method of automatic software update for terminal equipment |
| CN113504921A (en) * | 2021-06-03 | 2021-10-15 | 浙江吉利控股集团有限公司 | Vehicle software updating method and system |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104834537B (en) * | 2014-12-30 | 2018-04-27 | 沈阳东软医疗系统有限公司 | Data processing method, server and client |
| CN112181456A (en) * | 2020-09-24 | 2021-01-05 | 上海仙塔智能科技有限公司 | Vehicle version management method, system and computer storage medium |
| CN112416389B (en) * | 2020-11-11 | 2024-06-11 | 沈海峰 | OTA software version management method based on block chain technology |
| CN113946358B (en) * | 2021-10-27 | 2024-02-27 | 北京斯年智驾科技有限公司 | Automatic driving vehicle software remote upgrading method based on vehicle management system |
-
2022
- 2022-01-29 CN CN202210111296.9A patent/CN114428634B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1567843A (en) * | 2003-06-22 | 2005-01-19 | 华为技术有限公司 | Method of automatic software update for terminal equipment |
| CN113504921A (en) * | 2021-06-03 | 2021-10-15 | 浙江吉利控股集团有限公司 | Vehicle software updating method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114428634A (en) | 2022-05-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10162625B2 (en) | Vehicle control storage methods and systems | |
| US8806471B2 (en) | Upgrade and downgrade in package update operations | |
| CN102223256B (en) | Method and system for multi-ONU (optical network unit) automatic upgrading in GPON (gigabit-capable passive optical network) access system | |
| US20170242678A1 (en) | Method and apparatus for vehicle software update installation | |
| US20140282467A1 (en) | Method and Apparatus for Multiple Vehicle Software Module Reflash | |
| US20170242679A1 (en) | Method and apparatus for over the air updates | |
| EP2696532A2 (en) | Method, server and system for starting application | |
| CN106874026A (en) | For the method and apparatus via the air interface steadily firmware of more new vehicle | |
| CN108446129A (en) | Method and apparatus for the update accordance processing of multicycle vehicle software | |
| CN117032935B (en) | Management scheduling system and method for heterogeneous accelerator card based on K8s | |
| CN109831338A (en) | Vehicle system upgrade method, cloud server and mobile terminal | |
| CN204425405U (en) | A kind of upgrade-system of the car-mounted terminal based on cloud server | |
| CN101175001A (en) | Distributed multi-program product automatic updating system and method thereof | |
| CN114428634B (en) | Vehicle-mounted software version management and control method and system based on large software version | |
| CN113612824A (en) | Calibration data management method, system, medium, and device | |
| US11726443B2 (en) | Efficient controller data generation and extraction | |
| Shi et al. | A vehicle electric control unit over-the-air reprogramming system | |
| CN113268257A (en) | Vehicle-mounted application upgrading system, method and computer storage medium | |
| CN101925094A (en) | Updating system and method for network element management system | |
| CN108521452B (en) | Method and system for intelligently upgrading service version | |
| CN116366636A (en) | Vehicle software upgrading method and device and automobile | |
| CN105591749B (en) | A kind of authorization processing method, device and system | |
| CN111221556B (en) | Remote upgrade RSU mirror image method and system | |
| CN111225371A (en) | Method and device for controlling upgrading of intelligent business terminal system | |
| CN110865836A (en) | Cloud upgrading method and system for firmware of vehicle navigation CAN protocol box |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |