Automobile software architecture and automobile software code generation method and device

Abstract

The invention provides an automobile software architecture and an automobile software code generation method and device.The automobile software architecture comprises an application layer and a base layer, the application layer comprises a function module layer, a function code layer and a function code generation layer, the function module layer comprises a plurality of function modules and is used for running function strategies of the function modules; the customized interface layer is used for converting and verifying interface variables transmitted between the application layer and the base layer so as to realize decoupling of the application layer and the base layer; and the platform configuration layer is used for carrying out adaptive configuration on the data variable memory and the code of the functional module according to a platform type supported by the automobile controller, and the platform type comprises one of an embedded architecture and an automobile open system architecture. According to the embodiment of the invention, a traditional embedded code and an automobile open system code can be compatible at the same time, a traditional framework and an automobile open system framework are compatible, and platformization of application layer software is realized.

Description

Technical Field

[0001] The present invention relates to the field of automobile software technology, and in particular to an automobile software architecture, and a method and device for generating automobile software code. Background Art

[0002] In the related technologies, due to the differences in people's demands for automobiles and the diversity of automobile hardware and configurations, the combination of automobile embedded software functions is diversified. Secondly, the changes in controller hardware and chips cause changes in controller memory distribution. Moreover, most of the current automobile control software has a coexistence of traditional software architecture and AUTOSAR (Automotive Open System Architecture) software architecture. These reasons have led to the fact that application layer software cannot be universal. At the beginning of each new project, it is necessary to connect to the whole vehicle function and evaluate it first. At the same time, the application layer software also needs to be changed accordingly. The reliability of the software needs to be further verified, which requires a lot of time and manpower.

[0003] With respect to the above-mentioned problems existing in the related technologies, no efficient and accurate solutions have been found yet. Summary of the invention

[0004] The present invention provides a vehicle software architecture, a method and a device for generating vehicle software code to solve technical problems in related technologies.

[0005] According to one embodiment of the present invention, a software architecture of an automobile is provided, including an application layer and a base layer, wherein the application layer includes: a functional module layer, including a plurality of functional modules, for running functional strategies of the plurality of functional modules; a customized interface layer, for converting and verifying interface variables transmitted between the application layer and the base layer, so as to realize decoupling of the application layer and the base layer; a platform configuration layer, for adaptively configuring data variable memory and code of the functional module according to the platform type supported by the automobile controller, wherein the platform type includes one of the following: embedded architecture, automotive open system architecture.

[0006] Optionally, the platform configuration layer includes: a memory mapping allocation module, used to secondary allocate initial data of variable types of functional modules in data dictionary files, wherein the functional modules include strategy logic information, data information and model attribute information, the strategy logic information is stored in the model file, the data information and model attribute information are stored in the data dictionary file, and the data information includes variable types; an automobile open system framework configuration module, used to configure first configuration information of the automobile open system in the functional module and the custom interface layer; a data dictionary configuration module, used to select a target configuration template from multiple data dictionary configuration templates preset in the data dictionary files of the functional module and the custom interface layer, and the target configuration template is used to generate code adapted to the platform type.

[0007] Optionally, the memory mapping allocation module presets a plurality of secondary allocation strategies, and each secondary allocation strategy corresponds to a division requirement of an actual memory space.

[0008] Optionally, a plurality of data unit types are preset in the data dictionary file, wherein each data unit type includes the following fields: variable type, variable dimension, variable minimum value, and variable maximum value.

[0009] Optionally, the first configuration information is located in the model file, and the first configuration information includes function information, running entity, port mapping and xml option information corresponding to the automobile open system.

[0010] Optionally, the target configuration template includes second configuration information required for simulation and code generation, and the second configuration information includes: model diagnosis content, system target configuration, and code generation source style.

[0011] Optionally, the customized interface layer includes: a signal input interface, including a first variable rewrite switch, used to receive input variables of the basic layer, convert the data type of the input variables, judge the validity of the input variables, rewrite the input variables according to the switching state of the first variable rewrite switch, and input them into the functional module layer; a signal output interface, including a second variable rewrite switch, used to rewrite the output variables according to the switching state of the second variable rewrite switch, convert the data type, and output the output variables to the basic layer.

[0012] Optionally, each functional module in the functional module layer has a built-in calibration variable, and the calibration variable is used to indicate whether the corresponding functional module is enabled.

[0013] According to another embodiment of the present invention, a method for generating automobile software code is provided, which is applied in the software architecture of the automobile described in the above embodiment, and includes: receiving software installation information, wherein the software installation information is used to indicate the platform type supported by the automobile controller that runs the software code; generating an application layer code and / or an interface description arxml file of an automobile open system architecture according to the platform type; if it is an embedded architecture, using the application layer code and the basic layer code to compile and generate a binary file of the software installation package; if it is an automobile open system architecture, using the arxml file to compile and generate an RTE code for running a virtual bus interface, and using the application layer code, the RTE code, and the basic layer code to compile and generate a binary file of the software installation package.

[0014] Optionally, generating application layer code according to the platform type includes: loading a model file of a custom interface layer of the platform type; if the platform type is an embedded architecture, selecting a configuration template in the data dictionary file of the functional module layer as an embedded configuration, and selecting an embedded code generation template; using the embedded configuration and the embedded code generation template to generate a first application layer code; if the platform type is an automotive open system architecture, selecting a configuration template in the data dictionary file of the functional module layer as an automotive open system configuration, selecting an automotive open system code generation template, and using the automotive open system configuration and the automotive open system code generation template to generate a second application layer code and the arxml file of the custom interface layer.

[0015] Optionally, after compiling the application layer code and the basic layer code to generate a binary file of the software installation package, the method further includes: flashing the binary file to the vehicle controller; configuring calibration variables of each functional module, wherein the calibration variables are used to indicate whether the corresponding functional module is enabled.

[0016] According to another embodiment of the present invention, a device for generating automobile software code is provided, which is applied in the automobile software architecture described in the above embodiment, and includes: a receiving module, used to receive software installation information, wherein the software installation information is used to indicate the platform type supported by the automobile controller that runs the software code; a first generating module, used to generate application layer code and / or an interface description file arxml of the Autosar architecture according to the platform type; a second generating module, used to compile and generate a binary file of the software installation package using the application layer code and the basic layer code if it is an embedded architecture; if it is an Autosar architecture, use the arxml file to compile and generate a virtual bus interface RTE code, and use the application layer code, the RTE code, and the basic layer code to compile and generate a binary file of the software installation package.

[0017] Optionally, the first generation module includes: a loading unit, used to load the model file of the custom interface layer of the platform type; a first generation unit, used to select the configuration template in the data dictionary file of the functional module layer as the embedded configuration if the platform type is an embedded architecture, and select the embedded code generation template; use the embedded configuration and the embedded code generation template to generate the first application layer code; a second generation unit, used to select the configuration template in the data dictionary file of the functional module layer as the Autosar configuration if the platform type is an Autosar architecture, select the Autosar code generation template, and use the Autosar configuration and the Autosar code generation template to generate the second application layer code and the arxml file of the custom interface layer.

[0018] Optionally, the device also includes: a flashing module, used to flash the binary file to the vehicle controller after the second generation module compiles the application layer code and the basic layer code to generate a binary file of the software installation package; a configuration module, used to configure the calibration variables of each functional module, wherein the calibration variables are used to indicate whether the corresponding functional module is enabled.

[0019] According to another aspect of an embodiment of the present application, a storage medium is further provided, which includes a stored program, and the above steps are executed when the program is run.

[0020] According to another aspect of an embodiment of the present application, there is also provided an electronic device, including a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; wherein: the memory is used to store a car program; and the processor is used to execute the steps in the above method by running the program stored in the memory.

[0021] An embodiment of the present application also provides an automobile program product comprising instructions, which, when executed on a computer, enables the computer to execute the steps in the above method.

[0022] Beneficial effects of the present invention:

[0023] 1. By adding a platform configuration layer and a custom interface layer to the application layer, the application layer can be decoupled from the basic layer. At the same time, different memory allocations can be matched without changing the application layer functional module model and code. It is compatible with both traditional embedded code and Autosar code, and compatible with traditional architecture and Autosar architecture, thus realizing the platformization of application layer software.

[0024] 2. Through platform configuration, traditional embedded code or code that meets Autosar requirements can be selectively generated, thereby achieving compatibility between traditional architecture and Autosar architecture;

[0025] 3. The memory mapping module in the configuration layer of the same specification platform performs secondary allocation of the variable types of the functional modules, thereby realizing the memory reconfiguration of the data variables in the application layer software;

[0026] 4. The combination of different project functions is directly realized through calibration without changing the logical functions of the application layer, realizing the platformization of the application layer software while improving the stability and reliability of the software. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0028] Figure 1 is a hardware structure block diagram of a car according to an embodiment of the present invention;

[0029] Figure 2 is a schematic diagram of a software architecture of a car according to an embodiment of the present invention;

[0030] Figure 3 is a schematic diagram of memory secondary allocation according to an embodiment of the present invention;

[0031] Figure 4 is a complete diagram of the software architecture in an embodiment of the present invention;

[0032] Figure 5 is a flow chart of a method for generating automobile software code according to an embodiment of the present invention;

[0033] Figure 6 is a workflow diagram of the software architecture of the automobile according to an embodiment of the present invention;

[0034] Figure 7 The present invention is a structural block diagram of a device for generating automobile software code according to an embodiment of the present invention. DETAILED DESCRIPTION

[0035] In order to enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only embodiments of a part of the present application, not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work should fall within the scope of protection of the present application. It should be noted that the embodiments in the present application and the features in the embodiments can be combined with each other without conflict.

[0036] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0037] Example 1

[0038] The method embodiment provided in the first embodiment of the present application can be executed in a car, a controller or a similar processing device. Taking running on a car as an example, Figure 1 1 is a hardware structure diagram of a car according to an embodiment of the present invention. Figure 1 As shown, a car may include one or more ( Figure 1 Only one is shown in the figure) a processor 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data. Optionally, the above-mentioned automobile may also include a transmission device 106 and an input / output device 108 for communication functions. It can be understood by those skilled in the art that Figure 1 The structure shown is for illustration only and does not limit the structure of the above-mentioned automobile. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations shown.

[0039] The memory 104 can be used to store automobile programs, for example, software programs and modules of application software, such as automobile programs corresponding to a method for generating automobile software code of an automobile in an embodiment of the present invention. The processor 102 executes various functional applications and data processing by running the automobile program stored in the memory 104, that is, to implement the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the automobile via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0040] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the car. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0041] In this embodiment, a software architecture of a car is provided. Figure 2 is a schematic diagram of a software architecture of a car according to an embodiment of the present invention, such as Figure 2 As shown, the software architecture includes an application layer and a basic layer, wherein the functions in the application layer are implemented by various software components (SWC), and the components encapsulate part or all of the automotive electronic functions.

[0042] In the embodiment of the present application, the application layer may include: a function module layer 20 , a custom interface layer 22 and a platform configuration layer 24 .

[0043] The function module layer 20 includes several function modules and is used to run the function strategies of the several function modules; the function strategy refers to the software program corresponding to each function module, each software program is composed of code segments, and executing the code segments can realize the corresponding software functions.

[0044] Optionally, the functional modules may be, but are not limited to: power on and off module, instrument information processing module, sensor detection module, driving mode selection module, media control module, etc.

[0045] Each functional module includes strategy logic information, data information and model attribute information. The strategy logic information, data information and model attribute information are stored separately. The strategy logic information is stored in the model file, and the data information and model attribute information are stored in the data dictionary file. The data information includes data unit type, variable type, variable preset value, etc.

[0046] The customized interface layer 22 is used to convert and verify the interface variables transmitted between the application layer and the basic layer to achieve decoupling of the application layer and the basic layer. The interface layer is used for communication; the communication content is divided into: DataElements and Operations; among which: Data Elements use the sender-receiver (Sender / Receiver) communication method, and Operations use the client-server (Client / Server) communication method.

[0047] The platform configuration layer 24 is used to adaptively configure the data variable memory and code of the functional module according to the platform type supported by the automobile controller, wherein the platform type includes one of the following: embedded architecture, Autosar architecture;

[0048] In the embedded architecture, the basic layer includes the basic software layer. In the Autosar architecture, the basic layer includes RTE (real-time environment, which may be optional) and the basic software layer.

[0049] The above software architecture includes a function module layer, a customized interface layer and a platform configuration layer. The function module layer includes several function modules and is used to run the function strategies of the several function modules; the customized interface layer is used to convert and verify the interface variables transmitted between the application layer and the basic layer to realize the decoupling of the application layer and the software layer; the platform configuration layer is used to adaptively configure the data variable memory and code of the function module according to the platform type supported by the automobile controller, wherein the platform type includes one of the following: embedded architecture, Autosar architecture. By adding the platform configuration layer and the customized interface layer to the application layer, the application layer can be decoupled from the basic layer, different memory allocations can be matched without changing the application layer function module model and code, and the traditional architecture and Autosar architecture are compatible. At the same time, traditional embedded code and Autosar code are generated, and the platformization of the application layer software is realized.

[0050] In one implementation of the present embodiment, the platform configuration layer includes: a memory mapping allocation module, which is used to perform secondary allocation of initial data of variable types of functional modules in data dictionary files, wherein the functional modules include strategy logic information, data information and model attribute information, the strategy logic information is stored in the model file, the data information and model attribute information are stored in the data dictionary file, and the data information includes variable types; an Autosar framework configuration module, which is used to configure the first configuration information of Autosar in the functional module and the custom interface layer; a data dictionary configuration module, which is used to select a target configuration template from multiple data dictionary configuration templates preset in the data dictionary files of the functional module and the custom interface layer, and the target configuration template is used to generate code adapted to the platform type.

[0051] Optionally, the first configuration information of Autosar is located in a model file, including Autosar-specific function information, software running entity, port mapping and xml option information, etc.

[0052] The Autosar framework configuration module in the platform configuration layer defines the Autosar configuration required for the functional module and the model in the custom interface layer, including the module's function information, software running entity information, mapping rules between the interface in the model and the Autosar interface, and other field contents, so that the correct Autosar code can be generated when the data dictionary configuration template is selected as the Autosar template.

[0053] When it is necessary to generate traditional embedded code, there is no need to configure the code field in the Autosar framework. The data dictionary configuration template is directly selected through the platform configuration to select the traditional configuration file, and the source code, header file and / or A2l file corresponding to the traditional configuration file are generated. When it is necessary to generate the code corresponding to the Autosar architecture, it is necessary to first configure the code field in Autosar through the Autosar framework configuration module, and configure the first configuration information so that the specific code field in Autosar is modified to the code corresponding to the first configuration information, which may specifically include the function information of the module, the software running entity information, the mapping rules of the interface in the model and the Autosar interface, etc., preferably, this part of the model configuration information is realized by script automation, that is, the script automatically modifies the code, and after the code modification is completed, that is, the configuration is completed, the Autosar configuration of the data dictionary configuration template is configured through the platform configuration to generate source code, header file, A2l file, Arxml file (AUTOSAR description file). Only through the platform configuration, traditional embedded code or code that meets the requirements of Autosar can be generated at the same time, so that the traditional architecture and the Autosar architecture can be compatible at the code level.

[0054] Optionally, the target configuration template includes second configuration information required for simulation and code generation, and the second configuration information includes: code corresponding to model diagnosis content, system target configuration, code generation source code style, etc.

[0055] In addition to variable information, the above data dictionary file also presets multiple data dictionary configuration templates, each model template includes model diagnosis, system target configuration information, code generation source code style, etc. The data dictionary configuration template is selected through the data dictionary configuration module in the platform configuration, and can generate traditional embedded code or code that meets the requirements of Autosar, thereby achieving compatibility between the traditional architecture and the Autosar architecture at the code level.

[0056] In one example, a memory mapping allocation module presets multiple secondary allocation strategies, each secondary allocation strategy corresponds to a division requirement of an actual memory space. If the online calibration space is sufficient, the variable types of all calibration types of the target functional module are remapped to the online calibration space; if the online calibration space is insufficient, the variable type of the first calibration type of the target functional module is remapped to the online calibration space, and the variable type of the second calibration type of the target functional module is remapped to the offline calibration space.

[0057] The target functional module can be any functional module in the functional module layer.

[0058] When the functional module is modeled using simulink, the software and data are stored separately, in the first file and the second file respectively. For example, the model of the functional module is stored in the *.slx file, and the data of the functional module is stored in the data dictionary *.sldd. In the data dictionary file, a variety of memory types are preset according to the combination of data unit type (observation quantity, calibration type 1, calibration type 2) and variable type (Boolean quantity, 8-bit length, 16-bit length, 32-bit length), such as Boolean type observation quantity (Signal_Bool), 8-bit length calibration type 1 (Parameter1_8Bits), 16-bit length calibration type 2 (Parameter2_16Bits), etc. All data are selected as needed when created and other attributes such as initial values ​​are added. In the data dictionary file, each variable type is initially defined at the same time during the preset process, and then secondary allocation is performed through the memory mapping module in the platform configuration layer. Figure 3 It is a schematic diagram of memory secondary allocation in an embodiment of the present invention, and the variable type illustrates 4 observation quantities (BOOL, 8BITS, 16BITS, 32BITS), 4 calibration type 1s (BOOL, 8BITS, 16BITS, 32BITS), and 4 calibration type 2s (BOOL, 8BITS, 16BITS, 32BITS). When controller A is used and the online calibration space is sufficient, all variable types of calibration type 1 and calibration type 2 are remapped to the online calibration space. When controller B is used and the online calibration space is insufficient and part of the calibration needs to be placed in a non-volatile storage location, i.e., an offline calibration space, all variable types of calibration type 1 are remapped to the online calibration space, and all variable types of calibration type 2 are remapped to the offline calibration space, thereby realizing the reconfiguration of the data variable memory in the application layer software. More specifically, the above variable types can be further subdivided, such as calibration type 1, calibration type 2, calibration type 3, etc. according to their importance. When performing secondary allocation, memory space alignment can also be performed according to data type, and the same data type can be stored uniformly, thereby optimizing memory space.

[0059] Optionally, a plurality of data unit types are pre-stored in the data dictionary file of the data dictionary, wherein each data unit type includes the following fields: variable type, variable dimension, variable minimum value, variable maximum value, etc.

[0060] When the functional module is modeled using simulink, the software and data are stored separately, that is, the software model is stored in the *.slx file, and the data is stored in the data dictionary *.sldd. In addition to data information, the data dictionary file also presets multiple data dictionary configuration templates, such as traditional configuration and Autosar configuration. Each model template includes model diagnosis, system target configuration information, code generation source code style, etc. Specifically, the traditional configuration includes setting the system target TLC file to ert.tlc, source code style such as C code, code standard such as C99 standard, chip settings, etc. The main difference between Autosar configuration and traditional configuration is that the system target file is the system target TLC file is Autosar.tlc, and the compilation tools used by the tool chain are different.

[0061] Optionally, the above data dictionary file presets multiple memory types according to the combination of data unit type (observation quantity, calibration type 1, calibration type 2) and variable type (Boolean quantity, 8-bit length, 16-bit length, 32-bit length), such as Boolean type observation quantity (Signal_Bool), 8-bit length calibration type 1 (Parameter1_8Bits), 16-bit length calibration type 2 (Parameter2_16Bits), etc. All data are selected as needed when created and other attributes such as initial values ​​are added.

[0062] Optionally, each variable type in the above data dictionary file is initially segment defined during the preset process, and then secondary allocated through the memory mapping module in the platform configuration layer, thereby realizing the memory reconfiguration of the data variables in the application layer software.

[0063] In one example, the customized interface layer includes: a signal input interface, including a first variable rewrite switch, used to receive the input variable of the base layer, convert the data type of the input variable, judge the validity of the input variable, rewrite the input variable according to the switch state of the first variable rewrite switch, and input it to the corresponding code position in the functional module layer; a signal output interface, including a second variable rewrite switch, used to rewrite the output variable according to the switch state of the second variable rewrite switch, convert the data type, and output the output variable to the corresponding code position in the base layer.

[0064] Each module in the custom interface layer is managed and automatically generated through an interface management table. The interface management table contains variables such as the required basic layer input variable name, input data type, input variable rewrite switch name, input variable rewrite value name, basic layer output variable name, output data type, output variable rewrite switch name, output variable rewrite value name, etc., and the model file and data dictionary file of the custom layer are generated through automatic modeling through Matlab scripts. The model file and data dictionary file are both implemented in code form.

[0065] In one example, each functional module in the functional module layer has a built-in calibration variable, and the calibration variable is used to indicate whether the corresponding functional module is enabled.

[0066] Each functional module has a calibration variable to determine whether to enable the functional module. When the application layer code and the basic layer software code are uniformly compiled to generate a flashable binary file and flashed to the controller, the combination of different project functions is directly implemented through calibration without changing the application layer logical function, thereby realizing the platformization of the application layer software and improving the stability and reliability of the software during the project development process.

[0067] Figure 4 It is a complete diagram of the software architecture in the embodiment of the present invention, including a functional module layer, a platform configuration layer, a custom interface layer, and a basic software layer (basic layer). The functional module layer is a specific implementation of the functional strategy, including but not limited to: power-on and power-off modules, instrument information processing modules, sensor detection modules, driving mode selection modules, etc.; the custom interface layer includes but is not limited to conversion and verification modules for connecting application layer and basic layer interface variables such as signal input and signal output; the platform configuration layer includes a memory mapping module, an Autosar framework configuration module, a data dictionary configuration module, etc.

[0068] In this embodiment, a method for generating automobile software code is provided, which is applied to the automobile software architecture described in the above embodiment. Figure 5 is a flow chart of a method for generating automobile software code according to an embodiment of the present invention, such as Figure 5 As shown, the process includes the following steps:

[0069] Step S502, receiving software installation information, wherein the software installation information is used to indicate the platform type supported by the automobile controller running the software code;

[0070] Step S504, generating an application layer code and / or an interface description arxml file of the Autosar architecture according to the platform type;

[0071] Step S506, if it is an embedded architecture, the application layer code and the basic layer code are used to compile and generate a binary file of the software installation package; if it is an Autosar architecture, the arxml file is used to compile and generate the RTE code for running the virtual bus interface, and the application layer code, the RTE code, and the basic layer code are used to compile and generate a binary file of the software installation package.

[0072] In one example, generating application layer code according to the platform type includes: loading a model file of a custom interface layer of the platform type; if the platform type is an embedded architecture, selecting a configuration template in a data dictionary file of the functional module layer as an embedded configuration, specifically: determining that the configuration template is a code file of a preset embedded configuration, selecting an embedded code generation template, and the code generation template is a preset code generation file; using the embedded configuration and the embedded code generation template to generate a first application layer code, and combining the code file of the embedded configuration with the preset code generation file to generate the first application layer code; if the platform type is an Autosar architecture, selecting the configuration template in the data dictionary file of the functional module layer as an Autosar configuration, selecting an Autosar code generation template, and using the Autosar configuration and the Autosar code generation template to generate a second application layer code and an arxml file of the custom interface layer.

[0073] When the configuration option is AUTOSAR architecture, set the configuration template in the data dictionary file of each module to AUTOSAR configuration, select the AUTOSAR code generation template, and generate C code that complies with the AUTOSAR standard. At the same time, the interface model generates the AUTOSAR description file arxml file;

[0074] When the configuration option is not the AUTOSAR architecture, set the configuration template in the data dictionary file of each module to the traditional embedded configuration, select the embedded code generation template, and generate traditional C code.

[0075] Optionally, after compiling the application layer code and the basic layer code to generate a binary file of the software installation package, it also includes: flashing the binary file to the vehicle controller; configuring calibration variables of each functional module, wherein the calibration variables are used to indicate whether the corresponding functional module is enabled.

[0076] After all the codes are generated, they are compiled together with the basic software layer (RTE (optional) + basic software layer) code to generate a flashable binary file, which is then flashed to the controller. The calibration engineer selects the functional modules according to the configuration of the project and vehicle type and turns on the corresponding calibration switch to finally complete the control software for the corresponding project.

[0077] Figure 6 It is a workflow diagram of the software architecture of the automobile of the embodiment of the present invention, which includes three stages, wherein the first stage, the model preparation stage, includes the modeling of the functional modules and the modeling of the customized interface layer modules;

[0078] Functional module modeling: if there are new system requirements, the functional modules are modeled according to the requirements. When using simulink for modeling, the corresponding code is created by separating the model and the data. Taking functional module 1 as an example, the model file Func1.slx and the data dictionary file Func1.sldd are created and stored during modeling. The model file stores the strategy logic of the module, and the data dictionary file stores all the attribute information of the model file, such as data unit type, variable type, variable preset value, etc.

[0079] Optionally, all data unit types in the code corresponding to the data dictionary file have preset multiple formats, such as observation type, online calibration type, offline calibration type, etc. Select the preset format when creating data, and fill in the remaining attribute information in the code according to the preset format;

[0080] The data unit type in the data dictionary file is used in combination with the memory mapping configuration file in the platform configuration to readjust the memory distribution of the variables in the software. Generally speaking, after a variable can only select one data unit type in the data dictionary file, after the code modeling corresponding to a functional module is completed, all variable types in the relevant software code have been determined, and the memory space corresponding to the software code has also been determined. If the memory space changes significantly, it is necessary to change the variable type in the data dictionary file, regenerate the code, and retest, which brings a large workload. However, when the controller hardware or chip changes, the memory distribution may change. For example, the memory space for online calibration in project A is 320K, while the memory space for online calibration in project B is only 160K. At this time, if the actual space for calibrating variables in the software is already 200K, the conventional solution needs to change the variable type in the software to meet the requirements. In the application layer platform solution, a memory mapping file is added to the platform configuration. For example, the variable 200K in the software is subdivided into 160K for online calibration and 40K for offline calibration. In project A, when the online calibration space is sufficient, the online calibration and offline calibration in the data dictionary file are remapped to online calibration. In project B, when the online calibration space is insufficient, the online calibration and offline calibration in the data dictionary file are remapped respectively, and the offline calibration is divided into memory space separately, so that the variable memory can be redistributed without changing the variable type of the data dictionary or regenerating the code.

[0081] More specifically, the above variables can be further subdivided, such as online calibration type 1, online calibration type 2, offline calibration type 1, offline calibration type 2, etc., and memory space alignment can be performed according to data type, and the same data type can be stored uniformly, thereby optimizing memory space;

[0082] Customized interface layer module modeling. The main difference between different projects lies in the customized interface layer modules. For example, Project A uses Project A’s customized interface, including signal input, signal output and other modules. Signal input mainly introduces basic layer variables, converts data types, judges the validity of input variables, and adds variable rewrite switches. The output module at the output signal adds a rewrite switch to the upper layer output variable and converts the data type. Signal output outputs the variable to the basic layer.

[0083] Optionally, the modeling of the above-mentioned custom interface layer module can be realized through script automation. In the project configuration folder, there are two variable management tables, SignalInput.xlsx and SignalOutput.xlsx, which contain variables such as the required base layer input variable name, input data type, input variable rewrite switch name, input variable rewrite value name, base layer output variable name, output data type, output variable rewrite switch name, output variable rewrite value name, etc. The model file and data dictionary file of the custom interface are generated through Matlab script to realize automatic modeling;

[0084] Optionally, the data dictionary files (*.sldd) of all functional modules and custom interface modules contain simulink model configuration in addition to logic strategies. The model configuration information has multiple templates, including but not limited to traditional embedded configuration templates and AUTOSAR configuration templates. Each template includes model diagnosis, code generation source code type, code template and other contents. The subsequent code generation stage will select the configuration template according to the project configuration to generate traditional embedded code or AUTOSAR code, which is compatible with traditional architecture and AUTOSAR architecture.

[0085] The second stage: the model loading stage, including selecting a project in the pop-up window during the model loading process, and loading the customized interface layer model according to the selected project;

[0086] The project uses MATLAB for project management and modeling. During the model loading process, a pop-up window is displayed for users to select specific projects.

[0087] Load the customized interface layer model according to the selected project, select the corresponding allocation mechanism and write it into the memory mapping file according to the project selected by the user, and determine whether it is an Autosar architecture. If so, perform the Autosar framework configuration and update the data dictionary configuration to Autosar configuration; if not, update the data dictionary configuration to traditional embedded configuration. The third stage: code generation stage, generate the code for each module according to the configuration options output in the second stage.

[0088] When the data dictionary is configured as Autosar configuration and the corresponding Autosar framework configuration is performed, a C code that complies with the AUTOSAR standard is generated, and an interface description file is generated at the same time;

[0089] When the data dictionary configuration option is non-AUTOSAR architecture (embedded architecture), traditional C code is generated.

[0090] This embodiment provides a platform software architecture, system and code generation method for the automotive embedded software application layer. A customized interface layer is added between the application layer software (ASW) and the base layer software (BSW) to achieve decoupling of the application layer from the base layer; the platform configuration file is used to match different memory mapping rules and change configuration options to generate code styles of different standards, which is compatible with the traditional architecture and the AUTOSAR architecture, realizes the platformization of the application layer software, and reduces the development cost and maintenance cost of automotive software.

[0091] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention, 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, a magnetic disk, or an optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present invention.

[0092] Example 2

[0093] In this embodiment, a device for generating a car software code is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0094] Figure 7 is a structural block diagram of a device for generating automobile software code according to an embodiment of the present invention, and in the automobile software architecture described in the above embodiment, Figure 7 As shown, the device comprises:

[0095] A receiving module 70, configured to receive software installation information, wherein the software installation information is used to indicate a platform type supported by a vehicle controller running the software code;

[0096] A first generating module 72 is used to generate an application layer code and / or an interface description file arxml of the Autosar architecture according to the platform type;

[0097] The second generation module 74 is used to compile and generate a binary file of the software installation package using the application layer code and the basic layer code if it is an embedded architecture; if it is an Autosar architecture, use the arxml file to compile and generate the RTE code for running the virtual bus interface, and use the application layer code, the RTE code, and the basic layer code to compile and generate a binary file of the software installation package.

[0098] Optionally, the first generation module includes: a loading unit, used to load the model file of the custom interface layer of the platform type; a first generation unit, used to select the configuration template in the data dictionary file of the functional module layer as the embedded configuration if the platform type is an embedded architecture, and select the embedded code generation template; use the embedded configuration and the embedded code generation template to generate the first application layer code; a second generation unit, used to select the configuration template in the data dictionary file of the functional module layer as the Autosar configuration if the platform type is an Autosar architecture, select the Autosar code generation template, and use the Autosar configuration and the Autosar code generation template to generate the second application layer code and the arxml file of the custom interface layer.

[0099] Optionally, the device also includes: a flashing module, used to flash the binary file to the vehicle controller after the second generation module compiles the application layer code and the basic layer code to generate a binary file of the software installation package; a configuration module, used to configure the calibration variables of each functional module, wherein the calibration variables are used to indicate whether the corresponding functional module is enabled.

[0100] It should be noted that the above modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.

[0101] Example 3

[0102] An embodiment of the present invention further provides a storage medium, in which a car program is stored, wherein the car program is configured to execute the steps of any one of the above method embodiments when running.

[0103] Optionally, in this embodiment, the storage medium may be configured to store a vehicle program for performing the following steps:

[0104] S1, receiving software installation information, wherein the software installation information is used to indicate a platform type supported by a vehicle controller running a software code;

[0105] S2, generating an application layer code and / or an interface description arxml file of the Autosar architecture according to the platform type;

[0106] S3, if it is an embedded architecture, the application layer code and the basic layer code are used to compile and generate a binary file of the software installation package; if it is an Autosar architecture, the arxml file is used to compile and generate the RTE code for running the virtual bus interface, and the application layer code, the RTE code, and the basic layer code are used to compile and generate a binary file of the software installation package.

[0107] Optionally, in this embodiment, the above-mentioned storage medium may include but is not limited to: a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and other media that can store automobile programs.

[0108] An embodiment of the present invention further provides an electronic device, including a memory and a processor, wherein a car program is stored in the memory, and the processor is configured to run the car program to execute the steps in any one of the above method embodiments.

[0109] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0110] Optionally, in this embodiment, the processor may be configured to perform the following steps through a car program:

[0111] S1, receiving software installation information, wherein the software installation information is used to indicate a platform type supported by a vehicle controller running a software code;

[0112] S2, generating an application layer code and / or an interface description arxml file of the Autosar architecture according to the platform type;

[0113] S3, if it is an embedded architecture, the application layer code and the basic layer code are used to compile and generate a binary file of the software installation package; if it is an Autosar architecture, the arxml file is used to compile and generate the RTE code for running the virtual bus interface, and the application layer code, the RTE code, and the basic layer code are used to compile and generate a binary file of the software installation package.

[0114] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.

[0115] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0116] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a general hardware platform, and of course, by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0117] It should be understood that the terms used herein are only for the purpose of describing specific example embodiments and are not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "one", "an" and "said" as used herein may also be meant to include plural forms. The terms "include", "comprise", "contain", and "have" are inclusive, and therefore specify the existence of stated features, steps, operations, elements and / or parts, but do not exclude the existence or addition of one or more other features, steps, operations, elements, parts, and / or combinations thereof. The method steps, processes, and operations described herein are not interpreted as necessarily requiring them to be performed in the specific order described or illustrated, unless the execution order is clearly indicated. It should also be understood that additional or alternative steps may be used.

[0118] The foregoing is merely a specific embodiment of the present invention, which enables those skilled in the art to understand or implement the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A software architecture for an automobile, characterized in that: The application layer includes an application layer and a basic layer, wherein the application layer includes: The function module layer includes a plurality of function modules and is used to run the function strategies of the plurality of function modules; A customized interface layer, used for converting and verifying interface variables transmitted between the application layer and the basic layer, so as to achieve decoupling of the application layer and the basic layer; The platform configuration layer is used to adaptively configure the data variable memory and code of the functional module according to the platform type supported by the automobile controller, wherein the platform type includes one of the following: embedded architecture, automotive open system architecture.

2. The software architecture according to claim 1, characterized in that: The platform configuration layer includes: A memory mapping allocation module, used for secondary allocation of initial data of variable types of function modules in a data dictionary file, wherein the function modules include strategy logic information, data information and model attribute information, the strategy logic information is stored in a model file, the data information and model attribute information are stored in the data dictionary file, and the data information includes variable types; An automobile open system framework configuration module, used to configure first configuration information of the automobile open system in the functional module and the custom interface layer; The data dictionary configuration module is used to select a target configuration template from a plurality of data dictionary configuration templates preset in the data dictionary files of the functional module and the custom interface layer, wherein the target configuration template is used to generate a code adapted to the platform type.

3. The software architecture according to claim 2, characterized in that: The memory mapping allocation module presets a plurality of secondary allocation strategies, and each secondary allocation strategy corresponds to a division requirement of an actual memory space.

4. The software architecture according to claim 2, characterized in that: The data dictionary file has a plurality of data unit types preset, wherein each data unit type includes the following fields: variable type, variable dimension, variable minimum value, and variable maximum value.

5. The software architecture according to claim 2, characterized in that: The first configuration information is located in the model file, and the first configuration information includes function information, running entity, port mapping and xml option information corresponding to the automobile open system.

6. The software architecture according to claim 2, characterized in that: The target configuration template contains second configuration information required for simulation and code generation, and the second configuration information includes: model diagnosis content, system target configuration, and code generation source style.

7. The software architecture according to claim 1, characterized in that: The customized interface layer includes: A signal input interface, including a first variable rewriting switch, for receiving an input variable of the base layer, converting a data type of the input variable, judging the validity of the input variable, rewriting the input variable according to a switch state of the first variable rewriting switch, and inputting the variable into the functional module layer; The signal output interface includes a second variable rewriting switch, which is used to rewrite the output variable according to the switch state of the second variable rewriting switch, convert the data type, and output the output variable to the basic layer.

8. The software architecture according to claim 1, characterized in that: Each functional module in the functional module layer has a built-in calibration variable, and the calibration variable is used to indicate whether the corresponding functional module is enabled.

9. A method for generating automotive software code, characterized in that: The software architecture of the vehicle as claimed in any one of claims 1 to 8 comprises: Receiving software installation information, wherein the software installation information is used to indicate a platform type supported by a vehicle controller running the software code; Generate application layer code and / or an interface description arxml file of an automotive open system architecture according to the platform type; If it is an embedded architecture, the application layer code and the basic layer code are used to compile and generate a binary file of the software installation package; if it is an automotive open system architecture, the arxml file is used to compile and generate the RTE code for running the virtual bus interface, and the application layer code, the RTE code, and the basic layer code are used to compile and generate a binary file of the software installation package.

10. The method according to claim 9, characterized in that Generating application layer code according to the platform type includes: Loading a model file of a custom interface layer of the platform type; If the platform type is an embedded architecture, select the configuration template in the data dictionary file of the functional module layer as an embedded configuration, select an embedded code generation template; use the embedded configuration and the embedded code generation template to generate a first application layer code; If the platform type is an automotive open system architecture, select the configuration template in the data dictionary file of the functional module layer as the automotive open system configuration, select the automotive open system code generation template, and use the automotive open system configuration and the automotive open system code generation template to generate the second application layer code and the arxml file of the custom interface layer.

11. The method according to claim 9, characterized in that After compiling the application layer code and the base layer code to generate a binary file of the software installation package, the method further includes: Flashing the binary file to the vehicle controller; A calibration variable is configured for each functional module, wherein the calibration variable is used to indicate whether the corresponding functional module is enabled.

12. A device for generating automobile software code, characterized in that: The software architecture of the vehicle as claimed in any one of claims 1 to 8 comprises: A receiving module, used to receive software installation information, wherein the software installation information is used to indicate a platform type supported by a vehicle controller running a software code; A first generating module, used for generating application layer code and / or an interface description file arxml of an automotive open system architecture according to the platform type; The second generation module is used to compile and generate a binary file of the software installation package using the application layer code and the basic layer code if it is an embedded architecture; if it is an automotive open system architecture, use the arxml file to compile and generate the RTE code for running the virtual bus interface, and use the application layer code, the RTE code, and the basic layer code to compile and generate a binary file of the software installation package.

13. A storage medium, characterized in that: The storage medium stores a vehicle program, wherein the vehicle program is configured to execute the method described in any one of claims 9 to 11 when running.

14. An electronic device comprising a memory and a processor, characterized in that: The memory stores a vehicle program, and the processor is configured to run the vehicle program to execute the method described in any one of claims 9 to 11.

Images