AUTOSAR architecture and complex driver access method thereof
By introducing the CDD abstraction layer, the problem of difficult interaction and integration between complex drivers and application layer software components is solved, and the application layer is enabled to call CDD complex drivers through the AUTOSAR standardized interface, which improves development efficiency and reduces change costs.
Patent Information
- Application Number
- CN202411295872.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-14
- Publication Date
- 2025-01-21
AI Technical Summary
In the prior art, there is difficulty in integrating the interaction between complex drivers and application layer software components, resulting in low development efficiency and high change cost, and the inability to directly call CDD complex drivers through the AUTOSAR standardized interface.
Introducing the CDD abstraction layer, providing the AUTOSAR standardized interface to the application layer through the CDD abstraction layer software component, and matching it with the CDD complex driver interface to achieve hierarchical decoupling, connecting the upper software component interface and linking the lower CDD complex driver layer provided software program.
It enables software components in the application layer to call CDD complex drivers through the AUTOSAR standardized interface, reducing additional development costs caused by software changes, reducing developer workload, and thus improving development efficiency.
Smart Images

Figure CN119336415A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of software development technology, and in particular to an AUTOSAR architecture and a complex driver access method thereof. Background Art
[0002] AUTOSAR stands for AUTomotive Open System Architecture, which defines a set of distributed, function-driven automotive electronic software development methods and a standardized software architecture for electronic control units, so that it can be applied to different automotive platforms.
[0003] like Figure 1 As shown in the figure, in the AUTOSAR architecture, the basic software is divided into: service layer, basic software ECU abstraction layer, microcontroller abstraction layer, and RTE runtime environment layer. In addition, it also includes a complex driver (CDD) program layer. CDD is different from other standardized basic software modules. It is a software entity that is not subject to AUTOSAR standardization. It can directly access the microcontroller abstraction layer software program to enable specific interrupts or complex microcontroller peripherals, external device communication transceivers, ASICs (Application Specific Integrated Circuits), etc. to meet special functional and timing requirements. CDD can access other software components (SoftWare Component, SWC) through interfaces or basic software module APIs, or be accessed by other software components.
[0004] In actual development work, due to the high degree of liberalization and low degree of standardization of complex drivers, the interaction between them and application-layer software components with highly standardized software interfaces is difficult to integrate. Generally, application-layer software components require developers to manually write macro definition codes to match and map and call complex drivers. If the program is modified, the macro definition needs to be manually re-written, which is troublesome and time-consuming, resulting in low software development efficiency and high change costs. Summary of the invention
[0005] The present application provides an AUTOSAR architecture and a complex driver access method thereof, so as to solve the above-mentioned technical problems in the prior art.
[0006] According to a first aspect of the present application, there is provided an AUTOSAR architecture, comprising: an application layer, a CDD abstraction layer and a CDD complex driver layer;
[0007] The application layer includes at least one software component;
[0008] The CDD abstract layer is located between the application layer and the CDD complex driver layer, and includes a CDD abstract layer software component, which is used to provide an AUTOSAR standardized interface to the software components in the application layer and match the AUTOSAR standardized interface mapping, and match the CDD complex driver interface in the CDD complex driver layer, so as to assist the software components in the application layer in calling the CDD complex driver;
[0009] The CDD complex driver layer includes a CDD complex driver, and the CDD complex driver includes at least one encapsulated software program that can be called by an upper layer.
[0010] In some implementations, the CDD abstract layer software component is further used to create and save a mapping relationship between the CDD abstract layer interface and the AUTOSAR standardized interface, including:
[0011] By importing the description file of the software component in the AUTOSAR development tool, an AUTOSAR standardized interface for the software component to call the CDD complex driver is obtained;
[0012] A mapping relationship between the AUTOSAR standardized interface and the CDD abstract layer interface is established and saved in the AUTOSAR development tool.
[0013] In some implementations, the CDD abstract layer software component is further used to create and save a correspondence between the CDD abstract layer interface and the CDD complex driver interface, including:
[0014] The corresponding relationship between the CDD abstract layer interface and the CDD complex driver interface is established and saved through an integrated compilation tool, and an executable software program is generated.
[0015] In some implementations, the CDD abstraction layer interface in the CDD abstraction layer software component corresponding to the CDD complex driver interface is an editable open interface.
[0016] In some implementations, the CDD abstraction layer software component is further configured to provide the software component of the application layer with internal behaviors and RTE event types required by the software component.
[0017] In some implementations, the internal behavior required by the software component includes at least one of the following:
[0018] Data sending node, data receiving node, synchronous caller and asynchronous caller.
[0019] In some implementations, the RTE event types include the following:
[0020] Call events and / or run events periodically.
[0021] According to a second aspect of the present application, a complex driver access method based on the above AUTOSAR architecture is provided, the method comprising:
[0022] receiving a call request of the software component through an AUTOSAR standardized interface provided to the software component in the application layer, wherein the call request is a request for calling a CDD complex driver;
[0023] Determine a matching CDD abstract layer interface by using a mapping relationship between the CDD abstract layer interface and the AUTOSAR standardized interface;
[0024] Obtaining a CDD complex driver interface corresponding to the matched CDD abstract layer interface by using the corresponding relationship between the CDD abstract layer interface and the CDD complex driver interface in the CDD complex driver layer;
[0025] By calling the obtained CDD complex driver interface, the software component in the application layer is assisted to call at least one software program in the CDD complex driver.
[0026] According to a third aspect of the present application, an electronic device is provided, comprising: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the steps of the above-mentioned complex driver access method based on the AUTOSAR architecture are implemented.
[0027] According to a fourth aspect of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned complex driver access method based on the AUTOSAR architecture are implemented.
[0028] In summary, the AUTOSAR architecture and complex driver access method, electronic device, and computer-readable storage medium provided by the present application have at least the following beneficial effects:
[0029] The CDD abstract layer matches the standard interface mapping required by the software components of the application layer, and matches the CDD complex driver interface. Through layered decoupling, the upper-layer software component interface is connected and the software program provided by the lower-layer CDD complex driver layer is linked. The software components of the application layer are converted from being unable to call the CDD complex driver through the AUTOSAR standardized interface to being able to call the CDD complex driver through the AUTOSAR standardized interface. When the software components of the application layer change, the developer does not need to rewrite the macro definition code for interface mapping matching, which reduces the additional development costs caused by software changes, reduces the workload of developers, and thus improves development efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0030] In order to more clearly illustrate the technical solutions of the specific implementation methods of the present application, the drawings required for use in the prior art or the specific implementation methods of the present application will be briefly introduced below in conjunction with the accompanying drawings. It is obvious that the drawings described below are some implementation methods of the present application. For those skilled in the art, other drawings or solutions can be obtained based on these drawings without paying any creative work.
[0031] Figure 1 is a schematic diagram of the AUTOSAR architecture in the prior art;
[0032] Figure 2 A call hierarchy diagram for a software component at the application layer in the prior art to call a CDD complex driver;
[0033] Figure 3 A schematic diagram of the AUTOSAR architecture in one embodiment of the present application;
[0034] Figure 4 A call hierarchy diagram of a software component of the application layer calling a CDD complex driver in one embodiment of the present application;
[0035] Figure 5 This is a flowchart of a complex driver access method based on the AUTOSAR architecture in one embodiment of the present application;
[0036] Figure 6 This is a structural diagram of an electronic device in one embodiment of the present application. DETAILED DESCRIPTION
[0037] In order to make the above and other features and advantages of the present application more clear, the present application is further described below in conjunction with the accompanying drawings. It should be understood that the specific embodiments given herein are for the purpose of explaining to those skilled in the art and are only exemplary and not restrictive.
[0038] In the following description, many specific details are set forth to provide a thorough understanding of the present application. However, it is apparent to those skilled in the art that specific details need not be adopted to practice the present application. In other cases, well-known steps or operations are not described in detail to avoid blurring the present application.
[0039] Currently based on Figure 1 The general process of embedded software development based on the AUTOSAR architecture is as follows:
[0040] ① Use AUTOSAR development tools to configure various software components with established functions and established configuration items, and you can also configure user-defined software components. If a customized software component wants to interact with other software components with established functions, it needs to have an interface that complies with the AUTOSAR standard and be mapped and connected.
[0041] ② Use AUTOSAR development tools to generate the source code corresponding to the above configured software components.
[0042] ④ Use the integrated compilation tool to compile the source code generated above. In this process, you can also add some other codes (such as application layer code, or CDD code, which is handwritten and can be generated by other development tools), and finally convert the source code into an executable software program.
[0043] In the actual development process, although the application layer code and CDD code are added to the project for compilation, the other added codes do not completely match the code generated in "②". The application layer software, other established software components, and CDD software cannot interact and call each other, so step ③ is added before step ④.
[0044] ③Import the Arxml description file corresponding to the interface information of the application layer code into the AUTOSAR development tool, map and match it with the software component interface configured in "②", and then generate the source code containing the mapping relationship (i.e., the RTE runtime environment layer).
[0045] Here in step ③, because the CDD complex driver is handwritten and not subject to the AUTOSAR standard, it is impossible to convert these handwritten contents into Arxml description files, and there is no way to import its interface information into the AUTOSAR development tool (the development tool only accepts imports in the form of Arxml, and the code cannot be imported). The CDD complex driver side cannot perform interface mapping matching in the AUTOSAR development tool. At present, the mapping relationship is handwritten by developers manually writing macro definition codes, and the functions called at the standard interface of the application layer software component program are replaced with the functions provided by the complex driver. Therefore, when the application layer software that calls the CDD complex driver changes and needs to be re-integrated with the CDD complex driver, since the application layer software component code is regenerated, it is necessary to manually re-write the macro definition code so that the new application layer software component interface needs to be re-matched with the CDD complex driver, resulting in low development efficiency and high software change costs. Based on this, the present application provides a new AUTOSAR architecture.
[0046] refer to Figure 3 The present application provides an AUTOSAR architecture, including: an application layer, a CDD abstraction layer and a CDD complex driver layer. Specifically, the AUTOSAR architecture may also include other layers, for example, the AUTOSAR architecture may also include an RTE runtime environment layer, a service layer, a basic software ECU abstraction layer, a microcontroller abstraction layer, etc.
[0047] Among them, the application layer includes at least one software component, for example, application layer software component 1, application layer software component 2, ..., application layer software component N. The CDD abstract layer is located between the application layer and the CDD complex driver layer, and includes a CDD abstract layer software component. The CDD abstract layer software component is used to provide AUTOSAR standardized interfaces to software components in the application layer and match the AUTOSAR standardized interface mapping, as well as match the CDD complex driver interface in the CDD complex driver layer, and assist the software components in the application layer to call the CDD complex driver. Specifically, the CDD abstract layer is expressed in the AUTOSAR development tool as a software component, and the corresponding entity is software code. For example, a software component can be created in the AUTOSAR development tool as a CDD abstract layer component. It can be understood that the number of CDD abstract layer components can be one or more. Specifically, the AUTOSAR standardized interfaces required by the software components of the upper application layer are created in the CDD abstract layer, such as supply-type ports and demand-type ports, client interfaces and server interfaces, and sending interfaces and receiving interfaces.
[0048] The CDD complex driver layer includes a CDD complex driver, which includes at least one encapsulated software program that can be called by the upper layer. The software component of the application layer implements the call access to the CDD complex driver through the interface provided by the software component of the CDD abstract layer.
[0049] Specifically, the CDD abstract layer software component provides two interfaces, the upper layer is the AUTOSAR standardized interface, and the lower layer is an editable open interface with a higher degree of freedom. The CDD abstract layer software component matches the standard interface mapping required by the software components of the application layer through the AUTOSAR standardized interface, and matches the CDD complex driver interface through the editable open interface, achieving hierarchical decoupling.
[0050] The CDD abstraction layer has an interface that complies with the AUTOSAR standard and can be mapped and matched with other modules, but the actual functions behind the interface are not yet defined and will be manually edited after the code is generated. Therefore, after the interface mapping and matching is performed in the AUTOSAR development tool, when the CDD abstraction layer is converted into code, there is a source code containing the mapping and matching relationship between the CDD abstraction layer software component and other software components. At this time, the function code of the CDD complex driver can be written to give it actual functions.
[0051] The above-mentioned AUTOSAR architecture provided by the present application introduces a CDD abstraction layer. The CDD abstraction layer software components included in the CDD abstraction layer match the standard interface mapping required by the software components of the application layer at the upper level and match the CDD complex driver interface at the lower level. Through layered decoupling, the upper-level software component interfaces are connected and the software programs provided by the lower-level CDD complex driver layer are linked, so that the software components of the application layer are converted from being unable to call the CDD complex driver through the AUTOSAR standardized interface to being able to call the CDD complex driver through the AUTOSAR standardized interface. When the software components of the application layer are changed, the developer does not need to rewrite the macro definition code for interface mapping matching, thereby reducing the additional development costs caused by software changes, reducing the workload of developers and thus improving development efficiency.
[0052] For example, when the software components of the application layer change and need to be reintegrated with the CDD complex driver, it is only necessary to perform interface mapping and matching between the software components of the application layer and the CDD abstract layer in the AUTOSAR development tool, and then the tool will automatically generate the relevant runtime environment layer software code to complete the matching of the call relationship. Developers do not need to rewrite the macro definition code or manually develop and match the corresponding application layer software components and CDD complex drivers.
[0053] In one of the embodiments, the CDD abstraction layer software component is further used to provide the internal behaviors and RTE event types required by the software components of the application layer.
[0054] For example, the internal behaviors required by the software components of the application layer include: at least one of a data sending node, a data receiving node, a synchronous calling program, and an asynchronous calling program. Specifically, the internal behaviors such as the data sending node, the data receiving node, the synchronous calling program, and the asynchronous calling program required by the upper-layer software components are created in the CDD abstraction layer.
[0055] For example, the RTE event types required by the software components of the application layer include call events and / or periodic run events. Specifically, the RTE event types required by the software components of the application layer are created in the CDD abstraction layer.
[0056] By creating the internal behaviors and RTE event types required by software components in the CDD abstraction layer, the requirements for calling software components in the upper application layer are provided to ensure the effective implementation of the calls.
[0057] In one of the embodiments, the CDD abstract layer software component is further used to create and save a mapping relationship between the CDD abstract layer interface and the AUTOSAR standardized interface, including the following steps (a1) and (a2).
[0058] Step (a1): Obtain the AUTOSAR standardized interface used by the software component to call the CDD complex driver by importing the description file of the software component in the AUTOSAR development tool.
[0059] The description file of the software component is an Arxml description file, which stores the standard interface information required for the software component to call the CDD complex driver, and obtains the AUTOSAR standardized interface based on the standard interface information.
[0060] Step (a2): Establish and save the mapping relationship between the AUTOSAR standardized interface and the CDD abstract layer interface in the AUTOSAR development tool.
[0061] Specifically, the mapping and matching between the AUTOSAR standardized interfaces required by the software components of the application layer and the upper interface of the CDD abstract layer is completed in the AUTOSAR development tool. The software code of the runtime environment layer and the code of the CDD abstract layer are generated in the AUTOSAR development tool to complete the matching of the call relationship, so that the interface of the software component is connected to the upper interface of the CDD abstract layer through the RTE runtime environment layer, such as Figure 4 shown.
[0062] In one of the embodiments, the CDD abstract layer software component is also used to create and save the correspondence between the CDD abstract layer interface and the CDD complex driver interface, including: establishing and saving the correspondence between the CDD abstract layer interface and the CDD complex driver interface through an integrated compilation tool, and generating an executable software program.
[0063] Specifically, the CDD abstract layer lower layer interface is matched with the CDD complex driver interface in the integrated compilation tool, and an executable software program is compiled and generated in the integrated compilation tool to implement the software component's call to the CDD complex driver.
[0064] In one of the embodiments, the CDD abstraction layer interface in the CDD abstraction layer software component corresponding to the CDD complex driver interface is an editable open interface.
[0065] Specifically, the CDD abstraction layer software component provides an editable open interface to the CDD complex driver, and matches the CDD complex driver interface in the CDD complex driver layer based on the editable open interface. The editable open interface has a high degree of freedom, and developers can link the encapsulated CDD complex driver based on the editable open interface.
[0066] The application of the AUTOSAR architecture of this application is as follows:
[0067] 1. Basic software developers develop various modules of basic software, including CDD complex drivers;
[0068] 2. Application layer developers develop software components for the application layer, and at this time they need to call the encapsulated functions in the CDD complex driver;
[0069] 3. The application layer developer provides the Arxml description file of the application layer software component to the software integrator;
[0070] 4. Software integrators perform the following operations:
[0071] (a) Create a software component as a CDD abstraction layer component in the AUTOSAR development tool;
[0072] (b) Create the AUTOSAR standardized interfaces required by the upper application layer software components in the CDD abstraction layer;
[0073] (c) creating the internal behaviors of software components required by upper application layer software components in the CDD abstraction layer;
[0074] (d) Create the RTE event types required by the upper application layer software components in the CDD abstraction layer;
[0075] (e) Import the Arxml description file generated by the application layer software component into the AUTOSAR development tool to obtain the standard interface information of the application layer software component;
[0076] (f) Complete the interface mapping and matching between the application layer software components and the CDD abstraction layer in the AUTOSAR development tool;
[0077] (g) Generate runtime environment layer software code and CDD abstraction layer code in AUTOSAR development tools;
[0078] (h) Complete the matching between the lower layer interface of the CDD abstract layer and the complex driver interface in the integrated compilation tool;
[0079] (i) Compile and generate an executable software program in an integrated compilation tool.
[0080] 5. When the application layer software changes, repeat operations 1-4.
[0081] The CDD abstract layer software component releases a standardized AUTOSAR interface to the upper application layer software component. The interface of the application layer software component used to call the CDD complex driver software program can be obtained by importing the Arxml description file of the software component. Then, a callable interface corresponding to the application layer software component is established in the CDD abstract layer software component, and a one-to-one mapping match is made with it. At the same time, the CDD abstract layer software component releases an editable open interface for developers to link to the packaged complex driver program, so that the application layer software component is converted from being unable to call the CDD complex driver program through the AUTOSAR standardized interface to being able to call the CDD complex driver program through the AUTOSAR standardized interface.
[0082] This application provides a complex driver access method based on the above AUTOSAR architecture, such as Figure 5 As shown, the method includes the following steps S510 to S570.
[0083] S510: receiving a calling request of a software component through an AUTOSAR standardized interface provided to the software component in the application layer, where the calling request is a request for calling a CDD complex driver.
[0084] S530: Determine a matching CDD abstract layer interface by using a mapping relationship between the CDD abstract layer interface and the AUTOSAR standardized interface.
[0085] S550: Obtain a CDD complex driver interface corresponding to the matching CDD abstract layer interface by using the correspondence between the CDD abstract layer interface and the CDD complex driver interface in the CDD complex driver layer.
[0086] S570: Calling the obtained CDD complex driver interface to enable the software component in the auxiliary application layer to call at least one software program in the CDD complex driver.
[0087] The above-mentioned complex driver access method based on AUTOSAR architecture uses the interface of the CDD abstract layer to connect the upper-level software component interface and link the software program provided by the lower-level CDD complex driver layer, so that the software components of the application layer are converted from being unable to call the CDD complex driver through the AUTOSAR standardized interface to being able to call the CDD complex driver through the AUTOSAR standardized interface, thereby reducing the additional development costs caused by software changes, reducing the workload of developers and thus improving development efficiency.
[0088] The present application provides an electronic device, comprising: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the steps of implementing the above-mentioned complex driver access method based on AUTOSAR architecture are implemented.
[0089] like Figure 6 As shown, the present application provides an electronic device 600, which includes a processor 601 and a memory 602 storing computer program instructions. When the processor 601 executes the computer program instructions, each step of the above-mentioned complex driver access method based on the AUTOSAR architecture is implemented. The electronic device 600 can be a computer, a smart terminal, etc. in a broad sense.
[0090] In one embodiment, the electronic device 600 may include a processor, a memory, a network interface, a communication interface, etc. connected through a system bus. The processor of the electronic device 600 may be used to provide necessary computing, processing and / or control capabilities. The memory of the electronic device 600 may include a non-volatile storage medium and an internal memory. The non-volatile storage medium may store an operating system, a computer program, etc. The internal memory may provide an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface and the communication interface of the electronic device 600 may be used to connect and communicate with external devices through a network. When the computer program is executed by the processor, the steps of the method of the present application are executed.
[0091] In addition, the present application provides a computer-readable storage medium on which computer program instructions are stored. When the computer program instructions are executed by a processor, the steps of the above-mentioned complex driver access method based on the AUTOSAR architecture are implemented.
[0092] Those skilled in the art will appreciate that the method steps of the present application can be completed by instructing related hardware such as the electronic device 600 or a processor through a computer program, and the computer program can be stored in a non-temporary computer-readable storage medium, and the computer program causes the steps of the present application to be executed when it is executed. Depending on the circumstances, any reference to memory, storage, or other media herein may include non-volatile or volatile memory. Examples of non-volatile memory include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid state disk, etc. Examples of volatile memory include random access memory (RAM), external cache memory, etc.
[0093] The various technical features described above can be combined arbitrarily. Although all possible combinations of these technical features are not described, any combination of these technical features should be considered to be covered by this specification as long as there is no contradiction in such combination.
[0094] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein by equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.
Claims
1. An AUTOSAR architecture, characterized in that: include: Application layer, CDD abstraction layer and CDD complex driver layer; The application layer includes at least one software component; The CDD abstract layer is located between the application layer and the CDD complex driver layer, and includes a CDD abstract layer software component, which is used to provide an AUTOSAR standardized interface to the software components in the application layer and match the AUTOSAR standardized interface mapping, and match the CDD complex driver interface in the CDD complex driver layer, so as to assist the software components in the application layer in calling the CDD complex driver; The CDD complex driver layer includes a CDD complex driver, and the CDD complex driver includes at least one encapsulated software program that can be called by an upper layer.
2. The AUTOSAR architecture according to claim 1, characterized in that: The CDD abstract layer software component is also used to create and save a mapping relationship between the CDD abstract layer interface and the AUTOSAR standardized interface, including: By importing the description file of the software component in the AUTOSAR development tool, an AUTOSAR standardized interface for the software component to call the CDD complex driver is obtained; A mapping relationship between the AUTOSAR standardized interface and the CDD abstract layer interface is established and saved in the AUTOSAR development tool.
3. The AUTOSAR architecture according to claim 1 or 2, characterized in that: The CDD abstract layer software component is also used to create and save the corresponding relationship between the CDD abstract layer interface and the CDD complex driver interface, including: The corresponding relationship between the CDD abstract layer interface and the CDD complex driver interface is established and saved through an integrated compilation tool, and an executable software program is generated.
4. The AUTOSAR architecture according to claim 3, characterized in that: The CDD abstract layer interface in the CDD abstract layer software component corresponding to the CDD complex driver interface is an editable open interface.
5. The AUTOSAR architecture according to claim 1, characterized in that: The CDD abstraction layer software component is further used to provide the software component of the application layer with internal behaviors and RTE event types required by the software component.
6. The AUTOSAR architecture according to claim 5, characterized in that: The internal behavior required by the software component includes at least one of the following: Data sending node, data receiving node, synchronous caller and asynchronous caller.
7. The AUTOSAR architecture according to claim 5 or 6, characterized in that: The RTE event types include the following: Call events and / or run events periodically.
8. A complex driver access method based on the AUTOSAR architecture according to any one of claims 1 to 7, characterized in that: The method comprises: receiving a call request of the software component through an AUTOSAR standardized interface provided to the software component in the application layer, wherein the call request is a request for calling a CDD complex driver; Determine a matching CDD abstract layer interface by using a mapping relationship between the CDD abstract layer interface and the AUTOSAR standardized interface; Obtaining a CDD complex driver interface corresponding to the matched CDD abstract layer interface by using the corresponding relationship between the CDD abstract layer interface and the CDD complex driver interface in the CDD complex driver layer; By calling the obtained CDD complex driver interface, the software component in the application layer is assisted to call at least one software program in the CDD complex driver.
9. An electronic device, characterized in that: include: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, the steps of the method according to claim 8 are implemented.
10. A computer-readable storage medium, characterized in that: The computer readable storage medium has a computer program stored thereon, which implements the steps of the method according to claim 8 when executed by a processor.