Vehicle end software architecture, electronic and electrical architecture of the vehicle and vehicle

Abstract

This application relates to a vehicle-side software architecture, a vehicle's electronic and electrical architecture, and a vehicle, falling under the field of vehicle technology. The vehicle-side software architecture includes a cross-domain service layer, an enhanced service layer, an atomic service layer, and a device abstraction layer deployed on the vehicle's area controller and communicating sequentially, as well as an electronic control layer that communicates with the enhanced service layer. The cross-domain service layer is used for communication between the area controller and other vehicle domain controllers. The enhanced service layer performs logical judgments on control request signal groups and transmits target control signals to the cross-domain service layer and the atomic service layer. The atomic service layer, based on the target component control service pointed to by the target control signal, calls the device abstraction layer to control the corresponding vehicle components to execute control functions. The device abstraction layer provides a standard abstraction of hardware interfaces to enable communication between components and the atomic service layer. The electronic control layer provides a standard interface for communication protocol interfaces to enable communication between components and the enhanced service layer. This approach is beneficial for improving the overall vehicle intelligence level and development efficiency.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a vehicle-side software architecture, a vehicle's electronic and electrical architecture, and a vehicle. Background Technology

[0002] Current vehicle software architectures are mostly based on distributed ECU (Electronic Control Unit) designs, which suffer from problems such as distributed computing power, limited communication bandwidth, and strong coupling between hardware and software, making it difficult to support the needs of advanced autonomous driving and continuous OTA (Over-The-Air) upgrades. As electronic and electrical architectures evolve towards domain control and even centralized computing, traditional software architectures are increasingly showing bottlenecks in resource scheduling, functional iteration, and security isolation. Therefore, a new software architecture is urgently needed to achieve centralized computing power and service decoupling, thereby improving the overall vehicle intelligence level and development efficiency. Summary of the Invention

[0003] Therefore, it is necessary to provide a vehicle-side software architecture, vehicle electronic and electrical architecture, and vehicle that can improve the overall vehicle intelligence level and development efficiency.

[0004] Firstly, a vehicle-side software architecture is provided, wherein the vehicle-side software architecture is deployed on the area controller of the vehicle, including:

[0005] The cross-domain service layer is configured to enable communication between the area controller and other vehicle domain controllers.

[0006] An enhanced service layer is configured to communicate with both the cross-domain service layer and the atomic service layer, perform logical judgments on control request signal groups from at least one of the cross-domain service layer and the atomic service layer, and transmit a target control signal matching the control request signal group to the at least one of the two based on the logical judgment results; the control request signal group includes at least two control request signals.

[0007] The atomic service layer is also configured to communicate with the device abstraction layer; the atomic service layer invokes the device abstraction layer to control the corresponding vehicle components to perform relevant control functions based on the atomic service pointed to by the received target control signal.

[0008] The device abstraction layer is configured to provide abstract services for device hardware interfaces; and

[0009] The electronic control layer, which communicates with the enhanced service layer, is configured to provide an abstract service for the device communication protocol interface.

[0010] In this embodiment, the service-oriented architecture of the vehicle area controller is configured, including, from top to bottom, a cross-domain service layer, an enhanced service layer, an atomic service layer, a device abstraction layer, and an electronic control layer that communicates directly with the enhanced service layer. The device abstraction layer and the electronic control layer provide unified access interfaces (hardware interface and protocol interface, respectively) to the upper layers (atomic service layer and enhanced service layer). This allows the upper-layer software to interact normally with the vehicle components connected to the area controller simply by calling the standard interface, without needing to concern itself with the electrical parameters of the hardware (ECU or electronic device) or the communication protocols adapted to the hardware. This ensures smooth communication between the vehicle components and the upper-layer software. The atomic service layer serves as… The smallest functional unit of the service-oriented architecture encapsulates the hardware capabilities provided by the device abstraction layer into independent, indivisible "atomic services," which facilitates the precise and efficient execution of control services related to various vehicle components. The enhanced service layer encapsulates business logic for orchestrating and combining multiple "atomic services" and selecting the specific control request signals executed by the same "atomic service," ensuring the smooth execution of multiple control requirements for vehicle components. The cross-domain service layer enables communication between the area controller and other vehicle domain controllers, achieving data collaboration among multiple domain controllers. This improves the control accuracy for vehicle components and enhances vehicle user comfort based on the control of these components. Adopting the vehicle-side software architecture provided in this application improves software reusability and reduces development complexity. It also enhances the efficiency, convenience, and scalability of application scenario changes in the vehicle control system, while simultaneously improving the control accuracy and efficiency of vehicle components communicating with the area controller, thus improving the user experience.

[0011] In one embodiment, the enhanced service layer includes a plurality of enhanced service units; at least some of the enhanced service units are in a one-to-one matching relationship with the vehicle components communicating with the device abstraction layer and / or the electronic control layer, and at least some of the enhanced service units are in a one-to-many matching relationship with the vehicle components communicating with the device abstraction layer and / or the electronic control layer.

[0012] In this embodiment, the enhanced service layer includes multiple enhanced service units. These enhanced service units can be configured to be matched with specific vehicle components (ECUs and traditional ECUs) that communicate with the device abstraction layer and / or electronic control layer. This matching relationship involves both one-to-one and one-to-many matching relationships. Each enhanced service unit encapsulates the business logic for the vehicle component pointed to by the control request signal group, thus binding the "business logic" with the "physical actions" of the vehicle component. This enables the enhanced service layer to prioritize complex multi-control requirements, which helps ensure the smooth execution of control requirements for multiple vehicle components, thereby improving the user experience of the vehicle.

[0013] In one embodiment, the region controller includes multiple sub-region controllers, and the cross-domain service layer and the enhanced service layer are deployed on the same sub-region controller.

[0014] In this embodiment, when the area controller in the vehicle's electronic and electrical architecture includes at least two sub-area controllers, the cross-domain service layer and the enhanced service layer can be deployed on the same sub-area controller. This allows the interaction between the cross-domain service layer and the enhanced service layer to be intra-process communication or local bus communication, which can reduce network transmission latency and ensure the real-time performance of function control. Furthermore, the function control of vehicle components related to the communication connection of the area controller can be scheduled and processed using the resources available to the area controller. This also reduces the resource consumption of other vehicle domain controllers and / or the central computing platform in the vehicle's electronic and electrical architecture, allowing other vehicle domain controllers and / or the central computing platform to focus on higher-level decision-making and further improve the overall user experience of the vehicle.

[0015] In one embodiment, the region controller includes a plurality of sub-region controllers, each of which is deployed with the atomic service layer.

[0016] In this embodiment, by deploying atomic service layers in each sub-region controller, each sub-region controller can encapsulate "services" related to the vehicle components it communicates with. This achieves hardware-software decoupling to reduce communication and control difficulties caused by hardware differences, and also enables each sub-region controller to have control capabilities for the vehicle components it communicates with, which helps improve the response speed of related control signals.

[0017] In one embodiment, when the enhanced service layer receives multiple control request signals for the same vehicle component, it determines a target control signal based on the control priority pre-matched to each control request signal; the multiple control request signals are triggered in different ways.

[0018] In this embodiment, since multiple control request signals may be generated simultaneously based on different triggering methods for the same vehicle component (ECU or electronic device), by enhancing the business logic encapsulated in the service layer, priority judgment can be made for these multiple control request signals to determine which control request signal (target control signal) should be used to implement the execution control of the relevant vehicle component. This can avoid situations where control requests cannot be executed or are executed chaotically, and can also prevent damage to the relevant vehicle component due to chaotic control signals to a certain extent, thereby helping to improve the service life of the vehicle component.

[0019] In one embodiment, the control request signal group received by the enhanced service layer includes, in the case of control requirements for multiple vehicle components, a business control logic pre-matched to the control request signal group is used to determine the logical judgment result for the multiple vehicle components, and the target controller signal matched by the control request signal group is transmitted to each of the vehicle components in sequence based on the logical judgment result.

[0020] In this embodiment, the control request signal group received by the enhanced service layer may involve control requirements for multiple vehicle components, and these control requirements for multiple vehicle components are used to complete a pre-set convenient control request. Simultaneously, the control request signal group related to a convenient control request can be pre-matched with relevant business control logic in the enhanced service layer. Therefore, if the control request signal group received by the enhanced service layer is used to implement a convenient control request, the enhanced service layer can determine the logical judgment results of each relevant vehicle component based on the pre-matched business control logic of the convenient control request. Then, based on the logical judgment results, it sequentially transmits the target controller signal matched by the control request signal group to each relevant vehicle component to achieve drive control of each vehicle component, thereby achieving complete and smooth execution of the convenient control request and improving the vehicle's user experience.

[0021] In one embodiment, the atomic service layer is further configured to receive the control request signal and / or vehicle component operating parameters transmitted by the device abstraction layer, and forward the control request signal and / or vehicle component operating parameters to the enhanced service layer.

[0022] In this embodiment, the atomic service layer can be used to collect data such as control request signals and vehicle component operating parameters uploaded by the device abstraction layer, and forward the collected data to the communication enhancement service layer, so as to facilitate the smooth execution of relevant control request signals by calling the enhancement service layer, and to facilitate the enhancement service layer to determine more accurate and appropriate control signals for each vehicle component, which is beneficial to improving the user experience of the vehicle.

[0023] In a second aspect, an electronic and electrical architecture for a vehicle is provided, including a region controller, wherein the region controller is configured with the vehicle-side software architecture described in any one of the first aspects.

[0024] The regional controller is communicatively connected to the vehicle domain controller and the remote communication module; the vehicle domain controller includes an intelligent driving domain controller and a cockpit domain controller.

[0025] In this embodiment, since the area controller in the vehicle's electronic and electrical architecture is configured with the vehicle-side software architecture provided in this application, the electronic and electrical architecture provided in this application has at least the technical effects of improving the efficiency, convenience, and scalability of application scenario changes, as well as improving the control accuracy and efficiency of vehicle components.

[0026] In one embodiment, the area controller includes a first sub-area controller and at least one second sub-area controller;

[0027] The first sub-zone controller is communicatively connected to the intelligent driving domain controller, the cockpit domain controller, the remote communication module, and at least one second sub-zone controller.

[0028] The first sub-region controller is deployed in a first sub-region of the vehicle, and each second sub-region controller is deployed in a second sub-region of the vehicle. The first sub-region and each second sub-region are different regions. The first sub-region controller is communicatively connected to at least a portion of the vehicle components in the first sub-region, and the second sub-region controller is communicatively connected to at least a portion of the vehicle components in the second sub-region.

[0029] In this embodiment, the first sub-zone controller in the architecture can serve as a communication middleware between the second sub-zone controller and any one of the intelligent driving domain controller, cockpit domain controller, and remote communication module. This eliminates the need for the second sub-zone controller to have direct communication connections with any of these three entities, reducing the complexity and bulkiness of the vehicle's internal electronic and electrical architecture and lowering the overall vehicle manufacturing cost. Furthermore, this embodiment deploys the first sub-zone controller in a first sub-region of the vehicle and configures it to communicate with vehicle components in that sub-region. Similarly, each second sub-zone controller is deployed in a second sub-region of the vehicle and configured to communicate with vehicle components in that sub-region. This arrangement allows vehicle components to communicate with controllers located as close as possible in terms of physical proximity, further reducing the complexity and bulkiness of the vehicle's internal electronic and electrical architecture and further lowering the overall vehicle manufacturing cost.

[0030] Thirdly, a vehicle is provided, comprising the electronic and electrical architecture of the vehicle described in any one of the second aspects.

[0031] In this embodiment, since the vehicle adopts the electronic and electrical architecture of the vehicle provided in this application, the vehicle has at least the technical effects of reduced vehicle manufacturing costs, improved efficiency, convenience and scalability of vehicle application scenario changes, and improved control accuracy and efficiency of vehicle components.

[0032] The vehicle-side software architecture, vehicle electronic and electrical architecture, and service-oriented architecture of the vehicle's area controller provided in this application include, from top to bottom, a cross-domain service layer, an enhanced service layer, an atomic service layer, a device abstraction layer, and an electronic control layer that communicates directly with the enhanced service layer. The device abstraction layer and electronic control layer provide unified access interfaces (including hardware interfaces and protocol interfaces, respectively) to the upper layers (atomic service layer and enhanced service layer). This allows the upper-layer software to interact normally with the vehicle components connected to the area controller simply by calling standard interfaces, without needing to concern itself with the electrical parameters of the hardware (ECU or electronic equipment) or the communication protocols adapted to the hardware. This ensures smooth communication between the vehicle components and the upper-layer software. The atomic service layer, as the smallest functional unit of the service-oriented architecture, encapsulates the hardware capabilities provided by the device abstraction layer into independent, indivisible "atomic services," facilitating the precise and efficient execution of control services related to various vehicle components. The enhancement service layer encapsulates business logic for orchestrating and combining multiple "atomic services" and selecting the specific control request signals executed by the same "atomic service," ensuring the smooth execution of multiple control requirements for vehicle components. The cross-domain service layer enables communication between the area controller and other vehicle domain controllers, achieving data collaboration among multiple domain controllers. This improves the control accuracy for vehicle components and enhances vehicle user comfort based on the control of vehicle components. Adopting the vehicle-side software architecture provided in this application improves software reusability and reduces development complexity. It also improves the efficiency, convenience, and scalability of application scenario changes in the vehicle control system, while enhancing the control accuracy and efficiency of vehicle components communicating with the area controller, thus improving the user experience. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of this application or the conventional technology, the drawings used in the description of the embodiments or the conventional technology will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 A schematic diagram of an optional vehicle-side software architecture provided for one embodiment;

[0035] Figure 2 A schematic diagram illustrating the workflow of an optional vehicle-side software architecture provided in one embodiment;

[0036] Figure 3 A schematic diagram illustrating the workflow of another optional vehicle-side software architecture provided in one embodiment;

[0037] Figure 4 A schematic diagram of an optional electronic and electrical architecture provided for one embodiment;

[0038] Figure 5 A schematic diagram of the layout of an optional sub-zone controller provided in one embodiment;

[0039] Figure 6 A schematic diagram of an alternative vehicle provided for one embodiment. Detailed Implementation

[0040] To facilitate understanding of this application, a more complete description will be provided below with reference to the accompanying drawings, which illustrate embodiments of the present application. However, the present application can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that the disclosure of this application will be thorough and complete.

[0041] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0042] The terms "first," "second," etc., used herein may be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish one element from another. For example, without departing from the scope of this application, a first resistor may be referred to as a second resistor, and similarly, a second resistor may be referred to as a first resistor. Both the first resistor and the second resistor are resistors, but they are not the same resistor.

[0043] It is understood that the term "connection" in the following embodiments should be understood as "electrical connection," "communication connection," etc., if the connected circuits, modules, units, etc., have electrical signal or data transmission with each other.

[0044] It is understandable that "at least one" refers to one or more, and "multiple" refers to two or more. "At least a part of an element" refers to part or all of an element.

[0045] When used herein, the singular forms of “a,” “an,” and “the” may also include the plural forms unless the context clearly indicates otherwise. It should also be understood that the terms “comprising / including” or “having,” etc., specify the presence of the stated features, wholes, steps, operations, components, parts, or combinations thereof, but do not preclude the possibility of the presence or addition of one or more other features, wholes, steps, operations, components, parts, or combinations thereof. Meanwhile, the term “and / or” as used in this specification includes any and all combinations of the associated listed items.

[0046] Please refer to Figure 1 This application provides a vehicle-side software architecture deployed on the vehicle's area controller (VIU). The vehicle-side software architecture includes a cross-domain service layer 11, an enhanced service layer 12, an atomic service layer 13, a device abstraction layer 14, and an electronic control layer 15. The cross-domain service layer 11 is configured to enable communication between the area controller and other vehicle-mounted domain controllers 16. The enhanced service layer 12 is configured to communicate with both the cross-domain service layer 11 and the atomic service layer 13. The enhanced service layer 12 performs logical judgments on control request signal groups from at least one of the cross-domain service layer 11 and the atomic service layer 13, and sends the results to the cross-domain service layer 11 and the atomic service layer 13 based on the logical judgment results. At least one of them transmits a target control signal that matches the control request signal group; the control request signal group includes at least two control request signals; the atomic service layer 13 is also configured to communicate with the device abstraction layer 14; the atomic service layer 13 is used to call the device abstraction layer 14 to control the corresponding vehicle component to perform relevant control functions based on the atomic service (target component control service) pointed to by the received target control signal; the device abstraction layer 14 is configured to provide an abstract service for the device hardware interface; the electronic control layer 15, which communicates with the enhancement service layer 12, is configured to provide an abstract service for the device communication protocol interface.

[0047] The area controller plays a crucial role in the vehicle architecture, integrating various body control functions. In some examples of this embodiment, it communicates with other parts of the vehicle via a network connection, and directly drives or powers multiple systems of body functions to achieve unified control of sensors and actuators of the body electronic systems. For example, the area controller can be responsible for integrating functions such as overall vehicle control, regional body control, thermal management, and power distribution.

[0048] Other vehicle domain controllers 16 include, for example, at least a cockpit domain controller (CDC) and a mobile data center (MDC).

[0049] The device abstraction layer 14 provides an interface abstraction between various types of hardware interfaces and standard hardware interfaces, enabling communication between the various vehicle components (ECUs) incorporated by the region controller and the atomic service layer 13. The device abstraction layer 14 shields hardware differences; for example, window motors from different suppliers may have different electrical parameters and control commands. The device abstraction layer 14 provides a unified standard interface for these different hardware components. For instance, for the vehicle component control requirement of "opening the window," the underlying hardware might require a specific voltage signal to trigger this requirement. The device abstraction layer 14 encapsulates these complex hardware details and provides a unified command, so that the upper-layer software does not need to know the relevant physical parameters of the window motor; it only needs to call this standard command. This helps reduce repetitive development work caused by hardware replacement.

[0050] The electronic control layer 15 provides an interface abstraction between various communication protocol interfaces and standard communication protocol interfaces, enabling communication between the various vehicle components incorporated by the area controller and the enhanced service layer 12. The electronic control layer 15 shields protocol differences; it is responsible for converting and mapping signals from traditional, non-SOA (Service-Oriented Architecture) legacy ECUs (Legacy ECUs, Legacy Electronic Control Units) connected to the area controller, such as CAN (Controller Area Network), LIN (Local Interconnect Network), and ETH (Ethernet) signals, into SOA services, making them recognizable and invoked by the upper-layer architecture. These traditional ECUs can be referred to as electronic devices.

[0051] In summary, the "vehicle components" in the embodiments of this application include at least one of an ECU and an electronic device (conventional ECU).

[0052] The atomic service layer 13, located above the device abstraction layer 14, is the smallest, indivisible software unit that constitutes all complex functions. The atomic service layer 13 provides standardized basic capabilities, specifically encapsulating the hardware capabilities provided by the device abstraction layer 14 into independent, repeatedly invoked "services." For example, the "open," "close," and "stop" functions of a car window are three independent atomic services.

[0053] The atomic service layer 13 can be used to receive user-triggered control request signals transmitted by the device abstraction layer 14 and transmit the control request signals to the enhancement service layer 12. The enhancement service layer 12 determines whether to execute or not to execute the control request signals by performing relevant logical judgments. The atomic service layer 13 can be used to receive target control signals transmitted by the enhancement service layer 12 and realize drive control of the vehicle components pointed to by the target control signals based on the atomic service (target component control service) pointed to by the target control signals.

[0054] In other words, the atomic service layer 13 carries the vehicle's common business capabilities. As the smallest functional unit (such as executing commands to lock / unlock doors or move seats forward and backward), it does not have logical integration. It defines different parameters according to different vehicle models to achieve rapid functional iteration compatibility. It can call device abstraction and provide a single-function service interface to the upper enhanced service layer 12 through API (Application Programming Interface). It can be called across VIUs. For example, the enhanced service layer 12 deployed on the first VIU can call the atomic services provided by the atomic service layer 13 deployed in the second VIU through the cross-domain service layer 11.

[0055] The Enhanced Service Layer 12 (or Application Service Layer) sits above the Atomic Service Layer 13 and is responsible for integrating multiple atomic services to implement more complex business logic. The Enhanced Service Layer 12 is used to encapsulate business logic to prioritize multiple control requirements and determine whether to execute relevant controls.

[0056] For example, the two control request signals included in the control request signal group may be generated for the same control requirement of the same vehicle component. For instance, if a user triggers the control request "open the right front window" simultaneously via voice and physical button, the enhanced service layer 12 can, based on the pre-encapsulated business logic that "for opening the window, physical button control has the highest priority," select the physical button trigger to control the opening of the right front window, instead of executing the voice-triggered "open the right front window" control request. That is, the "service" encapsulates the business logic that prioritizes the control requirement based on which triggering method. Furthermore, the multiple control request signals included in the control request signal group may also be for different vehicle components. The enhanced service layer 12 can perform logical judgment on the execution order of the received multiple control request signals and obtain the corresponding control result to be executed. The control request signal group may consist of multiple control request signals received by the enhanced service layer 12 within a preset time period or at the same time.

[0057] A group of control request signals may contain multiple control request signals that are directed to the same vehicle component or to multiple vehicle components.

[0058] For example, the multiple control signals included in a control request signal group may be for a pre-encapsulated convenience control request. For instance, if a user triggers the "convenient alighting" function, the enhanced service layer 12 can call multiple atomic services such as "unlock the car door," "open the car window," and "adjust the seat position" in the order specified by the pre-encapsulated business logic. That is, the "service" encapsulates the business logic of the entire convenient alighting process. For the upper-layer application (enhanced service layer), it is only necessary to call the "convenient alighting" service, without needing to care about which atomic services are called internally.

[0059] For example, when the vehicle component to be driven and controlled by the target control signal determined by the enhanced service layer 12 belongs to the integrated control of the area controller, the target control signal can be transmitted to the atomic service layer 13 to call the required atomic service to realize the drive control of the relevant vehicle component; when the vehicle component to be driven and controlled by the target control signal determined by the enhanced service layer 12 belongs to the integrated control of other vehicle domain controllers 16, the target control signal can be transmitted to the cross-domain service layer 11 to realize the drive control of the relevant vehicle component through other vehicle domain controllers 16.

[0060] In other words, the enhanced service layer 12 is a functional module that can realize certain data fusion or control logic. It can call multi-atomic services, has logic arbitration function, strong independence, and can enhance logic fusion, and can realize whole vehicle function control.

[0061] The cross-domain service layer 11 can orchestrate and combine enhanced services and atomic services from different domains to create a wide variety of user scenarios. Specifically, the cross-domain service layer 11 can transmit or integrate enhanced service data, providing a unified API interface to other vehicle domain controllers 16 (cross-domain service reporting). The internal logic of the VIU is not exposed to other ETH controllers, providing Ethernet communication security. Other vehicle domain controllers 16 can also make cross-domain service calls relative to the cross-domain service layer 11.

[0062] In this embodiment, a service-oriented architecture (SOA) is configured for the vehicle area controller, including a cross-domain service layer 11, an enhanced service layer 12, an atomic service layer 13, and a device abstraction layer 14 that communicate sequentially from top to bottom, as well as an electronic control layer 15 that communicates directly with the enhanced service layer 12. The device abstraction layer 14 and the electronic control layer 15 provide a unified access interface (hardware interface and protocol interface, respectively) to the upper layers (atomic service layer 13 and enhanced service layer 12). This allows the upper-layer software to interact normally with the vehicle components connected to the area controller simply by calling the standard interface, without needing to concern itself with the electrical parameters of the hardware (ECU or electronic device) or the communication protocols adapted to the hardware. This facilitates smooth communication between the vehicle components and the upper-layer software. The atomic service layer 13, as the smallest functional unit of the service-oriented architecture, encapsulates the hardware capabilities provided by the device abstraction layer 14 into independent, indivisible "atomic services," which facilitates the accurate and efficient execution of control services related to various vehicle components. The enhanced service layer 12 encapsulates business logic for orchestrating and combining multiple "atomic services" and selecting the specific control request signals executed by the same "atomic service," ensuring the smooth execution of multiple control requirements for vehicle components. The cross-domain service layer 11 enables communication between the area controller and other vehicle domain controllers 16, achieving data collaboration among multiple domain controllers. This improves the accuracy of control over vehicle components and enhances the user experience based on the control of vehicle components. Adopting the vehicle-side software architecture provided in this application improves software reusability and reduces development complexity. It also improves the efficiency, convenience, and scalability of application scenario changes in the vehicle control system, while enhancing the accuracy and efficiency of control over vehicle components communicating with the area controller, thus improving the user experience.

[0063] In an exemplary embodiment, when the enhanced service layer 12 receives multiple control request signals for the same vehicle component, it determines the target control signal based on the control priority pre-matched to each control request signal; the multiple control request signals are triggered in different ways.

[0064] The triggering methods include physical button control, screen touch control, voice control, air gesture control, etc.; physical button control can be configured to have the highest priority.

[0065] In this embodiment, since multiple control request signals may be generated simultaneously based on different triggering methods for the same vehicle component (ECU or traditional ECU), by enhancing the business logic encapsulated in the service layer 12, priority judgment can be made for these multiple control request signals to determine which control request signal (target control signal) should be used to implement the execution control of the relevant vehicle component. This can avoid situations where control requests cannot be executed or are executed in a chaotic manner, and can also prevent damage to the relevant vehicle component due to chaotic control signals to a certain extent, thereby helping to improve the service life of the vehicle component.

[0066] In an exemplary embodiment, when the control request signal group received by the enhanced service layer 12 includes control requirements for multiple vehicle components, the layer determines the logical judgment result for the multiple vehicle components based on the business control logic pre-matched to the control request signal group, and transmits the target controller signal matched by the control request signal group to each vehicle component in sequence based on the logical judgment result.

[0067] For example, the enhanced service layer 12 may pre-encapsulate multiple convenience control requirements, each of which may include unified control requirements for multiple vehicle components. Therefore, if the control request signal group received by the enhanced service layer 12 includes control requirements for multiple vehicle components, it may be that the user of the vehicle has triggered a pre-encapsulated convenience control requirement. For example, the control request for "easy entry" may involve sequentially executing "lower the driver's side window", "open the driver's side door", "reverse the driver's seat", and "turn on the main control display".

[0068] In this embodiment, the control request signal group received by the enhanced service layer 12 may involve control requirements for multiple vehicle components, and these control requirements for multiple vehicle components are used to complete a pre-set convenient control request. At the same time, the control request signal group related to a convenient control request can be pre-matched with relevant business control logic in the enhanced service layer 12. Based on this, if the control request signal group received by the enhanced service layer 12 is used to implement a convenient control request, the enhanced service layer 12 can determine the logical judgment result of each relevant vehicle component based on the pre-matched business control logic of the convenient control request, and then transmit the target controller signal matched by the control request signal group to each relevant vehicle component in sequence based on the logical judgment result, so as to realize the drive control of each vehicle component, thereby realizing the complete and smooth execution of the convenient control request, which is beneficial to improving the user experience of the vehicle.

[0069] In an exemplary embodiment, the enhanced service layer 12 includes a plurality of enhanced service units; at least some of the enhanced service units have a one-to-one matching relationship with the vehicle components communicating with the device abstraction layer 14 and / or the electronic control layer 15, and at least some of the enhanced service units have a one-to-many matching relationship with the vehicle components communicating with the device abstraction layer 14 and / or the electronic control layer 15.

[0070] Each enhanced service unit represents an independent business function module with a certain degree of complexity, used to decompose various complex vehicle business functions (such as light shows, intelligent entry, thermal management strategies, etc.) into independent, reusable software modules. Each enhanced service unit may encapsulate judgment logic and control timing for specific functions, specific vehicle components, or specific vehicle component actuators.

[0071] For example, an enhanced service unit may encapsulate judgment logic for a single vehicle component; for instance, the "open passenger window" enhanced service unit may contain only priority sorting for opening the passenger window based on different triggering methods. An enhanced service unit may also encapsulate judgment logic and control timing for multiple vehicle components or multiple vehicle component actuators; for instance, the "easy exit" enhanced service unit may contain an ordered combination of three atomic service actions: "unlock door," "seat retraction," and "steering wheel retraction."

[0072] Since the enhanced service layer 12 includes multiple enhanced service units, these enhanced service units exist independently. When needed, only one of the enhanced service units needs to be called to achieve drive control of the relevant vehicle components or actuators in the vehicle components.

[0073] In this embodiment, the enhanced service layer 12 includes multiple enhanced service units, each of which can be configured to match with specific vehicle components (ECUs and traditional ECUs) communicating with the device abstraction layer 14 and / or the electronic control layer 15. This matching relationship involves both one-to-one and one-to-many matching relationships. Each enhanced service unit encapsulates the business logic for each vehicle component pointed to by the control request signal group, realizing the binding between the "business logic" and the "physical actions" of the vehicle component. This enables the enhanced service layer 12 to have the ability to combine and orchestrate complex multi-control requirements, which is conducive to ensuring the smooth execution of control requirements for multiple vehicle components, thereby improving the user experience of the vehicle.

[0074] In an exemplary embodiment, the atomic service layer 13 is also configured to receive control request signals and / or vehicle component operating parameters transmitted by the device abstraction layer 14, and forward the control request signals and / or vehicle component operating parameters to the enhanced service layer 12.

[0075] In this embodiment, the atomic service layer 13 can be used to collect data such as control request signals and vehicle component operating parameters uploaded by the device abstraction layer 14, and to forward the collected data to the communication enhancement service layer 12, so as to call the enhancement service layer 12 to smoothly execute the relevant control request signals, and to facilitate the enhancement service layer 12 to determine more accurate and appropriate control signals for each vehicle component, which is beneficial to improving the user experience of the vehicle.

[0076] In one exemplary embodiment, the vehicle’s area controller includes multiple sub-area controllers, with cross-domain service layer 11 and enhanced service layer 12 deployed on the same sub-area controller.

[0077] The vehicle may be equipped with 2-4 sub-zone controllers. For example, if 2 sub-zone controllers are configured, one sub-zone controller can be placed in the driver's side area and the other in the passenger side area. This application is not limited to this, and the number of sub-zone controllers in the vehicle and the placement of each sub-zone controller can be adjusted based on design requirements.

[0078] When the cross-domain service layer 11 and the enhanced service layer 12 are deployed in the same sub-zone controller, there is no limitation on whether the relevant sub-zone controller is directly connected to other vehicle domain controllers 16. That is, the cross-domain service layer 11 and the enhanced service layer 12 can be deployed in any sub-zone controller.

[0079] In this embodiment, when the area controller in the vehicle's electronic and electrical architecture includes at least two sub-area controllers, the cross-domain service layer 11 and the enhanced service layer 12 can be deployed on the same sub-area controller. This allows the interaction between the cross-domain service layer 11 and the enhanced service layer 12 to be intra-process communication or local bus communication, which can reduce network transmission latency and ensure the real-time performance of function control. Furthermore, the function control of vehicle components related to the communication connection of the area controller can be scheduled and processed using the resources available to the area controller. This also reduces the resource consumption of other vehicle domain controllers 16 in the vehicle's electronic and electrical architecture, allowing other vehicle domain controllers 16 and / or the central computing platform to focus on higher-level decision-making, further improving the overall user experience of the vehicle.

[0080] In one exemplary embodiment, the vehicle’s area controller includes multiple sub-area controllers, each of which is deployed with an atomic service layer 13.

[0081] In this embodiment, by deploying atomic service layers 13 in each sub-region controller, each sub-region controller can encapsulate "services" related to the vehicle components it communicates with. This achieves hardware-software decoupling to reduce communication and control difficulties caused by hardware differences, and also enables each sub-region controller to have control capabilities for the vehicle components it communicates with, which is beneficial to improving the response speed of related control signals.

[0082] In one exemplary embodiment, the hardware interface type of the vehicle component communicating with the device abstraction layer 14 includes at least one of a digital input interface, an analog input interface, a high-speed data interface, and a high-bandwidth interface.

[0083] In this embodiment, the hardware interface type of the vehicle component that communicates with the area controller can include various types such as digital input interface (DI), analog input interface (AI), high-speed data interface (HSD), and high-bandwidth interface (HB). This is beneficial for the area controller to communicate with vehicle components produced by different manufacturers and used to transmit different types of data, which improves the selectivity of vehicle components and also improves the maintainability of vehicle components.

[0084] For example, the device abstraction layer 14 can achieve hardware and software decoupling; the device abstraction layer 14 is used to incorporate the device actuator for VIU, shielding the upper layer application software from hardware implementation and manufacturer differences; it abstracts different types of hardwired interfaces (DI, AI, HSD, HB, etc.) into a unified interface type to form standardization, and provides a unified API interface to the upper layer atomic service layer 13, which can effectively and flexibly adapt to hardware changes without the upper layer being aware of them, thus accelerating software iteration.

[0085] In one exemplary embodiment, the communication protocol interface type of the vehicle components communicating with the electronic control layer 15 includes at least one of a controller area network interface, a local interconnect network interface, and an Ethernet interface.

[0086] In some embodiments, the area controller supports communication with vehicle components through various types of communication protocol interfaces such as the controller area network interface, local interconnection network interface, and Ethernet interface. This helps to improve the selectivity of vehicle components and also improves the maintainability of vehicle components.

[0087] For example, the Legacy ECU can achieve communication decoupling. For the CAN / LIN nodes of the downstream VIU, it shields the differences between CAN / LIN / ETH interfaces from the upper-layer application software and forms standardized service interfaces through LIN->API, API->LIN, CAN->API, and API->CAN, abstracting different types of communication protocols into a unified API interface.

[0088] like Figure 2 As shown, a reference embodiment is provided. The backrest local switch is an AI signal, which is directly acquired by the VIU. Therefore, a device abstraction layer is constructed for the backrest local switch. By mapping the switch position to voltage through the different resistance and voltage corresponding to different positions, an API interface is provided to report the switch status to the switch atomic service layer. The backrest switch atomic service layer transmits the switch status to the seat enhancement service layer. After receiving the switch status, the seat enhancement service layer performs logical judgment and arbitration. If the calling conditions are met, it will immediately call the seat atomic service layer to start the step-by-step adjustment of the seat backrest angle. The atomic service layer then calls the backrest fore-and-aft adjustment motor device abstraction to control the motor's forward and reverse rotation, thereby realizing the fore-and-aft adjustment of the backrest. After changing the supplier of the backrest local switch or adjustment motor, only the acquisition and driver of the backrest switch device abstraction need to be re-adapted. It does not affect the atomic and above application layer software, enabling rapid software iteration to adapt to different vehicle models.

[0089] like Figure 3 As shown, a reference embodiment is provided. The area controller collects AI signals from seat adjustment switches (such as fore-aft adjustment, backrest adjustment, seat cushion adjustment, and height adjustment). Different resistance values ​​correspond to different seat adjustments. The area controller maps the collected voltages to different adjustments and provides an API interface to report the switch status to the seat switch atomic service. After receiving the switch status, the seat enhancement service performs logical judgment and arbitration. If the calling conditions are met, it calls the seat motor adjustment atomic service. The atomic service then calls the seat adjustment motor device abstraction and controls the motor's forward and reverse rotation through the HB hardwired interface to achieve seat motor adjustment. When the user operates the seat massage on the large screen, the cockpit domain controller calls the comfort enhancement service within the area controller through cross-domain services. If the calling conditions are met, the information is transmitted to the driver's seat massage module via the Legacy ECU service API to LIN, realizing the massage function.

[0090] Based on the same inventive concept, please refer to Figure 4 and Figure 5This application also provides an electronic and electrical architecture for a vehicle, including a region controller configured with any of the vehicle-side software architectures provided in this application. The region controller is communicatively connected to an in-vehicle domain controller 16 and a telematics box (TBOX) 50; the in-vehicle domain controller 16 includes a driving domain controller 30 and a cockpit domain controller 40.

[0091] The Intelligent Driving Domain Controller 30 is the central decision-making component of the intelligent driving system. It connects multiple cameras via LVDS (Low-Voltage Differential Signaling), connects LiDAR and mid-range millimeter-wave radar via Ethernet, and connects short-range millimeter-wave radar and ultrasonic radar via CANFD (Controller Area Network with Flexible Data-Rate). By integrating and processing data from various sensors, the Intelligent Driving Domain Controller 30 performs environmental perception, path planning, and decision-making, controls vehicle movement, and coordinates communication with other systems to ensure driving safety and real-time performance.

[0092] The cockpit domain controller 40, serving as the "intelligent control hub" of the automotive cockpit system, can be configured to integrate a computing platform, software platform, display platform, and ecosystem to achieve interconnection and full-scenario collaboration. The cockpit domain controller 40 can be configured as an instrument cluster (IC), head-up display (HUD), external power amplifier controller (EPA), etc. The cockpit domain controller 40 can be used to achieve multi-functional coordination; for example, it can synchronize navigation information to the IC and HUD, and the voice command interaction large screen soft switch, through SOA based on SOME / IP (Scalable service-oriented middleware over IP), can call the body functions of the first sub-zone controller 21 and / or the second sub-zone controller 22 related to doors, windows, etc., to achieve full vehicle comfort functions.

[0093] In this embodiment, since the area controller in the vehicle's electronic and electrical architecture is configured with the vehicle-side software architecture provided in this application, the electronic and electrical architecture provided in this application has at least the technical effects of improving the efficiency, convenience, and scalability of application scenario changes, as well as improving the control accuracy and efficiency of vehicle components.

[0094] In an exemplary embodiment, the area controller 20 includes a first sub-area controller 21 and at least one second sub-area controller 22. The first sub-area controller 21 is communicatively connected to the intelligent driving domain controller 30, the cockpit domain controller 40, the remote communication module 50, and at least one second sub-area controller 22. The first sub-area controller 21 is deployed in a first sub-area N1 of the vehicle, and each second sub-area controller 22 is deployed in a second sub-area N2 of the vehicle. The first sub-area N1 and each second sub-area N2 are different areas. The first sub-area controller 21 is communicatively connected to at least some vehicle components 60 in the first sub-area N1, and the second sub-area controller 22 is communicatively connected to at least some vehicle components 60 in the second sub-area N2. In an exemplary embodiment, the first sub-area controller 21 may be communicatively connected to vehicle components in the whole vehicle domain to achieve the integration of the first sub-area controller 21 with the whole vehicle domain control function of the vehicle.

[0095] Specifically, the vehicle domain control function may include power domain control function and chassis domain control function. In addition, it may also be possible to integrate thermal management function, air conditioning control function and intelligent power distribution function.

[0096] For example, such as Figure 4 and Figure 5 As shown, this application divides the vehicle into a first sub-region N1 and a second sub-region N2 that do not overlap. A first sub-region controller 21 is deployed in the first sub-region N1 and configured to be primarily electrically connected to at least a portion of the vehicle components 60 in the first sub-region N1. A second sub-region controller 22 is deployed in the second sub-region N2 and configured to be primarily electrically connected to at least a portion of the vehicle components 60 in the second sub-region N2. Based on this configuration, each region controller 20 (first sub-region controller 21, second sub-region controller 22) can be electrically connected to the vehicle components 60 closest to it, which helps reduce the length of the connecting wires required for the vehicle components 60 to electrically connect to the region controllers 20 (first sub-region controller 21, second sub-region controller 22), thereby reducing the overall vehicle manufacturing cost and weight.

[0097] Optionally, the entire vehicle may use the first sub-zone controller 21 as the core gateway architecture, integrating VDC (Vehicle Domain Controller) and VIU functions. For example, the first sub-zone controller 21 may be equipped with an Ethernet bus and a CANFD bus to allow it to connect to the second sub-zone controller 22, the intelligent driving domain controller 30, and the cockpit domain controller 40. The first sub-zone controller 21 can be electrically connected to the downstream vehicle components 60 via CAN or LIN wiring. The components connected to the domain controllers (intelligent driving domain controller 30, cockpit domain controller 40, first sub-zone controller 21, and second sub-zone controller 22) can actually be some component actuators and component controllers within the vehicle.

[0098] In this embodiment, since the area controller 20 in the vehicle's electronic and electrical architecture is equipped with the vehicle-side software architecture provided in this application, the electronic and electrical architecture provided in this application has at least the technical effects of improved efficiency, convenience, and scalability in application scenario changes, as well as improved control accuracy and efficiency of vehicle components 60. Furthermore, the first sub-area controller 21 in this architecture can serve as a communication middleware for the second sub-area controller 22 with any one of the intelligent driving domain controller 30, cockpit domain controller 40, and remote communication module 50. This eliminates the need for the second sub-area controller 22 to have direct communication connections with any one of the three, reducing the complexity and bulkiness of the vehicle's internal electronic and electrical architecture and lowering the overall vehicle manufacturing cost. Meanwhile, in this embodiment of the application, the first sub-area controller 21 is deployed in the first sub-area N1 of the vehicle and configured to communicate with the vehicle component 60 in the first sub-area N1. The second sub-area controllers 22 are deployed in the second sub-area N2 of the vehicle and configured to communicate with the vehicle component 60 in the second sub-area N2. This arrangement is beneficial for the vehicle component 60 in the vehicle to communicate with the area controller that is physically close as much as possible, which can further reduce the bulkiness and complexity of the electronic and electrical architecture inside the vehicle, and also helps to further reduce the overall manufacturing cost of the vehicle.

[0099] In this embodiment, since the vehicle domain control function is integrated into the first sub-domain controller 21, the electronic and electrical architecture provided in this application embodiment does not need to set up a separate vehicle domain controller to realize the vehicle domain control function. This reduces the number of domain controllers that need to be deployed in the vehicle's electronic and electrical architecture, which is beneficial to reducing the overall manufacturing cost of the vehicle and also to reducing the number of connection harnesses required in the vehicle, thereby reducing the overall weight of the vehicle.

[0100] For example, the first sub-zone controller 21 and the second sub-zone controller 22 are electrically connected via a Controller Area Network (CANFD) bus, which is also electrically connected to a Low Voltage Battery Management System (LBMS). This allows the LBMS to synchronously drive and control the first sub-zone controller 21 and the second sub-zone controller 22. This eliminates the need for either the drive control signal for the first sub-zone controller 21 to be forwarded through the second sub-zone controller 22, or vice versa. This ensures that the LBMS can simultaneously drive and control the first and second sub-zone controllers, shortening the vehicle wake-up time related to the first and second sub-zone controllers 21 and 22. This also helps ensure the stability and safety of the power supply provided by the LBMS to the first and second sub-zone controllers 21 and 22. Meanwhile, the low-voltage battery management system can be configured to provide low-voltage power to the first sub-zone controller 21 and the second sub-zone controller 22. When the main battery management system or the main power supply circuit fails, the low-voltage battery management system can immediately take over to ensure that the zone controller 20 does not lose power and improve the driving safety of the vehicle.

[0101] For example, the first sub-zone controller 21 is electrically connected to the cockpit domain controller 40 and the intelligent driving domain controller 30 respectively via a first type of Ethernet cable; the first sub-zone controller 21 is electrically connected to the second zone controller via a second type of Ethernet cable; wherein, the data transmission efficiency of the first type of Ethernet cable is higher than that of the second type of Ethernet cable. This enables the selection of different types of Ethernet cables according to the data transmission requirements between domain controllers, which helps to reduce the procurement cost of Ethernet cables used in the vehicle, thereby helping to reduce the overall vehicle manufacturing cost.

[0102] Based on the same inventive concept, please refer to Figure 6 This application also provides a vehicle, including the electronic and electrical architecture of any of the vehicles provided in the above embodiments.

[0103] In this embodiment, since the vehicle adopts the electronic and electrical architecture of the vehicle provided in this application, the vehicle has at least the technical effects of reduced vehicle manufacturing costs, improved efficiency, convenience and scalability of vehicle application scenario changes, and improved control accuracy and efficiency of vehicle components.

[0104] In the description of this specification, references to terms such as "some embodiments," "other embodiments," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative descriptions of the above terms do not necessarily refer to the same embodiments or examples.

[0105] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0106] The embodiments described above illustrate several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. Those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these modifications and improvements all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A vehicle-side software architecture, characterized in that, The vehicle-side software architecture is deployed on the vehicle's area controller and includes: The cross-domain service layer is configured to enable communication between the area controller and other vehicle domain controllers. An enhanced service layer is configured to communicate with both the cross-domain service layer and the atomic service layer, perform logical judgments on control request signal groups from at least one of the cross-domain service layer and the atomic service layer, and transmit a target control signal matching the control request signal group to the at least one of the two based on the logical judgment results; the control request signal group includes at least two control request signals. The atomic service layer is also configured to communicate with the device abstraction layer; the atomic service layer invokes the device abstraction layer to control the corresponding vehicle components to perform relevant control functions based on the atomic service pointed to by the received target control signal. The device abstraction layer is configured to provide abstract services for device hardware interfaces; and The electronic control layer, which communicates with the enhanced service layer, is configured to provide an abstract service for device communication protocol interfaces; the electronic control layer communicates with vehicle components in the vehicle with a traditional, non-service-oriented architecture.

2. The vehicle-side software architecture according to claim 1, characterized in that, The enhanced service layer includes multiple enhanced service units; at least some of the enhanced service units have a one-to-one matching relationship with the vehicle components that communicate with the device abstraction layer and / or the electronic control layer, and at least some of the enhanced service units have a one-to-many matching relationship with the vehicle components that communicate with the device abstraction layer and / or the electronic control layer.

3. The vehicle-side software architecture according to claim 1, characterized in that, When the enhanced service layer receives multiple control request signals for the same vehicle component, it determines the target control signal based on the control priority pre-matched to each control request signal; the multiple control request signals are triggered in different ways.

4. The vehicle-side software architecture according to claim 1, characterized in that, The enhanced service layer receives a control request signal group that includes, in the case of control requirements for multiple vehicle components, determines the logical judgment result for the multiple vehicle components based on the pre-matched service control logic of the control request signal group, and transmits the target controller signal matched by the control request signal group to each vehicle component in sequence based on the logical judgment result.

5. The vehicle-side software architecture according to claim 1, characterized in that, The region controller includes multiple sub-region controllers, and the cross-domain service layer and the enhanced service layer are deployed on the same sub-region controller.

6. The vehicle-side software architecture according to claim 1, characterized in that, The region controller includes multiple sub-region controllers, and each sub-region controller is deployed with the atomic service layer.

7. The vehicle-side software architecture according to claim 1, characterized in that, The atomic service layer is also used to receive the control request signal and / or vehicle component operating parameters transmitted by the device abstraction layer, and forward the control request signal and / or vehicle component operating parameters to the enhanced service layer.

8. An electronic and electrical architecture for a vehicle, characterized in that, Includes a region controller, and the region controller is configured with the vehicle-side software architecture as described in any one of claims 1-7; The regional controller is communicatively connected to the vehicle domain controller and the remote communication module; the vehicle domain controller includes an intelligent driving domain controller and a cockpit domain controller.

9. The electronic and electrical architecture of the vehicle according to claim 8, characterized in that, The area controller includes a first sub-area controller and at least one second sub-area controller; The first sub-zone controller is communicatively connected to the intelligent driving domain controller, the cockpit domain controller, the remote communication module, and at least one second sub-zone controller. The first sub-region controller is deployed in a first sub-region of the vehicle, and each second sub-region controller is deployed in a second sub-region of the vehicle. The first sub-region and each second sub-region are different regions. The first sub-region controller is communicatively connected to at least a portion of the vehicle components in the first sub-region, and the second sub-region controller is communicatively connected to at least a portion of the vehicle components in the second sub-region.

10. A vehicle, characterized in that, Including the electronic and electrical architecture of the vehicle as described in any one of claims 8-9.

Images