Software architecture of vehicle and vehicle
By dividing multiple levels in the automotive on-board software architecture, including the sensing layer, the collaborative control layer and the execution layer, the problem of repetitive code between the application layer components is solved and development efficiency is improved.
Patent Information
- Application Number
- CN202311267480.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-09-27
- Publication Date
- 2025-03-28
AI Technical Summary
When the existing automotive on-board software architecture extends new functions, it leads to repetitive code between application-level components, reducing development efficiency.
A vehicle software architecture is proposed, which divides the application layer into multiple different levels, including sensing layer, collaborative control layer and execution layer, and data transmission and control instructions are generated and executed through interfaces at these levels.
By designing the hierarchical level with single functions and clear responsibilities, the reusability of each level of the application layer is improved, and repetitive code is reduced, thereby improving the development efficiency of the application layer.
Smart Images

Figure CN119718261A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present application belong to the field of automotive technology, and in particular, relate to a vehicle software architecture and a vehicle. Background Art
[0002] With the rapid development of automobile electrification, intelligence and networking, the in-vehicle software of automobiles has become increasingly complex and large. In order to better adapt to the increasingly complex in-vehicle software, the form of the software architecture of in-vehicle software is also evolving. Automotive Open System Architecture (AUTOSAR) is the most widely used in-vehicle software architecture. The automotive open system architecture is mainly composed of an application layer and a basic software layer. Among them, the application layer can contain multiple application layer components for realizing the logical functions of the electronic control unit (ECU). The application layer can generate functional mode requests through multiple application layer components and send the functional mode requests to the basic software layer. The basic software layer can arbitrate the functional mode requests from the application layer according to simple rules, and perform a variety of basic actions according to the arbitration results. The basic software layer can perform a variety of basic actions such as signal transmission and reception, signal analysis, fault code (DTC) storage, non-volatile memory (NVM) storage, and call code execution. Therefore, the decoupling between the application software and hardware of the vehicle can be achieved through the automotive open system architecture.
[0003] However, with the continuous development of intelligent automobile technology, vehicle terminals need to expand new functions, which requires the construction of new application layer components. However, when most application layer components implement corresponding functions, the hardware called is the same. As a result, when different application layer components call the same hardware, the same calling statements need to be written in the application layer components, which greatly increases the duplication between application layer components and reduces the development efficiency of application layer components. Summary of the invention
[0004] In view of this, an embodiment of the present application provides a vehicle software architecture and a vehicle to improve the development efficiency of application layer components.
[0005] A first aspect of an embodiment of the present application provides a vehicle software architecture, characterized in that the software architecture is applied to an application layer of an open system architecture of an automobile, the open system architecture of the automobile is applied to any controller of a plurality of controllers of the vehicle, the controller is used to control a plurality of hardware modules in the vehicle through the open system architecture of the automobile, the software architecture comprises a plurality of layers, the plurality of layers comprises a sensing layer, a collaborative control layer and an execution layer;
[0006] The sensing layer is used to obtain functional information of the vehicle;
[0007] The collaborative control layer is used to receive the functional information sent by the sensing layer through a first interface, and generate a control instruction based on the functional information; the first interface is a data transmission interface between the sensing layer and the collaborative control layer;
[0008] The execution layer is used to receive the control instruction sent by the collaborative control layer through the second interface, and control the hardware module corresponding to any controller to execute the control operation corresponding to the control instruction through the control instruction; the second interface is the data transmission interface between the execution layer and the collaborative control layer.
[0009] A second aspect of an embodiment of the present application provides a software architecture of a vehicle, characterized in that the function information includes collaborative function information, the control instruction includes a first control instruction for implementing the collaborative function, the collaborative control layer includes a coordination layer and a control layer, the control layer includes a plurality of control modules, each of the control modules corresponds to a control operation, the first interface includes a collaborative interface, and the collaborative interface is a data transmission interface between the sensing layer and the coordination layer;
[0010] The coordination layer is further used for, when the function information is collaborative function information, receiving the collaborative function information sent by the sensing layer through the collaborative interface, and generating a plurality of call information corresponding to the collaborative function information; each of the call information is used to call a control module in the control layer;
[0011] The control layer is used to receive the multiple call information sent by the coordination layer through the third interface, and generate a first control instruction corresponding to each call information through a control module corresponding to each call information; the third interface is a data transmission interface between the coordination layer and the control layer.
[0012] A third aspect of the embodiment of the present application provides a software architecture of a vehicle, characterized in that the function information includes non-cooperative function information, the control instruction includes a second control instruction for implementing the non-cooperative function, the first interface also includes a control interface, and the control interface is a data transmission interface between the sensing layer and the control layer;
[0013] The control layer is also used to, when the function information is non-cooperative function information, receive the non-cooperative function information sent by the sensor layer through the control interface, and generate the second control instruction based on the control module corresponding to the non-cooperative function information.
[0014] A fourth aspect of the embodiments of the present application provides a vehicle software architecture, characterized in that the software architecture further includes a display layer;
[0015] The display layer is used to receive display information transmitted by other layers except the display layer through a fourth interface, and perform display operations based on the display information. The fourth interface is a data transmission interface between the display layer and other layers except the display layer.
[0016] A fifth aspect of the embodiments of the present application provides a vehicle software architecture, characterized in that the software architecture further includes an intermediate layer and a basic software layer;
[0017] The intermediate layer is used to receive the control instructions sent by the collaborative control layer through the fifth interface, and transmit the control instructions to the basic software layer through the data transmission interface corresponding to the control instructions to realize at least one function control. The fifth interface is the data transmission interface between the intermediate layer and the collaborative control layer.
[0018] A sixth aspect of the embodiments of the present application provides a vehicle software architecture, characterized in that the control instruction includes a communication instruction, and the intermediate layer includes a plurality of communication control interfaces;
[0019] The intermediate layer is used to receive the communication instructions sent by the collaborative control layer through the fifth interface, and transmit the communication instructions to the basic software layer through the communication control interface corresponding to the communication instructions, so as to implement the communication function corresponding to the communication instructions.
[0020] A seventh aspect of the embodiments of the present application provides a vehicle software architecture, characterized in that the control instruction includes a configuration instruction, and the intermediate layer includes a plurality of configuration interfaces;
[0021] The intermediate layer is used to receive the configuration instruction sent by the collaborative control layer through the fifth interface, and transmit the configuration instruction to the basic software layer through the configuration interface corresponding to the configuration instruction to execute the configuration operation corresponding to the configuration instruction.
[0022] An eighth aspect of the embodiments of the present application provides a vehicle software architecture, characterized in that the control instruction further includes a storage instruction, and the intermediate layer includes a plurality of storage interfaces;
[0023] The intermediate layer is used to receive the storage instruction sent by the collaborative control layer through the fifth interface, and transmit the storage instruction to the basic software layer through the storage interface corresponding to the storage instruction to execute the storage operation corresponding to the storage instruction.
[0024] A ninth aspect of an embodiment of the present application provides a software architecture of a vehicle, characterized in that the vehicle includes a first controller and a second controller, the first automotive open system architecture in the first controller includes a first execution layer, and the second automotive open system architecture in the second controller includes a first sensing layer;
[0025] The first execution layer is used to send execution information corresponding to the control instruction to the second controller through the sixth interface, so that the second controller implements at least one control operation based on the execution information; the sixth interface is a data transmission interface between the first execution layer and the first sensing layer.
[0026] A tenth aspect of the embodiments of the present application provides a vehicle, characterized in that the vehicle includes at least two controllers, each of the controllers is installed with an automotive open system framework, and the application layer of the automotive open system framework is constructed based on the software architecture described in the embodiments of any one of the first to ninth aspects above;
[0027] The controller includes a first controller and a second controller, the first controller includes a first software architecture, the first software architecture includes a first execution layer, the second controller includes a second software architecture, and the second software architecture includes a first sensing layer;
[0028] The first controller is used to send execution information to the second controller through the first execution layer;
[0029] The second controller is used to receive the execution information sent by the first controller through the first sensing layer, so as to implement at least one control operation based on the execution information.
[0030] The eleventh aspect of an embodiment of the present application provides a controller, comprising a computer program stored in the controller and executable on the controller, wherein the controller implements the software architecture of the vehicle as described in the first aspect above when executing the computer program.
[0031] A twelfth aspect of an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the software architecture of the vehicle as described in the first aspect above.
[0032] A thirteenth aspect of an embodiment of the present application provides a computer program product, which, when executed on a computer, enables the computer to execute the software architecture of the vehicle described in the first aspect.
[0033] Compared with the prior art, the embodiments of the present application have the following advantages:
[0034] In the embodiment of the present application, a vehicle software architecture is proposed, which divides the application layer in the automobile open system architecture into multiple different levels; wherein the automobile open system architecture can be applied to any of the multiple controllers of the vehicle; the controller in the vehicle can be used to control multiple hardware modules in the vehicle through the automobile open system architecture; the multiple different levels in the software architecture can be respectively the sensing layer, the collaborative control layer and the execution layer; specifically, the sensing layer in the software architecture can be used to obtain the functional information of the vehicle; the collaborative control layer can be used to receive the functional information sent by the sensing layer through the first interface between the sensing layer and the collaborative control layer, and generate control instructions based on the received functional information; the execution layer can be used to receive the control instructions sent by the collaborative control layer through the second interface between the execution layer and the collaborative control layer; the execution layer can also control the hardware module corresponding to any controller in the vehicle to execute the control operation corresponding to the control instruction through the received control instruction. The software architecture provided in this embodiment can make the functions of each level of the application layer single and the responsibilities clear. Therefore, the software architecture provided in this embodiment can improve the reusability of each level of the application layer, reduce the duplication of each level of the application layer, and thus improve the development efficiency of the application layer. BRIEF DESCRIPTION OF THE DRAWINGS
[0035] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or prior art descriptions. Obviously, the drawings described below are only some embodiments of the present application, and for ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.
[0036] Figure 1 is a schematic diagram of an automotive open system architecture provided by an embodiment of the present application;
[0037] Figure 2 is a schematic diagram of a basic software layer provided in an embodiment of the present application;
[0038] Figure 3 is a schematic diagram of another automotive open system architecture provided by an embodiment of the present application;
[0039] Figure 4 It is a structural schematic diagram of an intermediate layer provided in an embodiment of the present application;
[0040] Figure 5 It is a schematic diagram of the data transmission relationship between two controllers provided in an embodiment of the present application. DETAILED DESCRIPTION
[0041] In order to make the technical problems, technical solutions and beneficial effects to be solved by the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.
[0042] It should be noted that when an element is referred to as being "fixed to" or "disposed on" another element, it can be directly on the other element or indirectly on the other element. When an element is referred to as being "connected to" another element, it can be directly connected to the other element or indirectly connected to the other element.
[0043] It should be understood that the orientation or position relationship indicated by terms such as "length", "width", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside" and "outside" are based on the orientation or position relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be understood as a limitation on the present application.
[0044] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of this application, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.
[0045] It should be noted that, in this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in this application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.
[0046] In the present application, "and / or" describes the association relationship of associated objects, indicating that there may be three types of relationships. For example, A and / or B may represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B may be singular or plural.
[0047] With the rapid development of automobile electrification, intelligence and networking, the form of vehicle electronic architecture is also gradually evolving. The evolution process of vehicle electronic architecture can be divided into three major stages, namely distributed, domain centralized and central centralized. Specifically, the distributed stage can also include two small stages of modularization and integration. The domain centralized stage can also include two small stages of centralization and domain fusion. The central centralized stage can also include two small stages of on-board computers and vehicle cloud computing. With the introduction of the design concept of service-oriented software architecture (SOA), major automobile companies have further accelerated the pace of research and development of the next generation of vehicle electronic architecture. Previously, automotive software development was mainly based on distributed development methods. Different application software in the distributed development are responsible for different functions. The functions of each application software are independent of each other, and each application software responsible for different independent functions will be integrated into independent hardware. The distributed development method leads to the single function of the application software, so the distributed development method makes the software iteration speed slower.
[0048] With the widespread use of distributed Automotive Open System Architecture (AUTOSAR), application software can be developed in a decentralized manner and configured in a centralized manner, and a certain degree of decoupling can be achieved between basic software and hardware under the AUTOSAR. However, since the application layer of the AUTOSAR still lacks a good application software design method, the application layer is still developed using the previous distributed development method in the existing technology.
[0049] In the development of traditional embedded software, there is often a lack of design guidance when designing software architecture. When developing software based on functional requirements, software personnel often rarely consider the scalability of the software, and generally choose the simplest implementation path, which often leads to the discovery that the current software architecture is not applicable when the functional expansion changes are made later. At this time, software personnel either supplement the extended functions by patching or readjust the software architecture and logic. However, the patching method easily makes the software bloated and chaotic, and readjusting the software architecture and logic will cause a lot of manpower and time waste. In addition, in the traditional development method, new software needs to be fully tested before it can be put on the market, so new functions and products cannot be launched quickly. In addition, the traditional development method of embedded software is also prone to the situation where the underlying logic is common but the application layer components cannot be reused, so it is easy to cause different application layer components to write the same call segment in the application layer component when calling the same hardware. Therefore, the existing software development method greatly increases the duplication between application layer components, thereby reducing the reusability of application layer components and the development efficiency of application layer components.
[0050] The technical solution of the present application is described below through specific embodiments.
[0051] Reference Figure 1 , shows a schematic diagram of an automotive open system architecture provided by an embodiment of the present application. For ease of explanation, only the parts related to this embodiment are shown. The above automotive open system architecture can be applied to any controller among multiple controllers of a vehicle. Specifically, the above controller can be an electronic control unit (ECU) in the vehicle. Figure 1 As shown, the automotive open system architecture installed in the controller 1 may include but is not limited to an application layer 11 (Application Layer), a runtime environment layer 12 (Run Time Environment, RTE) and a basic software layer 13 (Basic Software, BSW). Among them, the software architecture of the application layer 11 may include a sensing layer 111, a collaborative control layer 112 and an execution layer 113.
[0052] Among them, the application layer 11 in the automotive open system architecture can encapsulate specific application function runnable entities (RE), such as runnable entities that control hardware modules such as headlights and air conditioners. Among them, there is no direct data transmission relationship between the application layer 11 in the automotive open system architecture and the various hardware modules of the vehicle. After the application layer 11 generates a control instruction based on the function information, the control instruction can be transmitted to the runtime environment layer 12 and the basic software layer 13, and the control instruction can be transmitted to the hardware module through the basic software layer 13 to implement the control operation corresponding to the control instruction.
[0053] The runtime environment layer 12 in the automotive open system architecture is used to connect the application layer 11 and the basic software layer 13. The runtime environment layer 12 may include an operating system and some runtime libraries (RL) to support the operation of the application layer. The runtime environment layer 12 may also include multiple standard interfaces, and the standard interfaces in the runtime environment layer 12 may provide communication between the application layer and the basic software layer. The runtime environment layer 12 may provide a communication environment for the application layer 11 and the basic software layer 13.
[0054] The basic software layer 13 in the automotive open system architecture consists of multiple basic service software components with different functions. The basic software layer 13 is mainly used to provide basic software services that are not application-related, including standardized system functions and functional interfaces to support the functional implementation of the runtime environment layer and the application layer. The basic service software components in the basic software layer 13 may include, but are not limited to, system services (System Service), memory services (Memory Service), communication services (Communication Service) and other components.
[0055] In this embodiment, the sensing layer 111 in the application layer 11 can obtain the functional information of the vehicle through the collection mode preset by the user. Among them, the user can configure the collection mode of the sensing layer through the configuration file. The collection mode of the sensing layer 111 may include a periodic collection mode and a trigger collection mode. When the sensing layer 111 is configured as the periodic collection mode, the sensing layer 111 can obtain the functional information sent by the hardware module at intervals according to the time interval in the configuration file. When the sensing layer 111 is configured as the trigger collection mode, the sensing layer 111 can obtain the functional information sent by the hardware module in response to the collection instruction after receiving the collection instruction initiated by the user. Among them, the sensing layer 111 can obtain the functional information sent by the hardware module through the runtime environment layer 12 and the basic software layer 13. The functional information obtained by the sensing layer 111 may include but is not limited to the sensing information sent by the sensor, the operating status information of the hardware module, the switch instruction information initiated by the user, and other functional information.
[0056] In one possible implementation, referring to Figure 2 , shows a schematic diagram of a basic software layer provided by an embodiment of the present application. For ease of explanation, Figure 2 Only the part of the basic software layer 13 that is relevant to this embodiment is shown. Figure 2As shown, the basic software layer 13 may include but is not limited to a service layer 131 (Services Layer), a complex driver layer 132 (Complex Drivers) and an electronic control unit abstraction layer 33 (ECU Abstraction Layer). Among them, the service layer 131 can provide a variety of basic services for the application layer 11, such as system services, communication services, storage services and other basic services. The complex driver layer 132 can store complex drivers related to hardware modules, such as control area network (Controller Area Network, CAN) driver, FlexRay driver, Ethernet driver, etc. The complex driver layer 132 can transmit data to the hardware module and / or control the hardware module through the stored complex driver. The electronic control unit abstraction layer 133 can be used to provide an abstract interface for the hardware resources of the electronic control unit, such as a control area network (Controller Area Network, CAN) bus, LIN bus, FlexRay bus, etc. The application layer 11 can communicate with other external electronic control units through the electronic control unit abstraction layer 33, and share data with other electronic control units.
[0057] In a possible implementation, the sensing layer 111 can obtain the functional information of the vehicle through the basic software layer 13. Specifically, the sensing layer 111 can obtain the functional information from the service layer 131, the complex driver layer 132 and the electronic control unit abstraction layer 133 of the basic software layer 13 through the data transmission interface. It should be noted that the data transmission interface between the sensing layer 111 and the basic software layer 13 can be a one-way data transmission interface, that is, the sensing layer 111 can obtain the functional information of the vehicle from the basic software layer 13 through the data transmission interface, but the sensing layer 111 cannot send data to the basic software layer 13 through the data transmission interface. Specifically, the sensing layer 111 can obtain various communication information of the vehicle from the communication module of the electronic control unit abstraction layer 133 through the data transmission interface. The sensing layer 111 can obtain the service status information of various basic services in the service layer 131 from the service layer 131 through the data transmission interface. The sensing layer 111 can obtain the hardware information transmitted by the hardware module from the complex driver layer 132 through the data transmission interface.
[0058] In a possible implementation, the sensing layer 111 may include multiple sensing components, and each sensing component may be used to obtain different types of functional information. For example, the sensing layer 111 may include a communication information component, a hardware information component, and a service status component. The communication information component may be used to obtain various communication information of the vehicle from the communication module of the electronic control unit abstract layer 133. Among them, the sensing layer 111 may obtain communication information of different protocol types from the communication module of the electronic control unit abstract layer 133, such as communication information of the control area network protocol type, communication information of the local area Internet (Local Interconnect Network, LIN) protocol type, communication information of the Ethernet protocol type, and communication information of the FlexRay protocol type. The hardware information component may be used to obtain hardware information transmitted by the hardware module from the complex driver layer 132. The service status component may be used to obtain service status information from the service layer 131. Among them, the various sensing components in the sensing layer 111 cannot transmit functional information to each other through the data transmission interface.
[0059] In this embodiment, since there are many different types of sensors installed in the vehicle, and the data formats of various types of sensors may be different. Therefore, in the prior art, when the application component in the application layer needs to obtain the functional information sent by the sensor, the application component needs to change the data transmission interface as the currently obtained sensor type changes, so that the data transmission interface can conform to the sensor type. In this embodiment, the application layer 11 can obtain a variety of different types of functional information through the sensor layer 111, and the sensor layer 11 can send all functional information to the collaborative control layer through the first interface. By setting the sensor layer 111 for obtaining functional information, other layers in the application layer 11 do not need to change the data transmission interface as the sensor type changes. Therefore, the method provided in this embodiment improves the reusability of the data transmission interface between each layer in the application layer by setting the sensor layer in the application layer 11 to obtain the functional information of the vehicle, thereby achieving the effect of improving development efficiency.
[0060] In this embodiment, after acquiring the functional information, the sensing layer 111 may send the acquired functional information to the collaborative control layer 112 through the first interface. The first interface is a data transmission interface between the sensing layer 111 and the collaborative control layer 112. It should be noted that, in this embodiment, the first interface may be a unidirectional data transmission interface, that is, the sensing layer 111 may transmit functional information to the collaborative control layer 112 through the first interface, but the collaborative control layer 112 may not transmit data to the sensing layer 111.
[0061] In this embodiment, after the collaborative control layer 112 receives the functional information sent by the sensing layer 111 through the first interface, it can generate a control instruction based on the received functional information, and transmit the generated control instruction to the execution layer 113 through the second interface. Among them, the second interface can be a data transmission interface between the collaborative control layer 112 and the execution layer 113. It should be noted that, in this embodiment, the second interface can be a unidirectional data transmission interface, that is, the collaborative control layer 112 can transmit control instructions to the execution layer 113 through the second interface, but the execution layer 113 cannot transmit data to the collaborative control layer 112.
[0062] In this embodiment, the execution layer 113 can receive the control instruction sent by the collaborative control layer 112 through the second interface, and control the hardware module corresponding to any controller in the vehicle to execute the control operation corresponding to the control instruction through the control instruction. It should be noted that the execution layer 113 in the application layer 11 can be used to execute the control instruction sent by the control layer, and the execution layer 113 is not used for conditional judgment.
[0063] In one possible implementation, after receiving the control instruction sent by the collaborative control layer 112, the execution layer can generate an execution signal corresponding to the control instruction, and send the generated execution signal to the basic software layer 13 to control the hardware module to perform the control operation through the basic software layer 13.
[0064] The software architecture of the application layer is provided in the embodiment of the present application. Through the software architecture provided in the embodiment, the application layer in the automotive open system architecture can be divided into a sensing layer 111, a collaborative control layer 112, and an execution layer 112. The software architecture provided in the embodiment can make the functions of each layer of the application layer single and the responsibilities clear. Therefore, the software architecture provided in the embodiment can improve the reusability of each layer of the application layer, thereby improving the development efficiency of the application layer.
[0065] Reference Figure 3 , shows a schematic diagram of another automotive open system architecture provided by an embodiment of the present application. For ease of explanation, only the parts related to this embodiment are shown. Figure 1 The same parts are not repeated here. For details, please refer to the manual about Figure 1 The application layer 11 in the automotive open system architecture may include a sensing layer 111, a collaborative control layer 112, an execution layer 113, a display layer 114, and an intermediate layer 115. The collaborative control layer 112 may include a coordination layer 1121 and a control layer 1122.
[0066] In this embodiment, the collaborative control layer 112 in the application layer 11 may include a coordination layer 1121 and a control layer 1122. Among them, the control layer 1122 may include multiple control modules. Each control module in the control layer 1122 may correspond to a control operation. Each control module in the control layer 1122 may be used to execute the corresponding logical control and / or condition judgment of the module. Each control module in the control layer 1122 may also be used to provide a standardized data transmission interface for the coordination layer 1121 and the execution layer 113. Among them, the functions of each control module in the control layer 1122 may include, but are not limited to, precondition judgment, arbitration, execution control, exit condition judgment, fault handling, and fault detection. The coordination layer 1121 can be used to coordinate and manage multiple control modules in the control layer.
[0067] In a possible implementation, the functional information sent by the sensing layer 11 may be collaborative functional information, and the first interface between the sensing layer 11 and the collaborative control layer 12 may include a collaborative interface. When the functional information acquired by the sensing layer 11 is collaborative functional information, the sensing layer 11 may send the collaborative functional information to the coordination layer 1121 through the collaborative interface. The coordination layer 1121 may receive the collaborative functional information sent by the sensing layer 11 through the collaborative interface. The coordination layer 1121 may generate multiple call information corresponding to the collaborative functional information based on the received collaborative functional information. Among them, each call information generated by the coordination layer 1121 may be used to call a control module in the control layer 1122. After the coordination layer 1121 generates multiple call information, the multiple call information may be transmitted to the control layer 1122 through the third interface. Among them, the third interface may be a data transmission interface between the coordination layer 1121 and the control layer 1122.
[0068] The control layer 1122 may receive multiple call information sent by the coordination layer 1121 through the third interface, and generate first control instructions corresponding to each call information through the control module corresponding to each call information. The first control instruction may be a control instruction for implementing a collaborative function. The control layer 1122 may transmit the generated first control instruction to the execution layer 113 through the second interface, so as to control multiple hardware modules to execute the control operation corresponding to the first control instruction through the execution layer 113, so as to implement the collaborative function corresponding to the first control instruction.
[0069] In a possible implementation, the functional information sent by the sensing layer 11 may be non-cooperative functional information, and the first interface between the sensing layer 11 and the collaborative control layer 12 may include a control interface. When the functional information acquired by the sensing layer 11 is non-cooperative functional information, the sensing layer 11 may send the non-cooperative functional information to the control layer 1122 through the control interface. The control layer 1122 may receive the non-cooperative functional information sent by the sensing layer 11 through the control interface. The control layer 1122 may generate a second control instruction corresponding to the non-cooperative functional information through a control module corresponding to the non-cooperative functional information. Among them, the second control instruction generated by the control layer 1122 may be a control instruction for realizing a non-cooperative function. The control layer 1122 may transmit the generated second control instruction to the execution layer 113 through the second interface. The control layer 1122 may control a hardware module corresponding to the second control instruction through the execution layer 113 to execute a control operation corresponding to the second control instruction, so as to realize the non-cooperative function corresponding to the second control instruction.
[0070] In this embodiment, the collaborative control layer is divided into a coordination layer and a control layer in the software architecture proposed in the embodiment of the present application. Among them, the coordination layer is used to manage multiple control modules in the control layer to collaboratively complete a function, and each control module in the control layer is used to complete the corresponding logical control and conditional judgment according to its functional requirements and its module responsibilities. Therefore, the software architecture provided by the embodiment of the present application can ensure the stability of each control module in the control layer and the singularity of the responsibilities of each control module, so that the control layer will not become bloated and complicated due to too much coordinated control. Therefore, the embodiment of the present application provides a software architecture that can improve the reusability of each control module in the control layer, thereby improving the efficiency of software development.
[0071] like Figure 3 As shown, the arrows connecting the various levels can be used to indicate the direction of data transmission between the various levels. A dotted line connecting any two levels can indicate that there is a restrictive transmission relationship between the two levels connected by the dotted line, that is, the two levels can only transmit partial data through the data transmission interface. A solid line connecting any two levels can indicate that there is a non-restrictive transmission relationship between the two levels connected by the dotted line, that is, the two levels can only transmit partial data through the data transmission interface. If there is no solid line and / or dotted line connection between any two levels, it can indicate that there is no data transmission relationship between the above two levels.
[0072] For example, the coordination layer 1121 and the execution layer 113 are connected by a dotted line of a one-way arrow. Therefore, a one-way restrictive transmission relationship may exist between the coordination layer 1121 and the execution layer 113. Among them, the coordination layer 1121 can transmit part of the data preset by the user to the execution layer 113 through the data transmission interface, while the execution layer 113 cannot transmit data to the coordination layer 1121. Specifically, the coordination layer 1121 can indicate data of the control execution state to the execution layer 113, such as the logical state data and the actual state data of the control. However, the coordination layer 1121 cannot transmit control instructions to the execution layer 113.
[0073] For another example, the coordination layer 1121 and the intermediate layer 115 are connected by a solid line with a double-headed arrow. Therefore, there may be a double non-restrictive transmission relationship between the coordination layer 1121 and the execution layer 113. Therefore, the coordination layer 1121 may transmit various data to the execution layer 113 through the data transmission interface, and the execution layer 113 may also transmit various data to the coordination layer 1121 through the data transmission interface.
[0074] In this embodiment, the application layer 11 may further include a display layer 114. The display layer 114 in the application layer 11 may receive display information transmitted by other layers except the display layer 114 through the fourth interface. The display layer 114 may perform a display operation corresponding to the display information based on the received display information. The fourth interface is a data transmission interface between the display layer 114 and other layers except the display layer.
[0075] In a possible implementation, after receiving the display information, the display layer 114 may generate a display signal corresponding to the display information based on a display algorithm preset by the user. The display layer 114 may input the generated display signal into the runtime environment layer 12 through the data transmission interface, and input the display signal into the basic software layer 13 through the runtime environment layer 12, so as to control the human-machine interface (HMI) in the vehicle through the basic software layer 13 to perform corresponding display operations.
[0076] In a possible implementation, the display layer 114 may also be connected to the instrument system and / or audio system of the vehicle. After receiving the display information, the display layer 114 may generate a display signal corresponding to the display information based on a display algorithm preset by the user. After the display layer 114 generates the display signal, it may send the display signal to the instrument system and / or audio system of the vehicle through a data transmission interface preset by the user, so that the corresponding display operation is performed through the instrument system and / or audio system.
[0077] In this embodiment, the software architecture provided by the embodiment of the present application includes a display layer responsible for display processing. Therefore, the software architecture provided by the embodiment of the present application ensures the stability of each layer in the application layer and the singleness of the responsibilities of each layer, thereby improving the reusability of each layer in the application layer. In addition, by setting the display layer, the electronic controller can still keep the software simple and orderly when it involves more complex display operations.
[0078] In this embodiment, the application layer 11 may further include an intermediate layer 115. The intermediate layer 115 in the application layer 11 may receive control instructions sent by the collaborative control layer 112 through the fifth interface. The intermediate layer 115 may transmit the received control instructions to the basic software layer 113 in the automotive open system architecture through the data transmission interface corresponding to the control instructions to implement at least one functional control. Among them, the fifth interface may be a data transmission interface between the intermediate layer 115 and the collaborative control layer 112. Both the coordination layer 1121 and the control layer 1122 in the collaborative control layer 112 may send control instructions to the intermediate layer 115 through the fifth interface.
[0079] In one possible implementation, Figure 4 , which shows a schematic diagram of the structure of an intermediate layer provided in an embodiment of the present application. For the sake of convenience, only the parts related to this embodiment are shown. Figure 4 The middle layer 115 may include multiple middle modules, each of which may be used to provide different types of data transmission interfaces. The multiple middle modules in the middle layer 115 may include, but are not limited to, a configuration management module 1551, a storage management module 1552, an electronic control unit management module 1553, and a diagnosis management module 1554.
[0080] Among them, the electronic control unit management module 1553 of the middle layer 115 may include multiple communication control interfaces and multiple up and down power interfaces. Specifically, the communication control interface in the electronic control unit management module 1553 may include a communication request interface and a communication shutdown interface. The up and down power interfaces in the electronic control unit management module 1553 may include a power-on request interface and a power-off request interface. The electronic control unit management module 1553 in the middle layer 115 can be used to manage and coordinate the interaction between each layer in the application layer 11 and the basic software 13. The collaborative control layer 112 in the application layer 11 can send control instructions to the middle layer 115, and perform up and down power management and / or communication management on the electronic control unit through the electronic control unit management module 1553 in the middle layer 115.
[0081] When the collaborative control layer 112 needs to perform communication management on the electronic control unit, the control instruction sent by the collaborative control layer 112 may be a communication instruction. The collaborative control layer 112 may send a communication instruction to the middle layer 115 through the fifth interface. The middle layer 115 may receive the communication instruction sent by the collaborative control layer 112 through the fifth interface, and determine the communication control interface corresponding to the currently received communication instruction through the electronic control unit management module 1553. The electronic control unit management module 1553 in the middle layer 115 may transmit the communication instruction to the basic software layer 13 through the communication control interface corresponding to the communication instruction, so as to implement the communication function corresponding to the communication instruction.
[0082] When the collaborative control layer 112 needs to perform power on and off management of the electronic control unit, the control instruction sent by the collaborative control layer 112 may be a power on and off instruction. The collaborative control layer 112 may send the power on and off instruction to the middle layer 115 through the fifth interface. The middle layer 115 may receive the power on and off instruction sent by the collaborative control layer 112 through the fifth interface, and determine the power on and off interface corresponding to the currently received power on and off instruction through the electronic control unit management module 1553 in the middle layer 115. The electronic control unit management module 1553 in the middle layer 115 may transmit the power on and off instruction to the basic software layer 13 through the power on and off interface corresponding to the power on and off instruction, so as to implement the power on and off operation corresponding to the power on and off instruction.
[0083] Among them, the configuration management module 1551 of the middle layer 115 may include multiple configuration interfaces. The configuration management module 1551 can be used to manage the configuration information of the electronic control unit. The configuration management module 1551 can receive the configuration information of the electronic control unit sent by the basic software layer 13 through the runtime environment layer 12, and coordinate and manage the received configuration information. The configuration management module 1551 can also provide the collaborative control layer 112 with a configuration interface for all vehicle functions so that the collaborative control layer 112 can configure the configuration information of the vehicle. Specifically, the configuration management module 1551 can receive the configuration information sent by the communication management module (Communication Stack, COM) and the non-volatile memory manager module (NVRAMManager, NVM) in the basic software layer 13.
[0084] When the collaborative control layer 112 needs to configure the configuration information of the vehicle, the control instruction sent by the collaborative control layer 112 may be a configuration instruction. The collaborative control layer 112 may send the configuration instruction to the middle layer 115 through the fifth interface. The middle layer 115 may receive the configuration instruction sent by the collaborative control layer 112 through the fifth interface, and determine the configuration interface corresponding to the current configuration instruction through the configuration management module 1551. The configuration management module 1551 in the middle layer 115 may transmit the currently received configuration instruction to the basic software layer 13 through the configuration interface corresponding to the configuration instruction, so as to execute the configuration operation corresponding to the configuration instruction through the basic software layer 13.
[0085] The storage management module 1552 of the intermediate layer 115 may include multiple storage interfaces. The storage interface in the storage management module 1552 may include a write interface and a read interface. The storage management module 1552 may be used to manage and coordinate the interaction between the collaborative control layer 112 and the non-volatile memory manager module in the basic software layer 13. The storage management module 1552 may be used to perform partition storage management on the data written to the data non-volatile memory manager module by the coordinated collaborative control layer 112.
[0086] When the collaborative control layer 112 needs to perform storage management on data, the collaborative control layer 112 can send a storage instruction to the middle layer 115 through the fifth interface. The middle layer 115 can receive the storage instruction sent by the collaborative control layer 112 through the fifth interface, and determine the storage interface corresponding to the current storage instruction through the storage management module 1552. The storage management module 1552 in the middle layer 115 can transmit the currently received storage instruction to the basic software layer 13 through the storage interface corresponding to the storage instruction, so as to perform the storage operation corresponding to the storage instruction through the basic software layer 13. Specifically, when the storage instruction is a write instruction, the storage interface corresponding to the storage instruction can be a write interface, and the basic software layer 13 can perform a data write operation based on the received write instruction. When the storage instruction is a read instruction, the storage interface corresponding to the storage instruction can be a read interface, and the basic software layer 13 can perform a data read operation based on the received read instruction.
[0087] Among them, the diagnostic management module 1554 of the middle layer 115 may include multiple diagnostic interfaces. The storage management module 1552 can be used to manage and coordinate the diagnostic interaction between the collaborative control layer 112 and the diagnostic event management module (DEM) and the communication management module in the basic software layer 13. The collaborative control layer 112 can implement the diagnostic event management of the diagnostic event management module and the callback event management in the communication management module through the diagnostic management module 1554 of the middle layer 115. Among them, the multiple diagnostic interfaces in the diagnostic management module 1554 may include interfaces such as a diagnostic notification interface and a fault code storage interface.
[0088] For example, when the collaborative control layer 112 generates a fault event, the collaborative control layer 112 may send a fault instruction to the middle layer 115 through the fifth interface. The middle layer 115 may receive the fault instruction sent by the collaborative control layer 112 through the fifth interface, and determine the diagnostic interface corresponding to the current fault instruction through the diagnostic management module 1554. The diagnostic management module 1554 in the middle layer 115 may transmit the currently received fault instruction to the basic software layer 13 through the diagnostic interface corresponding to the fault instruction, so that the basic software layer 13 executes the storage of the fault event corresponding to the fault instruction.
[0089] In this embodiment, by setting up an intermediate layer in the application layer, more friendly interface types and interface calling methods can be provided for other layers in the application layer. In addition, by uniformly calling the interface through the intermediate layer, systemic conflicts caused by irregular use of basic software interfaces by different application modules can also be prevented. Therefore, the software architecture provided by this embodiment can improve the stability of the software while allowing the underlying services to be flexibly expanded and used by upper-layer applications. In addition, since the intermediate layer can be expanded according to the user's business needs during use, the flexibility of the automotive open system architecture can also be improved by setting up the intermediate layer.
[0090] like Figure 5 As shown, a schematic diagram of the data transmission relationship between two controllers provided in an embodiment of the present application is shown. In this embodiment, the vehicle may include at least two controllers, each of which may be installed with an automotive open system framework. The application layer of the automotive open system framework installed in each controller is constructed based on any software architecture provided in an embodiment of the present application. For ease of explanation, Figure 5 Only the parts related to this embodiment are shown. Figure 5As shown, the vehicle may include a first controller 1 and a second controller 2. The first controller 1 and the second controller 2 may be installed with an automotive open system framework. The automotive open system framework of the first controller 1 may include a first application layer 11, a first runtime environment layer 12, and a first basic software layer 13. The first application layer 11 of the first controller 1 may include a second sensing layer 111, a first collaborative control layer 112, and a first execution layer 113. The automotive open system framework of the second controller 2 may include a second application layer 21, a second runtime environment layer 22, and a second basic software layer 23. The second application layer 21 of the second controller 2 may include a first sensing layer 211, a second collaborative control layer 212, and a second execution layer 213.
[0091] When the first controller 1 determines that the currently generated control instruction requires the second controller 2 to cooperate to complete the control, the first controller 1 can send the control instruction to the second controller 1 through the first execution layer 113. The first execution layer 113 can send the execution information corresponding to the control instruction that needs to be completed in cooperation to the second controller 2 through the sixth interface. The sixth interface can be a data transmission interface between the first execution layer 113 and the first sensing layer 211. The second controller 2 can receive the execution information sent by the first controller 1 through the first sensing layer 211, and implement at least one control operation based on the received execution information.
[0092] In a possible implementation, after generating the execution information, the first execution layer 113 may send the generated execution information to the first basic software layer 13 through the first runtime environment layer 12. After receiving the execution information, the first basic software layer 13 may send the execution information to the second basic software layer 23 through the data transmission interface between the first basic software layer 13 and the second basic software layer 23. After receiving the execution information sent by the first basic software layer 13, the second basic software layer 23 may send the received execution information to the first sensing layer 211 through the second runtime environment layer 22.
[0093] For example, a key controller may be provided in the vehicle for receiving remote control commands initiated by a user through a remote control key and performing corresponding control operations in response to the received remote control commands. A light controller may also be provided in the vehicle for controlling each light module in the vehicle to perform corresponding control operations.
[0094] When the user initiates a start command to the vehicle through the remote control key, the sensing layer in the key controller can obtain the start command initiated by the user and transmit the received start command to the coordination layer in the key controller. The coordination layer in the key controller can generate multiple call information based on the start command. Among them, the call information generated by the coordination layer may include lock module call information and headlight module call information. The coordination layer in the key controller can send the generated call information to the execution layer of the key controller. The execution layer in the key controller can generate lock control information and headlight control information based on the received lock module call information and headlight module call information. The execution layer in the key controller can send the lock control information to the basic software layer of the key controller to control the vehicle's lock hardware module to perform the unlocking action through the basic software layer in the key controller. The execution layer in the key controller can also send the headlight control information to the sensing layer of the light controller to control the vehicle's headlight hardware module to perform the lighting action through the light controller.
[0095] In this embodiment, in order to ensure the unity of the responsibilities of each layer in the application layer, the embodiment of the present application can also formulate interface call rules for the interfaces between the various layers in the application layer. As shown in the following table, an interface call rule between the various layers in the application layer provided by the embodiment of the present application is shown.
[0096]
[0097]
[0098]
[0099] Table 1 Interface call rules
[0100] A software architecture provided by the embodiment of the present application can be applied to the application layer of the automotive open system architecture, wherein the software architecture may include a coordination layer, a control layer, a sensor layer, an execution layer, an intermediate layer and a display layer. Since the embodiment of the present application specifies the functions and interface call rules corresponding to each level, the software architecture provided by the embodiment of the present application can ensure the singleness of the responsibilities of each level in the application layer. The software architecture provided by the embodiment of the present application can achieve the technical effects of high cohesion and loose coupling at each level in the application layer under the condition of limited hardware resources, and the work responsibilities of the software at each level are single and clear. Therefore, when the application layer of the software architecture provided by the present embodiment needs to be iteratively upgraded, the various levels of the application layer can be independently stable. And when the user upgrades the application layer, he only needs to focus on the data transmission interface between the various levels instead of the specific internal implementation. Therefore, the software architecture provided by the present embodiment can improve the reusability and flexibility of the software under the condition of minimum resource consumption.
[0101] An embodiment of the present application further discloses a controller, including a computer program stored in and executable on the controller, wherein when the controller executes the computer program, the software architecture of the vehicle as described in the above-mentioned embodiments is implemented.
[0102] An embodiment of the present application further discloses a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the software architecture of the vehicle as described in the aforementioned embodiments is implemented.
[0103] An embodiment of the present application further discloses a computer program product. When the computer program product is run on a computer, the computer executes the software architecture of the vehicle described in the aforementioned embodiments.
[0104] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.
[0105] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.
[0106] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.
[0107] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.
[0108] In the embodiments provided in the present application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
[0109] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0110] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.
[0111] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.
[0112] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.
Claims
1. A vehicle software architecture, characterized in that: The software architecture is applied to an application layer of an open system architecture for automobiles, wherein the open system architecture for automobiles is applied to any controller among a plurality of controllers of a vehicle, wherein the controller is used to control a plurality of hardware modules in the vehicle through the open system architecture for automobiles, wherein the software architecture includes a plurality of layers, wherein the plurality of layers include a sensing layer, a collaborative control layer, and an execution layer; The sensing layer is used to obtain functional information of the vehicle; The collaborative control layer is used to receive the function information sent by the sensing layer through the first interface, and generate a control instruction based on the function information; The first interface is a data transmission interface between the sensing layer and the collaborative control layer; The execution layer is used to receive the control instruction sent by the collaborative control layer through the second interface, and control the hardware module corresponding to any controller to execute the control operation corresponding to the control instruction through the control instruction; the second interface is the data transmission interface between the execution layer and the collaborative control layer.
2. The software architecture according to claim 1, characterized in that: The function information includes collaborative function information, the control instruction includes a first control instruction for realizing the collaborative function, the collaborative control layer includes a coordination layer and a control layer, the control layer includes a plurality of control modules, each of the control modules corresponds to a control operation, the first interface includes a collaborative interface, and the collaborative interface is a data transmission interface between the sensing layer and the coordination layer; The coordination layer is further used for, when the function information is collaborative function information, receiving the collaborative function information sent by the sensing layer through the collaborative interface, and generating a plurality of call information corresponding to the collaborative function information; each of the call information is used to call a control module in the control layer; The control layer is used to receive the multiple call information sent by the coordination layer through the third interface, and generate a first control instruction corresponding to each call information through a control module corresponding to each call information; the third interface is a data transmission interface between the coordination layer and the control layer.
3. The software architecture according to claim 2, characterized in that: The functional information includes non-cooperative functional information, the control instruction includes a second control instruction for implementing the non-cooperative function, the first interface also includes a control interface, and the control interface is a data transmission interface between the sensing layer and the control layer; The control layer is also used to, when the function information is non-cooperative function information, receive the non-cooperative function information sent by the sensor layer through the control interface, and generate the second control instruction based on the control module corresponding to the non-cooperative function information.
4. The software architecture according to claim 1, characterized in that: The software architecture also includes a display layer; The display layer is used to receive display information transmitted by other layers except the display layer through a fourth interface, and perform display operations based on the display information. The fourth interface is a data transmission interface between the display layer and other layers except the display layer.
5. The software architecture according to claim 1, characterized in that: The software architecture also includes an intermediate layer and a basic software layer; The intermediate layer is used to receive the control instructions sent by the collaborative control layer through the fifth interface, and transmit the control instructions to the basic software layer through the data transmission interface corresponding to the control instructions to realize at least one function control. The fifth interface is the data transmission interface between the intermediate layer and the collaborative control layer.
6. The software architecture according to claim 5, characterized in that: The control instructions include communication instructions, and the middle layer includes a plurality of communication control interfaces; The intermediate layer is used to receive the communication instructions sent by the collaborative control layer through the fifth interface, and transmit the communication instructions to the basic software layer through the communication control interface corresponding to the communication instructions, so as to implement the communication function corresponding to the communication instructions.
7. The software architecture according to claim 5, characterized in that: The control instructions include configuration instructions, and the middle layer includes a plurality of configuration interfaces; The intermediate layer is used to receive the configuration instruction sent by the collaborative control layer through the fifth interface, and transmit the configuration instruction to the basic software layer through the configuration interface corresponding to the configuration instruction to execute the configuration operation corresponding to the configuration instruction.
8. The software architecture according to claim 5, characterized in that: The control instructions also include storage instructions, and the intermediate layer includes multiple storage interfaces; The intermediate layer is used to receive the storage instruction sent by the collaborative control layer through the fifth interface, and transmit the storage instruction to the basic software layer through the storage interface corresponding to the storage instruction to execute the storage operation corresponding to the storage instruction.
9. The software architecture according to claim 1, characterized in that: The vehicle includes a first controller and a second controller, the first automotive open system architecture in the first controller includes a first execution layer, and the second automotive open system architecture in the second controller includes a first sensing layer; The first execution layer is used to send execution information corresponding to the control instruction to the second controller through the sixth interface, so that the second controller implements at least one control operation based on the execution information; the sixth interface is a data transmission interface between the first execution layer and the first sensing layer.
10. A vehicle, characterized in that: The vehicle comprises at least two controllers, each of which is equipped with an automotive open system framework, and the application layer of the automotive open system framework is constructed based on the software architecture according to any one of claims 1 to 9; The controller includes a first controller and a second controller, the first controller includes a first software architecture, the first software architecture includes a first execution layer, the second controller includes a second software architecture, and the second software architecture includes a first sensing layer; The first controller is used to send execution information to the second controller through the first execution layer; The second controller is used to receive the execution information sent by the first controller through the first sensing layer, so as to implement at least one control operation based on the execution information.
11. A controller, comprising a computer program stored in and executable on the controller, characterized in that: When the controller executes the computer program, the software architecture of the vehicle as described in any one of claims 1-9 is implemented.
12. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the software architecture of the vehicle according to any one of claims 1 to 9 is implemented.