Target file updating method and device for automobile open system architecture

Abstract

The invention relates to a target file updating method for an automobile open system architecture. The method comprises the following steps: acquiring an extensible markup language file generated in response to modification of a target variable of a constructed attribute type and a corresponding to-be-updated first target file; obtaining address information of the target variable in the first target file based on the extensible markup language file; and updating the value of the target variable in the first target file based on the obtained address information to generate an updated second target file. The invention further relates to a target file updating device of the automobile open system architecture, computing equipment, a computer readable storage medium and a computer program product.

Description

Technical Field

[0001] The present disclosure relates to the field of automotive open system architecture, and in particular, to a target file updating method for an automotive open system architecture, a target file updating device for an automotive open system architecture, a computing device, a computer-readable storage medium, and a computer program product. Background Art

[0002] Autosar (Automotive Open System Architecture) is a collaborative development framework for automotive electronic systems jointly developed by global automakers, parts suppliers, and various research and service organizations, and has established an open standard software architecture for automotive control units (ECUs).

[0003] Autosar basic modules contain numerous parameters, defining three types of configuration parameters: pre-compile-time parameters (parameters with pre-compile attributes), link-time parameters (parameters with link-time attributes), and post-build-time parameters (parameters with post-build attributes). Pre-compile-time parameters primarily consist of macro definitions used to enable / disable optional features and provide options for optimizing executable file size or performance. These parameters are generated during the code generation phase in files such as *.cfg.h (macro definitions, etc.) and *.cfg.c (constant parameter definitions, etc.). Since most of these parameters are macro definitions, the module's static code must be provided in source code form. Changes to these parameters require module recompilation. Link-time parameters, such as module configuration callback functions (defined in other source code files), are primarily determined during the link phase. Post-build-time parameters are generated during the code generation phase in files such as *.lcfg.h and *.lcfg.c. This type of parameters is mainly applicable to situations where the structure of some parameters is determined, but the content is uncertain when the electronic control unit (ECU) is produced, or the parameters are likely to be changed after the ECU is produced. Summary of the Invention

[0004] The present invention specifically provides a method and device for updating target files for an automotive open system architecture. These methods and devices enable rapid product updates and iterations, are easy to configure, and help reduce development time and costs.

[0005] To this end, according to a first aspect of the present invention, a target file updating method for an automotive open system architecture is provided, comprising: obtaining an extensible markup language file generated in response to a modification of a target variable of a post-construction attribute type and a corresponding first target file to be updated; obtaining address information of the target variable in the first target file based on the extensible markup language file; and updating the value of the target variable in the first target file based on the obtained address information to generate an updated second target file.

[0006] In addition, according to the second aspect of the present invention, a target file updating device for an automotive open system architecture is provided, comprising: a file acquisition module for acquiring an extensible markup language file generated in response to a modification of a target variable of a post-construction attribute type and a corresponding first target file to be updated; an address information acquisition module for acquiring address information of the target variable in the first target file based on the extensible markup language file; and a target file updating module for updating the value of the target variable in the first target file based on the acquired address information to generate an updated second target file.

[0007] The apparatus according to the second aspect of the present invention may be implemented in software form, hardware form, or a software / hardware hybrid form, for example.

[0008] In addition, according to a third aspect of the present invention, a computing device is provided, which includes: a processor; and a memory for storing computer-executable instructions, which enables the processor to execute the method described above when the computer-executable instructions are executed.

[0009] Furthermore, according to a fourth aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium has computer-executable instructions stored thereon, and the computer-executable instructions are used to execute the method described above.

[0010] Furthermore, according to a fourth aspect of the present invention, there is provided a computer program product, which is tangibly stored on a computer-readable storage medium and comprises computer-executable instructions which, when executed, cause at least one processor to perform the method described above.

[0011] The above technical solution according to the present invention has the following advantages in particular: customers can directly modify the target file corresponding to the variable of the post-build attribute type to obtain the updated target file, without modifying the entire set of source codes and without re-compiling and linking, which can achieve rapid update and iteration of products and has the advantages of short development cycle, low cost and low open source risk. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Other features and advantages of the present invention will be better understood through the following detailed description of preferred embodiments with reference to the accompanying drawings, in which:

[0013] Figure 1 An exemplary flow chart of a method for updating a target file of an automotive open system architecture according to an embodiment of the present invention is shown.

[0014] Figure 2 An exemplary flow chart of a method for updating a target file of an automotive open system architecture according to another embodiment of the present invention is shown.

[0015] Figure 3 An exemplary block diagram of a target file updating device for an automotive open system architecture according to an embodiment of the present invention is shown.

[0016] Figure 4 An exemplary block diagram of a computing device according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0017] The making and using of the embodiments are discussed in detail below. However, it should be understood that the specific embodiments discussed are merely illustrative of specific ways to make and use the invention, and are not intended to limit the scope of the invention.

[0018] like Figure 1 FIG2 is an exemplary flow chart of a method 100 for updating a target file of an automotive open system architecture according to an embodiment of the present invention. The method 100 specifically includes the following steps:

[0019] Step 110: Obtain an XML file generated in response to a modification of a target variable of a post-build attribute type and a corresponding first target file to be updated. The XML file generated in response to a modification of a target variable of a post-build attribute type can be obtained by performing configuration modification operations using tools such as Vector DaVinci Configurator Pro (an Autosar configuration tool for configuring and integrating Autosar software components, modules, and parameters), Elektrobit Tresos Studio (a centralized development environment for Autosar software development and integration, providing rich functionality such as code generation, configuration management, and simulation), ETAS ASCET-DEVELOPER (a tool suite for developing AUTOSAR software, providing model-driven development capabilities and integration with other tools), dSPACE SystemDesk (a tool for designing, simulating, and generating Autosar system descriptions, providing a graphical interface that enables developers to quickly design and configure systems), or MathWorks Simulink, generating the corresponding XML file. The first target file is the object code (object code) before the update. The object code is a machine-executable file that contains binary machine instructions generated by a compiler. Object code is the machine-executable code that a compiler converts source code into. Source code typically needs to be compiled to reflect changes in the object code. In some instances, target variables of the post-build attribute type can include product serialization and version information.

[0020] Step 120, based on the extensible markup language file (Arxml file), obtains the address information of the target variable in the first target file. Arxml file, as a general configuration file or database file under the Autosar architecture, plays a key role in data transmission and storage. In this example, Arxml is used as the corresponding configuration file generated by modifying the target variable of the post-build attribute type, providing the address information of the target variable in the corresponding target file. In some embodiments, the target variable includes preset information, and the preset information includes the storage location, storage format, sorting method and / or alignment method of the target variable in the target file. The storage location, storage format, sorting method and / or alignment method of the target variable in the target file remain unchanged before and after the value of the target variable is modified.

[0021] In some examples, Arxml files include system configuration files (System Configuration, which contains description information of multiple ECUs. It describes the information sent or received between ECUs and the interface and port description information across ECU components. It also contains ECU hardware resource information. System Configuration describes the interaction information between ECUs from the perspective of the entire vehicle system), ECU extract files (ECU Extract, which is a subset of System Configuration. It describes the information sent or received by a single ECU. It also contains the software components (SWC, Software Components) contained in a single ECU and detailed information of the SWC, such as interface definition and port definition. ECU Extract is consistent with the communication matrix we currently use), ECU configuration files (ECU Configuration, which belongs to the scope of a single ECU. It describes all information after configuration such as SWCDescription, ECU Extract and BSW (Basic Software) modules), SWC description files (SWC Description, which describes all user-defined design information, including SWC definition, running entity, interface, and port data type definition) and BSW module description files (BSW Module Description, which belongs to standard module information. Module information is related to the code package and may vary from supplier to supplier, but all comply with the AUTOSAR standard definition).

[0022] Step 130 updates the target variable values ​​in the first target file based on the acquired address information to generate an updated second target file. By directly modifying and replacing the variable values ​​at corresponding locations in the first target file, the corresponding second target file required for the configuration update is quickly obtained. This eliminates the need to recompile the source code due to product configuration changes, resulting in a simple implementation process and convenient user operation.

[0023] In some examples, the modification method of the target variable of the post-construction attribute type includes: modification through a flash erase tool, a unified diagnostic services (UDS) service and / or a boot loader.

[0024] Based on this method 100, existing Autosar tools (such as Vector DaVinci ConfiguratorPro) can be updated, and a new update tool for the target file of variables of post-build attribute type can be added. The input of the tool includes Autosar's extensible markup language file (Arxml, Autosar eXtensible Markup Language) and the corresponding target file before the update, and the output is the target file corresponding to the modified configuration. The tool directly modifies and replaces the variables at the corresponding position of the original target file corresponding to the configuration modification to obtain the required target file, thereby improving the development efficiency of the Autosar tool and making it more convenient for users to use.

[0025] like Figure 2 FIG2 is an exemplary flow chart of a method 200 for updating a target file of an automotive open system architecture according to another embodiment of the present invention. The method 200 specifically includes the following steps:

[0026] Step 210: Obtain a first Extensible Markup Language file (first Arxml file) generated in response to the modification of the target variable of the post-build attribute type and a corresponding first target file to be updated. Also obtain a second Extensible Markup Language file (second Arxml file) generated in response to the modification of the target variable of the pre-compiled attribute type and / or the link-time attribute type.

[0027] Step 220: Obtain address information of the target variable in the first target file based on the XML file, and update the value of the target variable in the first target file based on the obtained address information to generate an updated second target file. Furthermore, a source file (source code) is generated based on the first and second XML files; and the source file is compiled to generate a corresponding updated third target file.

[0028] In this embodiment, the user or configuration engineer not only modifies the variables of the post-build attribute type, but also modifies the variables of the pre-compile and / or link time attribute types, generating the corresponding first Arxml file and the second Arxml file, wherein the first Arxml file can not only obtain the second target file through the first path, that is, obtain the updated target file by directly modifying and replacing the target file corresponding to the variable of the post-build attribute type; but also obtain the updated target file through the second path, that is, by generating the source file and compiling it. It should be noted that the acquisition paths of the two updated target files do not conflict and can be performed simultaneously. Preferably, the second path is triggered if and only if the variables of the pre-compile and / or link time attribute types are modified. Other implementation methods of this embodiment are similar to the method described above, so they will not be repeated here.

[0029] like Figure 3 The following is an exemplary block diagram of a target file update device 300 for an automotive open system architecture (OSA) according to another embodiment of the present invention. The device 300 specifically includes: a file acquisition module 310 for acquiring an XML file generated in response to a modification of a target variable of a post-construction attribute type, and a corresponding first target file to be updated; an address information acquisition module 320 for acquiring address information of the target variable in the first target file based on the XML file; and a target file update module 330 for updating the value of the target variable in the first target file based on the acquired address information to generate an updated second target file. The implementation of this embodiment is similar to the method described above, and therefore will not be further described.

[0030] like Figure 4 FIG2 is an exemplary block diagram of a computing device 400 according to another embodiment of the present invention. The computing device 400 includes a processor 410 and a memory 420 coupled to the processor 410. The memory 420 is configured to store computer-executable instructions that, when executed, cause the processor 410 to perform the method described in the above embodiment (e.g., any one or more steps in the aforementioned method).

[0031] In addition, alternatively, the above method can be implemented by a computer-readable storage medium. The computer-readable storage medium is loaded with computer-readable program instructions for executing the various embodiments of the present disclosure. The computer-readable storage medium can be a tangible device that can hold and store instructions used by an instruction execution device. The computer-readable storage medium can be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. More specific examples (non-exhaustive list) of computer-readable storage media include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device, for example, a punch card or a protrusion structure in a groove on which instructions are stored, and any suitable combination thereof. The computer-readable storage medium used herein is not to be construed as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., light pulses through a fiber optic cable), or an electrical signal transmitted through wires.

[0032] Therefore, in another embodiment, the present disclosure provides a computer-readable storage medium having computer-executable instructions stored thereon, the computer-executable instructions being used to execute the methods in various embodiments of the present disclosure.

[0033] In another embodiment, the present disclosure provides a computer program product, which is tangibly stored on a computer-readable storage medium and includes computer-executable instructions that, when executed, cause at least one processor to perform the methods of various embodiments of the present disclosure.

[0034] In general, the various example embodiments of the present disclosure may be implemented in hardware or dedicated circuitry, software, firmware, logic, or any combination thereof. Certain aspects may be implemented in hardware, while other aspects may be implemented in firmware or software that may be executed by a controller, microprocessor, or other computing device. When various aspects of the embodiments of the present disclosure are illustrated or described as block diagrams, flow charts, or using some other graphical representation, it will be understood that the blocks, devices, systems, techniques, or methods described herein may be implemented, as non-limiting examples, in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or a controller or other computing device, or some combination thereof.

[0035] Computer-readable program instructions or computer program products for executing the various embodiments of the present disclosure can also be stored in the cloud. When needed, users can access the computer-readable program instructions for executing an embodiment of the present disclosure stored in the cloud through mobile Internet, fixed network or other networks, thereby implementing the technical solutions disclosed in accordance with the various embodiments of the present disclosure.

[0036] Although the embodiments of the present disclosure have been described with reference to several specific embodiments, it should be understood that the embodiments of the present disclosure are not limited to the specific embodiments disclosed. The embodiments of the present disclosure are intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims. The scope of the claims is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures and functions.

[0037] It is obvious to those skilled in the art that various changes or modifications can be made to the above preferred embodiments without departing from the spirit of the present invention, and these changes or modifications do not depart from the scope of the present invention.

Claims

1. A method for updating a target file of an automotive open system architecture, comprising: Acquire an extensible markup language file generated in response to modification of a target variable of a post-construction attribute type and a corresponding first target file to be updated; Acquire address information of the target variable in the first target file based on the extensible markup language file; The value of the target variable in the first target file is updated based on the acquired address information to generate an updated second target file.

2. The method for updating target files of an automotive open system architecture according to claim 1, wherein: The extensible markup language file is a first extensible markup language file, and the method further includes: obtaining a second extensible markup language file generated in response to modification of a target variable of a precompiled attribute type and / or a link-time attribute type; generating a source file based on the first extensible markup language file and the second extensible markup language file; The source file is compiled to generate a corresponding updated third target file.

3. The method for updating target files of an automotive open system architecture according to claim 1, wherein: The target variable includes preset information, and the preset information includes the storage location, storage format, sorting method and / or alignment method of the target variable in the target file.

4. The method for updating target files of an automotive open system architecture according to claim 1, wherein: The target variable of the post-construction attribute type includes the sequence information and version information of the product.

5. The method for updating target files of an automotive open system architecture according to claim 1, wherein: The modification method of the target variable of the post-construction attribute type includes: modifying through a flash erase tool, a unified diagnostic service and / or a boot program.

6. The method for updating target files of an automotive open system architecture according to claim 1, wherein: The extensible markup language file includes a system configuration file, an electronic control unit extract file, an electronic control unit configuration file, a software component description file and / or a basic software module description file.

7. A target file update device for an automotive open system architecture, comprising: A file acquisition module, configured to acquire an extensible markup language file generated in response to a modification of a target variable of a post-construction attribute type and a corresponding first target file to be updated; An address information acquisition module, configured to acquire address information of the target variable in the first target file based on the extensible markup language file; The target file updating module is configured to update the value of the target variable in the first target file based on the acquired address information to generate an updated second target file.

8. A computing device, comprising: processor; as well as A memory for storing computer-executable instructions, which, when executed, cause the processor to perform the method according to any one of claims 1 to 6. 9 . A computer-readable storage medium having computer-executable instructions stored thereon, wherein the computer-executable instructions are used to execute the object file updating method of the automotive open system architecture according to any one of claims 1 to 6.

10. A computer program product, tangibly stored on a computer-readable storage medium, and comprising computer-executable instructions that, when executed, cause at least one processor to perform the object file update method of the Automotive Open System Architecture according to any one of claims 1 to 6.

Images