Method, device, controller, vehicle, equipment and product for vehicle-mounted software

Abstract

The embodiment of the invention relates to a method and device for vehicle-mounted software, a controller, a vehicle, equipment and a product. The method includes obtaining in-vehicle software including a first compiled version of an executable file separate from an executable file implementing a set of functions. The method further includes parsing the executable file to obtain a set of enabling settings, and controlling execution of the first compiled version of the in-vehicle software based on the set of enabling settings. Another method includes receiving a set of enable settings for a set of functions of the in-vehicle software, and generating an enable profile for the set of functions based on the set of enable settings. The method also includes generating, based on the enable profile, an in-vehicle software including a first compiled version of an executable file indicating the set of enable settings and separated from the executable file implementing the set of functions. According to the scheme, vehicle-mounted software function implementation and starting setting can be decoupled, and more flexible vehicle-mounted software integration and control are achieved.

Description

Technical Field

[0001] Embodiments of this disclosure relate to in-vehicle software, and more specifically, to methods, apparatus, and computer program products for execution control and functional integration of in-vehicle software. Background Technology

[0002] During the development of automotive software, an increasing number of features are developed to meet customer needs, such as infrastructure control, autonomous driving, and communication functions. Multiple software versions may be delivered during development. For a specific version, a particular feature may need to be disabled for various reasons, such as testing requirements or hardware limitations of the vehicle where the software is actually installed. In another software version, that feature may be required to be enabled. Summary of the Invention

[0003] The embodiments of this disclosure provide a scheme for execution control and function integration of in-vehicle software.

[0004] In a first aspect of this disclosure, a method for execution control of in-vehicle software is provided. The method includes: obtaining a first compiled version of the in-vehicle software, wherein the first compiled version of the in-vehicle software includes a first executable file, the first executable file indicating a first set of enable settings for a set of functions of the in-vehicle software and being separate from an executable file implementing the set of functions; parsing the first executable file to obtain the first set of enable settings, wherein enable settings corresponding to corresponding functions indicate whether the corresponding functions are enabled; and controlling the execution of the first compiled version of the in-vehicle software based on the first set of enable settings.

[0005] In a second aspect of this disclosure, a method for integrating functions in vehicle software is provided. The method includes: receiving a set of enable settings for a set of functions of the vehicle software, wherein the enable settings corresponding to a specific function indicate whether that function is enabled; generating an enable configuration file for the set of functions based on the set of enable settings; and generating a first compiled version of the vehicle software based on the enable configuration file, wherein the first compiled version of the vehicle software includes a first executable file that indicates the set of enable settings and is separate from an executable file that implements the set of functions.

[0006] In a third aspect of this disclosure, an apparatus for execution control of in-vehicle software is provided. The apparatus includes: an acquisition module configured to acquire a first compiled version of the in-vehicle software, wherein the first compiled version of the in-vehicle software includes a first executable file, the first executable file indicating a first set of enable settings for a set of functions of the in-vehicle software, and is separate from an executable file implementing the set of functions; a parsing module configured to parse the first executable file to acquire the first set of enable settings, wherein enable settings corresponding to corresponding functions indicate whether the corresponding functions are enabled; and a control module configured to control the execution of the first compiled version of the in-vehicle software based on the first set of enable settings.

[0007] In a fourth aspect of this disclosure, an apparatus for integrating functions of in-vehicle software is provided, comprising: a receiving module configured to receive a set of enable settings for a set of functions of the in-vehicle software, wherein the enable settings corresponding to the respective functions indicate whether the respective functions are enabled; generating an enable configuration file for the set of functions based on the set of enable settings; and generating a first compiled version of the in-vehicle software based on the enable configuration file, wherein the first compiled version of the in-vehicle software includes a first executable file that indicates the set of enable settings and is separate from an executable file that implements the set of functions.

[0008] In a fifth aspect of this disclosure, a controller is provided, including at least one processor and a memory. The memory is coupled to the at least one processor and has instructions stored thereon that, when executed by the at least one processor, cause the controller to perform the method according to a first aspect of this disclosure.

[0009] In a sixth aspect of this disclosure, a vehicle is provided that includes the controller described in the fifth aspect of this disclosure.

[0010] In a seventh aspect of this disclosure, an electronic device is provided, including at least one processor and a memory. The memory is coupled to the at least one processor and has instructions stored thereon that, when executed by the at least one processor, cause the electronic device to perform the method according to a second aspect of this disclosure.

[0011] In an eighth aspect of this disclosure, a computer program product is provided, comprising a computer program that is executed by a processor to implement the methods described in the first or second aspect of this disclosure.

[0012] Please note that this summary is provided to present a simplified version of the chosen concepts, which will be further described in the detailed embodiments below. This summary is not intended to identify key or principal features of this disclosure, nor is it intended to limit the scope of this disclosure. Attached Figure Description

[0013] The above and other objects, features, and advantages of this disclosure will become more apparent from a more detailed description of exemplary embodiments thereof, taken in conjunction with the accompanying drawings, wherein:

[0014] Figure 1 A schematic diagram of an example environment in which several embodiments of the present disclosure can be implemented is shown;

[0015] Figure 2 Example methods for execution control of in-vehicle software according to some embodiments of the present disclosure are shown;

[0016] Figure 3 Example methods for functional integration of in-vehicle software according to some embodiments of the present disclosure are shown;

[0017] Figure 4 An example system architecture diagram for functional integration and execution control of in-vehicle software according to some embodiments of the present disclosure is shown;

[0018] Figure 5 An example workflow for functional integration and execution control of in-vehicle software according to some embodiments of this disclosure is shown;

[0019] Figure 6 An example apparatus for execution control of in-vehicle software according to some embodiments of the present disclosure is shown;

[0020] Figure 7 Example apparatuses for functional integration of in-vehicle software according to some embodiments of the present disclosure are shown; and

[0021] Figure 8 A schematic block diagram of a device that can be used to implement embodiments of the present disclosure is shown.

[0022] In all the accompanying drawings, the same or similar reference numerals denote the same or similar elements. Detailed Implementation

[0023] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0024] The term "comprising" and its variations as used herein are open-ended inclusion, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment". Definitions of other terms will be given in the description below.

[0025] During in-vehicle software development, for a specific delivered version, a certain function may need to be disabled / turned off (in the context of this article, this means that the function does not work or is not present in that version). In another software version, the function may need to be enabled / turned on (in the context of this article, this means that the function works or is present in that other version). Although the function has actually been implemented, when integrating the software function to generate the corresponding version of the in-vehicle software, developers still need to manually locate the corresponding part of the software code and adjust the function switching logic therein.

[0026] In automotive software, which typically comprises numerous different code files, manually adjusting function switches can be extremely time-consuming and labor-intensive, and prone to introducing errors. Furthermore, even after adjusting the code files, although the functions whose states have been changed are not actually altered, the entire software project still needs to be recompiled. Since automotive software is usually quite large, its compilation process can take hours or even longer.

[0027] To at least partially address the aforementioned problems and other potential issues, embodiments of this disclosure propose a scheme for execution control and function integration of in-vehicle software. In this scheme, for a set of functions in the in-vehicle software, a development device can receive settings indicating whether a corresponding function is enabled, and generate an enablement configuration file for that set of functions based on these settings. When compiling the in-vehicle software, the development device generates a separate executable file (e.g., a BIN file) in the compiled in-vehicle software based on the enablement configuration file. In other words, this executable file is separate from the executable files implementing the individual functions of the in-vehicle software, and it contains settings regarding whether these functions are enabled during execution.

[0028] On the other hand, a terminal device (e.g., a vehicle-mounted device) can obtain the aforementioned compiled in-vehicle software to execute its various functions. During execution, the terminal device automatically parses the executable file containing the function activation settings to obtain the activation settings corresponding to the functions. Furthermore, the terminal device can control the execution of the compiled in-vehicle software based on these activation settings.

[0029] Compiling and controlling the execution of in-vehicle software according to embodiments of this disclosure allows for the separation of settings for enabling or disabling certain functions from specific functional components within the in-vehicle software. Based on this, different versions of the in-vehicle software, each enabling different combinations of functions, can be obtained by individually modifying and compiling the enabling configuration file without altering the implementation code of the specific functions. Furthermore, by utilizing separate files compiled from different configuration files, the vehicle can control the enabling or disabling of software functions differently. Thus, a more efficient and convenient method for integrating and controlling the execution of in-vehicle software functions is provided.

[0030] The embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. First, refer to... Figure 1 This illustrates a schematic diagram of an example environment 100 in which various embodiments of the present disclosure can be implemented. For example... Figure 1 As shown, environment 100 includes computing device 110, which can be a host computer for developing and integrating in-vehicle software. Computing device 110 is capable of running various development tools, including but not limited to general-purpose or dedicated integrated development environments (IDEs). Computing device 110 includes the tools and resources required for developing in-vehicle software, such as code editors, compilation tools, debugging tools, and so on.

[0031] It should be understood that, although in Figure 1 While shown as a single entity, computing device 110 can exist in any suitable form in embodiments. For example, computing device 110 can be a centralized device, a distributed device, a virtual device hosted in the cloud, and so on. As a non-limiting example, computing device 110 can be a server for a collaborative development environment, which developers can communicate with via their respective client devices to perform online development. Alternatively, computing device 110 can be a developer's personal device, with various necessary development resources installed locally. Embodiments of this disclosure do not limit the specific form of computing device 110.

[0032] Computing device 110 can compile software code based on user input and package multiple compiled files. For example, computing device 110 can generate a corresponding executable file 150 based on configuration file 140. As an example, configuration file 140 can be a JSON file, and executable file 150 can be a BIN file. In other examples, other configuration file formats and executable file formats may also be used. Computing device 110 can perform actions according to embodiments of this disclosure to generate a specific version of compiled vehicle software, as will be discussed later. Figure 3 A more detailed description.

[0033] In some embodiments, computing device 110 may communicate directly or indirectly with terminal device to push compiled in-vehicle software or updates thereof to it. It should be understood that in some embodiments, terminal device may also access software resources in other ways, such as by connecting to a removable storage medium carrying the compiled software or portions thereof (e.g., a BIN file containing enabling settings for software functionality).

[0034] As an example Figure 1 Terminal device 120 is shown. Terminal device 120 may include controller 130. Terminal device 120 may be a vehicle for which software is to be installed for execution, and its controller 130 may be an electronic control unit (ECU) used by terminal device 120 to control electronics, electronic and other systems. Terminal device 120 may utilize controller 130 to perform methods according to embodiments of this disclosure to control the execution of in-vehicle software, as will be discussed later. Figure 2 In a more detailed description, in some embodiments, the terminal device may also be a simulation test machine or the like for testing in-vehicle software.

[0035] The architecture and functionality in example environment 100 are described for illustrative purposes only and do not imply any limitation on the scope of this disclosure. Other devices, systems, or components, etc., not shown, may also be present in example environment 100. Furthermore, embodiments of this disclosure can be applied to other environments with different structures and / or functionalities.

[0036] Figure 2 A flowchart illustrating an example method for execution control of in-vehicle software according to some embodiments of the present disclosure is shown. Example method 200 can be, for example, by... Figure 1 The method is executed by the controller 130 of the terminal device 120 shown. It should be understood that method 200 may also include additional actions not shown, and the scope of this disclosure is not limited in this respect. The following is in conjunction with... Figure 1 Example environment 100 is used to describe method 200 in detail.

[0037] At 210, a first compiled version of the vehicle software is obtained, wherein the first compiled version of the vehicle software includes a first executable file. The first executable file indicates a first set of enable settings for a set of functions of the vehicle software and is separate from the executable file that implements the set of functions.

[0038] For example, terminal device 120 may directly or indirectly obtain a first compiled version of the vehicle software generated by computing device 110, which includes executable file 150. Executable file 150 indicates a first set of enable settings for a set of functions of the vehicle software and is separate from other executable files that implement that set of functions.

[0039] In one embodiment, executable file 150 may be a binary file. (As will be discussed later...) Figure 3 As described in detail, the executable file 150 may be generated by the computing device 110 during the compilation of the vehicle software according to the configuration file 140 indicating the first set of enabled settings in the vehicle software project.

[0040] At 220, the first executable file is parsed to obtain a first set of enable settings. Each enable setting in the first set corresponds to a corresponding function of the in-vehicle software, and the enable setting corresponding to the corresponding function indicates whether the corresponding function is enabled.

[0041] For example, terminal device 120 can use its ECU to execute a first compiled version of the vehicle software. Upon software startup (e.g., in response to power-on of the ECU of terminal device 120), the ECU of terminal device 120 can parse executable file 150 to obtain a set of enabling settings for vehicle software functions. As specified by the software's memory layout, this set of enabling settings can be organized into appropriate locations in memory, making them accessible and usable by the relevant functions.

[0042] As an example implementation, the group of enable settings can be organized into one or more 1-byte data blocks, where each bit in the block indicates whether its corresponding specific function is enabled during software execution (e.g., 1 for enabled, 0 for disabled). Other sizes and / or organizational structures can also be used in other implementations, as will be discussed later. Figure 3 The specific values ​​for the enable settings described can be set by the developer in a separate enable configuration file during development and compiled into the first executable file.

[0043] At 230, the execution of the first compiled version of the vehicle software is controlled based on the first set of enable settings. For example, terminal device 120 can control the execution of a set of functions in the first compiled version of the vehicle software based on the first set of enable settings obtained at 220.

[0044] According to the enable setting instruction, the terminal device 120 can enable or disable the corresponding function during the execution of the first compiled version of the vehicle software. In some embodiments, the first compiled version of the vehicle software includes a control function for controlling whether other functional components are enabled. During the execution of the vehicle software, the terminal device 120 can invoke this control function to control the execution of various other functions.

[0045] Terminal device 120 can pass a first set of enable settings to the control function. For example, the control function can locate and obtain the first set of enable settings during execution. Furthermore, by executing the control function, terminal device 120 can pass enable instructions to the corresponding functions in the set of functions. For example, the control function can determine the value of the first setting in the set of settings and its corresponding function, and instruct the corresponding function to be executed or not executed based on the value.

[0046] In method 200, the implementation of specific functions in the in-vehicle software is decoupled from the settings regarding whether these functions are actually enabled. By executing the in-vehicle software in this way, when a new version of the software with different combinations of enabled functions needs to be executed later, developers can quickly and intuitively generate the new version of the software by modifying the enable configuration file, which will be compiled into a separate executable file. Furthermore, as described below, in-vehicle software executed using method 200 can be updated on the vehicle side without having to re-acquire and reinstall the entire new version of the software when changes to enabled functions are needed.

[0047] In some embodiments, after the terminal device 120 already has a first compiled version of the vehicle software, the terminal device 120 may also obtain a second executable file (e.g., received from the computing device 110). This second executable file functions the same as the first executable file in the first compiled version, indicating a second set of enable settings for a set of functions of the aforementioned vehicle software. Compared to the first executable file, at least some of the enable settings for the set of functions in the second set of enable settings have their values ​​changed.

[0048] Based on the acquired second executable file, terminal device 120 can generate a second compiled version of the vehicle software corresponding to the second set of enable settings. Terminal device 120 can replace the first executable file in the first compiled version of the vehicle software with the second executable file to generate the second compiled version of the vehicle software. Furthermore, terminal device 120 can automatically parse the second executable file to obtain the second set of enable settings. Then, similar to controlling the first version of the vehicle software, terminal device 120 can control the execution of the second compiled version of the vehicle software based on the second set of enable settings.

[0049] In some embodiments, during the execution of the first compiled version of the vehicle software, the terminal device 120 can determine a first enabled state of a first function in a set of functions during the execution of the first compiled version of the vehicle software, based on a first set of states. Subsequently, during the execution of the second compiled version of the vehicle software, the terminal device 120 can determine a second enabled state of the first function during the execution of the second compiled version of the vehicle software, based on a second set of states. The second enabled state differs from the first enabled state if the enabled setting for the first function in the second set of enabled settings changes compared to the first set of enabled settings. For example, the first function may be enabled in the first compiled version and disabled in the second compiled version. The terminal device 120 can then correspondingly enable or disable the first function.

[0050] The in-vehicle software can be hosted by a microcontroller and / or a system-on-a-chip (SoC). When controlling the execution of corresponding functional components, the enabled settings are transmitted across the chip. Errors may occur during control. Some embodiments of this disclosure also include error detection mechanisms for functional control, used to detect and alert to control errors for subsequent troubleshooting.

[0051] Taking the first compiled version of the vehicle software as an example, during its execution, the terminal device 120 can detect the actual activation status of a function (e.g., the first function) in a set of functions and determine whether there is a mismatch between the activation setting (e.g., the first activation setting) corresponding to that function in the first set of activation settings and its actual activation status. If the terminal device 120 determines that there is a mismatch between the setting status and the actual activation status of the function (e.g., set to enabled but not actually executed), the terminal device 120 can generate a Diagnostic Trouble Code (DTC) indicating the mismatch. In this way, it is possible to detect whether the corresponding function is controlled in accordance with the expected settings.

[0052] Figure 3 A flowchart of an example method 300 for functional integration of in-vehicle software according to some embodiments of the present disclosure is shown. Example method 300 can be, for example, by... Figure 1 The computing device 110 shown is used to perform this action. It should be understood that method 300 may also include additional actions not shown, and the scope of this disclosure is not limited in this respect. The following is in conjunction with... Figure 1 Example environment 100 is used to describe method 300 in detail.

[0053] At 310, a set of enable settings for a set of functions of the vehicle software is received. The enable setting corresponding to a specific function in this set of enable settings indicates whether that function is enabled. For example, computing device 110 may receive a set of enable settings for a set of functions of the vehicle software, where each enable setting corresponds to a specific function and indicates whether that function is enabled.

[0054] In some embodiments, as a host computer for developing in-vehicle software, the computing device 110 can receive user input for a set of enabling settings for functions of the in-vehicle software under development. In some embodiments, the computing device 110 can provide a graphical configuration interface for developers to edit enabling settings for in-vehicle software functions. Developers can enable or disable a function via this graphical configuration interface.

[0055] At 320, an enable profile for a set of functions is generated based on a set of enable settings. For example, computing device 110 may generate an enable profile for a set of functions of the vehicle software based on a set of enable settings received at 310.

[0056] In some embodiments, the computing device 110 may generate a default activation profile when the in-vehicle software project is created for subsequent editing by the user, thereby ultimately generating an activation profile including the required activation settings, such as profile 140. In some embodiments, the computing device 110 may generate an initial activation profile based on received user instructions for subsequent editing by the user, thereby ultimately generating profile 140.

[0057] At 330, a first compiled version of the vehicle software is generated based on an enable configuration file. This first compiled version of the vehicle software includes a first executable file that indicates a set of enable settings and is separate from other executable files that implement that set of functions. For example, computing device 110 can generate a first compiled version of the vehicle software that includes an executable file 150 based on configuration file 140. Executable file 150 indicates a set of enable settings for a set of functions of the vehicle software and is separate from other executable files that implement that set of functions.

[0058] Method 300 decouples the implementation of specific functions in in-vehicle software from the settings for whether these functions are actually enabled. In this way, when integrating in-vehicle software functions to obtain their specific compiled versions, developers only need to intuitively edit a separate enabling configuration file, thereby saving development effort and reducing the error rate.

[0059] Furthermore, in conventional automotive software development, if a different version of the software is required later, indicating a change in the enabled state of a function, developers need to manually remove or re-add the corresponding code. Alternatively, developers need to manually locate the logic and / or variables within the relevant code that indicate whether the function is actually executed and modify them. This process requires significant development effort and is equally prone to introducing errors. Moreover, after modification, the entire software needs to be recompiled and delivered. Compared to these conventional methods, automotive software generated by integrating functions based on Method 300 allows for the generation of different combinations of automotive software versions with varying functionalities in a simpler, more time- and resource-efficient manner.

[0060] Taking a vehicle as an example. In some embodiments, after the first compiled version of the in-vehicle software is sent to the vehicle, the user may want to change the enabled status of some functions on the vehicle. For example, for testing purposes, the user may want to remove a device from the vehicle. Accordingly, the vehicle needs to update the first version of the in-vehicle software to the corresponding version, wherein the software functions associated with that hardware need to be disabled to ensure that the software functions properly.

[0061] In such an embodiment, computing device 110 can receive modifications to the enable settings (e.g., via the graphical configuration interface described above) and update the enable profile based on the modifications. Similar to the first executable file, computing device 110 can generate a second executable file based on the updated enable profile. Computing device 110 can then send the second executable file to terminal device 120 as an update file modifying the in-vehicle software to a second compiled version, without recompiling and sending the entire software.

[0062] In other embodiments, after generating a first compiled version of the in-vehicle software, computing device 110 may need to generate a second compiled version of the in-vehicle software for another terminal device, including different combinations of functions. In such embodiments, computing device 110 may receive modifications to the aforementioned set of enabling settings. Computing device 110 may update the enabling profile based on these modifications, and generate a second executable file based on the updated enabling profile. Furthermore, by replacing the first executable file in the first compiled version of the in-vehicle software with the second executable file, computing device 110 can generate a second compiled version of the in-vehicle software without recompiling the entire software.

[0063] Figure 4 An example architecture 400 for functional integration and execution control of in-vehicle software according to some embodiments of the present disclosure is illustrated. As shown, architecture 400 may include development equipment 410 and execution equipment 420, which may be respectively... Figure 1 Example implementations of computing device 110 and terminal device 120.

[0064] Development device 410 may include an editing component 430 and a compilation component 440. The editing component 430 can provide developers with various functions for editing in-vehicle software projects. The editing component 430 may, for example, provide a user interface for editing in-vehicle software programs on the development device 410 or a client communicating with it. Developers can generate and edit the code of the in-vehicle software project via the user interface. In some embodiments, the editing component may provide a graphical editing interface.

[0065] In some embodiments, the editing component 110 may provide a dedicated editing interface for the configuration file. For example, the graphical user interface may display the names of the various functions to be configured, and editable Boolean values ​​indicating the current enabled setting for each function (such as 1 for enabled, 0 for disabled, or other appropriate values). For example, the graphical interface may also provide toggle buttons for enabling settings. Users can edit the settings for each function via the interface, and the computing device 110 modifies the corresponding function's enabled setting in the configuration file based on the user's edits on the interface. Furthermore, users can also input new function settings directly or via the user interface.

[0066] It should be understood that in other embodiments, other forms of configuration interfaces may also be provided, such as command-line interfaces. By modifying the configuration file accordingly based on user input, computing device 110 can ultimately generate an activation configuration file, such as configuration file 140, which includes a set of activation settings expected by the user.

[0067] The data contained in configuration file 140 can be mapped to a specific region in the memory layout of the in-vehicle software. The location of this specific region depends on the memory layout of the specific implementation. For example, this specific region is located at the beginning of the data region in the memory of the in-vehicle software (e.g., on terminal device 120) during execution. In the memory layout of this example implementation, the data section for enabling settings is arranged at the beginning of the data region, followed by data sections for other applications and supporting functions. The memory layout information includes the arrangement of the various parts of the software in memory, their starting address, and length, etc. The device executing the software retrieves the relevant information from the software and loads the software data into the appropriate memory location for execution.

[0068] When compiling the vehicle software, development device 410 compiles configuration file 140 into a separate executable file 150. When the vehicle software is subsequently executed on a terminal device, this executable file 150 can be parsed, and its enabling settings can be organized into corresponding areas of the terminal device's memory, enabling these enabling settings to be used for function control during execution. As those skilled in the art will understand, computing device 110 will also generate multiple executable files for other parts of the vehicle software code, and can link and package them for delivery.

[0069] In one example implementation, configuration file 140 can be a JSON file (e.g., blockheader.json), and computing device 110 generates a separate executable file for it when compiling the in-vehicle software (e.g., generated as blockheader.bin with the same filename). In other implementations, other configuration file formats and executable file formats may also be used.

[0070] After compilation, development device 110 can send the compiled vehicle software to execution device 420. Furthermore, in some embodiments, execution device 420 may already include a previous version of the vehicle software (e.g., a first compiled version of the vehicle software). Development device 110 can update configuration file 140 based on received user input and recompile it separately to generate an updated executable file 150. In this case, development device 110 can send only executable file 150 to execution device 420 for updating the first compiled version of the vehicle software thereon.

[0071] As described above, the execution device 420 can obtain and install the first compiled version of the vehicle software. Furthermore, after obtaining the first compiled version of the vehicle software, the execution device 420 can also obtain an updated executable file 150. Then, the execution device 420 can use the updated executable file 150 to replace the previous version of the executable file 150 in the first compiled version of the vehicle software, thereby generating a second compiled version of the vehicle software.

[0072] The execution device 420 may include a configuration module 450, a function switch control module 460, and a diagnostic module 470. These modules may be sent from the development device 410 to the execution device 420 as part of the vehicle software project when it is installed on the execution device.

[0073] Configuration module 450 can parse the current version of executable file 150 to obtain a set of enable settings and assign them to corresponding software functions. Function switch control module 460 is used to control whether other functional components are enabled. Function switch control module 460 can control the execution of the vehicle software by passing enable or disable instructions to the corresponding functions based on the enable settings during the execution of the vehicle software. For example, based on the enable setting value of 1 for a first function, the state of the first function can be determined to be enabled. Then, function switch control module 460 indicates that the first function is enabled based on the determined state.

[0074] The diagnostic module 470 can detect whether a function is actually enabled and compare it with a corresponding setting in a set of enable settings. The diagnostic module 470 can obtain the enable settings and actual enable status of the onboard software functions from the configuration module 450 and the function switch control module 460, respectively. As a non-limiting example, in an implementation where the enable setting is represented as 1 or 0, the diagnostic module 470 can mark actually running functions as 1 and not actually running functions as 0. The diagnostic module 470 can then compare whether the marking of the corresponding function matches the value of its enable setting. If a mismatch is detected, the diagnostic module can generate a diagnostic fault code for the mismatch to indicate an error in the execution control.

[0075] It should be understood that architecture 400 is shown only as an example, wherein the individual components shown can be divided into multiple components, and multiple components can be combined into a single component, and architecture 700 can also contain fewer, more, or different components.

[0076] Figure 5 An example workflow 500 for function integration and execution control of in-vehicle software according to some embodiments of the present disclosure is shown. This example workflow 500 can, for example, be used in… Figure 4 It executes in architecture 400. The following is combined with... Figure 4 To describe workflow 500

[0077] At 510, based on user input, development device 410 adds the definition of a new data block containing enabling settings to the enabling configuration file in the vehicle software project. At 520, development device 420 adds a variable indicating the address of this data block to the vehicle software. This allows subsequent execution devices to locate the data block and obtain its settings to control the execution of corresponding functions.

[0078] At 530, development device 410 updates the value of the enable setting in the enable configuration file based on user input and compiles the vehicle software, wherein the enable configuration file is compiled into a separate executable file. As mentioned above, depending on whether execution device 420 has already installed a previously compiled version of the vehicle software, the compiled vehicle software or its update (e.g., an executable file based on the enable configuration file) is sent to execution device 420. Execution device 420 can then execute the vehicle software. In the case of obtaining an update, the execution device can first replace the executable file including the previously enabled settings to obtain the updated version of the vehicle software.

[0079] At 540, configuration module 450 can parse the executable file to obtain the enable settings for each vehicle software function. At 550, based on this set of enable settings, function switch control module 460 can pass enable or disable instructions to the corresponding functions, thereby controlling the execution of the vehicle software. At 560, diagnostic module 470 can detect whether the actual enable status of the function matches the settings and generate diagnostic fault codes if necessary.

[0080] The steps in the above workflow 500 are combined with the previous text. Figures 2 to 4 This has already been described in more detail and will not be repeated here. It should be understood that Workflow 500 is provided as an example only, and it may also include additional actions not shown, and some of these actions may be omitted.

[0081] Figure 6 An example apparatus 600 for execution control of in-vehicle software according to some embodiments of the present disclosure is shown. Apparatus 600 includes an acquisition module 610, a parsing module 620, and a control module 630. The acquisition module 610 is configured to acquire a first compiled version of the in-vehicle software, wherein the first compiled version of the in-vehicle software includes a first executable file indicating a first set of enable settings for a set of functions of the in-vehicle software, and is separate from an executable file implementing the set of functions. The parsing module 620 is configured to parse the first executable file to obtain the first set of enable settings, wherein the enable settings corresponding to a corresponding function indicate whether the corresponding function is enabled. The control module 630 is configured to control the execution of the first compiled version of the in-vehicle software based on the first set of enable settings.

[0082] In some embodiments, the apparatus 600 further includes: a second acquisition module configured to receive a second executable file indicating a second set of enable settings for a set of functions; a generation module configured to generate a second compiled version of the vehicle software by replacing a first executable file in a first compiled version of the vehicle software with the second executable file; a second parsing module configured to parse the second executable file to obtain the second set of enable settings; and a second control module configured to control the execution of the second compiled version of the vehicle software based on the second set of enable settings.

[0083] In some embodiments, the control module 630 includes: a first determining module configured to determine a first enabled state of a first function in a set of functions during execution of a first compiled version of the vehicle software based on a first set of enabling settings; and the second control module includes: a second determining module configured to determine a second enabled state of the first function during execution of a second compiled version of the vehicle software based on a second set of enabling settings, wherein the second enabled state is different from the first enabled state.

[0084] In some embodiments, the first compiled version of the vehicle software includes control functions, and the control module 630 includes: a first delivery module configured to deliver a first set of enable settings to the control functions; and a second delivery module configured to deliver enable instructions to a corresponding function in the set of functions by executing the control functions.

[0085] In some embodiments, the apparatus 600 further includes: a detection module configured to detect the enable status of a first function in a set of functions during the execution of the first compiled version of the vehicle software; a matching module configured to determine whether there is a mismatch between the first enable setting corresponding to the first function in the first set of enable settings and the enable status; and a diagnostic module configured to generate a diagnostic fault code indicating the mismatch in response to determining that a mismatch exists.

[0086] Figure 7 An example apparatus 700 for function integration of in-vehicle software according to some embodiments of the present disclosure is shown. Apparatus 700 includes a receiving module 710, a generating module 720, and a compiling module 730. The receiving module 710 is configured to receive a set of enable settings for a set of functions of the in-vehicle software, wherein the enable settings corresponding to a respective function indicate whether the corresponding function is enabled. The generating module 720 is configured to generate an enable profile for the set of functions based on the set of enable settings. The compiling module 730 is configured to generate a first compiled version of the in-vehicle software based on the enable profile, wherein the first compiled version of the in-vehicle software includes a first executable file that indicates the set of enable settings and is separate from an executable file that implements the set of functions.

[0087] In some embodiments, the apparatus 700 further includes: a sending module configured to send a first compiled version of the vehicle software to a terminal device; a first modification receiving module configured to receive modifications to the enabling settings after sending the first compiled version of the vehicle software to the terminal device; a first updating module configured to update the enabling configuration file based on the modifications; a second compilation module configured to generate a second executable file based on the updated enabling configuration file; and an update sending module configured to send the second executable file to the terminal device as an update file that modifies the vehicle software to the second compiled version.

[0088] In some embodiments, the apparatus 700 further includes: a second modification receiving module configured to receive modifications to the enable settings after generating the first compiled version; a second update module configured to update the enable configuration file based on the modifications; a third compilation module configured to generate a second executable file based on the updated enable configuration file; and a replacement module configured to generate a second compiled version of the vehicle software by replacing the first executable file in the first compiled version of the vehicle software with the second executable file.

[0089] In some embodiments, the receiving module 710 includes an input receiving module configured to receive user input for a set of enable settings via a graphical configuration interface; and the generating module 720 includes an input-based generating module configured to generate an enable profile based on the user input.

[0090] Figure 8 A block diagram is shown of an electronic device 800 that can implement various embodiments of the present disclosure. Device 800 may be, for example, as shown below. Figure 1 The computing device 110 shown may also be the control unit of the terminal device 120. As shown, the controller 800 includes a processor 801, which can perform various appropriate actions and processes based on computer program instructions loaded into random access memory (RAM) 803 according to computer program instructions stored in read-only memory (ROM) 802. The RAM 803 may also store various programs and data required for the operation of the controller 800. The processor 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0091] Processor 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 801 performs the various methods and processes described above, such as method 200 or method 300. For example, in some embodiments, method 200 and / or method 300 may be implemented as computer software programs tangibly contained in a machine-readable medium. In some embodiments, part or all of the computer program may be loaded and / or installed on controller 800 via ROM 802. When the computer program is loaded into RAM 803 and executed by processor 801, one or more steps of method 200 described above may be performed, or one or more steps of method 300 may be performed. Alternatively, in other embodiments, processor 801 may be configured to perform method 200 or method 300 by any other suitable means (e.g., by means of firmware).

[0092] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload programmable logic devices (CPLDs), and so on.

[0093] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0094] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. Furthermore, although operations are depicted in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in sequential order, or requiring that all illustrated operations be performed to achieve the desired result. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple implementations.

[0095] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A method for execution control (200) of in-vehicle software, comprising: obtaining (210) a first compiled version of in-vehicle software, wherein the first compiled version of the in-vehicle software comprises a first executable file that indicates a first set of enablement settings for a set of functions of the in-vehicle software and is separate from executable files that implement the set of functions; parsing (220) the first executable file to obtain the first set of enablement settings, wherein an enablement setting corresponding to a respective function indicates whether the respective function is enabled; and controlling (230) execution of the first compiled version of the in-vehicle software based on the first set of enablement settings.

2. The method (200) of claim 1, further comprising: obtaining a second executable file that indicates a second set of enablement settings for the set of functions; generating a second compiled version of the in-vehicle software by replacing the first executable file in the first compiled version of the in-vehicle software with the second executable file; parsing the second executable file to obtain the second set of enablement settings; and controlling execution of the second compiled version of the in-vehicle software based on the second set of enablement settings.

3. The method (200) of claim 2, wherein controlling execution of the first compiled version of the in-vehicle software comprises: determining, based on the first set of enablement settings, a first enablement state of a first function in the set of functions during execution of the first compiled version of the in-vehicle software; and wherein controlling execution of the second compiled version of the in-vehicle software comprises: determining, based on the second set of enablement settings, a second enablement state of the first function during execution of the second compiled version of the in-vehicle software, wherein the second enablement state is different from the first enablement state.

4. The method (200) of claim 1, wherein the first compiled version of the in-vehicle software comprises a control function, and controlling execution of the first compiled version of the in-vehicle software based on the first set of enablement settings comprises: passing the first set of enablement settings to the control function; and passing, by executing the control function, an enablement indication to a respective function in the set of functions.

5. The method (200) of claim 1, further comprising: detecting an enablement state of a first function in the set of functions during execution of the first compiled version of the in-vehicle software; determining whether a first enablement setting in the first set of enablement settings corresponding to the first function and the enablement state are mismatched; and in response to determining that the mismatch exists, generating a diagnostic trouble code that indicates the mismatch.

6. A method (300) for function integration of in-vehicle software, comprising: receiving (310) a set of enablement settings for a set of functions of in-vehicle software, an enablement setting corresponding to a respective function indicating whether the respective function is enabled; generating (320) an enablement configuration file for the set of functions based on the set of enablement settings; and ​ ​ ​ ​ generating (330) a first compiled version of the in-vehicle software based on the enablement profile, wherein the first compiled version of the in-vehicle software comprises a first executable file that indicates the set of enablement settings and is separate from an executable file that implements the set of functions.

7. The method (300) of claim 6, further comprising: sending the first compiled version of the in-vehicle software to a terminal device; after sending the first compiled version of the in-vehicle software to the terminal device, receiving a modification to the set of enablement settings; updating the enablement profile based on the modification; generating a second executable file based on the updated enablement profile; and sending the second executable file to the terminal device as an update file that modifies the in-vehicle software to a second compiled version.

8. The method (300) of claim 6, further comprising, after generating the first compiled version of the in-vehicle software: receiving a modification to the set of enablement settings; updating the enablement profile based on the modification; generating a second executable file based on the updated enablement profile; and generating a second compiled version of the in-vehicle software by replacing the first executable file in the first compiled version of the in-vehicle software with the second executable file.

9. The method (300) of claim 6, wherein receiving the set of enablement settings comprises receiving user input for the set of enablement settings via a graphical configuration interface; and generating the enablement profile comprises generating the enablement profile based on the user input.

10. An apparatus (600) for execution control of in-vehicle software, comprising: an obtaining module (610) configured to obtain a first compiled version of in-vehicle software, wherein the first compiled version of the in-vehicle software comprises a first executable file that indicates a first set of enablement settings for a set of functions of the in-vehicle software and is separate from an executable file that implements the set of functions; a parsing module (620) configured to parse the first executable file to obtain the first set of enablement settings, wherein an enablement setting corresponding to a respective function indicates whether the respective function is enabled; and a control module (630) configured to control execution of the first compiled version of the in-vehicle software based on the first set of enablement settings.

11. An apparatus (700) for function integration of in-vehicle software, comprising: a receiving module (710) configured to receive a set of enablement settings for a set of functions of in-vehicle software, an enablement setting corresponding to a respective function indicating whether the respective function is enabled; a first generating module (720) configured to generate an enablement profile for the set of functions based on the set of enablement settings; and a second generating module (730) configured to generate a first executable file that indicates the set of enablement settings and is separate from an executable file that implements the set of functions based on the enablement profile. a second generation module (730) configured to generate the first compiled version of the in-vehicle software based on the enablement configuration file, wherein the first compiled version of the in-vehicle software comprises a first executable file that indicates the set of enablement settings and is separate from an executable file that implements the set of functions.

12. A controller (800) comprising: at least one processor (801); and a memory (802) coupled to the at least one processor (801) and having stored therein instructions that, when executed by the at least one processor (801), cause the controller (800) to perform the method according to any one of claims 1 to 5.

13. A vehicle (120) comprising the controller (800) according to claim 12.

14. An electronic device (800) comprising: at least one processor (801); and a memory (802) coupled to the at least one processor (801) and having stored therein instructions that, when executed by the at least one processor (801), cause the electronic device (800) to perform the method according to any one of claims 6 to 9.

15. A computer program product comprising a computer program to be executed by a processor to implement the method according to any one of claims 1 to 5 or claims 6 to 9.

Images