CN117938906A - Vehicle upgradeable version matching method, system, equipment and readable storage medium - Google Patents
Vehicle upgradeable version matching method, system, equipment and readable storage medium Download PDFInfo
- Publication number
- CN117938906A CN117938906A CN202410090239.6A CN202410090239A CN117938906A CN 117938906 A CN117938906 A CN 117938906A CN 202410090239 A CN202410090239 A CN 202410090239A CN 117938906 A CN117938906 A CN 117938906A
- Authority
- CN
- China
- Prior art keywords
- version
- vehicle
- software
- hardware
- upgradeable
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 44
- 238000003860 storage Methods 0.000 title claims description 28
- 238000004364 calculation method Methods 0.000 claims description 14
- 238000004590 computer program Methods 0.000 claims description 13
- 230000015654 memory Effects 0.000 claims description 10
- 238000013486 operation strategy Methods 0.000 claims description 10
- 238000010586 diagram Methods 0.000 description 15
- 238000012545 processing Methods 0.000 description 9
- 230000005540 biological transmission Effects 0.000 description 8
- 238000007726 management method Methods 0.000 description 7
- 102100034112 Alkyldihydroxyacetonephosphate synthase, peroxisomal Human genes 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 238000011161 development Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- RYGMFSIKBFXOCR-UHFFFAOYSA-N Copper Chemical compound [Cu] RYGMFSIKBFXOCR-UHFFFAOYSA-N 0.000 description 2
- 238000003491 array Methods 0.000 description 2
- 229910052802 copper Inorganic materials 0.000 description 2
- 239000010949 copper Substances 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 101000799143 Homo sapiens Alkyldihydroxyacetonephosphate synthase, peroxisomal Proteins 0.000 description 1
- 238000000848 angular dependent Auger electron spectroscopy Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000009472 formulation Methods 0.000 description 1
- 230000004927 fusion Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Abstract
The invention discloses a vehicle upgradeable version matching method, which comprises the steps of distributing a software baseline version through the relation among an electric platform definition domain, a logic and a controller, setting a hardware large version, calculating the compatibility of vehicle information and the hardware large version when the vehicle upgradeable version is required to be acquired, obtaining a second software baseline version compatible with the current vehicle, and comparing the second software baseline version with the first software baseline version to obtain final vehicle upgradeable software. The method has the advantages that whether the vehicle can be compatible with the large hardware version related to the first software baseline version is judged through the hardware information of the vehicle, on the basis, the upgradeable software version of the vehicle is obtained through the software information of the vehicle, the problem that the existing manually judged upgradeable version of the vehicle is easy to be incompatible in version is solved, the upgradeable software version of the vehicle can be obtained more comprehensively, the obtaining efficiency and accuracy are improved, the cost of manual judgment is also reduced, and the stability of OTA operation is also improved.
Description
Technical Field
The present invention relates to OTA technology, and in particular, to a method, a system, a device, and a readable storage medium for matching a vehicle upgradeable version.
Background
An Over-the-Air Technology (OTA) is a Technology for implementing remote management of mobile terminal equipment and SIM card data through an Air interface of mobile communication, and the OTA Technology is also applied to the automotive industry and is used for implementing mass automobile upgrades.
In actual OTA operation activities, OTA operation strategies are generated by identifying OTA tasks, the traditional method is manual identification, updated contents are obtained according to experience, time and effort are wasted, whole software is pushed to a vehicle end, the vehicle end identifies the updated contents, and a platform end cannot acquire the updated contents of each vehicle. After the OTA is upgraded or the hardware is replaced, the upgradeable software version which can be used by the vehicle is required to be confirmed so as to ensure the replacement accuracy and the feasibility of a software upgrade path, the manually judged upgradeable software is easy to misjudge and miss the upgradeable software version, the situation that the vehicle software version and the hardware version are incompatible is caused, and the incompatibility can lead to repeated adjustment of an OTA operation strategy.
Disclosure of Invention
In view of the fact that the existing manual confirmation of the vehicle upgradeable software version is easy to cause errors, the invention provides a vehicle upgradeable version matching method, vehicle information is compared with a software baseline version and a hardware version, compatibility of the vehicle to the software baseline version can be calculated, and the vehicle upgradeable software version is obtained.
In order to achieve the above purpose, the embodiment of the present invention adopts the following technical scheme:
A vehicle upgradeable version matching method, the vehicle upgradeable software matching method comprising the steps of:
acquiring a first software baseline version and vehicle information;
setting a hardware large version according to the first software baseline version;
Calculating the compatibility of the vehicle information and the large hardware version to obtain a second software baseline version;
And comparing the vehicle information with the second software baseline version to obtain the vehicle upgradeable software version.
According to one aspect of the invention, the vehicle information includes at least: vehicle hardware version and vehicle software version.
In accordance with one aspect of the present invention, before the acquiring the first software baseline version, the method further comprises: and building an electrical platform, and releasing a first software baseline version on the electrical platform.
In accordance with one aspect of the invention, the setting the hardware large version according to the first software baseline version includes:
Acquiring hardware information, and calculating compatibility of hardware and a first software baseline version;
making the calculation result into a compatible hardware list;
and setting a large hardware version according to the compatible hardware list.
According to one aspect of the present invention, the vehicle scalable version matching method further includes: and setting a software version number contained in the first software baseline version and a version number of the hardware large version, and associating the version number of the hardware large version with the software version number of the first software baseline version.
According to one aspect of the invention, the electrical platform further comprises a domain comprising at least one domain hardware version, the large hardware version being a combination of domain hardware versions of different domains.
According to one aspect of the invention, the domain comprises at least: chassis domain, body domain, power domain, recreational domain, and auxiliary driving domain.
According to one aspect of the invention, the calculating compatibility of the vehicle information with the large hardware version, obtaining the second software baseline version includes:
Acquiring all domain hardware versions of a vehicle according to the hardware versions of the vehicle;
comparing all domain hardware versions of the vehicle with the hardware large version to obtain a hardware large version compatible with the vehicle;
And matching the large version of the vehicle-compatible hardware with the first software baseline version to obtain a second software baseline version.
According to one aspect of the present invention, the comparing the vehicle information with the second software baseline version to obtain the vehicle upgradeable software version includes:
Acquiring a software version number of the vehicle according to the software version of the vehicle, and comparing the software version number with a second software baseline version;
and returning to the software version with the version number larger than the vehicle software version in the second software baseline version to obtain the vehicle upgradeable software version.
According to one aspect of the present invention, the vehicle upgrade software matching method further includes: acquiring all domain hardware versions and vehicle software versions of a vehicle according to vehicle information, performing vehicle portrait, and storing the vehicle portrait and the obtained vehicle upgradeable software versions
In accordance with one aspect of the present invention, after the acquiring the first software baseline version, and the vehicle information, further comprises:
judging whether the vehicle information is consistent with the existing vehicle portrait;
If the vehicle images are consistent, the upgrade software version of the vehicle is directly obtained.
According to one aspect of the present invention, the vehicle upgradeable software matching method further includes: and generating an OTA operation strategy according to the vehicle information and the vehicle upgradeable software version.
A vehicle upgradeable version matching system, the vehicle upgradeable version matching system comprising:
the information acquisition module is used for acquiring the first software baseline version and the vehicle information;
the hardware setting module is used for setting a large hardware version according to the first software baseline version;
the compatibility calculating module is used for calculating the compatibility of the vehicle information and the large hardware version to obtain a second software baseline version;
And the result generation module is used for comparing the vehicle information with the second software baseline version to obtain the vehicle upgradeable software version.
A vehicle upgradeable version matching device comprising:
a memory for storing a computer program;
a processor for implementing the steps of a vehicle upgradeable version matching method as described above when executing the computer program.
A vehicle upgradeable version matching readable storage medium having stored thereon a computer program which is executed with the steps of a vehicle upgradeable version matching method as described above.
The implementation of the invention has the advantages that: according to the vehicle upgradeable version matching method, the relation among the electric platform definition domain, the logic and the controller is used for distributing the software baseline version, the hardware large version is set through the software baseline version, when the vehicle upgradeable version needs to be acquired, the compatibility of vehicle information and the hardware large version is calculated, a software large version set compatible with the current vehicle is obtained, namely a second software baseline version, and the second software baseline version is compared with the first software baseline version to obtain final vehicle upgradeable software. The method comprises the steps of judging whether the vehicle can be compatible with a large hardware version related to a first software baseline version or not through hardware information of the vehicle, confirming an upgradeable software version of the vehicle through software information of the vehicle, solving the problem that the existing manually-judged upgradeable version of the vehicle is easy to cause incompatibility of the version, acquiring the upgradeable software version of the vehicle more comprehensively, improving the acquiring efficiency and accuracy, reducing the cost of manual judgment and improving the stability of OTA operation activities.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings that are needed in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a flowchart of a vehicle scalable version matching method according to an embodiment of the present invention;
FIG. 2 is a flow chart of a vehicle scalable version matching method according to other embodiments of the present invention;
FIG. 3 is a schematic diagram of a vehicle upgradeable version matching system according to a fourth embodiment of the invention;
Fig. 4 is a diagram of a vehicle scalable version matching apparatus according to a fifth embodiment of the present invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
Example 1
As shown in fig. 1, a vehicle scalable version matching method includes the steps of:
step S1: acquiring a first software baseline version and vehicle information;
Specifically, by building an electrical platform, a logical topology structure diagram is defined on the electrical platform, and the relationship among the domain, the Request ID and the controller is defined through the logical topology structure diagram.
In practical application, build electric platform, electric platform can develop different motorcycle types, and the controller in the vehicle can carry out classification management through the territory generally, consequently, carry the territory in electric platform, carry the controller in the territory, and every controller has the Request ID, i.e. the position that the controller is located at the vehicle, and software research and development need combine the environment that the controller is located at the vehicle, just can guarantee the brush writing of software effectively.
In practical applications, the controller contains different software, and the different software is used as a software part for forming the controller, for example, in an ADAS software product, the bottom layer software, the application software and the calibration software are software parts for forming the software product. And each software part has respective software part numbers and software version numbers, the software part numbers can be ordered and combined according to a Request ID rule, and the result obtained by ordering and combining the software version numbers is the actual content of the large software version.
In this embodiment, by using a more compact software large version number, such as V1.0, V2.0, and V3.0, the large version of software released by the platform is represented, while the first software baseline version is the set of all large versions of software released by the platform.
In practical applications, the vehicle information may be obtained through a platform, a system or a database to which the vehicle belongs, where the vehicle information at least includes a hardware version and a software version of the vehicle.
Step S2: setting a hardware large version according to the first software baseline version;
In this embodiment, setting the hardware large version according to the first software baseline version may be achieved by:
Step S21: acquiring hardware information, and calculating compatibility of hardware and a first software baseline version;
In practical applications, each vehicle has its corresponding hardware version number, typically managed by a platform according to a control domain based on existing vehicle hardware configurations, and the platform typically contains one or even more control domains.
In this embodiment, the domain includes:
The chassis domain (CH) is related to the running of the automobile and consists of a transmission system, a running system, a steering system and a braking system;
A Body Domain (BD) integrating all functional devices such as key functions, car lights, car windows, etc.;
A power domain (PT), an intelligent powertrain management unit capable of implementing transmission management, engine management, battery monitoring, alternator regulation, etc.;
entertainment fields (IF), typically in-vehicle infotainment systems, streaming rearview mirrors, etc.;
And the auxiliary driving domain (ADAS) is used for assisting driving or automatic driving, so that the vehicle can have the capabilities of multi-sensor fusion, positioning, path planning and decision control.
In practical applications, each domain contains at least one domain hardware version, for example, the chassis domain may have a first version 01 and a second version 02, and the hardware configuration of the first version 01 is different from that of the second version 02, and the domain hardware version number of the domain is generally indicated by 01 and 02.
In practical applications, the first software baseline version usually includes a plurality of different large software versions, and the large software version is closely related to the hardware of the vehicle software, and is generally not applicable to all hardware, where the large software version is incompatible with the large hardware version, and the large hardware version is composed of a plurality of domain hardware versions, so that compatibility of the domain hardware version and the first software baseline version is determined, that is, compatibility of each domain hardware version and the large software version is determined.
Step S22: making the calculation result into a compatible hardware list;
in this embodiment, the hardware versions of the body domain, the power domain and the auxiliary driving domain are only two versions of 01 and 02, and the hardware versions of the chassis domain and the entertainment domain comprise three versions of 01, 02 and 03.
According to the compatibility of the domain hardware version and the first software baseline version, a compatible hardware list is obtained, and the following table 1 is referred to:
Table 1: compatible hardware inventory
Step S3: setting a large hardware version according to the compatible hardware list;
In this embodiment, the five control domains are sequentially arranged to form a new large hardware version, the domain hardware version is represented by a domain hardware version number in the large hardware version, and in the large hardware version, the domain hardware version is not unique, that is, the same large hardware version can be compatible with multiple different domain hardware versions.
In this embodiment, in the large hardware version, the arrangement order of the domains is fixed, and is: chassis domain, body domain, power domain, recreational domain, auxiliary driving domain.
In this embodiment, according to the compatibility of the chassis domain, the vehicle body domain, the power domain, the entertainment domain, and the auxiliary driving domain with the first software baseline version, a compatible domain hardware version number is obtained, and according to the actual situation, the hardware large version V1.0.0 and v2.0.0 are set, and the compatibility of the compatible domain hardware version and the hardware large version is determined, referring to the following table 2:
Table 2: compatibility judgment table of domain hardware version number and hardware large version
For example, after excluding the situation that the hardware version numbers of the domains are not compatible with each other, the hardware version numbers of the five control domains corresponding to the large hardware version V1.0.0 are obtained as follows: [01.01.02.02.01, 01.02.01.03.02, 02.02.01.03.02]; taking the first data as an example, the first data represents that the domain hardware version of the chassis domain is 01, the domain hardware version of the vehicle body domain is 01, and the domain hardware version of the power domain is 02; domain hardware version of entertainment domain 02; the domain hardware version of the auxiliary driving domain is 01. In practical application, if the newly added vehicle information or the vehicle information of the existing vehicle changes, the compatibility calculation of the hardware version and the large hardware version of the vehicle domain is triggered; and if the domain hardware version corresponding to the new software large version is added, triggering the compatibility calculation of the domain hardware version and the hardware large version.
Step S24: the version number of the large version of hardware is associated with the version number of the first software baseline version.
In this embodiment, according to tables 1 and 2, the version number of the large hardware version is associated with the software version number of the first software baseline version, wherein large hardware version V1.0.0 is associated with large software versions V1.0 and V2.0; while the hardware large version v2.0.0 is associated with the software large version V3.0.
In practical applications, the large hardware version V0.0.1 represents the factory configuration of the vehicle, and the large software version is usually accompanied by the alternation of the large hardware version, so when the large hardware version is set, the large hardware version V0.0.1 is not associated with the large software version, and when the upgradeable software version of the vehicle is obtained, the compatibility with the vehicle information is not required to be repeatedly calculated.
Step S3: calculating the compatibility of the vehicle information and the large hardware version to obtain a second software baseline version;
step S31: acquiring all domain hardware versions of a vehicle according to the hardware versions of the vehicle;
In this embodiment, all domain hardware versions of the vehicle are acquired, that is, the domain hardware versions of the chassis domain, the body domain, the power domain, the entertainment domain, and the auxiliary driving domain of the vehicle are acquired, for example, the hardware version of the vehicle a is 01.01.02.02.01.
Step S32: and comparing all domain hardware versions of the vehicle with the hardware large version to obtain the hardware large version compatible with the vehicle.
In this embodiment, all domain hardware versions of the vehicle are compared to the hardware major versions V1.0.0 and v2.0.0:
wherein V1.0.0 is [01.01.02.02.01, 01.02.01.03.02, 02.02.01.03.02], the domain hardware version of vehicle a is consistent with the first data in the large hardware version V1.0.0, and therefore, the vehicle is consistent with the large hardware version V1.0.0;
V2.0.0 is [01.02.02.03.02, 02.01.01.02.02, 03.02.01.01.02], and the driver assistance domain version is 01 in the domain hardware version of vehicle a, whereas referring to table 2, it is known that the hardware large version v2.0.0 is not compatible with the driver assistance domain version 01, and thus, vehicle a is not compatible with the hardware large version v2.0.0.
Step S33: matching the large version of the vehicle-compatible hardware with the first software baseline version to obtain a second software baseline version;
In this embodiment, the first software baseline version includes 3 large software versions V1.0, V2.0, and V3.0, where large software versions V1.0, V2.0 are associated with large hardware version V1.0.0, and thus the second software baseline version includes V1.0, V2.0.
Step S4: and comparing the vehicle information with the second software baseline version to obtain the vehicle upgradeable software version.
Acquiring a software version number of the vehicle according to the software version of the vehicle, and comparing the software version number with a second software baseline version;
and returning to the software version with the version number larger than the vehicle software version in the second software baseline version to obtain the vehicle upgradeable software version.
In this embodiment, the software version of the vehicle a is obtained by obtaining the software version of the vehicle a, where the software version number of the second software baseline version includes the software version numbers V1.0 and V2.0, and by comparing the software version of the second software baseline version, the version number of which is greater than the software version of the vehicle is V2.0, so that the vehicle upgradeable software version is V2.0.
In the embodiment, a large hardware version is associated with a first software baseline version issued by a platform, when a vehicle needs to acquire an upgradeable software version, a large compatible hardware version of the vehicle is obtained through compatibility calculation, and a large compatible software version is searched according to the acquired large hardware version; the upgradeable software version of the vehicle is finally obtained through the vehicle software version, so that the situation that the vehicle information is incompatible with the upgradeable software version in the upgrading process is avoided, the upgradeable software version of the vehicle can be obtained more comprehensively, and the obtaining efficiency and accuracy are improved.
Example two
As shown in fig. 2, a vehicle scalable version matching method includes the steps of:
step S1: acquiring a first software baseline version and vehicle information;
Specifically, by building an electrical platform, a logical topology structure diagram is defined on the electrical platform, and the relationship among the domain, the Request ID and the controller is defined through the logical topology structure diagram.
In practical application, build electric platform, electric platform can develop different motorcycle types, and the controller in the vehicle can carry out classification management through the territory generally, consequently, carry the territory in electric platform, carry the controller in the territory, and every controller has the Request ID, i.e. the position that the controller is located at the vehicle, and software research and development need combine the environment that the controller is located at the vehicle, just can guarantee the brush writing of software effectively.
In practical applications, the controller contains different software, and the different software is used as a software part for forming the controller, for example, in an ADAS software product, the bottom layer software, the application software and the calibration software are software parts for forming the software product. And each software part has respective software part numbers and software version numbers, the software part numbers can be ordered and combined according to a Request ID rule, and the result obtained by ordering and combining the software version numbers is the actual content of the large software version.
In this embodiment, by using a more compact software large version number, such as V1.0, V2.0, and V3.0, the large version of software released by the platform is represented, while the first software baseline version is the set of all large versions of software released by the platform. In practical applications, the vehicle information may be obtained through a platform, a system or a database to which the vehicle belongs, where the vehicle information at least includes a hardware version and a software version of the vehicle.
Step S2: setting a hardware large version according to the first software baseline version;
In this embodiment, setting the hardware large version according to the first software baseline version may be achieved by:
Step S21: acquiring hardware information, and calculating compatibility of hardware and a first software baseline version;
In practical applications, each vehicle has its corresponding hardware version number, typically managed by a platform according to a control domain based on existing vehicle hardware configurations, and the platform typically contains one or even more control domains.
In this embodiment, the domain includes: chassis domain, body domain, power domain, recreational domain, auxiliary driving domain.
In practical applications, each domain contains at least one domain hardware version, for example, the chassis domain may have a first version 01 and a second version 02, and the hardware configuration of the first version 01 is different from that of the second version 02, and the domain hardware version number of the domain is generally indicated by 01 and 02.
In practical applications, the first software baseline version usually includes a plurality of different large software versions, and the large software version is closely related to the hardware of the vehicle software, and is generally not applicable to all hardware, where the large software version is incompatible with the large hardware version, and the large hardware version is composed of a plurality of domain hardware versions, so that compatibility of the domain hardware version and the first software baseline version is determined, that is, compatibility of each domain hardware version and the large software version is determined.
Step S22: making the calculation result into a compatible hardware list;
in this embodiment, the hardware versions of the body domain, the power domain and the auxiliary driving domain are only two versions of 01 and 02, and the hardware versions of the chassis domain and the entertainment domain comprise three versions of 01, 02 and 03.
Wherein, according to the compatibility of the domain hardware version and the first software baseline version, a compatible hardware list is obtained, referring to the following table 3:
table 3: compatible hardware inventory
Step S3: setting a large hardware version according to the compatible hardware list;
In this embodiment, the five control domains are sequentially arranged to form a new large hardware version, the domain hardware version is represented by a domain hardware version number in the large hardware version, and in the large hardware version, the domain hardware version is not unique, that is, the same large hardware version can be compatible with multiple different domain hardware versions.
In this embodiment, in the large hardware version, the arrangement order of the domains is fixed, and is: chassis domain, body domain, power domain, recreational domain, auxiliary driving domain.
In this embodiment, according to the compatibility of the chassis domain, the vehicle body domain, the power domain, the entertainment domain, and the auxiliary driving domain with the first software baseline version, a compatible domain hardware version number is obtained, and according to the actual situation, the hardware large version V1.0.0 and v2.0.0 are set, and the compatibility of the compatible domain hardware version and the hardware large version is determined, referring to the following table 4:
Table 4: compatibility judgment table of domain hardware version number and hardware large version
In practical application, if the newly added vehicle information or the vehicle information of the existing vehicle changes, the compatibility calculation of the hardware version and the large hardware version of the vehicle domain is triggered; and if the domain hardware version corresponding to the new software large version is added, triggering the compatibility calculation of the domain hardware version and the hardware large version.
Step S24: the version number of the large version of hardware is associated with the version number of the first software baseline version.
In this embodiment, according to tables 3 and 4, the version number of the large hardware version is associated with the software version number of the first software baseline version, wherein large hardware version V1.0.0 is associated with large software versions V1.0 and V2.0; while the hardware large version v2.0.0 is associated with the software large version V3.0.
Step S3: calculating the compatibility of the vehicle information and the large hardware version to obtain a second software baseline version;
step S31: acquiring all domain hardware versions of a vehicle according to the hardware versions of the vehicle;
In this embodiment, all domain hardware versions of the vehicle are acquired, that is, the domain hardware versions of the chassis domain, the body domain, the power domain, the entertainment domain, and the auxiliary driving domain of the vehicle are acquired, for example, the hardware version of the vehicle a is 01.01.02.02.01.
Step S32: and comparing all domain hardware versions of the vehicle with the hardware large version to obtain the hardware large version compatible with the vehicle.
In this embodiment, all domain hardware versions of the vehicle are compared to the hardware major versions V1.0.0 and v2.0.0:
wherein V1.0.0 is [01.01.02.02.01, 01.02.01.03.02, 02.02.01.03.02], the domain hardware version of vehicle a is consistent with the first data in the large hardware version V1.0.0, and therefore, the vehicle is consistent with the large hardware version V1.0.0;
V2.0.0 is [01.02.02.03.02, 02.01.01.02.02, 03.02.01.01.02], and the driver assistance domain version is 01 in the domain hardware version of vehicle a, whereas referring to table 2, it is known that the hardware large version v2.0.0 is not compatible with the driver assistance domain version 01, and thus, vehicle a is not compatible with the hardware large version v2.0.0.
Step S33: matching the large version of the vehicle-compatible hardware with the first software baseline version to obtain a second software baseline version;
In this embodiment, the first software baseline version includes 3 large software versions V1.0, V2.0, and V3.0, where large software versions V1.0, V2.0 are associated with large hardware version V1.0.0, and thus the second software baseline version includes V1.0, V2.0.
Step S4: and comparing the vehicle information with the second software baseline version to obtain the vehicle upgradeable software version.
Acquiring a software version number of the vehicle according to the software version of the vehicle, and comparing the software version number with a second software baseline version;
and returning to the software version with the version number larger than the vehicle software version in the second software baseline version to obtain the vehicle upgradeable software version.
In this embodiment, the software version of the vehicle a is obtained by obtaining the software version of the vehicle a, where the software version number of the second software baseline version includes the software version numbers V1.0 and V2.0, and by comparing the software version of the second software baseline version, the version number of which is greater than the software version of the vehicle is V2.0, so that the vehicle upgradeable software version is V2.0.
Step S5: and generating an OTA operation strategy according to the vehicle information and the vehicle upgradeable software version.
In practical applications, the generated OTA operation policy should at least include: source version, target upgrade vehicle, and content to be upgraded.
In this embodiment, the source version is the vehicle software version, the target version is the calculated vehicle upgradeable software version, the target vehicle is all vehicles corresponding to the vehicle hardware version, and the content to be upgraded needs to be obtained by comparing the source version and the target version.
According to the embodiment, the compatibility of the vehicle information and the large hardware version is calculated, the associated large software version is found out according to the large hardware version to serve as the large compatible software version, the vehicle upgradeable software version is found out according to the version number of the vehicle software version, and the OTA operation strategy is finally formulated according to the upgradeable software version and the vehicle information, so that the problem that the strategy needs to be repeatedly regulated due to incompatibility of the vehicle software upgradeable version and the vehicle in the conventional manual formulation of the OTA operation strategy can be solved.
Example III
As shown in fig. 2, a vehicle scalable version matching method includes the steps of:
step S1: acquiring a first software baseline version and vehicle information;
Specifically, by building an electrical platform, a logical topology structure diagram is defined on the electrical platform, and the relationship among the domain, the Request ID and the controller is defined through the logical topology structure diagram.
In practical application, build electric platform, electric platform can develop different motorcycle types, and the controller in the vehicle can carry out classification management through the territory generally, consequently, carry the territory in electric platform, carry the controller in the territory, and every controller has the Request ID, i.e. the position that the controller is located at the vehicle, and software research and development need combine the environment that the controller is located at the vehicle, just can guarantee the brush writing of software effectively.
In practical applications, the controller contains different software, and the different software is used as a software part for forming the controller, for example, in an ADAS software product, the bottom layer software, the application software and the calibration software are software parts for forming the software product. And each software part has respective software part numbers and software version numbers, the software part numbers can be ordered and combined according to a Request ID rule, and the result obtained by ordering and combining the software version numbers is the actual content of the large software version.
In this embodiment, by using a more compact software large version number, such as V1.0, V2.0, and V3.0, the large version of software released by the platform is represented, while the first software baseline version is the set of all large versions of software released by the platform. In practical applications, the vehicle information may be obtained through a platform, a system or a database to which the vehicle belongs, where the vehicle information at least includes a hardware version and a software version of the vehicle.
In this embodiment, a vehicle hardware version and a vehicle software version of a vehicle are acquired according to vehicle information, a vehicle portrait is stored in an electrical platform, and after a vehicle upgradeable software version is finally calculated, the vehicle upgradeable software version and the vehicle portrait are associated and stored in the electrical platform.
In this embodiment, after acquiring the vehicle information, it is also necessary to determine whether the vehicle information is consistent with the existing vehicle portrait;
If the vehicle images are inconsistent, the vehicle images are carried out on the current vehicle, and the vehicle images are stored in the electric platform;
if the vehicle portraits are consistent, searching the associated stored vehicle upgradeable software version according to the vehicle portraits, taking the searched result as the vehicle upgradeable software version, and executing the task after acquiring the vehicle upgradeable software version.
In the present embodiment, a vehicle representation, that is, a hardware representation of a vehicle is performed based on a hardware version of the vehicle; performing vehicle portrayal according to the vehicle software version, namely performing vehicle software portrayal according to the current software large version of the vehicle; a vehicle representation is made by a hardware representation of a vehicle and a software representation of the vehicle, and only when the vehicle information matches the vehicle hardware representation and the vehicle software representation, the vehicle information is determined to match the existing vehicle representation.
Step S2: setting a hardware large version according to the first software baseline version;
In this embodiment, setting the hardware large version according to the first software baseline version may be achieved by:
Step S21: acquiring hardware information, and calculating compatibility of hardware and a first software baseline version;
In practical applications, each vehicle has its corresponding hardware version number, typically managed by a platform according to a control domain based on existing vehicle hardware configurations, and the platform typically contains one or even more control domains.
In this embodiment, the domain includes: chassis domain, body domain, power domain, recreational domain, auxiliary driving domain.
In practical applications, each domain contains at least one domain hardware version, for example, the chassis domain may have a first version 01 and a second version 02, and the hardware configuration of the first version 01 is different from that of the second version 02, and the domain hardware version number of the domain is generally indicated by 01 and 02.
In practical applications, a vehicle is represented by a hardware version of the vehicle, that is, a hardware version of the vehicle is represented by all hardware versions of the vehicle.
In practical applications, the first software baseline version usually includes a plurality of different large software versions, and the large software version is closely related to the hardware of the vehicle software, and is generally not applicable to all hardware, where the large software version is incompatible with the large hardware version, and the large hardware version is composed of a plurality of domain hardware versions, so that compatibility of the domain hardware version and the first software baseline version is determined, that is, compatibility of each domain hardware version and the large software version is determined.
Step S22: making the calculation result into a compatible hardware list;
in this embodiment, the hardware versions of the body domain, the power domain and the auxiliary driving domain are only two versions of 01 and 02, and the hardware versions of the chassis domain and the entertainment domain comprise three versions of 01, 02 and 03.
Wherein, according to the compatibility of the domain hardware version and the first software baseline version, a compatible hardware list is obtained, referring to the following table 5:
Table 5: compatible hardware inventory
Step S3: setting a large hardware version according to the compatible hardware list;
In this embodiment, the five control domains are sequentially arranged to form a new large hardware version, the domain hardware version is represented by a domain hardware version number in the large hardware version, and in the large hardware version, the domain hardware version is not unique, that is, the same large hardware version can be compatible with multiple different domain hardware versions.
In this embodiment, in the large hardware version, the arrangement order of the domains is fixed, and is: chassis domain, body domain, power domain, recreational domain, auxiliary driving domain.
In this embodiment, according to the compatibility of the chassis domain, the vehicle body domain, the power domain, the entertainment domain, and the auxiliary driving domain with the first software baseline version, a compatible domain hardware version number is obtained, and according to the actual situation, the hardware large version V1.0.0 and v2.0.0 are set, and the compatibility of the compatible domain hardware version and the hardware large version is determined, referring to the following table 6:
table 6: compatibility judgment table of domain hardware version number and hardware large version
In practical application, if the newly added vehicle information or the vehicle information of the existing vehicle changes, the compatibility calculation of the hardware version and the large hardware version of the vehicle domain is triggered; and if the domain hardware version corresponding to the new software large version is added, triggering the compatibility calculation of the domain hardware version and the hardware large version.
Step S24: the version number of the large version of hardware is associated with the version number of the first software baseline version.
In this embodiment, according to tables 5 and 6, the version number of the large hardware version is associated with the software version number of the first software baseline version, wherein large hardware version V1.0.0 is associated with large software versions V1.0 and V2.0; while the hardware large version v2.0.0 is associated with the software large version V3.0.
Step S3: calculating the compatibility of the vehicle information and the large hardware version to obtain a second software baseline version;
step S31: acquiring all domain hardware versions of a vehicle according to the hardware versions of the vehicle;
In this embodiment, all domain hardware versions of the vehicle are acquired, that is, the domain hardware versions of the chassis domain, the body domain, the power domain, the entertainment domain, and the auxiliary driving domain of the vehicle are acquired, for example, the hardware version of the vehicle a is 01.01.02.02.01.
Step S32: and comparing all domain hardware versions of the vehicle with the hardware large version to obtain the hardware large version compatible with the vehicle.
In this embodiment, all domain hardware versions of the vehicle are compared to the hardware major versions V1.0.0 and v2.0.0:
wherein V1.0.0 is [01.01.02.02.01, 01.02.01.03.02, 02.02.01.03.02], the domain hardware version of vehicle a is consistent with the first data in the large hardware version V1.0.0, and therefore, the vehicle is consistent with the large hardware version V1.0.0;
V2.0.0 is [01.02.02.03.02, 02.01.01.02.02, 03.02.01.01.02], and the driver assistance domain version is 01 in the domain hardware version of vehicle a, whereas referring to table 2, it is known that the hardware large version v2.0.0 is not compatible with the driver assistance domain version 01, and thus, vehicle a is not compatible with the hardware large version v2.0.0.
Step S33: matching the large version of the vehicle-compatible hardware with the first software baseline version to obtain a second software baseline version;
In this embodiment, the first software baseline version includes 3 large software versions V1.0, V2.0, and V3.0, where large software versions V1.0, V2.0 are associated with large hardware version V1.0.0, and thus the second software baseline version includes V1.0, V2.0.
Step S4: and comparing the vehicle information with the second software baseline version to obtain the vehicle upgradeable software version.
Acquiring a software version number of the vehicle according to the software version of the vehicle, and comparing the software version number with a second software baseline version;
and returning to the software version with the version number larger than the vehicle software version in the second software baseline version to obtain the vehicle upgradeable software version.
In this embodiment, the software version of the vehicle a is obtained by obtaining the software version of the vehicle a, where the software version number of the second software baseline version includes the software version numbers V1.0 and V2.0, and by comparing the software version of the second software baseline version, the version number of which is greater than the software version of the vehicle is V2.0, so that the vehicle upgradeable software version is V2.0.
Step S5: and generating an OTA operation strategy according to the vehicle information and the vehicle upgradeable software version.
In practical applications, the generated OTA operation policy should at least include: source version, target upgrade vehicle, and content to be upgraded.
In this embodiment, the source version is the vehicle software version, the target version is the calculated vehicle upgradeable software version, the target vehicle is all vehicles corresponding to the vehicle hardware version, and the content to be upgraded needs to be obtained by comparing the source version and the target version.
In this embodiment, the source version may be obtained from a software representation of the vehicle, and the target vehicle may be obtained from a hardware representation of the vehicle.
According to the embodiment, the hardware portrait and the software portrait are respectively carried out for the vehicle by acquiring the hardware version and the software version of the vehicle, the hardware portrait and the software portrait are combined into the complete vehicle portrait, when the vehicle upgradeable software version is required to be acquired, whether the vehicle is consistent with the existing vehicle portrait in the platform is judged, and if the vehicle upgradeable software version is consistent with the existing vehicle portrait, the upgradeable software version of the vehicle can be directly obtained, so that the problem of repeated calculation compatibility of the same type of vehicle in the implementation process of an OTA operation strategy is avoided, the useless calculation process is reduced, and the implementation efficiency of the OTA operation strategy is improved.
Example IV
As shown in fig. 3, the vehicle scalable version matching system 2 includes:
An information acquisition module 22 for acquiring the first software baseline version, and the vehicle information;
A hardware setting module 23 for setting a hardware large version according to the first software baseline version;
a compatibility calculating module 24, configured to calculate compatibility between the vehicle information and the large hardware version, and obtain a second software baseline version;
the result generating module 25 is configured to compare the vehicle information with the second software baseline version to obtain a vehicle upgradeable software version.
In practical applications, the vehicle upgradeable version matching system further includes:
an electrical development platform 21 for defining a logical topology structure diagram and developing a first software baseline version;
the policy generation module 26 is configured to generate an OTA operation policy according to the vehicle information and the vehicle upgradeable software version.
Wherein, the logic topology structure diagram defines the relation among the domain, the Request ID and the controller;
The policy generation module 26 is connected to the information acquisition module 22 and the result generation module 25, and acquires the source version and the target upgrade vehicle through the information acquisition module 22, and acquires the target version through the result generation module 25.
In practical application, the electric development platform 21 is connected with the information acquisition module 22 and the hardware setting module 23, and the electric development platform 21 is also used for storing vehicle images and vehicle upgrading software corresponding to the vehicle images.
In practical applications, the hardware setting module 23 is connected to the compatible computing module 24, and the compatibility of the hardware information with the first software baseline version is computed by the compatible computing module 24.
In practical applications, the hardware setting module 23 further includes:
The hardware list is used for intuitively and completely displaying hardware information;
and the association module is used for associating the first software baseline version with the large hardware version compatible with the first software baseline version through the version number.
Example five
As shown in fig. 4, a vehicle scalable version matching apparatus includes:
a memory 100 for storing a computer program;
A processor 200, configured to implement the steps of the vehicle scalable version matching method described in the first, second and third embodiments when executing the computer program.
Example six
A vehicle-upgradeable version matching readable storage medium having stored thereon a computer program that is executed with the steps of the vehicle-upgradeable version matching method described in embodiments one, two, and three.
The present invention may be a system, method, and/or computer program product. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to perform aspects of the invention.
The readable storage medium is a computer readable storage medium that can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: portable computer disks, hard disks, random Access Memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), static Random Access Memories (SRAM), portable compact disc read-only memories (CD-ROM), digital Versatile Discs (DVD), memory sticks, floppy disks, mechanical coding devices such as punch cards or a protruding structure in a groove with instructions recorded thereon, and any suitable combination of the foregoing. Computer readable storage media as used herein should not be construed as vehicle information itself, such as vehicle hardware versions, vehicle software versions, and/or vehicle upgradeable software versions.
The computer readable program instructions described herein may be downloaded from a computer readable storage medium to a corresponding computing/processing device or to an external computer or external storage device via a network (e.g., the internet, a local area network, a wide area network, and/or a wireless network). The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers and/or edge servers. The network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.
The computer programs described herein are computer readable program instructions that can be downloaded from a computer readable storage medium to a corresponding computing/processing device or to an external computer or external storage device via a network (e.g., the internet, a local area network, a wide area network, and/or a wireless network). The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers and/or edge servers. The network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.
Computer readable program instructions for performing the operations of the present invention can be assembly instructions, instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including an object oriented SMALLTALK, C ++ or the like programming language and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, electronic circuitry, including, for example, programmable logic circuitry, field Programmable Gate Arrays (FPGAs), or Programmable Logic Arrays (PLAs), may be personalized by executing computer-readable program instructions using state information of the computer-readable program instructions in order to perform aspects of the invention.
Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, systems, apparatus, and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.
These computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having the instructions stored therein includes an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The foregoing is merely illustrative of the present invention, and the present invention is not limited thereto, and any changes or substitutions easily contemplated by those skilled in the art within the technical scope of the present invention should be included in the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.
Claims (15)
1. A vehicle upgradeable version matching method, characterized in that the vehicle upgradeable software matching method comprises the following steps:
acquiring a first software baseline version and vehicle information;
setting a hardware large version according to the first software baseline version;
Calculating the compatibility of the vehicle information and the large hardware version to obtain a second software baseline version;
And comparing the vehicle information with the second software baseline version to obtain the vehicle upgradeable software version.
2. The vehicle upgradeable version matching method of claim 1, wherein the vehicle information comprises at least: vehicle hardware version and vehicle software version.
3. The vehicle upgradeable version matching method of claim 2, further comprising, prior to the obtaining the first software baseline version: and building an electrical platform, and releasing a first software baseline version on the electrical platform.
4. A vehicle upgradeable version matching method according to claim 3, in which the setting of the hardware large version according to the first software baseline version comprises:
Acquiring hardware information, and calculating compatibility of hardware and a first software baseline version;
making the calculation result into a compatible hardware list;
and setting a large hardware version according to the compatible hardware list.
5. A vehicle upgradeable version matching method according to claim 3, further comprising: and setting a software version number contained in the first software baseline version and a version number of the hardware large version, and associating the version number of the hardware large version with the software version number of the first software baseline version.
6. The vehicle upgradeable version matching method of claim 5, wherein the electrical platform further comprises a domain containing at least one domain hardware version, the large hardware version being a combination of domain hardware versions of different domains.
7. The vehicle scalable version matching method of claim 6, wherein said domain comprises at least: chassis domain, body domain, power domain, recreational domain, and auxiliary driving domain.
8. The method of claim 6, wherein calculating compatibility of the vehicle information with the large hardware version to obtain the second software baseline version comprises:
Acquiring all domain hardware versions of a vehicle according to the hardware versions of the vehicle;
comparing all domain hardware versions of the vehicle with the hardware large version to obtain a hardware large version compatible with the vehicle;
And matching the large version of the vehicle-compatible hardware with the first software baseline version to obtain a second software baseline version.
9. The method for matching a vehicle upgradeable version of claim 3, wherein comparing the vehicle information with the second baseline version of software to obtain the vehicle upgradeable version of software comprises:
Acquiring a software version number of the vehicle according to the software version of the vehicle, and comparing the software version number with a second software baseline version;
and returning to the software version with the version number larger than the vehicle software version in the second software baseline version to obtain the vehicle upgradeable software version.
10. The vehicle upgradeable version matching method of claim 6, further comprising: and acquiring all domain hardware versions and vehicle software versions of the vehicle according to the vehicle information, carrying out vehicle portraits, and storing the vehicle portraits and the obtained vehicle upgradeable software versions.
11. The vehicle upgrade software matching method according to claim 10, further comprising, after said obtaining the first software baseline version, and the vehicle information:
judging whether the vehicle information is consistent with the existing vehicle portrait;
If the vehicle images are consistent, the upgrade software version of the vehicle is directly obtained.
12. The vehicle upgradeable version matching method of claim 1, further comprising: and generating an OTA operation strategy according to the vehicle information and the vehicle upgradeable software version.
13. A vehicle upgradeable version matching system, the vehicle upgradeable version matching system comprising:
the information acquisition module is used for acquiring the first software baseline version and the vehicle information;
the hardware setting module is used for setting a large hardware version according to the first software baseline version;
the compatibility calculating module is used for calculating the compatibility of the vehicle information and the large hardware version to obtain a second software baseline version;
And the result generation module is used for comparing the vehicle information with the second software baseline version to obtain the vehicle upgradeable software version.
14. A vehicle upgradeable version matching device, comprising:
a memory for storing a computer program;
A processor for implementing the steps of a vehicle upgradeable version matching method according to any one of claims 1-12 when executing the computer program.
15. A vehicle upgradeable version matching readable storage medium, characterized in that the readable storage medium has stored thereon a computer program which is executed with the steps of a vehicle upgradeable version matching method according to any one of claims 1-12.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410090239.6A CN117938906A (en) | 2024-01-23 | 2024-01-23 | Vehicle upgradeable version matching method, system, equipment and readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410090239.6A CN117938906A (en) | 2024-01-23 | 2024-01-23 | Vehicle upgradeable version matching method, system, equipment and readable storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117938906A true CN117938906A (en) | 2024-04-26 |
Family
ID=90750233
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410090239.6A Pending CN117938906A (en) | 2024-01-23 | 2024-01-23 | Vehicle upgradeable version matching method, system, equipment and readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117938906A (en) |
-
2024
- 2024-01-23 CN CN202410090239.6A patent/CN117938906A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3301565B1 (en) | Computer system, method of updating software with computer system, and program therefor | |
| US10042635B2 (en) | Method for wireless remote updating vehicle software | |
| US10705826B2 (en) | Control apparatus, program updating method, and computer program | |
| EP2453354A1 (en) | Online update method for vehicle-mounted device | |
| CN108136984A (en) | Portable vehicle is set | |
| CN111127130B (en) | Energy site recommendation method based on user preference, storage medium and electronic equipment | |
| AU2019202373A1 (en) | Apparatuses, systems, and methods for remotely capturing automotive vehicle diagnostic information, monitoring, and controlling | |
| CN112363984B (en) | Method and device for generating in-vehicle security rule file | |
| CN112363767A (en) | Vehicle-mounted camera calling method and device | |
| CN105512097A (en) | File analyzing method | |
| CN113791817A (en) | Method and device for creating new energy automobile scene product and storage medium | |
| CN112015489A (en) | Management method, device, storage medium and system for vehicle-mounted software | |
| CN117573553A (en) | Method, device, equipment and storage medium for debugging automobile machine | |
| CN117938906A (en) | Vehicle upgradeable version matching method, system, equipment and readable storage medium | |
| CN101894024B (en) | Model bank-based model element consistency ensuring method | |
| CN110990870A (en) | Operation and maintenance, processing method, device, equipment and medium using model library | |
| US20220250637A1 (en) | Vehicle control and task processing method and apparatus, computing device and system | |
| JP2023531701A (en) | Efficient controller data generation and extraction | |
| CN117931236A (en) | OTA operation policy automatic generation method, system, equipment and readable storage medium | |
| CN117407392A (en) | Apparatus, method, vehicle and computer program product for constructing electronic parts catalog | |
| CN112948956A (en) | Vehicle parameter generation method, device and equipment | |
| CN103810225A (en) | Information processing system, portable information processing apparatus, and information processing method | |
| US20220222054A1 (en) | Center, update management method, and non-transitory storage medium | |
| Kochhar | Leading the Transformation in the Automotive Industry Through the Digital Twin | |
| CN113590159B (en) | Parallel upgrading method and system for vehicle-mounted traveling crane computers |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination |