Automobile software and hardware version management method, device and equipment and readable storage medium

Abstract

The invention provides an automobile software and hardware version management method, device and equipment and a readable storage medium, and the method comprises the steps: collecting software and hardware data of each controller on an automobile before the start of a first development stage, and summarizing the software and hardware data to obtain initial baseline data of the first development stage; for each development stage after the first development stage, generating initial baseline data of the current development stage according to the final baseline data of the previous development stage; in each development stage, if the software version or the hardware version of any controller is received and the verification is passed, updating the current baseline data; and in each development stage, regularly comparing the software version and the hardware version of each controller in the current baseline data with the software version and the hardware version in the target file, and sending early warning information to a corresponding person in charge for the controller of which the software version or the hardware version is different. According to the method and the device, the error rate of the baseline data can be reduced, and errors can be checked in time.

Description

Technical Field

[0001] The present application relates to the field of vehicle management technology, and in particular to a method, device, equipment and readable storage medium for managing automobile software and hardware versions. Background Art

[0002] At present, automobiles are developing towards networking and intelligence. There are more and more types of controller parts and corresponding software used in automobiles, and management is becoming more and more complicated. At the same time, in order to improve their competitiveness, the vehicle development cycle is getting shorter and shorter. In the existing technology, at each stage of the project development process, the baseline data of the whole vehicle software and hardware is collected manually on a regular basis. However, the collection of baseline data is cumbersome and labor-intensive, and it is easy to make mistakes manually and difficult to check in time. Usually, the baseline data errors are not discovered until the abnormality occurs during the loading. Summary of the invention

[0003] The present application provides a method, device, equipment and readable storage medium for managing automobile software and hardware versions, which can solve the technical problems existing in the prior art that the baseline data error rate is high and difficult to check in time.

[0004] In a first aspect, an embodiment of the present application provides a method for managing automobile software and hardware versions, the method comprising:

[0005] Before the start of the first development phase, collect the software and hardware data of each controller on the car and summarize them to obtain the initial baseline data of the first development phase. The software and hardware data of the controller includes software number, hardware number, software version and hardware version, which are uploaded by the corresponding person in charge;

[0006] For each development phase after the first development phase, initial baseline data of the current development phase is generated based on the final baseline data of the previous development phase;

[0007] In each development phase, if the software version or hardware version of any controller is received and the verification passes, the current baseline data is updated;

[0008] In each development stage, the software version and hardware version of each controller in the current baseline data are regularly compared with those in the target file. For controllers with different software or hardware versions, early warning information is sent to the corresponding person in charge.

[0009] Furthermore, in one embodiment, when the target file is a controller document, the step of comparing the software version and the hardware version of each controller in the current baseline data with those in the target file includes:

[0010] For each controller in the current baseline data:

[0011] Obtaining a software number, a first software version, and a first hardware version of the controller from the current baseline data;

[0012] Obtain controller documents based on the controller software number in the product lifecycle management system;

[0013] Obtain a second software version and a second hardware version of the controller from the controller documentation;

[0014] The first software version is compared to the second software version, and the first hardware version is compared to the second hardware version.

[0015] Further, in one embodiment, when the target file is a design bill of materials, the step of comparing the software version and the hardware version of each controller in the current baseline data with those in the target file includes:

[0016] For each controller in the current baseline data:

[0017] Obtaining the software number, hardware number, first software version, and first hardware version of the controller from the current baseline data;

[0018] In the design material list, a third software version of the controller is obtained according to the software number of the controller, and a third hardware version of the controller is obtained according to the hardware number of the controller;

[0019] The first software version is compared to the third software version, and the first hardware version is compared to the third hardware version.

[0020] Further, in one embodiment, when the target file is a manufacturing bill of materials, the step of comparing the software version and the hardware version of each controller in the current baseline data with those in the target file includes:

[0021] For each controller in the current baseline data:

[0022] Obtaining the software number, hardware number, first software version, and first hardware version of the controller from the current baseline data;

[0023] Obtaining a fourth software version of the controller according to the software number of the controller in the manufacturing material bill, and obtaining a fourth hardware version of the controller according to the hardware number of the controller;

[0024] The first software version is compared to the fourth software version, and the first hardware version is compared to the fourth hardware version.

[0025] Furthermore, in one embodiment, for the controllers with different software versions or hardware versions, the step of sending warning information to the corresponding person in charge includes:

[0026] If there is a difference in the software version of any controller in the current baseline data and in the target file, a description of the software version difference is added to the difference document;

[0027] If the hardware version of any controller in the current baseline data is different from that in the target file, a description of the hardware version difference is added to the difference document;

[0028] If the difference document of any controller is not empty, the difference document is sent to the corresponding person in charge.

[0029] Furthermore, in one embodiment, the requirements for verification in each development stage include:

[0030] The received software version or hardware version is a specific character combination of preset digits;

[0031] The revision number in the received software version or hardware version is greater than the corresponding revision number in the current baseline data.

[0032] Furthermore, in one embodiment, the requirement for passing verification in the last N development stages also includes:

[0033] The major version number in the received software version or hardware version is equal to the sequence number of the current development stage.

[0034] In a second aspect, an embodiment of the present application further provides a vehicle software and hardware version management device, the vehicle software and hardware version management device comprising:

[0035] The collection module is used to collect the software and hardware data of each controller on the vehicle before the start of the first development phase, and summarize the initial baseline data of the first development phase. The software and hardware data of the controller includes software number, hardware number, software version and hardware version, which are uploaded by the corresponding person in charge;

[0036] An inheritance module, for generating, for each development stage after the first development stage, initial baseline data of the current development stage based on the final baseline data of the previous development stage;

[0037] An update module is used to update the current baseline data in each development stage if the software version or hardware version of any controller is received and the verification passes;

[0038] The comparison module is used to regularly compare the software version and hardware version of each controller in the current baseline data with those in the target file in each development stage, and send warning information to the corresponding person in charge for controllers with different software or hardware versions.

[0039] In a third aspect, an embodiment of the present application also provides an automobile software and hardware version management device, which includes a processor, a memory, and an automobile software and hardware version management program stored in the memory and executable by the processor, wherein when the automobile software and hardware version management program is executed by the processor, the steps of the above-mentioned automobile software and hardware version management method are implemented.

[0040] In a fourth aspect, an embodiment of the present application further provides a readable storage medium, on which is stored a vehicle software and hardware version management program, wherein when the vehicle software and hardware version management program is executed by a processor, the steps of the above-mentioned vehicle software and hardware version management method are implemented.

[0041] In this application, before the start of the first development stage, the software and hardware data of each controller on the car are collected and summarized to obtain the initial baseline data of the first development stage; for each development stage after the first development stage, the initial baseline data of the current development stage is generated according to the final baseline data of the previous development stage; in each development stage, if the software version or hardware version of any controller is received and the verification passes, the current baseline data is updated; in each development stage, the software version and hardware version of each controller in the current baseline data are regularly compared with those in the target file, and for controllers with different software or hardware versions, early warning information is sent to the corresponding person in charge. Through this application, the manual participation in baseline data maintenance is reduced as much as possible, and the controller version is compared regularly in each development stage, thereby reducing the error rate of baseline data and realizing timely troubleshooting of errors. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 This is a flow chart of a method for managing automobile software and hardware versions in one embodiment of the present application;

[0043] Figure 2 This is a schematic diagram of the functional modules of a vehicle software and hardware version management device in one embodiment of the present application;

[0044] Figure 3 This is a schematic diagram of the hardware structure of the automobile software and hardware version management device involved in the embodiment of the present application. DETAILED DESCRIPTION

[0045] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0046] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0047] In a first aspect, an embodiment of the present application provides a method for managing automobile software and hardware versions.

[0048] Figure 1 A flow chart of a method for managing automobile software and hardware versions in one embodiment of the present application is shown.

[0049] Reference Figure 1 In one embodiment, the automobile software and hardware version management method includes the following steps:

[0050] S1. Before the start of the first development phase, collect the software and hardware data of each controller on the car and summarize them to obtain the initial baseline data of the first development phase. The software and hardware data of the controller includes software number, hardware number, software version and hardware version, which are uploaded by the corresponding person in charge.

[0051] Specifically, there is no software or hardware data of any controller in the initial state. In order to obtain the initial baseline data of the first development phase, the software and hardware data of each controller needs to be collected and summarized. The initial baseline data refers to the baseline data at the beginning of the corresponding development phase.

[0052] Optionally, the software and hardware data of the controller also includes an English name and a Chinese name.

[0053] Optionally, before the first development phase begins, a reminder message is sent to the persons in charge of each type of controller, reminding them that they need to upload the software and hardware data of the controllers for which they are responsible.

[0054] S2. For each development stage after the first development stage, generate initial baseline data of the current development stage based on the final baseline data of the previous development stage.

[0055] Specifically, different development stages do not overlap in time, and subsequent development stages inherit the baseline data of the previous development stage without the need to collect it again. The final baseline data refers to the baseline data at the end of the corresponding development stage.

[0056] S3. In each development stage, if the software version or hardware version of any controller is received and the verification passes, the current baseline data is updated;

[0057] Specifically, as the development progresses, the software versions or hardware versions of some controllers will be updated, and the person in charge will upload the new software version or hardware version. Only the software version or hardware version that has passed the verification will be updated to the current baseline data.

[0058] S4. In each development stage, regularly compare the software version and hardware version of each controller in the current baseline data with those in the target file. For controllers with different software or hardware versions, send warning information to the corresponding person in charge.

[0059] Specifically, the software and hardware data of the controller will be saved in a variety of files. Under normal circumstances, the software and hardware versions in these files will be consistent with the software and hardware versions in the current baseline data. If there are differences in some software or hardware versions, it means that there is an error in the baseline data or the corresponding file, and the corresponding person in charge needs to conduct error troubleshooting. By regularly comparing versions at each development stage, the controller version anomalies can be discovered before installation and early warning can be given, enabling timely troubleshooting of errors.

[0060] Therefore, in this embodiment, before the start of the first development stage, the software and hardware data of each controller on the car are collected and the initial baseline data of the first development stage are summarized; for each development stage after the first development stage, the initial baseline data of the current development stage is generated according to the final baseline data of the previous development stage; in each development stage, if the software version or hardware version of any controller is received and the verification is passed, the current baseline data is updated; in each development stage, the software version and hardware version of each controller in the current baseline data are regularly compared with those in the target file, and for controllers with different software versions or hardware versions, early warning information is sent to the corresponding person in charge. Through this embodiment, the manual participation in the maintenance of baseline data is reduced as much as possible, and the controller version is compared regularly in each development stage, thereby reducing the error rate of baseline data and realizing timely troubleshooting of errors.

[0061] Optionally, the target file may be an Engineering Bill of Material (E-BOM), a Manufacturing Bill of Material (M-BOM), a controller document, etc.

[0062] Specifically, when the target file is a controller document, the step of comparing the software version and the hardware version of each controller in the current baseline data with those in the target file includes:

[0063] For each controller in the current baseline data:

[0064] Obtaining a software number, a first software version, and a first hardware version of the controller from the current baseline data;

[0065] Obtain controller documents based on the controller software number in the product lifecycle management system;

[0066] Obtain a second software version and a second hardware version of the controller from the controller documentation;

[0067] The first software version is compared to the second software version, and the first hardware version is compared to the second hardware version.

[0068] Specifically, when the target file is a design bill of materials, the step of comparing the software version and the hardware version of each controller in the current baseline data with those in the target file includes:

[0069] For each controller in the current baseline data:

[0070] Obtaining the software number, hardware number, first software version, and first hardware version of the controller from the current baseline data;

[0071] In the design material list, a third software version of the controller is obtained according to the software number of the controller, and a third hardware version of the controller is obtained according to the hardware number of the controller;

[0072] The first software version is compared to the third software version, and the first hardware version is compared to the third hardware version.

[0073] Specifically, when the target file is a manufacturing bill of materials, the step of comparing the software version and the hardware version of each controller in the current baseline data with those in the target file includes:

[0074] For each controller in the current baseline data:

[0075] Obtaining the software number, hardware number, first software version, and first hardware version of the controller from the current baseline data;

[0076] Obtaining a fourth software version of the controller according to the software number of the controller in the manufacturing material bill, and obtaining a fourth hardware version of the controller according to the hardware number of the controller;

[0077] The first software version is compared to the fourth software version, and the first hardware version is compared to the fourth hardware version.

[0078] Furthermore, in one embodiment, for the controllers with different software versions or hardware versions, the step of sending warning information to the corresponding person in charge includes:

[0079] If there is a difference in the software version of any controller in the current baseline data and in the target file, a description of the software version difference is added to the difference document;

[0080] If the hardware version of any controller in the current baseline data is different from that in the target file, a description of the hardware version difference is added to the difference document;

[0081] If the difference document of any controller is not empty, the difference document is sent to the corresponding person in charge.

[0082] In this embodiment, the person in charge can obtain the software version difference description or the hardware version difference description from the difference document to facilitate targeted problem troubleshooting.

[0083] Furthermore, in one embodiment, the requirements for verification in each development stage include:

[0084] The received software version or hardware version is a specific character combination of preset digits;

[0085] The revision number in the received software version or hardware version is greater than the corresponding revision number in the current baseline data.

[0086] In this embodiment, basic verification requirements are defined for each development stage, thereby providing a certain degree of flexibility while reducing the error rate.

[0087] Furthermore, in one embodiment, the requirement for passing verification in the last N development stages also includes:

[0088] The major version number in the received software version or hardware version is equal to the sequence number of the current development stage.

[0089] In this embodiment, additional verification requirements for the last N development stages are defined, thereby further reducing the error rate before loading.

[0090] For example, the software version or hardware version is in the format of V①.②.③④, where ①-④ are numbers, ① represents the main version number, ② represents the version number of the controller function specification, and ③④ represents the revision number. Assuming that the project development has 4 development stages, the first two development stages do not need to verify whether ① is equal to the serial number of the current development stage, and the last two development stages need to verify whether ① is equal to the serial number of the current development stage.

[0091] In a second aspect, an embodiment of the present application also provides a device for managing automobile software and hardware versions.

[0092] Figure 2 A schematic diagram of the functional modules of a vehicle software and hardware version management device in one embodiment of the present application is shown.

[0093] Reference Figure 2 In one embodiment, the automobile software and hardware version management device includes:

[0094] The collection module 10 is used to collect the software and hardware data of each controller on the vehicle before the first development phase begins, and summarize the initial baseline data of the first development phase, wherein the software and hardware data of the controller includes software number, hardware number, software version and hardware version, which are uploaded by the corresponding person in charge;

[0095] An inheritance module 20, for generating, for each development stage after the first development stage, initial baseline data of the current development stage based on the final baseline data of the previous development stage;

[0096] An update module 30 is used to update the current baseline data in each development stage if the software version or hardware version of any controller is received and the verification passes;

[0097] The comparison module 40 is used to regularly compare the software version and hardware version of each controller in the current baseline data with those in the target file in each development stage, and send warning information to the corresponding person in charge for controllers with different software versions or hardware versions.

[0098] Further, in one embodiment, when the target file is a controller document, the comparison module 40 is used to:

[0099] For each controller in the current baseline data:

[0100] Obtaining a software number, a first software version, and a first hardware version of the controller from the current baseline data;

[0101] Obtain controller documents based on the controller software number in the product lifecycle management system;

[0102] Obtain a second software version and a second hardware version of the controller from the controller documentation;

[0103] The first software version is compared to the second software version, and the first hardware version is compared to the second hardware version.

[0104] Further, in one embodiment, when the target file is a design bill of materials, the comparison module 40 is used to:

[0105] For each controller in the current baseline data:

[0106] Obtaining the software number, hardware number, first software version, and first hardware version of the controller from the current baseline data;

[0107] In the design material list, a third software version of the controller is obtained according to the software number of the controller, and a third hardware version of the controller is obtained according to the hardware number of the controller;

[0108] The first software version is compared to the third software version, and the first hardware version is compared to the third hardware version.

[0109] Further, in one embodiment, when the target file is a manufacturing bill of materials, the comparison module 40 is used to:

[0110] For each controller in the current baseline data:

[0111] Obtaining the software number, hardware number, first software version, and first hardware version of the controller from the current baseline data;

[0112] Obtaining a fourth software version of the controller according to the software number of the controller in the manufacturing material bill, and obtaining a fourth hardware version of the controller according to the hardware number of the controller;

[0113] The first software version is compared to the fourth software version, and the first hardware version is compared to the fourth hardware version.

[0114] Furthermore, in one embodiment, the comparison module 40 is used to:

[0115] If there is a difference in the software version of any controller in the current baseline data and in the target file, a description of the software version difference is added to the difference document;

[0116] If the hardware version of any controller in the current baseline data is different from that in the target file, a description of the hardware version difference is added to the difference document;

[0117] If the difference document of any controller is not empty, the difference document is sent to the corresponding person in charge.

[0118] Further, in one embodiment, in the update module 30, the requirements for passing the verification in each development stage include:

[0119] The received software version or hardware version is a specific character combination of preset digits;

[0120] The revision number in the received software version or hardware version is greater than the corresponding revision number in the current baseline data.

[0121] Furthermore, in one embodiment, in the update module 30, the requirement of passing the verification in the last N development stages also includes:

[0122] The major version number in the received software version or hardware version is equal to the sequence number of the current development stage.

[0123] Among them, the functional implementation of each module in the above-mentioned automobile software and hardware version management device corresponds to the various steps in the above-mentioned automobile software and hardware version management method embodiment, and its functions and implementation processes are no longer repeated here.

[0124] In a third aspect, an embodiment of the present application provides an automobile software and hardware version management device, which may be a personal computer (PC), a laptop computer, a server, or other device with data processing capabilities.

[0125] Figure 3 A schematic diagram of the hardware structure of the automobile software and hardware version management device involved in the embodiment of the present application is shown.

[0126] Reference Figure 3 In an embodiment of the present application, the automobile software and hardware version management device may include a processor, a memory, a communication interface, and a communication bus.

[0127] The communication bus may be of any type and is used to interconnect the processor, the memory, and the communication interface.

[0128] The communication interface includes input / output (I / O) interface, physical interface and logical interface, etc., which are used to realize the interconnection of devices inside the automobile software and hardware version management device, and the interface used to realize the interconnection between the automobile software and hardware version management device and other devices (such as other computing devices or user devices). The physical interface can be an Ethernet interface, a fiber optic interface, an ATM interface, etc.; the user device can be a display (Display), a keyboard (Keyboard), etc.

[0129] The memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0130] The processor may be a general-purpose processor, and the general-purpose processor may call the automobile software and hardware version management program stored in the memory, and execute the automobile software and hardware version management method provided by the embodiment of the present application. For example, the general-purpose processor may be a central processing unit (CPU). Among them, the method executed when the automobile software and hardware version management program is called can refer to the various embodiments of the automobile software and hardware version management method of the present application, which will not be repeated here.

[0131] Those skilled in the art will understand that Figure 3 The hardware structure shown in the figure does not constitute a limitation on the present application, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.

[0132] In a fourth aspect, an embodiment of the present application also provides a readable storage medium.

[0133] The readable storage medium of the present application stores an automobile software and hardware version management program, wherein when the automobile software and hardware version management program is executed by a processor, the steps of the automobile software and hardware version management method as described above are implemented.

[0134] Among them, the method implemented when the automobile software and hardware version management program is executed can refer to the various embodiments of the automobile software and hardware version management method of the present application, and will not be repeated here.

[0135] It should be noted that the serial numbers of the above-mentioned embodiments of the present application are only for description and do not represent the advantages or disadvantages of the embodiments.

[0136] The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices. The terms "first", "second" and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit "first", "second" and "third" to different types.

[0137] In the description of the embodiments of the present application, "exemplary", "for example" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary", "for example" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary", "for example" or "for example" is intended to present related concepts in a specific way.

[0138] In the description of the embodiments of the present application, unless otherwise specified, “ / ” means or, for example, A / B can mean A or B; the “and / or” in the text is merely a description of the association relationship of associated objects, indicating that three relationships may exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, “multiple” refers to two or more than two.

[0139] In some processes described in the embodiments of the present application, multiple operations or steps that appear in a specific order are included, but it should be understood that these operations or steps may not be executed in the order in which they appear in the embodiments of the present application or in parallel, and the sequence number of the operation is only used to distinguish the different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed in sequence or in parallel, and these operations or steps may be combined.

[0140] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, disk, CD) as described above, and includes a number of instructions for a terminal device to execute the methods described in each embodiment of the present application.

[0141] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A method for managing automobile software and hardware versions, characterized in that: The automobile software and hardware version management method comprises: Before the start of the first development phase, collect the software and hardware data of each controller on the car and summarize them to obtain the initial baseline data of the first development phase. The software and hardware data of the controller includes software number, hardware number, software version and hardware version, which are uploaded by the corresponding person in charge; For each development phase after the first development phase, initial baseline data of the current development phase is generated based on the final baseline data of the previous development phase; In each development phase, if the software version or hardware version of any controller is received and the verification passes, the current baseline data is updated; In each development stage, the software version and hardware version of each controller in the current baseline data are regularly compared with those in the target file. For controllers with different software or hardware versions, early warning information is sent to the corresponding person in charge.

2. The method for managing automobile software and hardware versions according to claim 1, characterized in that: When the target file is a controller document, the step of comparing the software version and the hardware version of each controller in the current baseline data with those in the target file includes: For each controller in the current baseline data: Obtaining a software number, a first software version, and a first hardware version of the controller from the current baseline data; Obtain controller documents based on the controller software number in the product lifecycle management system; Obtain a second software version and a second hardware version of the controller from the controller documentation; The first software version is compared to the second software version, and the first hardware version is compared to the second hardware version.

3. The method for managing automobile software and hardware versions according to claim 1, characterized in that: When the target file is a design bill of materials, the step of comparing the software version and the hardware version of each controller in the current baseline data with those in the target file includes: For each controller in the current baseline data: Obtaining the software number, hardware number, first software version, and first hardware version of the controller from the current baseline data; In the design material list, a third software version of the controller is obtained according to the software number of the controller, and a third hardware version of the controller is obtained according to the hardware number of the controller; The first software version is compared to the third software version, and the first hardware version is compared to the third hardware version.

4. The method for managing automobile software and hardware versions according to claim 1, characterized in that: When the target file is a manufacturing bill of materials, the step of comparing the software version and the hardware version of each controller in the current baseline data with those in the target file includes: For each controller in the current baseline data: Obtaining the software number, hardware number, first software version, and first hardware version of the controller from the current baseline data; Obtaining a fourth software version of the controller according to the software number of the controller in the manufacturing material bill, and obtaining a fourth hardware version of the controller according to the hardware number of the controller; The first software version is compared to the fourth software version, and the first hardware version is compared to the fourth hardware version.

5. The automobile software and hardware version management method according to claim 1, characterized in that: The step of sending warning information to the corresponding person in charge for the controller with different software versions or hardware versions includes: If there is a difference in the software version of any controller in the current baseline data and in the target file, a description of the software version difference is added to the difference document; If the hardware version of any controller in the current baseline data is different from that in the target file, a description of the hardware version difference is added to the difference document; If the difference document of any controller is not empty, the difference document is sent to the corresponding person in charge.

6. The method for managing automobile software and hardware versions according to claim 1, characterized in that: Requirements for verification at each development stage include: The received software version or hardware version is a specific character combination of preset digits; The revision number in the received software version or hardware version is greater than the corresponding revision number in the current baseline data.

7. The method for managing automobile software and hardware versions as claimed in claim 6, characterized in that: Requirements for verification during the last N development stages also include: The major version number in the received software version or hardware version is equal to the sequence number of the current development stage.

8. A vehicle software and hardware version management device, characterized in that: The automobile software and hardware version management device comprises: The collection module is used to collect the software and hardware data of each controller on the vehicle before the start of the first development phase, and summarize the initial baseline data of the first development phase. The software and hardware data of the controller includes software number, hardware number, software version and hardware version, which are uploaded by the corresponding person in charge; An inheritance module, for generating, for each development stage after the first development stage, initial baseline data of the current development stage based on the final baseline data of the previous development stage; An update module is used to update the current baseline data in each development stage if the software version or hardware version of any controller is received and the verification passes; The comparison module is used to regularly compare the software version and hardware version of each controller in the current baseline data with those in the target file in each development stage, and send warning information to the corresponding person in charge for controllers with different software or hardware versions.

9. An automobile software and hardware version management device, characterized in that: The automobile software and hardware version management device includes a processor, a memory, and an automobile software and hardware version management program stored in the memory and executable by the processor, wherein when the automobile software and hardware version management program is executed by the processor, the steps of the automobile software and hardware version management method as described in any one of claims 1 to 7 are implemented.

10. A readable storage medium, characterized in that: The readable storage medium stores an automobile software and hardware version management program, wherein when the automobile software and hardware version management program is executed by a processor, the steps of the automobile software and hardware version management method according to any one of claims 1 to 7 are implemented.

Images