Software upgrade package binary flashing format implementation method and device, equipment and medium
By establishing a unified SWFBF file format, the problem of low efficiency and low reliability caused by the difference in binary file formats in vehicle software upgrades is solved, and an efficient and stable software upgrade process is achieved.
Patent Information
- Application Number
- CN202510567679.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-30
- Publication Date
- 2025-08-15
AI Technical Summary
During the current vehicle software upgrade process, the different binary file formats lead to low upgrade efficiency and low reliability.
Establish a unified SWFBF file format, including version information segments, header information segments and data segments, which are used to create software upgrade packages and store them on cloud servers, and build and distribute them to vehicles to be upgraded according to upgrade requirements.
Significantly shorten the adaptation and debugging time of developers, realize full-domain adaptation in one development, improve the efficiency and reliability of software upgrades, and ensure the stable operation of all models and components systems.
Smart Images

Figure CN120491998A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of vehicle intelligent control technology, and specifically to a method, apparatus, device and medium for implementing a binary flash format for a software upgrade package. Background Art
[0002] Over-the-Air (OTA) technology is becoming increasingly common in vehicles, enabling online updates of vehicle systems or software without the need for tedious on-site visits to dealerships. Specifically, OTA technology allows manufacturers to send software packages via cloud servers. Users simply connect their vehicles to the internet to automatically receive and install updates, making it easy to fix bugs, optimize performance, or add new features.
[0003] As vehicle functions become more diverse, OTA functions are being used more and more frequently, involving a large number of components. However, the binary file formats used during current software upgrades vary widely, resulting in low upgrade efficiency and low reliability during vehicle upgrade operations. Summary of the Invention
[0004] This application provides a method, device, equipment and medium for implementing the binary flash format of a software upgrade package. By establishing a unified technical standard, it greatly shortens the time developers spend on adaptation and debugging of different formats, and realizes an efficient model of one-time development and global adaptation.
[0005] In a first aspect, an embodiment of the present application provides a method for implementing a binary flash format for a software upgrade package, wherein the binary flash format implementation of the software upgrade package includes:
[0006] Based on the version information segment, header information segment and data segment, a SWFBF file is created and stored in the cloud server;
[0007] A software upgrade package is constructed in combination with the SWFBF file according to the upgrade requirements, and the software upgrade package is sent to the vehicle to be upgraded to realize the vehicle upgrade.
[0008] In conjunction with the first aspect, in one embodiment,
[0009] The SWFBF file includes three parts: version information segment, header information segment and data segment;
[0010] The version information segment is used to indicate the SWFBF specification version number followed by the SWFBF file, and the version information segment is represented by an ASCII string, and the first character is a specific fixed character;
[0011] All header information of the header information segment is located within the set symbol, and the header information segment includes multiple identifiers, including description, flash type, flash parameters, part number, software version number, flash file type, compression / encryption method, CAN number of ECU, physical request address of target ECU, function request address of target ECU, response address of target ECU, memory range to be erased, file CRC32 check polynomial, file CRC32 check initial value, file CRC32 check output XOR value, file CRC32 check input and output inversion, checksum value, number of failed single-step retries, number of complete retries from the beginning after the single-step retry number is exhausted, and security algorithm mask;
[0012] The data segment includes multiple blocks, and each block includes a start address, a length, data, and a checksum.
[0013] In conjunction with the first aspect, in one embodiment,
[0014] The description is an optional identifier, which is used for a brief description of the SWFBF file;
[0015] The flashing types include normal flashing, silent flashing, and forced flashing;
[0016] The part number is in a specific character set, and the specific character set does not contain blank characters and comments, and the part number has an upper limit on the number of characters;
[0017] The software version number is in specific characters, and the software version number has an upper limit on the number of characters;
[0018] The flash file type is one of Flash Driver, application, and data.
[0019] In conjunction with the first aspect, in one embodiment,
[0020] The compression / encryption mode is an optional identifier. When the value of the compression / encryption mode is not 0, it indicates that a compression or encryption mode is used. When the value is a byte 0x00-0xFF, the high bit represents the compression mode and the low bit represents the encryption mode.
[0021] The physical request address of the target ECU includes domain ID, network ID and ECUID;
[0022] The memory range to be erased is used to indicate the memory range that needs to be erased before software downloading.
[0023] In conjunction with the first aspect, in one embodiment,
[0024] The file CRC32 check input and output inversion is represented by binary, with a total of 2 bits, bit0 indicates whether the input is inverted, and bit1 indicates whether the output is inverted;
[0025] The checksum value is used to verify the integrity of the file before downloading, and the checksum value is the CRC32 checksum value of the data segment content.
[0026] In combination with the first aspect, in one implementation, the last byte of the header information segment is a fixed character, and the content of the data segment is located after the header information segment.
[0027] In conjunction with the first aspect, in one embodiment,
[0028] The length of the data segment is the size of the data in the data segment, and is the size of the data before compression;
[0029] The checksum in the data segment includes the starting address and length.
[0030] In a second aspect, an embodiment of the present application provides a device for implementing a binary flash format for a software upgrade package, the device comprising:
[0031] A construction module is used to create a SWFBF file based on the version information segment, the header information segment and the data segment and store it in a cloud server;
[0032] The execution module is used to build a software upgrade package in combination with the SWFBF file according to the upgrade requirements, and send the software upgrade package to the vehicle to be upgraded to realize the vehicle upgrade.
[0033] In the third aspect, an embodiment of the present application provides a software upgrade package binary flash format implementation device, the software upgrade package binary flash format implementation device includes a processor, a memory, and a software upgrade package binary flash format implementation program stored on the memory and executable by the processor, wherein when the software upgrade package binary flash format implementation program is executed by the processor, the steps of the above-mentioned software upgrade package binary flash format implementation method are implemented.
[0034] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a software upgrade package binary flash format implementation program is stored. When the software upgrade package binary flash format implementation program is executed by a processor, the steps of the above-mentioned software upgrade package binary flash format implementation method are implemented.
[0035] The beneficial effects of the technical solutions provided in the embodiments of the present application include:
[0036] By establishing unified technical standards, the time developers spend on adaptation and debugging for different formats can be greatly shortened, achieving an efficient model of one-time development and global adaptation, fundamentally accelerating the software upgrade process and allowing car owners to experience new functions and performance optimization more quickly. At the same time, under the unified standard framework, all components follow consistent technical specifications, effectively avoiding compatibility risks caused by format differences, ensuring that software upgrades run stably and reliably in all vehicle models and component systems, and comprehensively improving the overall reliability of automotive electronic systems. BRIEF DESCRIPTION OF THE DRAWINGS
[0037] Figure 1 This is a flowchart of the method for implementing the binary flash format of the software upgrade package in this application;
[0038] Figure 2 This is a functional module diagram of the device for implementing the binary flash format of the software upgrade package of this application;
[0039] Figure 3 This is a hardware structure diagram of the device that implements the binary flash format of the software upgrade package for this application. DETAILED DESCRIPTION
[0040] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0041] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.
[0042] In a first aspect, an embodiment of the present application provides a method for implementing a binary flash format of a software upgrade package.
[0043] In one embodiment, referring to Figure 1 , Figure 1 This is a flowchart of the implementation method of the binary flash format of the software upgrade package of this application. Figure 1 As shown, the implementation method of the binary flash format of the software upgrade package includes:
[0044] S1: Create a SWFBF file based on the version information segment, header information segment, and data segment and store it on the cloud server. SWFBF stands for Software Flash Binary Format, which is the software flash binary format.
[0045] S2: Building a software upgrade package based on the upgrade requirements and combining the SWFBF file, and sending the software upgrade package to the vehicle to be upgraded to implement the vehicle upgrade.
[0046] Specifically, the SWFBF file consists of three parts: version information segment, header information segment and data segment.
[0047] Specifically, the version information segment is shown in Table 1 below.
[0048] Table 1
[0049] name describe content SWFBFVersionSection SWFBF version information segment Text swfbf_version=1.0;
[0050] The header information segment is shown in Table 2 below.
[0051] Table 2
[0052] name describe content SWFBF Header Section SWFBF header information segment Text n bytes,ASCII
[0053] The data segment is shown in Table 3 below.
[0054] Table 3
[0055]
[0056]
[0057] Furthermore, the first line of the SWFBF file is a version information segment, which is used to indicate the SWFBF specification version number followed by the SWFBF file. The version information segment is represented by an ASCII (American Standard Code for Information Interchange) string, and the first character is a specific fixed character, which is 0x66 (f).
[0058] Furthermore, all header information of the header information segment is located within the set symbol, and the header information segment includes multiple identifiers, including description, flash type, flash parameters, part number, software version number, flash file type, compression / encryption method, CAN number, physical request address of target ECU, function request address of target ECU, response address of target ECU, memory range to be erased, file CRC32 check polynomial, file CRC32 check initial value, file CRC32 check output XOR value, file CRC32 check input and output inversion, checksum value, number of failed single-step retries, number of complete retries from the beginning after the single-step retries are used up, and security algorithm mask.
[0059] Specifically, all header information must be enclosed in a pair of curly braces. Comments and non-whitespace characters are not allowed before the header identifier or between the header identifier and {. For example: swfbf_version=1.0;header{swfbf_version=1.0;header{.
[0060] The format of the complete header section can be as follows:
[0061] header{
[0062] [description="{"textstringrow1",
[0063] "text string row 2","text string row 3", :
[0065] "textstringrown"
[0066] };]
[0067] flash_type=type; flash_parameters={
[0068] n_as=Network Layer Timing Parameter As; n_ar=Network Layer Timing Parameter Ar; n_bs=Network Layer Timing Parameter Bs; n_br=Network Layer Timing Parameter Br; n_cs=Network Layer Timing Parameter Cs; n_cr=Network Layer Timing Parameter Cr;
[0069] a_p2=ApplicationLayerTimingParametera_p2; a_p2star=Application LayerTiming Parameter a_p2star; t_stmin=Transport Layer Timing Parameter STmin;
[0070] bsize=Blockmaxsize;
[0071] padding=Paddingdataforunusedbyteindiagnosticframe;
[0072] };
[0073] sw_part_number="part number";sw_version="version suffix";sw_part_type=type;
[0074] [data_format_identifier=datacompressionandencryptionmethod;]
[0075] ecu_channel=ECU CAN index;ecu_phyaddr=ECU physical address;ecu_funaddr=ECU function address;ecu_rspaddr=ECUresponseaddress;
[0076] [erase={{startaddress1,length1},
[0077] {startaddress2,length2}, :
[0079] {startaddressn,lengthn}
[0080] };]
[0081] file_crc32_poly=CRC32 algorithmic polynomial;file_crc32_init=CRC32initial value;file_crc32_xout=CRC32XORoutput;file_crc32_bitrev=CRC32input / output bit reversal;file_crc32_checksum=CRC32 checksum;
[0082] fail_singal_retry=single-stepretrycounts;
[0083] fail_full_retry=fullretrycounts;
[0084] [security_mask=SecurityAlgorithmMask;]
[0085] }。
[0086] Specifically, description is an optional identifier that describes a short description of the SWFBF file. The value of description can contain up to 16 lines, with a maximum of 80 characters per line. Each line must be enclosed in quotation marks and end with ",". If it is the last line, it must end with "}" and ";". Whitespace characters within quotation marks are not ignored. Quotes cannot be nested. For example:
[0087] description="{"Created:2025-03-06"};
[0088] description="{"SOP software for BMS","Created:2025-03-06"}.
[0089] Specifically, the flash type (flash_type) includes normal flash, silent flash, and forced flash. Flash parameters are represented as flash_parameters.
[0090] Specifically, the part number (sw_part_number) must be enclosed in a specific string, and the specific string must not contain spaces or comments. Furthermore, the part number must have a maximum number of characters. Specifically, the part number must be enclosed in quotation marks, with a maximum of 20 characters, and spaces and comments are not allowed within the quotation marks. For example:
[0091] sw_part_number="12345678".
[0092] Specifically, the software version number (sw_version) must be enclosed in specific characters and has a maximum character limit. Specifically, the software version number must be enclosed in quotation marks, has a maximum of four characters, is case-sensitive, and can only contain A-Z.
[0093] Specifically, the flash file type (sw_part_type) is one of Flash Driver, Application, and Data. When sw_part_type=Flash Driver, the erase identifier cannot be used.
[0094] Specifically, the compression / encryption method (data_format_identifier) is an optional identifier. When the value of the compression / encryption method is not 0, it indicates that a compression or encryption method is used. When the value is a byte 0x00-0xFF, the high bit represents the compression method, and the low bit represents the encryption method. Specifically, data_format_identifier is optional. When its value is not 0, it indicates that a compression / encryption method is used for the data. When the value is a byte 0x00-0xFF, the high bit represents the compression method, and the low bit represents the encryption method. If it does not appear, it means that neither compression nor encryption is used. For example: data_format_identifier = 0x00.
[0095] Specifically, the CAN number of the ECU is represented by ecu_channel, starting from 0, for example: ecu_channel = 0. ECU stands for Electronic Control Unit, and CAN stands for Controller Area Network.
[0096] Specifically, the physical request address (ecu_phyaddr) of the target ECU includes the domain ID, network ID, and ECU ID, and the value length is 2 bytes. The function request address of the target ECU is represented by ecu_funaddr. The response address of the target ECU is represented by ecu_rspaddr.
[0097] Specifically, the erase memory range (erase) is used to indicate the memory range that needs to be erased before software downloading. The erase identifier indicates the memory range that needs to be erased before software downloading. The address value occupies 4 bytes, 0x00000000-0xFFFFFFFF. If sw_part_type = FlashDrv, the SWFBF file cannot contain the erase field. The identifier value range must be contained in double brackets. For example:
[0098] erase={{ / *start address* / 0x00004200, / *Length* / 0x00003CBF}};
[0099] erase={{0x00004200,0x00003CBF},{0x00008010,0x00002FF3}}; / / Twoblocks:0x00004200-0x00007EBE,0x00008010-0x0000B002.
[0100] The file CRC32 check polynomial is represented by file_crc32_poly, for example: file_crc32_poly = 0x04C11DB7. The file CRC32 check initial value is represented by file_crc32_init, for example: file_crc32_init = 0xFFFFFFFF. The file CRC32 check output XOR value is represented by file_crc32_xout, for example: file_crc32_xout = 0xFFFFFFFF.
[0101] Specifically, the file CRC32 check input and output reversal (file_crc32_reversal) is represented in binary format, with bit 0 indicating whether the input is reversed and bit 1 indicating whether the output is reversed. 0 indicates no reversal, and 1 indicates reversal. For example, file_crc32_reversal = 0b10 indicates no reversal of the input and reversal of the output.
[0102] Specifically, the checksum value (file_checksum) is used to verify the integrity of the file before downloading. The checksum value is a CRC32 checksum of the data segment contents. Specifically, the checksum value is 4 bytes in length and ranges from 0x00000000 to 0xFFFFFFFF. It is used to verify the integrity of the file before downloading. It is the CRC32 checksum of the data segment contents. If the data is compressed, the checksum uses the compressed data. CRC32 polynomial: 0x04C11DB7 Initial value: 0xFFFFFFFF bit-reversed, file_checksum = 0x29058c73.
[0103] The number of failed single-step retries (fail_singal_retry) is the number of single-step retries when the ECU returns a negative response or no response during the process, for example: fail_single_retry = 3.
[0104] The number of complete retries after the single-step retry attempts are exhausted is expressed as fail_full_retry, for example, fail_full_retry = 3. The security algorithm mask is expressed as security_mask, for example: security_mask = 0x12345678.
[0105] Furthermore, the data segment includes multiple blocks, and each block includes a starting address, length, data, and a checksum. At the beginning of the data segment, the last byte of the header information segment is a fixed character, such as 0x7D ('}'), and the content of the data segment is located after the header information segment.
[0106] The data segment structure consists of multiple blocks, each of which includes a starting address, length, data, and checksum. The starting address is 4 bytes, ranging from 0x00000000 to 0xFFFFFFFF. The length is 4 bytes, and the length in the data segment is the size of the data in the data segment before compression. The checksum is 2 bytes, and the checksum in the data segment includes the starting address and length. The starting address, length, and checksum are stored using the MSB.
[0107] It should be noted that, for symbols, the grouping symbol [] indicates that the content is optional, the grouping symbol {} indicates that a group of items are grouped, and the grouping symbol () indicates that it contains a group of items separated by |, and one of them must appear.
[0108] For generic structures, the header consists of a sequence of expressions, where an expression consists of "identifier," "reserved word," "constant," "integer," or "real number," and always ends in a semicolon. Expressions containing multiple values are grouped into nested sections using matching bracket characters "{" and "}." Data should be enclosed in braces only if there is more than one set of data, with the exception of the header information section and the erasure identifier description. Duplicate identifiers are not allowed.
[0109] For identifiers, the allowed identifiers are: swfbf_version, header, description, sw_part_number, sw_version, sw_part_type, data_format_identifier, ecu_channel, ecu_phyaddr, ecu_funaddr, ecu_rspaddr, file_crc32_poly, file_crc32_init, file_crc32_xout, file_crc32_reversal, file_crc32_checksum, fail_singal_retry, fail_whole_retry, security_mask, erase.
[0110] For the identifier value format, each element in the identifier value should be an integer, a real number, a string embedded in quotes, or a reserved identifier value (reserved word). The lexical rules for identifiers and reserved words are the same as those for the "C" programming language. Uppercase and lowercase are always distinguished. The format of the expression is as follows: ([WS / CM] represents whitespace characters and comments)
[0111] [WS / CM]identifier[WS / CM]=
[0112] WS / CM]IdentifierValue[WS / CM];[WS / CM]WS / CM]IdentifierValue[WS / CM];[WS / CM]{[WS / CM]IdentifierValue[WS / CM][,[WS / CM]IdentifierValue[WS / CM]]};
[0113] For example, sw_part_type=APP;sw_part_type; is a reserved word whose identifier APP is sw_part_type.
[0114] For integers, supported formats include hexadecimal, decimal, and binary.
[0115] For real numbers, a real number is a sequence of digits, followed by a period (."), and another sequence of digits. As with an integer, a prefix can specify hexadecimal or binary.
[0116] Comments can only be used in header sections and may appear in expressions. Multi-line comments / *...* / and single-line comments / / ... can be used.
[0117] For whitespace characters, the allowed whitespace characters include: horizontal tab, line feed, vertical tab, form feed, carriage return, and space.
[0118] For non-printing characters, 0x00 to 0x1 are defined as non-printing characters, and all non-printing characters are not allowed to appear in the header information segment.
[0119] The method for implementing the binary flash format of the software upgrade package in the embodiment of the present application, by establishing a unified technical standard, greatly shortens the time developers spend on adaptation and debugging for different formats, realizes an efficient model of one-time development and global adaptation, fundamentally accelerates the software upgrade process, and allows car owners to experience new functions and performance optimization more quickly. At the same time, under the unified standard framework, all components follow consistent technical specifications, effectively avoiding compatibility risks caused by format differences, ensuring that software upgrades run stably and reliably in all vehicle models and component systems, and comprehensively improving the overall reliability of automotive electronic systems.
[0120] In a second aspect, an embodiment of the present application also provides a device for implementing a binary flash format of a software upgrade package.
[0121] In one embodiment, referring to Figure 2 , Figure 2 This is a functional module diagram of the device for implementing the binary flash format of the software upgrade package of this application. Figure 2 As shown, the device for implementing the binary flash format of the software upgrade package includes: a construction module and an execution module.
[0122] The construction module is used to create a SWFBF file based on the version information segment, header information segment and data segment and store it on the cloud server; the execution module is used to build a software upgrade package in combination with the SWFBF file according to the upgrade requirements, and send the software upgrade package to the vehicle to be upgraded to realize the vehicle upgrade.
[0123] On the third aspect, an embodiment of the present application provides a device for implementing the binary flash format of a software upgrade package. The device for implementing the binary flash format of a software upgrade package can be a personal computer (PC), a laptop computer, a server, or other device with data processing capabilities.
[0124] Reference Figure 3 , Figure 3 Schematic diagram of the hardware structure of the device for implementing the binary flash format of the software upgrade package involved in the embodiment of the present application. In the embodiment of the present application, the device for implementing the binary flash format of the software upgrade package may include a processor, a memory, a communication interface and a communication bus.
[0125] The communication bus may be of any type and is used to interconnect the processor, memory, and communication interface.
[0126] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces. These interfaces are used to implement binary flashing of software upgrade packages to interconnect internal devices, as well as interfaces used to implement binary flashing of software upgrade packages to interconnect the device with other devices (such as other computing devices or user devices). Physical interfaces can be Ethernet, fiber, or ATM interfaces; user devices can be displays, keyboards, and other devices.
[0127] 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.
[0128] The processor may be a general-purpose processor, which may call the software upgrade package binary flash format implementation program stored in the memory and execute the software upgrade package binary flash format implementation method provided in the embodiment of the present application. For example, the general-purpose processor may be a central processing unit (CPU). The method executed when the software upgrade package binary flash format implementation program is called may refer to the various embodiments of the software upgrade package binary flash format implementation method of the present application, and will not be repeated here.
[0129] Those skilled in the art will understand that Figure 3 The hardware structure shown in the figure does not constitute a limitation to the present application and may include more or fewer components than shown in the figure, or a combination of certain components, or a different arrangement of components.
[0130] In a fourth aspect, an embodiment of the present application also provides a computer-readable storage medium.
[0131] The computer-readable storage medium of the present application stores a software upgrade package binary flash format implementation program, wherein when the software upgrade package binary flash format implementation program is executed by the processor, the steps of the software upgrade package binary flash format implementation method as described above are implemented.
[0132] Among them, the method implemented when the software upgrade package binary flash format implementation program is executed can refer to the various embodiments of the software upgrade package binary flash format implementation method of this application, and will not be repeated here.
[0133] 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 the "first", "second" and "third" to different types.
[0134] In the description of the embodiments of this application, the words "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 this application should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary," "for example," or "for example" is intended to present the relevant concepts in a concrete manner.
[0135] In the description of the embodiments of the present application, unless otherwise specified, “ / ” means or, for example, A / B can mean A or B; “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.
[0136] In some processes described in the embodiments of the present application, multiple operations or steps are included that appear in a specific order. However, it should be understood that these operations or steps may not be performed in the order in which they appear in the embodiments of the present application or may be performed in parallel. The sequence numbers of the operations are only used to distinguish between different operations, and the sequence numbers themselves do not represent any order of execution. In addition, these processes may include more or fewer operations, and these operations or steps may be performed in sequence or in parallel, and these operations or steps may be combined.
[0137] 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 the necessary general hardware platform, of course, it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, 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, magnetic disk, optical disk) as described above, and includes a number of instructions for enabling a terminal device to execute the methods described in each embodiment of the present application.
[0138] The above are only preferred embodiments of the present application and do not 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 implementing a binary flash format for a software upgrade package, characterized in that: The binary flash format of the software upgrade package includes: Based on the version information segment, header information segment and data segment, a SWFBF file is created and stored in the cloud server; A software upgrade package is constructed in combination with the SWFBF file according to the upgrade requirements, and the software upgrade package is sent to the vehicle to be upgraded to realize the vehicle upgrade.
2. A method for implementing a binary flash format for a software upgrade package according to claim 1, characterized in that: The SWFBF file includes three parts: version information segment, header information segment and data segment; The version information segment is used to indicate the SWFBF specification version number followed by the SWFBF file, and the version information segment is represented by an ASCII string, and the first character is a specific fixed character; All header information of the header information segment is located within the set symbol, and the header information segment includes multiple identifiers, including description, flash type, flash parameters, part number, software version number, flash file type, compression / encryption method, CAN number of ECU, physical request address of target ECU, function request address of target ECU, response address of target ECU, memory range to be erased, file CRC32 check polynomial, file CRC32 check initial value, file CRC32 check output XOR value, file CRC32 check input and output inversion, checksum value, number of failed single-step retries, number of complete retries from the beginning after the single-step retry number is exhausted, and security algorithm mask; The data segment includes multiple blocks, and each block includes a start address, a length, data, and a checksum.
3. A method for implementing a binary flash format for a software upgrade package according to claim 2, characterized in that: The description is an optional identifier, which is used for a brief description of the SWFBF file; The flashing types include normal flashing, silent flashing, and forced flashing; The part number is in a specific character set, and the specific character set does not contain blank characters and comments, and the part number has an upper limit on the number of characters; The software version number is in specific characters, and the software version number has an upper limit on the number of characters; The flash file type is one of Flash Driver, application, and data.
4. The method for implementing a binary flash format for a software upgrade package according to claim 2, wherein: The compression / encryption mode is an optional identifier. When the value of the compression / encryption mode is not 0, it indicates that a compression or encryption mode is used. When the value is a byte 0x00-0xFF, the high bit represents the compression mode and the low bit represents the encryption mode. The physical request address of the target ECU includes domain ID, network ID and ECUID; The memory range to be erased is used to indicate the memory range that needs to be erased before software downloading.
5. The method for implementing a binary flash format for a software upgrade package according to claim 2, wherein: The file CRC32 check input and output inversion is represented by binary, with a total of 2 bits, bit0 indicates whether the input is inverted, and bit1 indicates whether the output is inverted; The checksum value is used to verify the integrity of the file before downloading, and the checksum value is the CRC32 checksum value of the data segment content.
6. A method for implementing a binary flash format for a software upgrade package according to claim 2, characterized in that: The last byte of the header information segment is a fixed character, and the content of the data segment is located after the header information segment.
7. A method for implementing a binary flash format for a software upgrade package according to claim 2, characterized in that: The length of the data segment is the size of the data in the data segment, and is the size of the data before compression; The checksum in the data segment includes the starting address and length.
8. A device for implementing a binary flash format for a software upgrade package, characterized in that: The software upgrade package binary flash format implementation device includes: A construction module is used to create a SWFBF file based on the version information segment, the header information segment and the data segment and store it in a cloud server; The execution module is used to build a software upgrade package in combination with the SWFBF file according to the upgrade requirements, and send the software upgrade package to the vehicle to be upgraded to realize the vehicle upgrade.
9. A device for implementing a binary flash format for a software upgrade package, characterized in that: The software upgrade package binary flash format implementation device includes a processor, a memory, and a software upgrade package binary flash format implementation program stored on the memory and executable by the processor, wherein when the software upgrade package binary flash format implementation program is executed by the processor, the steps of the software upgrade package binary flash format implementation method as described in any one of claims 1 to 7 are implemented.
10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a software upgrade package binary flash format implementation program, wherein when the software upgrade package binary flash format implementation program is executed by the processor, the steps of the software upgrade package binary flash format implementation method as described in any one of claims 1 to 7 are implemented.