Autosar-based software architecture implementation method and device

Abstract

The invention discloses a software architecture implementation method and device based on Autosar, and relates to the technical field of vehicle networks. Comprising the following steps: constructing a target configuration interface and a target communication mechanism; the target configuration interface indicates parameter information needing to be configured for each module in the multiple modules of each layer in the Autosar software architecture, and the target communication mechanism can realize information sharing among the layers in the Autosar software architecture, so that interaction among the layers in the Autosar software architecture can be achieved by the scheme provided by the invention; the problem that in a traditional scheme, the operation process of obtaining the target file is tedious is solved, the operation process of a client can be simplified, and the work efficiency of obtaining the target file is improved.

Description

Technical Field

[0001] The present application relates to the field of vehicle network technology, and in particular to a method and device for implementing an AUTOSAR software architecture. Background Art

[0002] Autosar (Automotive open system architecture) is a standardized software architecture jointly established by major global automobile manufacturers and auto parts suppliers. The software architecture includes four layers: application layer, middleware and basic software layer, and microcontroller abstraction layer. A feature of the Autosar software architecture is that each layer can only use the interface provided by the next layer and provide the corresponding interface to the upper layer.

[0003] Currently, Autosar can be used to generate embedded code and XML format files used to describe software components in the Autosar architecture, namely Swc.Arxml files, but the steps are extremely cumbersome. On the one hand, it is necessary to complete the configuration of each layer by importing and exporting files; if the configuration process of the lower layer uses the configuration file of the upper layer, it is necessary to export the configuration file of the upper layer and then import it into the corresponding upper layer to realize the configuration of this layer; on the other hand, it is necessary to connect the ports of different levels through multiple configurations and manually connect equations to finally output the target file. Therefore, how to simplify the customer's operating process and obtain the target file simply and efficiently has become a technical problem that needs to be solved urgently. Summary of the invention

[0004] Based on the above problems, this application provides an implementation method based on the Autosar software architecture to open up the interaction between various levels in the Autosar software architecture, simplify the customer's operation process, and obtain the target file simply and efficiently.

[0005] The embodiments of the present application disclose the following technical solutions:

[0006] The first aspect of the present application provides a method for implementing the Autosar software architecture, including:

[0007] Constructing a target configuration interface; the target configuration interface indicates parameter information that needs to be configured for each module in a plurality of modules included in each layer of the Autosar software architecture;

[0008] Construct a target communication mechanism; the communication mechanism is used to realize information sharing between layers in the Autosar software framework.

[0009] In an optional implementation, the building target configuration interface includes:

[0010] Building a configuration standard based on the configuration item name, format and data structure of each module in the multiple modules included in each layer;

[0011] Based on the configuration standard, the target configuration interface is generated.

[0012] In an optional implementation, the method further includes:

[0013] A corresponding adapter is configured for each of the multiple modules included in each layer; the configurator is used to translate the configuration information of the corresponding module into a file format corresponding to the target configuration interface, and to perform data interaction with the configuration interface.

[0014] In an optional implementation, the constructing a target communication mechanism includes:

[0015] Defining a communication interface; the communication interface includes a message format, a data structure and a communication protocol;

[0016] Constructing a message delivery system; the message delivery system is used to implement sending, receiving and processing of messages;

[0017] Declare module information; the module information includes module identification, module function, module communication interface and data information that the module needs to obtain.

[0018] In an optional implementation, when the configuration information of a module at any layer in the Autosar software architecture changes, the method further includes:

[0019] If the configuration information change means that the module adds new configuration information, the new configuration information is loaded into the corresponding target system, and the target system is run; the target system is a system that implements the target function based on the Autosar software architecture;

[0020] If the configuration information change refers to a change in existing configuration information in the module, the configuration information before the change is replaced by the changed configuration information, and the target system is run.

[0021] In an optional implementation, the method further includes:

[0022] When the configuration information of a module of any layer in the Autosar software architecture changes, determining a module related to the module among a plurality of modules included in each layer of the Autosar software architecture;

[0023] Based on the change of the module configuration information, the configuration information of the modules related to the module is synchronously changed, and the target system is operated based on the changed configuration information.

[0024] In an optional implementation, the method further includes:

[0025] A configuration management system is introduced; the configuration management system is used to manage the configuration information of all modules in the Autosar software architecture.

[0026] In an optional implementation, the declaration module information includes:

[0027] Define a module identifier; the module identifier is used to uniquely indicate the corresponding module;

[0028] Register module information; the module information includes module function and parameter information;

[0029] Based on the compiler, the module identification and the module information are registered to the communication interface.

[0030] In an optional implementation, the method further includes:

[0031] Introduce an error handling mechanism; the error handling mechanism includes error reporting standards, error log recording, error log tracking, error message prompts and regular error troubleshooting, etc.; the error reporting standards include error message format, error message identification, error message classification and error level.

[0032] The second aspect of the present application provides a device based on the Autosar software architecture, including:

[0033] An interface configuration module is used to construct a target configuration interface; the target configuration interface indicates parameter information that needs to be configured for each of the multiple modules included in each layer of the Autosar software architecture;

[0034] The communication mechanism building module is used to build a target communication mechanism; the communication mechanism is used to realize information sharing between various layers in the Autosar software framework.

[0035] A third aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method introduced in any implementation manner of the first aspect.

[0036] A fourth aspect of the present application provides an electronic device, including:

[0037] a memory having a computer program stored thereon;

[0038] A processor is used to execute the computer program in the memory to implement the steps of the method introduced in any implementation manner of the first aspect.

[0039] Compared with the prior art, this application has the following beneficial effects:

[0040] The present application discloses a method for implementing the Autosar software architecture, including: constructing a target configuration interface and a target communication mechanism. Since the target configuration interface indicates the parameter information that needs to be configured for each module in the multiple modules included in each layer of the Autosar software architecture, the modules in each layer of the Autosar software framework can be configured with parameters based on a unified target configuration port; information sharing between the layers in the Autosar software framework can be achieved based on the target communication mechanism; therefore, the solution in the present application can open up the interaction between the various levels in the Autosar software architecture, simplify the operation process of the customer, and obtain the target file simply and efficiently; it solves the problem that the configuration of each layer needs to be completed by file import and export in the traditional solution, and the problem that the ports of different layers need to be connected through multiple configurations and manual connection equations in order to obtain the target file. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0042] Figure 1 A schematic diagram of the software and hardware matching before and after the appearance of Autosar provided in an embodiment of the present application;

[0043] Figure 2 A schematic diagram of the structure of an Autosar software architecture provided in an embodiment of the present application;

[0044] Figure 3 A flowchart of a method for implementing the Autosar software architecture provided in an embodiment of the present application;

[0045] Figure 4 A schematic diagram of a data structure of a configuration item provided in an embodiment of the present application;

[0046] Figure 5 A schematic diagram of the structure of an EAS plug-in package provided in an embodiment of the present application;

[0047] Figure 6 A schematic diagram of a developer mode provided in an embodiment of the present application;

[0048] Figure 7 A schematic diagram of the structure of an EAS tool provided in an embodiment of the present application;

[0049] Figure 8A schematic diagram of the structure of a device based on the Autosar software architecture provided in an embodiment of the present application. DETAILED DESCRIPTION

[0050] Autosar is a standardized software architecture; compared with the traditional ECU (Electronic Control Unit) software architecture, the high degree of abstraction of Autosar's layered architecture greatly reduces the coupling between software and hardware in automotive embedded systems.

[0051] Figure 1 A schematic diagram of the software and hardware matching before and after the appearance of Autosar is provided in an embodiment of the present application. Figure 1 (a) shows the matching between software and hardware before the emergence of Autosar; Figure 1 (b) shows the matching between software and hardware after the emergence of Autosar. Figure 1 As shown, Figure 1 (a) The software layer and the hardware layer are highly coupled; Figure 1 In (b), the software layer and the hardware layer are connected through the RTE layer (also referred to as middleware in this application). The middleware reduces the coupling between the software layer and the hardware layer, so that the automotive application software developed according to the AUTOSAR standard has better scalability and portability, and can realize the reuse of existing software, which greatly reduces the repetitive work in the automotive software development process, improves work efficiency and reduces the cost of automotive electronic software development.

[0052] Figure 2 A schematic diagram of the structure of the Autosar software architecture provided in the embodiment of the present application. Figure 2 As shown, the current Autosar software architecture on the market generally includes four layers, namely MCAL layer (Micaro-Controller Abstraction Layer, microcontroller abstraction layer), BSW layer (Basic Software, basic software layer), RTE layer (Run-time environment, runtime environment) and APP layer (Application Software Layer, application software layer).

[0053] Specifically, the MCAL layer is located at the bottom layer of the basic software in the Autosar software architecture. It can directly access the underlying drivers of the central processing registers and internal peripherals, customize parameters and generate code framework classes, configure parameters, and generate configuration code, which can facilitate users to integrate microcontroller drivers based on specific chips with the Autosar software architecture.

[0054] The BSW layer provides services for each software module, but does not actually complete the functions. The BSW layer specifically includes the service layer, ECU abstraction layer, microcontroller abstraction layer and complex driver layer. Users can graphically configure various parameters according to the host computer and generate configuration code with one click. By importing the files of the user application layer, functions such as data mapping and task hard defects can be realized, and RTE layer code that meets the requirements of the Autosar interface can be generated.

[0055] The RTE layer is the middleware in this application, which provides an environment for the operation of the APP layer, facilitates better separation of software and hardware, so that the APP can be reused, and provides standardized interface communication services for the application layer and the basic software layer.

[0056] The APP layer, also known as the application layer, can help users create application layer unit modules, build application frameworks, and define interface relationships and internal behaviors of SWC (Software Component, application layer unit modules).

[0057] As mentioned above, Autosar can currently be used to generate embedded code and XML format files used to describe software components in the Autosar architecture, namely Swc.Arxml files, but the steps are extremely cumbersome. For example, to develop a CDD (Complex Device Driver or Complex Driver) module, it is necessary to configure the MCAL layer to generate embedded code, configure the BSW layer to generate Port, and configure the APP layer to generate Swc.Arxml files, that is, it is necessary to use the configuration tools of each layer to configure and output the corresponding files of the layer, especially in the case of each iteration, the configuration needs to be repeated once. Therefore, how to simplify the customer's operating process and obtain the target file simply and efficiently has become a technical problem that needs to be solved urgently.

[0058] Based on this, the present application discloses a method for implementing the Autosar software architecture, including: constructing a target configuration interface and a target communication mechanism. Since the target configuration interface indicates the parameter information that needs to be configured for each module in the multiple modules included in each layer of the Autosar software architecture, the modules in each layer of the Autosar software framework can be parameter configured based on a unified target configuration port; information sharing between the layers in the Autosar software framework can be achieved based on the target communication mechanism; therefore, the solution in the present application can open up the interaction between the various levels in the Autosar software architecture, simplify the customer's operation process, and obtain the target file simply and efficiently; it solves the problem that the traditional solution needs to complete the configuration of each layer by importing and exporting files, and that multiple configurations and manual connection equations are required to connect the ports of different layers in order to obtain the target file.

[0059] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution 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 part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0060] Figure 3 A flowchart of a method for implementing the Autosar software architecture provided in the embodiment of the present application. Figure 3 As shown, the implementation method in this application includes:

[0061] Step 301, construct a target configuration interface.

[0062] In this application, the target configuration interface indicates the parameter information that needs to be configured for each module in the multiple modules included in each layer of the Autosar software architecture; that is, the target configuration interface includes the parameter information required by all modules involved in the Autosar software architecture. The target configuration interface can be regarded as a unified configuration interface. Based on the target configuration interface, the application layer, middleware, basic software layer and microcontroller abstraction layer of the Autosar software architecture can be configured with parameters through the same configuration model, allowing the configuration information to be shared and managed between different layers of the Autosar software architecture. Based on the target configuration interface, configuration item data of different layers can be associated in a tool such as INTEWORK-EAS (ECU Autosar Software, EAS software).

[0063] In an optional implementation, the configuration item names, formats and data structures required by the modules included in each layer of the application layer, middleware, basic software layer and microcontroller abstraction layer in the Autosar software architecture can be obtained to formulate configuration standards. Figure 4 A schematic diagram of a data structure of a configuration item provided in an embodiment of the present application. Figure 4 The specific content, data format and logical relationship between each configuration item are shown in the figure. Specifically, the data item in the gray bottom frame includes 5 data items in the white bottom frame; the first data item in the white bottom frame sorted from top to bottom includes 4 data items in the black bottom frame.

[0064] Then, based on the configuration standard, a general configuration interface, i.e., the target configuration interface, is designed. The target configuration interface includes the configuration file format and the configuration management API (Application Programming Interface). The target configuration interface can cover the parameters that all modules may need to configure, and provide appropriate scalability to adapt to future demand changes. Since generating a configuration interface based on configuration standards is a relatively mature technology, this application does not go into more detail on this content.

[0065] After obtaining the target configuration interface, to realize specific functions based on the Autosar software architecture, multiple modules in each layer of the Autosar software architecture need to cooperate with each other. It can be understood that different functions require different modules to cooperate with each other, and the configuration parameters in the corresponding modules are different.

[0066] Based on this, in this application, a corresponding adapter is configured for each of the multiple modules included in each layer of the Autosar software architecture. The adapter in this application can interact with the target configuration interface. Specifically, on the one hand, the adapter can translate the configuration information of the corresponding module into the file format corresponding to the target configuration interface, ensuring that the configuration information of the modules at each layer in the Autosar software architecture can be converted into the same file format; on the other hand, it can also obtain the configuration information of other modules from the target configuration port when necessary.

[0067] It should be noted that the premise of using EAS to implement the content in step 301 is that Figure 5 4 plugin packages of EAS in the Figure 5 After the EAS plug-in package is installed, the EAS software can provide a configuration management system for the method in this application to manage the configuration information of all modules in the Autosar software architecture. The configuration management system can provide a centralized database or configuration file storage system to ensure that all modules can read and write configuration information.

[0068] The benefit of building the target configuration interface in this step is that it can improve the maintainability and readability of the configuration information of the modules at each layer of the Autosar software architecture, reduce the probability of incorrect configuration, and simplify the configuration process.

[0069] Step 302: construct a target communication mechanism.

[0070] The target communication mechanism in this application is used to realize information sharing between layers in the Autosar software framework; enable the modules of each layer in the Autosar software framework to communicate and share information directly, replacing the traditional communication form through file import and export; reduce the coupling between layers, reduce the complexity of configuration information transmission, and improve the response speed of the system.

[0071] In an optional implementation, the target communication mechanism can be constructed by the following method, specifically: the first step is to define the communication interface, that is, to formulate a set of standard communication interfaces, including message formats, data structures and communication protocols. The specific technical methods are to define interface specifications, implement sending and interface interfaces, handle error retry mechanisms and implement confirmation mechanisms. For example, after defining the integration interface in the platform, and implementing the sending and receiving interfaces in the modules of the basic software layer and the microcontroller abstraction layer, respectively, when message communication is generated, it will be in the format of a message header, a message body and a message footer, and will be communicated in data formats such as sensor data, control commands and status information. At the same time, a retry mechanism and a confirmation mechanism are used to ensure the reliability of data transmission.

[0072] The second step is to build a messaging system. The messaging system is used to send, receive, and process messages. The messaging system can be based on the publish-subscribe model, message queues, or other appropriate communication mechanisms.

[0073] The third step is to declare module information, also known as module registration and discovery. Specifically, the module registration and discovery mechanism is implemented so that the module can register the services it provides or requires, and dynamically discover the needs of other modules. Module information includes module identification, module function, module communication interface, and data information that the module needs to obtain.

[0074] Furthermore, in order to prevent the situation where a module's long corresponding task causes other modules to be unable to quickly execute corresponding tasks when there are many modules, an asynchronous communication mode can be used to ensure that the communication is non-blocking, thereby improving the responsiveness of the system.

[0075] Furthermore, different message types can be determined so that the module can understand and correctly process received messages, such as defining the types of request-response messages and the types of event notification messages.

[0076] In an optional implementation, module registration can be implemented through the following steps.

[0077] First, define the module identifier. Each module has a unique identifier to distinguish other modules. The module name or module ID can be used as the module identifier.

[0078] Then, the module information is obtained, including the module's functions, the module's communication interface, and the data information that the module needs to obtain, so that other modules can understand the module's functions and how to communicate with the module.

[0079] Finally, register the acquired module information to the communication interface through a compiler such as Eclipse. For example, use the compiler to register the module in the Product configuration of the plug-in project, export it as a plug-in project, and put it in the plug-in directory. Obtain the extension point registrar through PlatForm, and take out and store all the registered modules, so that they can be directly obtained when needed.

[0080] It should be noted that loading Figure 5 After the four plug-in packages of EAS are installed, the relevant parameters can be compiled using compilation software such as Eclipses developer mode to implement the content in step 302.

[0081] Figure 6 A schematic diagram of a developer mode provided in an embodiment of the present application. Figure 7 A schematic diagram of the structure of an EAS tool provided in an embodiment of the present application. Figure 6 The configuration in the black box is configured, and finally the Figure 7 The merged tool hierarchy shown in .

[0082] In summary, based on the implementation method based on the Autosar software architecture disclosed in this application, the EAS tool can be used to uniformly display and configure all Autosar frameworks across modules, so that embedded code and Swc.Arxml files can be directly generated in one tool, opening up the four-layer structure of Autosar. For example, taking the EAS.INTEWORK tool chain as an example, the three tools EAS.SwcDesigner, EAS.Configurator and EAS.Framework are all developed as plug-in projects and exported in the form of plug-ins to realize a customized developer mode, thereby generating all files with one click.

[0083] In an optional implementation, when the configuration information of a module at any layer in the Autosar software architecture changes, real-time detection and synchronous adjustment (also known as introducing a real-time monitoring and adjustment mechanism) can be implemented based on EAS.

[0084] Specifically, if the configuration information change of the module refers to the addition of new configuration information to the module, the new configuration information is loaded into the corresponding target system, and the target system is run. The target system is a system that implements the target function based on the Autosar software architecture. In other words, the method in the present application supports dynamically loaded configuration files, so that the target system can apply the real-time adjusted configuration without interrupting the service, ensuring that the adjusted configuration takes effect immediately, which can improve the flexibility and scalability of the system, meet the ever-changing environment and business needs, and also reduce maintenance costs.

[0085] If the configuration information change of a module refers to the change of the existing configuration information in the module, the configuration information before the change is replaced with the changed configuration information, and the corresponding target system is run. Taking the hot loading mechanism as an example, when the system is running, if a new module is added or an existing module is modified in any BSW or MCAL layer, there is no need to reconfigure or reopen the tool. The new configuration can be dynamically loaded into the system by replacing the module in the plug-in directory. This allows the new configuration to be applied to the corresponding target system without interrupting the service.

[0086] Furthermore, based on the EAS tool, it is also possible to determine the modules related to the module in the multiple modules included in each layer of the Autosar software architecture; based on the changes in the configuration information of the module, synchronously change the configuration information of the modules related to the module, and run the target system. For example, when a configuration item has a standard that triggers real-time adjustment (that is, there is a linkage relationship between the configuration item parameters and other configuration items), the system will trigger the corresponding adjustment operation. If the configuration item A is a check box, and has a linkage relationship with another node set B and configuration item C (such as when A is enabled, node set B will add n child nodes, and configuration item C becomes uneditable), then after the system processes the corresponding operation of A, it will perform the corresponding operation on all the linkage relationships.

[0087] Furthermore, an automatic adjustment algorithm can be designed to adjust system parameters in real time according to performance monitoring results, including adjusting resource allocation, optimization algorithms and caching strategies, etc., to improve the overall performance of the system.

[0088] The benefit of introducing a real-time monitoring and adjustment mechanism is that the system can dynamically respond to module configuration changes, reduce the complexity of configuration information transmission, reduce repeated identical operations, optimize runtime system performance, and improve system stability and reliability.

[0089] Furthermore, in the implementation method based on the Autosar software architecture disclosed in the present application, the configuration version control can be achieved with the help of the EAS tool. Specifically, the target system will generate multiple versions of files during the operation and configuration process. Based on the method and EAS tool disclosed in the present application, specific versions can be used in different deployment stages and environments of the target system. For example, the target system generates two versions of files during the configuration and update process, namely, version A files and version B files; wherein the generation time of version A files is earlier than the generation time of version B files. The meaning of using specific versions in different deployment stages and environments of the target system is that when running version B files, you can stop running version B files and resume running version A files; you can also compare the differences between version A and version B to determine the differences between the two versions of files. The advantage of the above solution is that it can reduce the risk of misconfiguration, ensure configuration consistency between different levels, and simplify the process of system upgrade and maintenance.

[0090] In an optional implementation, an error handling mechanism may be introduced based on the EAS tool on the Autosar software architecture implementation method disclosed in the present application.

[0091] The error handling mechanism includes error reporting standards, error log recording, error log tracking, error message prompts, and regular error troubleshooting. The error reporting standards include error message format, error message identification, error message classification, and error level. Specifically,

[0092] (1) Establish a clear set of error reporting standards to ensure that all error messages can be identified and classified. This step helps users to more easily understand and handle incorrect configurations. For example, the error message format can be unified and the configuration information of errors can be displayed in a table. One row records one error message. The parameters of each column are time, name, error ID, type, and error description. Define a corresponding ID for each type of error, and one ID corresponds to one type of error. According to the severity of the error, define different error levels, such as serious errors, general errors, and warnings. Different error levels correspond to different processing methods and priorities. Provide detailed error information and provide enough contextual information in the error message so that developers can understand the source and cause of the error. Avoid redundant and ambiguous error messages, ensure that error messages are clear and accurate, and avoid using vague or uncertain words.

[0093] (2) Error logging and tracking tools. Implement error logging in the target system and write error information into a log file. The log should contain detailed information about the error, such as timestamp, error code, trigger location, etc. Introducing error tracking tools helps developers locate and debug errors more easily, which helps developers and support staff to troubleshoot problems more easily.

[0094] (3) Feedback error messages that are easy for users to understand. When the system reports an error to the user, the language in the error report is translated into a language that is easy for the user to understand, avoiding throwing overly technical error messages to the user. This helps users better understand the problem and take appropriate actions.

[0095] (4) Error recovery mechanism: Implement an error recovery mechanism to enable the system to continue running as much as possible after an error occurs without causing a crash.

[0096] (5) Periodic review: Regularly review the error logs and alarm records in the system, as well as the effectiveness of error handling. Continuously improve the error handling mechanism based on feedback to ensure that the system can respond to errors in a timely and accurate manner.

[0097] The advantage of introducing a global error handling mechanism to uniformly handle errors and exceptions that may occur at each level is that it can shorten the troubleshooting time, improve the fault tolerance of the system, simplify the troubleshooting process, and reduce the adverse impact on users.

[0098] In summary, the method disclosed in this application breaks the communication barrier between the upper and lower layers in the Autosar architecture, can simplify the repeated import and configuration operations of customers, generate the final file with one click, and improve the usability of the tool; can improve the software reuse, especially the cross-platform reuse; can reduce the amount of manual code, reduce the burden of testing and verification, and improve the software quality; provide a standardized data exchange format to facilitate cooperation and communication between companies, etc. It fundamentally solves the connectivity problem between the upper and lower layers, and brings higher efficiency and flexibility to the development, configuration and maintenance of the system. It can promote collaborative work at all levels, thereby improving the efficiency and maintainability of the entire system.

[0099] Based on the method provided in the foregoing embodiment, the present application also provides a device based on the Autosar software architecture. Figure 8 A schematic diagram of a device based on the Autosar software architecture provided in the embodiment of the present application. Figure 8 As shown, the implementation device 800 in the present application includes:

[0100] The interface configuration module 801 is used to construct a target configuration interface; the target configuration interface indicates parameter information that needs to be configured for each module in the multiple modules included in each layer of the Autosar software architecture;

[0101] The communication mechanism construction module 802 is used to construct a target communication mechanism; the communication mechanism is used to realize information sharing between various layers in the Autosar software framework.

[0102] In an optional implementation, the interface configuration module 801 includes:

[0103] A standard construction unit, used to construct a configuration standard based on the configuration item name, format and data structure of each module in the multiple modules included in each layer;

[0104] The interface generation unit is used to generate the target configuration interface based on the configuration standard.

[0105] In an optional implementation, the interface configuration module 801 further includes:

[0106] The adapter loading unit is used to configure a corresponding adapter for each module in the multiple modules included in each layer; the configurator is used to translate the configuration information of the corresponding module into a file format corresponding to the target configuration interface and to perform data interaction with the configuration interface.

[0107] In an optional implementation, the communication mechanism building module 802 includes:

[0108] An interface definition unit, used to define a communication interface; the communication interface includes a message format, a data structure and a communication protocol;

[0109] A message system construction unit, used to construct a message delivery system; the message delivery system is used to implement the sending, receiving and processing of messages;

[0110] The module information generating unit is used to declare the module information; the module information includes the module identification, module function, module communication interface and data information that the module needs to obtain.

[0111] In an optional implementation, the implementation device 800 further includes a monitoring adjustment module, and the monitoring adjustment module includes:

[0112] The first unit is used for loading the new configuration information into the corresponding target system and running the target system if the configuration information change means that the module adds new configuration information; the target system is a system that realizes the target function based on the Autosar software architecture;

[0113] The second unit is used to replace the configuration information before the change with the changed configuration information if the configuration information change means that the existing configuration information in the module has been changed, and to run the target system.

[0114] In an optional implementation, the monitoring adjustment module further includes:

[0115] The third unit is used to determine the module related to the module among the multiple modules included in each layer of the Autosar software architecture when the configuration information of the module of any layer in the Autosar software architecture changes;

[0116] The fourth unit is used to synchronously change the configuration information of the modules related to the module based on the change of the configuration information of the module, and run the target system based on the changed configuration information.

[0117] In an optional implementation manner, the implementation device 800 further includes:

[0118] The system management module is used to introduce a configuration management system; the configuration management system is used to manage the configuration information of all modules in the Autosar software architecture.

[0119] In an optional implementation, the module information generating unit includes:

[0120] A first subunit is used to define a module identifier; the module identifier is used to uniquely indicate a corresponding module;

[0121] The second subunit is used to register module information; the module information includes module function and parameter information;

[0122] The third subunit is used to register the module identifier and the module information to the communication interface based on the compiler.

[0123] In an optional implementation manner, the implementation device 800 further includes:

[0124] The error handling module is used to introduce an error handling mechanism; the error handling mechanism includes error reporting standards, error log recording, error log tracking, error message prompts and regular error troubleshooting, etc.; the error reporting standards include error message format, error message identification, error message classification and error level.

[0125] Based on the AUTOSAR software architecture implementation method and device provided in the aforementioned embodiments, the present application also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, it implements some or all of the steps in the aforementioned AUTOSAR software architecture implementation method.

[0126] Based on the method and device for implementing the Autosar software architecture provided in the above-mentioned embodiment, the present application further provides an electronic device, including:

[0127] a memory having a computer program stored thereon;

[0128] A processor is used to execute the computer program in the memory to implement some or all of the steps in the method based on the Autosar software architecture provided in the above embodiment.

[0129] It should be noted that each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. The device embodiment described above is merely schematic, in which the unit described as a separate component may or may not be physically separated, and the component prompted as a unit may or may not be a physical unit, that is, it may be located in one place, or it may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative work.

[0130] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A method for implementing the Autosar software architecture, wherein the Autosar software architecture includes an application layer, a middleware, a basic software layer and a microcontroller abstraction layer, characterized in that: The method comprises: Constructing a target configuration interface; the target configuration interface indicates parameter information that needs to be configured for each module in a plurality of modules included in each layer of the Autosar software architecture; Construct a target communication mechanism; the communication mechanism is used to realize information sharing between layers in the Autosar software framework.

2. The method according to claim 1, characterized in that The target configuration interface includes: Building a configuration standard based on the configuration item name, format and data structure of each module in the multiple modules included in each layer; Based on the configuration standard, the target configuration interface is generated.

3. The method according to claim 2, characterized in that The method further comprises: A corresponding adapter is configured for each of the multiple modules included in each layer; the configurator is used to translate the configuration information of the corresponding module into a file format corresponding to the target configuration interface, and to perform data interaction with the configuration interface.

4. The method according to claim 1, characterized in that: The target communication mechanism is constructed, including: Defining a communication interface; the communication interface includes a message format, a data structure and a communication protocol; Constructing a message delivery system; the message delivery system is used to implement sending, receiving and processing of messages; Declare module information; the module information includes module identification, module function, module communication interface and data information that the module needs to obtain.

5. The method according to claim 3, characterized in that: When the configuration information of a module at any layer in the Autosar software architecture changes, the method further comprises: If the configuration information change means that the module adds new configuration information, the new configuration information is loaded into the corresponding target system, and the target system is run; the target system is a system that implements the target function based on the Autosar software architecture; If the configuration information change refers to a change in existing configuration information in the module, the configuration information before the change is replaced by the changed configuration information, and the target system is run.

6. The method according to claim 5, characterized in that The method further comprises: When the configuration information of a module of any layer in the Autosar software architecture changes, determining a module related to the module among a plurality of modules included in each layer of the Autosar software architecture; Based on the change of the module configuration information, the configuration information of the modules related to the module is synchronously changed, and the target system is operated based on the changed configuration information.

7. The method according to claim 1, characterized in that The method further comprises: A configuration management system is introduced; the configuration management system is used to manage the configuration information of all modules in the Autosar software architecture.

8. The method according to claim 4, characterized in that The declaration module information includes: Define a module identifier; the module identifier is used to uniquely indicate the corresponding module; Register module information; the module information includes module function and parameter information; Based on the compiler, the module identification and the module information are registered to the communication interface.

9. The method according to claim 1, characterized in that: The method further comprises: Introduce an error handling mechanism; the error handling mechanism includes error reporting standards, error log recording, error log tracking, error message prompts and regular error troubleshooting, etc.; the error reporting standards include error message format, error message identification, error message classification and error level.

10. A device based on Autosar software architecture, characterized in that: The device comprises: An interface configuration module is used to construct a target configuration interface; the target configuration interface indicates parameter information that needs to be configured for each of the multiple modules included in each layer of the Autosar software architecture; The communication mechanism building module is used to build a target communication mechanism; the communication mechanism is used to realize information sharing between various layers in the Autosar software framework.

Images