Software architecture of automobile, and method and device for generating automobile software code

Abstract

The application provides a software architecture of an automobile, and a method and device for generating automobile software code, wherein the software architecture of the automobile comprises an application layer and a basic layer, the application layer comprises a function module layer comprising a plurality of function modules for running function strategies of the plurality of function modules, a custom interface layer for converting and checking interface variables transmitted between the application layer and the basic layer to realize decoupling of the application layer and the basic layer, and a platform configuration layer for adaptively configuring data variable memories and codes of the function modules according to platform types supported by an automobile controller, wherein the platform types comprise one of an embedded architecture and an automobile open system architecture. According to the embodiment of the application, traditional embedded codes and automobile open system codes can be simultaneously compatible, traditional architectures and automobile open system architectures can be compatible, and platformization of application layer software is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of automobile software, in particular to a software architecture of an automobile, and a method and device for generating automobile software code. BACKGROUND

[0002] In the related art, due to the difference in the demand for automobiles and the diversity of automobile hardware and configuration, the combination of automobile embedded software functions is diversified, secondly, the memory distribution of the controller is changed due to the change of the controller hardware and chip, and thirdly, the traditional software architecture and AUTOSAR (Automotive Open System Architecture) software architecture coexist in the current automobile control software, which leads to the fact that the application layer software cannot be universal, each new project needs to be connected with the whole vehicle function and assessed in advance, and the application layer software also needs to be changed accordingly, the reliability of the software needs to be further verified, and a large amount of time and manpower is required.

[0003] In view of the above problems in the related art, no efficient and accurate solution has been found. SUMMARY

[0004] The present application provides a software architecture of an automobile, and a method and device for generating automobile software code, to solve the technical problems in the related art.

[0005] According to an embodiment of the present application, a software architecture of an automobile is provided, comprising an application layer and a basic layer, wherein the application layer comprises: a function module layer comprising a plurality of function modules, configured to run a function strategy of the plurality of function modules; a customized interface layer, configured to convert and verify an interface variable transmitted between the application layer and the basic layer, so as to decouple the application layer and the basic layer; and a platform configuration layer, configured to adaptively configure a data variable memory and code of the function module according to a platform type supported by an automobile controller, wherein the platform type comprises one of: an embedded architecture and an automotive open system architecture.

[0006] Optionally, the platform configuration layer comprises: a memory mapping allocation module, configured to perform secondary allocation on initial data of variable types of the function modules in the data dictionary file, wherein the function modules comprise strategy logic information, data information and model attribute information, the strategy logic information is stored in a model file, the data information and the model attribute information are stored in the data dictionary file, and the data information comprises variable types; an automobile open system framework configuration module, configured to configure first configuration information of an automobile open system in the function modules and the custom interface layer; and a data dictionary configuration module, configured to select a target configuration template from a plurality of data dictionary configuration templates preset in the data dictionary file of the function modules 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 is preset with a plurality of secondary allocation strategies, and each secondary allocation strategy corresponds to a division requirement of an actual memory space.

[0008] Optionally, the data dictionary file is preset with a plurality of data unit types, and each data unit type comprises 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 comprises function information corresponding to the automobile open system, a running entity, port mapping and xml option information.

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

[0011] Optionally, the custom interface layer comprises: a signal input interface comprising a first variable rewriting switch, configured to receive an input variable of the basic layer, convert a data type of the input variable, judge validity of the input variable, rewrite the input variable according to a switch state of the first variable rewriting switch, and input the input variable to the function module layer; and a signal output interface comprising a second variable rewriting switch, configured to rewrite an output variable according to a switch state of the second variable rewriting switch, convert a data type, and output the output variable to the basic layer.

[0012] Optionally, each function module in the function module layer is built-in with a calibration variable, and the calibration variable is used to represent whether the corresponding function module is enabled.

[0013] According to another embodiment of the present application, a method for generating software code of a vehicle is provided, which is applied in the software architecture of the vehicle as described in the above embodiments, and 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; generating 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, compiling the binary file of a software installation package by using the application layer code and a basic layer code; if it is an automotive open system architecture, compiling a virtual bus interface RTE code by using the arxml file, and compiling the binary file of the software installation package by using the application layer code, the RTE code, and the basic layer code.

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

[0015] Optionally, after the binary file of the software installation package is compiled by using the application layer code and the basic layer code, the method further comprises: flashing the binary file to the vehicle controller; and configuring a calibration variable of each functional module, wherein the calibration variable is used to represent whether the corresponding functional module is enabled.

[0016] According to another embodiment of the present application, a device for generating software code of a vehicle is provided, which is applied in the software architecture of the vehicle as described in the above embodiments, and comprises: a receiving module, 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; a first generating module, configured to generate application layer code and / or an interface description arxml file of an automotive open system architecture according to the platform type; and a second generating module, configured to, if it is an embedded architecture, compile the binary file of a software installation package by using the application layer code and a basic layer code; if it is an automotive open system architecture, compile a virtual bus interface RTE code by using the arxml file, and compile the binary file of the software installation package by using the application layer code, the RTE code, and the basic layer code.

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

[0018] Optionally, the apparatus further comprises: a flashing module, configured to, after the second generating module compiles the application layer code and the base layer code to generate a binary file of a software installation package, flash the binary file to the automotive controller; and a configuration module, configured to configure a calibration variable of each functional module, wherein the calibration variable is used to represent whether the corresponding functional module is enabled.

[0019] According to another aspect of the embodiments of the present application, a storage medium is also provided, which comprises a stored program, and the program performs the steps described above when running.

[0020] According to another aspect of the embodiments of the present application, an electronic device is also provided, which comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete mutual communication through the communication bus; the memory is used to store an automotive program; and the processor is used to execute the steps in the above method by running the program stored in the memory.

[0021] The embodiments of the present application also provide an automotive program product comprising instructions, which, when running on a computer, cause the computer to execute the steps in the above method.

[0022] The present application has the following beneficial effects:

[0023] 1. By adding a platform configuration layer and a customized interface layer in the application layer, the application layer and the base layer can be decoupled, different memory allocations can be matched without changing the application layer functional module model and code, traditional embedded code and Autosar code can be compatible, traditional architecture and Autosar architecture can be compatible, and the platformization of the application layer software is realized.

[0024] 2. The platform configuration can selectively generate traditional embedded code or code meeting the requirements of Autosar, so that the compatibility of traditional architecture and Autosar architecture is realized.

[0025] 3. The memory mapping module in the same specification platform configuration layer performs secondary allocation to the variable type of the function module, thereby realizing the reconfiguration of the memory of the data variable in the application layer software.

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

[0027] The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application. In the drawings:

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

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

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

[0031] Figure 4 is a complete diagram of the software architecture according to an embodiment of the application;

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

[0033] Figure 6 is a work flow diagram of the software architecture of a car according to an embodiment of the application;

[0034] Figure 7 is a structure block diagram of a device for generating software code of a car according to an embodiment of the application. DETAILED DESCRIPTION

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

[0036] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0037] Example 1

[0038] The method embodiment provided in Embodiment 1 of this application can be executed in an automobile, controller, or similar processing device. Taking its operation in an automobile as an example, Figure 1 This is a hardware structure block diagram of a car according to an embodiment of the present invention. For example... Figure 1 As shown, a car may include one or more ( Figure 1 Only one is shown in the image. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. Optionally, the vehicle may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned automobile. For example, the automobile may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0039] The memory 104 can be used to store automotive programs, such as application software programs and modules, like the automotive program corresponding to the automotive software code generation method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the automotive program stored in the memory 104, thus implementing the aforementioned method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the vehicle via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0040] The transmission device 106 is configured to receive or send data via a network. The network can include a wireless network provided by a communication provider of the vehicle. In one example, the transmission device 106 includes a network interface controller (NIC) configured to connect to other network devices via a base station to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module configured to communicate with the Internet via a wireless manner.

[0041] In the embodiment, a software architecture of a vehicle is provided, Figure 2 Fig. 1 is a schematic diagram of a software architecture of a vehicle according to an embodiment of the present application, as shown in the figure, the software architecture includes an application layer and a foundation layer, wherein functions in the application layer are implemented by software components (SWC), and the components encapsulate part or all of vehicle electronic functions. Figure 2

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

[0043] The function module layer 20 includes a plurality of function modules, and is configured to run function strategies of the plurality of function modules. The function strategy refers to a software program corresponding to each function module, and each software program is composed of a code segment, and execution of the code segment can implement a corresponding software function.

[0044] Optionally, the function modules can include, but are not limited to, power-on and power-off modules, instrument information processing modules, sensor detection modules, driving mode selection modules, media control modules, and the like.

[0045] Each function module includes strategy logic information, data information, and model attribute information. The strategy logic information and the data information and the model attribute information are stored separately. The strategy logic information is stored in a model file, and the data information and the model attribute information are stored in a data dictionary file. The data information includes data unit types, variable types, and preset values of variables.

[0046] The custom interface layer 22 is configured to convert and verify interface variables transmitted between the application layer and the foundation layer, so as to decouple the application layer and the foundation layer. The interface layer is used for communication. The communication content includes Data Elements and Operations. The Data Elements use a sender-receiver (Sender / Receiver) communication mode, and the Operations use a client-server (Client / Server) communication mode. ​

[0047] The platform configuration layer 24 is configured to adaptively configure the data variable memory and code of the function modules according to a platform type supported by the automobile controller, wherein the platform type comprises one of the following: an embedded architecture and an Autosar architecture.

[0048] In the embedded architecture, the base layer comprises a basic software layer, and in the Autosar architecture, the base layer comprises an RTE (Real-Time Environment) and a basic software layer.

[0049] According to the above software architecture, the function module layer comprises a plurality of function modules, the custom interface layer is configured to convert and check the interface variables transmitted between the application layer and the base layer, so as to decouple the application layer and the software layer, and the platform configuration layer is configured to adaptively configure the data variable memory and code of the function modules according to a platform type supported by the automobile controller, wherein the platform type comprises one of the following: an embedded architecture and an Autosar architecture. By adding the platform configuration layer and the custom interface layer in the application layer, the application layer and the base layer can be decoupled, different memory allocations can be matched without changing the function module model and code of the application layer, the traditional architecture and the Autosar architecture can be compatible, the traditional embedded code and the Autosar code can be generated, and the platformization of the application layer software is realized.

[0050] In one embodiment of the embodiment, the platform configuration layer comprises: a memory mapping allocation module configured to perform secondary allocation on initial data of variable types in a data dictionary file of the function modules, wherein the function modules comprise strategy logic information, data information and model attribute information, the strategy logic information is stored in a model file, the data information and the model attribute information are stored in the data dictionary file, and the data information comprises variable types; an Autosar framework configuration module configured to configure first configuration information of Autosar in the function modules and the custom interface layer; and a data dictionary configuration module configured to select a target configuration template from a plurality of data dictionary configuration templates preset in a data dictionary file of the function modules and the custom interface layer, wherein 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 the model file and comprises function information specific to Autosar, software running entities, port mapping and xml option information, etc.

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

[0053] When traditional embedded code needs to be generated, the code field configuration in the Autosar framework is not required, and the data dictionary configuration template is selected as the traditional configuration file through the platform configuration to generate the source code, header file and / or A2l file corresponding to the traditional configuration file. When the code corresponding to the Autosar architecture needs to be generated, the code field in the Autosar needs to be configured through the Autosar framework configuration module, and the first configuration information is configured to modify the specific code field in the Autosar to the code corresponding to the first configuration information, which can specifically include the corresponding code of the function information of the module, the software running entity information, the mapping rule of the interface in the model and the Autosar interface, and preferably, this part of the model configuration information is automatically implemented through a script, that is, the script automatically modifies the code. After the code modification is completed, that is, the configuration is completed, the Autosar configuration of the data dictionary configuration template is generated through the platform configuration to generate the source code, header file, A2l file and Arxml file (AUTOSAR description file). Only through the platform configuration, the traditional embedded code or the code meeting the requirements of Autosar can be generated, so that the traditional architecture and the Autosar architecture can be compatible at the code level.

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

[0055] In addition to the variable information, the above-mentioned data dictionary file also predefines a plurality of 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 configured by the data dictionary configuration module in the platform configuration to select the configuration template, and the traditional embedded code or the code meeting the requirements of Autosar can be generated, so that the traditional architecture and the Autosar architecture are compatible at the code level.

[0056] In one example, the memory mapping allocation module presets multiple secondary allocation strategies, each corresponding to a division requirement of actual memory space, and if the online calibration space is sufficient, all variable types of the target functional module of each calibration type are remapped to the online calibration space; if the online calibration space is insufficient, the variable types of the first calibration type of the target functional module are remapped to the online calibration space, and the variable types of the second calibration type of the target functional module are 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 a first file and a second file, for example, the model of the functional module is stored in a *.slx file, and the data of the functional module is stored in a data dictionary *.sldd. The data dictionary file presets multiple memory types according to the combination of data unit types (observation, calibration type 1, calibration type 2) and variable types (Boolean, 8-bit length, 16-bit length, 32-bit length), such as Boolean observation (Signal_Bool), 8-bit length calibration type 1 (Parameter1_8Bits), 16-bit length calibration type 2 (Parameter2_16Bits), and the like, and all data is selected and added with initial values and other attributes as needed when created. Each variable type in the data dictionary file is initially defined during the presetting process, and is subsequently secondarily allocated by the memory mapping module in the platform configuration layer. Figure 3 is a schematic diagram of the secondary memory allocation of the embodiment of the present application, and the variable types show four observations (BOOL, 8BITS, 16BITS, 32BITS), four calibration types 1 (BOOL, 8BITS, 16BITS, 32BITS), and four calibration types 2 (BOOL, 8BITS, 16BITS, 32BITS). When using controller A, if the online calibration space is sufficient, all variable types of the calibration type 1 and the calibration type 2 are remapped to the online calibration space, and when using controller B, if the online calibration space is insufficient, a part of the calibration needs to be placed in the non-volatile storage location, i.e., the offline calibration space, then all variable types of the calibration type 1 are remapped to the online calibration space, and all variable types of the 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, for example, into calibration type 1, calibration type 2, calibration type 3, and the like, and when performing secondary allocation, the memory space can also be aligned according to the data type, and the same data type is uniformly stored, thereby optimizing the memory space.

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

[0060] When the function module is modeled using simulink, the software and data are stored separately, that is, the software model is stored in a *.slx file, and the data is stored in a data dictionary *.sldd. The data dictionary file pre-provides a plurality of data dictionary configuration templates in addition to data information, such as a traditional configuration and an Autosar configuration. Each model template includes model diagnosis, system target configuration information, code generation source code style, and the like. Specifically, the traditional configuration contains setting the system target TLC file to ert.tlc, source code style such as C code, code standard such as C99 standard, chip setting, and the like. The main difference between the Autosar configuration and the traditional configuration is that the system target file is the system target TLC file Autosar.tlc, and the compilation tool used by the tool chain is different.

[0061] Optionally, the data dictionary file pre-provides a plurality of memory types according to the combination of data unit types (observation quantity, calibration type 1, calibration type 2) and variable types (Boolean quantity, 8-bit length, 16-bit length, 32-bit length), such as a Boolean type observation quantity (Signal_Bool), an 8-bit length calibration type 1 (Parameter1_8Bits), a 16-bit length calibration type 2 (Parameter2_16Bits), and the like. All data is selected and added with initial values and other attributes as needed when created.

[0062] Optionally, each variable type in the data dictionary file is defined in the pre-setting process, and is then allocated again by a memory mapping module in the platform configuration layer, so as to realize the reconfiguration of the memory of the data variable in the application layer software.

[0063] In one example, the custom interface layer includes: a signal input interface including a first variable rewriting switch, configured to receive an input variable of the base layer, convert a data type of the input variable, judge validity of the input variable, rewrite the input variable according to a switch state of the first variable rewriting switch, and input to a corresponding code position in the function module layer; and a signal output interface including a second variable rewriting switch, configured to rewrite an output variable according to a switch state of the second variable rewriting switch, convert a data type, and output the output variable to a 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 includes required basic layer input variable names, input data types, input variable rewriting switch names, input variable rewriting value names, basic layer output variable names, output data types, output variable rewriting switch names, output variable rewriting value names, and the like. A model file and a data dictionary file of the custom layer are automatically generated through a Matlab script, and the model file and the data dictionary file are realized in a code form.

[0065] In one example, each function module in the function module layer is built-in with a calibration variable, which is used to represent whether the corresponding function module is enabled.

[0066] Each function module has a calibration variable to determine whether the function module is enabled. When the application layer code and the basic layer software code are uniformly compiled to generate a flashable binary file and are flashed into a controller, the combination of different project functions is directly realized through calibration, without the need to change the application layer logic function, so that the platformization of the application layer software is realized, and the stability and reliability of the software in the project development process are also realized.

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

[0068] In the embodiment, a method for generating automobile software code is provided, which is applied to the software architecture of the automobile described in the above embodiment, Figure 5 is a flowchart of a method for generating automobile software code according to the embodiment of the application, as shown in Figure 5 The flowchart includes the following steps:

[0069] In step S502, software installation information is received, wherein the software installation information is used to indicate a platform type supported by a controller of a running automobile software code;

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

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

[0072] In one example, generating the application layer code according to the platform type includes: loading a model file of a customized 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 preset code file of the embedded configuration, selecting an embedded code generation template, and the code generation template is a preset code generation file; generating first application layer code by using the embedded configuration and the embedded code generation template, 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 a configuration template in a data dictionary file of the functional module layer as an Autosar configuration, selecting an Autosar code generation template, and generating second application layer code and an arxml file of the customized interface layer by using the Autosar configuration and the Autosar code generation template.

[0073] When the configuration option is the AUTOSAR architecture, the configuration template in the data dictionary file of each module is set as the AUTOSAR configuration, the AUTOSAR code generation template is selected, and the c code conforming to the AUTOSAR standard is generated, and the interface model generates the AUTOSAR description file arxml file;

[0074] When the configuration option is not the AUTOSAR architecture, the configuration template in the data dictionary file of each module is set as the traditional embedded configuration, the embedded code generation template is selected, and the traditional c code is generated.

[0075] Optionally, after the application layer code and the base layer code are used to compile to generate a binary file of the software installation package, the binary file is further written to the automobile controller, and a calibration variable of each functional module is configured, where the calibration variable is used to represent whether the corresponding functional module is enabled.

[0076] After all the codes are generated, the binary file is compiled together with the base software layer (RTE (optional) + base software layer) code to generate a flashable binary file, and is flashed into the controller, and a calibration engineer selects functional modules according to the configuration of a project and a vehicle type and opens corresponding calibration switches, so as to finally complete control software of the corresponding project.

[0077] Figure 6 is a workflow diagram of the software architecture of the automobile of the embodiment of the present application, including three stages, wherein the first stage, the model preparation stage, includes functional module modeling and custom interface layer module modeling;

[0078] Functional module modeling, if there are new system requirements, then the functional module modeling is performed according to the requirements, when using simulink modeling, the corresponding code is created using the model and data separately, taking functional module 1 as an example, when modeling, the model file Func1.slx and the data dictionary file Func1.sldd are created and stored, wherein the model file stores the strategy logic of the module, and the data dictionary file stores all 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 are preset with multiple formats, such as observation type, online calibration type, offline calibration type, etc., the preset format is selected when data is created, and the remaining attribute information is filled 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, so that the memory distribution of the variables in the software can be adjusted. Generally speaking, after a functional module corresponding code modeling is completed, all variable types in the related software code are determined, and the memory space corresponding to the software code is also determined, if the memory space changes greatly, the variable type needs to be changed in the data dictionary file, the code needs to be regenerated, and the testing needs to be performed again, which brings a large amount of work. However, when the controller hardware or chip changes, the memory distribution may change, for example, the memory space for online calibration in the A project is 320K, and the memory space for online calibration in the B project is only 160K. At this time, if the actual space of the calibration variable in the software is 200K, the conventional scheme needs to change the variable type in the software to meet the requirements. In the application layer platform scheme, the memory mapping file is added in the platform configuration, for example, the variable 200K in the software is subdivided into online calibration 160K and offline calibration 40K, in the A project, when the online calibration space is sufficient, the online calibration and offline calibration in the data dictionary file are remapped as online calibration, in the B project, when the online calibration space is not sufficient, the online calibration and offline calibration in the data dictionary file are remapped respectively, and the offline calibration is divided into another memory space, so that the variable type in the data dictionary does not need to be changed, and the code does not need to be regenerated, and the redistribution of the variable memory is realized;

[0081] More specifically, the above-mentioned 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 can be aligned in memory space according to data type, and the same data type is uniformly stored, thereby optimizing memory space;

[0082] The modeling of the custom interface layer module is mainly different for different projects, for example, the A project uses an A project custom interface, including signal input, signal output and the like, wherein the signal input mainly introduces the base layer variable, and simultaneously converts the data type, judges the validity of the input variable, and increases the variable rewriting switch, the output signal at the output module increases the rewriting switch of the upper layer output variable, and converts the data type, and the signal output outputs the variable to the base layer;

[0083] Optionally, the modeling of the custom interface layer module can be automatically realized through a script, and in the project configuration folder, there are two variable management tables of SignalInput.xlsx and SignalOutput.xlsx, which contain the required base layer input variable name, input data type, input variable rewriting switch name, input variable rewriting value name, base layer output variable name, output data type, output variable rewriting switch name, output variable rewriting value name and the like, and the model file and data dictionary file of the custom interface are generated through a Matlab script to realize automatic modeling;

[0084] Optionally, the data dictionary file (*.sldd) of all the function modules and the custom interface module contains the model configuration of simulink in addition to the logic strategy, and the model configuration information has a plurality of templates, including but not limited to a traditional embedded configuration template and an AUTOSAR configuration template, each template includes model diagnosis, code generation source type, code template and the like, and in the subsequent code generation stage, the configuration template is selected according to the project configuration, so as to generate traditional embedded code or AUTOSAR code, and the traditional architecture and the AUTOSAR architecture are compatible.

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

[0086] The project uses MATLAB for project management and modeling, and a pop-up window is provided for the user to select a specific project in the model loading process;

[0087] According to the selected project, a customized interface layer model is loaded, according to the project selected by the user, a corresponding distribution mechanism is selected and written into a memory mapping file, and it is judged whether it is an Autosar architecture, if yes, Autosar framework configuration is performed, and the data dictionary configuration is updated to Autosar configuration; if it is not an Autosar architecture, the data dictionary configuration is updated to a traditional embedded configuration. The third stage is a code generation stage, and each module code is generated according to the configuration options output in the second stage.

[0088] When the data dictionary configuration is Autoar configuration and the corresponding Autosar framework configuration is performed, the c code conforming to the AUTOSAR standard is generated, and the interface description file is generated;

[0089] When the data dictionary configuration option is not an AUTOSAR architecture (embedded architecture), the traditional c code is generated.

[0090] The embodiment provides a platform software architecture, a system and a code generation mode for an automotive embedded software application layer. A customized interface layer is added between application layer software (ASW) and basic layer software (BSW), and application layer and basic layer are decoupled; platform configuration files are used to match different memory mapping rules and change configuration options, so that different standard code styles are generated, traditional architectures and AUTOSAR architectures are compatible, application layer software is platformized, and the development cost and maintenance cost of automotive software are reduced.

[0091] Through the description of the above implementation, those skilled in the art can clearly understand that the method according to the above embodiment can be realized by means of software and necessary general hardware platform, of course, it can also be realized by hardware, but in many cases, the former is a better implementation. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a plurality of instructions for making a terminal device (which can be a mobile phone, computer, server, or network device) execute the method described in each embodiment of the present application.

[0092] Embodiment 2

[0093] In this embodiment, an automotive software code generation device is also provided, which is used to implement the above embodiments and preferred embodiments, and has been described. 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, hardware, or a combination of software and hardware is also possible and is contemplated.

[0094] Figure 7 is a structural block diagram of a device for generating software code of a vehicle according to an embodiment of the present application. The device is applied to a software architecture of a vehicle as shown in the above embodiment, and comprises: Figure 7

[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 software code;

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

[0097] a second generating module 74, configured to, if the platform type is an embedded architecture, compile the application layer code and basic layer code to generate a binary file of a software installation package; or, if the platform type is an Autosar architecture, compile the arxml file to generate a virtual bus interface RTE code, and compile the application layer code, the RTE code, and the basic layer code to generate a binary file of a software installation package.

[0098] Optionally, the first generating module comprises: a loading unit, configured to load a model file of a customized interface layer of the platform type; a first generating unit, configured to, if the platform type is an embedded architecture, select an embedded configuration in a configuration template in a data dictionary file of the functional module layer, and select an embedded code generation template; generate first application layer code by using the embedded configuration and the embedded code generation template; and a second generating unit, configured to, if the platform type is an Autosar architecture, select an Autosar configuration in a configuration template in a data dictionary file of the functional module layer, and select an Autosar code generation template; generate second application layer code and an arxml file of the customized interface layer by using the Autosar configuration and the Autosar code generation template.

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

[0100] It should be noted that each of the above modules can be implemented by software or hardware, and for the latter, the following implementation manners can be used, but are not limited thereto: all of the above modules are located in the same processor; or, each of the above modules is located in a different processor in an arbitrary combination.

[0101] Embodiment 3 ​

[0102] The embodiment of the present application also provides a storage medium, wherein the storage medium stores an automobile program, and the automobile program is arranged to execute the steps in any of the method embodiments.

[0103] Optionally, in the embodiment, the storage medium is arranged to store the automobile program for executing the following steps:

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

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

[0106] S3, if the embedded architecture, compiling the application layer code and the basic layer code to generate a binary file of the software installation package; if the Autosar architecture, using the arxml file to compile to generate a virtual bus interface RTE code, and using the application layer code, the RTE code and the basic layer code to compile to generate a binary file of the software installation package.

[0107] Optionally, in the embodiment, the storage medium can include but is not limited to a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk and various storage media that can store the automobile program.

[0108] The embodiment of the present application also provides an electronic device, comprising a memory and a processor, wherein the memory stores an automobile program, and the processor is arranged to execute the automobile program to execute the steps in any of the method embodiments.

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

[0110] Optionally, in the embodiment, the processor can be arranged to execute the following steps through the automobile program:

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

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

[0113] S3, if the embedded architecture, using the application layer code and base layer code compiled to generate a binary file of software installation package; if Autosar architecture, using the arxml file to compile to generate a virtual bus interface RTE code, using the application layer code, the RTE code, and base layer code compiled to generate a binary file of software installation package.

[0114] Optionally, specific examples in the embodiments can refer to the examples described in the foregoing embodiments and optional implementation manners, and the embodiments will not be described here again.

[0115] The device embodiments described above are only schematic, wherein the units illustrated as separate components may or may not be physically separate, and the components illustrated as units may or may not be physical units, that is, they may be located in one place or distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the embodiments.

[0116] Through the description of the foregoing embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a general hardware platform, and of course can also be implemented by hardware. Based on such understanding, the above technical solutions can be embodied in the form of a software product, which can be stored in a computer readable storage medium, such as a ROM / RAM, a magnetic disk, an optical disk, etc., and includes a plurality of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute the methods described in each embodiment or some parts of the embodiments.

[0117] It should be understood that the terms used herein are for the purpose of describing specific example embodiments only and are not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprises", "comprising", "includes", "including" and "has" are inclusive and therefore specify the presence of stated features, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order in which they are described, unless specifically indicated as such. It is also to be understood that additional or alternative steps can be employed.

[0118] The foregoing is considered as illustrative only of the principles of the application. Numerous modifications and changes will readily occur to those skilled in the art, and it is intended to embrace all such modifications and changes that fall within the scope of the application. Accordingly, the application is not to be restricted in scope to the specific embodiments disclosed herein but is to be accorded the full scope that the principles and novel features request appropriately granted.

Claims

1. A software architecture for an automobile, characterized in that, comprise an application layer and a base layer, wherein the application layer comprises: a function module layer comprising a plurality of function modules, configured to run a function strategy of the plurality of function modules; a custom interface layer, configured to convert and check interface variables transmitted between the application layer and the base layer, so as to decouple the application layer and the base layer; a platform configuration layer, configured to adaptively configure data variable memory and code of the function module according to a platform type supported by the automotive controller, wherein the platform type comprises an embedded architecture and an automotive open system architecture, the embedded architecture comprises a base software layer, and the automotive open system architecture comprises a real-time environment (RTE) and a base software layer; the platform configuration layer comprises: a memory mapping allocation module, configured to perform secondary allocation on initial data of a variable type of a function module in a data dictionary file, wherein the function module comprises strategy logic information, data information and model attribute information, the strategy logic information is stored in a model file, the data information and the model attribute information are stored in the data dictionary file, and the data information comprises a variable type; an automotive open system framework configuration module, configured to configure first configuration information of an automotive open system in the function module and the custom interface layer; and a data dictionary configuration module, configured to select a target configuration template from a plurality of data dictionary configuration templates preset in a data dictionary file of the function module and the custom interface layer, the target configuration template being used to generate code adapted to the platform type.

2. The software architecture of claim 1, wherein, The memory mapping allocation module is preset with a plurality of secondary allocation strategies, and each secondary allocation strategy corresponds to a division requirement of an actual memory space.

3. The software architecture of claim 1, wherein, The data dictionary file is preset with a plurality of data unit types, and each data unit type comprises the following fields: a variable type, a variable dimension, a variable minimum value and a variable maximum value.

4. The software architecture of claim 1, wherein, The first configuration information is located in the model file, and the first configuration information comprises function information corresponding to the automotive open system, a running entity, port mapping and xml option information.

5. The software architecture of claim 1, wherein, The target configuration template comprises second configuration information required for simulation and code generation, and the second configuration information comprises model diagnosis content, system target configuration and code generation source code style.

6. The software architecture of claim 1, wherein, The custom interface layer comprises: a signal input interface comprising a first variable rewriting switch, configured to receive an input variable of the base layer, convert a data type of the input variable, judge validity of the input variable, rewrite the input variable according to a switch state of the first variable rewriting switch, and input the input variable to the function module layer; a signal output interface comprising a second variable rewriting switch, configured to rewrite an output variable according to a switch state of the second variable rewriting switch, convert a data type, and output the output variable to the base layer.

7. The software architecture of claim 1, wherein, Each function module in the function module layer is internally provided with a calibration variable, and the calibration variable is used to represent whether the corresponding function module is enabled.

8. A method of generating automotive software code, characterized by, application in the software architecture of the automobile of any one of claims 1 to 7, comprising: receiving software installation information, wherein the software installation information is used to indicate a platform type supported by a car controller running software code; generating application layer code and / or an interface description arxml file of a car open system architecture according to the platform type; if the platform type is an embedded architecture, compiling the application layer code and a base layer code to generate a binary file of a software installation package; if the platform type is a car open system architecture, using the arxml file to compile to generate a virtual bus interface RTE code, and using the application layer code, the RTE code, and a base layer code to compile to generate a binary file of a software installation package.

9. The method of claim 8, wherein, The generating of the application layer code according to the platform type comprises: loading a model file of a customized 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, and selecting an embedded code generation template; using the embedded configuration and the embedded code generation template to generate first application layer code; if the platform type is a car open system architecture, selecting a configuration template in a data dictionary file of the functional module layer as a car open system configuration, and selecting a car open system code generation template; using the car open system configuration and the car open system code generation template to generate second application layer code and an arxml file of the customized interface layer.

10. The method of claim 8, wherein, After the compiling of the binary file of the software installation package using the application layer code and the base layer code, the method further comprises: writing the binary file to the car controller; configuring a calibration variable of each functional module, wherein the calibration variable is used to represent whether the corresponding functional module is enabled.

11. An apparatus for generating automotive software code, characterized by The software architecture is applied to a car according to any one of claims 1 to 7, comprising: a receiving module configured to receive software installation information, wherein the software installation information is used to indicate a platform type supported by a car controller running software code; a first generating module configured to generate application layer code and / or an interface description arxml file of a car open system architecture according to the platform type; a second generating module configured to, if the platform type is an embedded architecture, compile the application layer code and a base layer code to generate a binary file of a software installation package; if the platform type is a car open system architecture, use the arxml file to compile to generate a virtual bus interface RTE code, and use the application layer code, the RTE code, and a base layer code to compile to generate a binary file of a software installation package.

12. A storage medium, characterized by The storage medium stores a car program, wherein the car program is set to execute the method in any one of claims 8 to 10 when running. 13.An electronic device comprising a memory and a processor, the electronic device characterized by, The storage medium stores a car program, wherein the car program is set to execute the method in any one of claims 8 to 10 when running.

Images