Domain controller and vehicle
By decoupling functional components at the basic software layer and using communication and routing modules for signal transmission, the problem of low development efficiency during the migration from traditional ECUs to domain controllers is solved, achieving a highly efficient migration process.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-01-06
- Publication Date
- 2026-04-21
AI Technical Summary
During the migration from traditional distributed ECU architecture to centralized domain controller, development efficiency is low, the system architecture needs to be restructured, and the interaction between components needs to be redeveloped, resulting in a longer development cycle.
The functional components are decoupled at the basic software layer. Signal encapsulation and path determination are achieved through communication and routing modules. Components can develop functions without knowing the system topology. Signal transmission is carried out using communication matrices and routing configuration tables.
It improves development efficiency, shortens the development cycle, and is suitable for scenarios where traditional distributed ECU architectures are migrated to centralized domain controllers, reducing the interaction latency between components to the microsecond level.
Smart Images
Figure CN121907882A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of domain controller technology, specifically to domain controllers and vehicles. Background Technology
[0002] An automotive domain controller is a centralized electronic control architecture used to replace the traditional distributed ECU (electronic control unit). Its core idea is to integrate related functions into a few high-performance computing platforms to form a system with high computing power and centralized control, thereby simplifying the vehicle's electronic system.
[0003] Traditional ECUs once played an important role in the development of automotive electronics, but with the evolution of intelligent connected vehicles, their inherent defects have become increasingly prominent: decentralized design leads to complex system structure, star / tree communication topology makes bus bandwidth a bottleneck, complex wiring harnesses lead to high costs, and the inability of ECUs to share data flexibly or in real time reduces system coordination. These defects have directly driven the evolution of automotive electronic architecture towards domain controllers.
[0004] During the development process of migrating from a traditional distributed ECU architecture to a centralized domain controller architecture, based on the previous division of labor in ECU development, problems such as the need to reconstruct the system architecture and redevelop the interactions between components will arise. These problems will reduce development efficiency and thus extend the development cycle. Summary of the Invention
[0005] This application provides a domain controller and a vehicle, aiming to solve the problem of low development efficiency during the migration from a traditional distributed ECU architecture to a centralized domain controller architecture.
[0006] In a first aspect, a domain controller is provided, including multiple functional components, multiple runtime environments and a basic software layer. The basic software layer includes a communication module and a routing module. Each functional component is connected to a corresponding runtime environment, each runtime environment is connected to the communication module, and the communication module is also connected to the routing module. Any one of the first components in each functional component is used to send the signal to be transmitted to the communication module through the corresponding runtime environment; The communication module is used to encapsulate the signal to be transmitted into target protocol data units and send them to the routing module; The routing module is used to determine the target transmission path corresponding to the target protocol data unit based on a preset routing configuration table, and forward the target protocol data unit to the communication module when the target transmission path includes a first path pointing to the second component among the functional components. The communication module is also used to parse the signal to be transmitted from the received target protocol data unit and send the signal to be transmitted to the second component through the runtime environment corresponding to the second component.
[0007] In some embodiments, the domain controller further includes a microprocessor abstraction layer and hardware resources, the hardware resources including a target bus, and the basic software layer further includes an interface abstraction layer corresponding to the target bus, the interface abstraction layer and the hardware resources being connected to the microprocessor abstraction layer respectively. The routing module is also used to forward target protocol data units to the interface abstraction layer when the target transmission path includes a second path pointing to the interface abstraction layer; The interface abstraction layer is used to convert target protocol data units into physical signals and send them to the target bus through the microprocessor abstraction layer.
[0008] In some embodiments, the microprocessor abstraction layer includes a driver component corresponding to the target bus; The interface abstraction layer is used to send target protocol data units to the driver component; The driver component is used to convert target protocol data units into physical signals and send them to the target bus.
[0009] In some embodiments, the first component is used to send the signal to be transmitted to the communication module through a corresponding runtime environment, including: Send the signal to be transmitted to the corresponding runtime environment, so that the runtime environment determines the communication configuration information corresponding to the signal to be transmitted based on the predefined communication matrix, and sends the signal to be transmitted and the communication configuration information to the communication module; The communication module is used to encapsulate the signal to be transmitted into a target protocol data unit, including: Based on the communication configuration information, the signal to be transmitted is encapsulated into a target protocol data unit.
[0010] In some embodiments, the communication matrix includes message configuration information and signal configuration information. The message configuration information includes message name, message identifier, sending component, receiving component, period, and message length. The signal configuration information includes signal name, associated message, start bit, length, scaling factor, offset, and unit. The communication configuration information includes the message configuration information and signal configuration information corresponding to the signals to be transmitted.
[0011] In some embodiments, the routing configuration table includes a mapping relationship from the source name to the destination name of a protocol data unit. The source name includes the message name corresponding to the protocol data unit and the transmission path from the sending module of the protocol data unit to the routing module. The destination name includes the message name and the transmission path from the routing module to the receiving module of the protocol data unit. Some destination names include identification information of functional components. The routing module is used to determine the target transmission path corresponding to the target protocol data unit based on a preset routing configuration table, including: The source name that matches the target protocol data unit is found in the routing configuration table, and the target transmission path is determined based on the target name corresponding to the found source name.
[0012] In some embodiments, the communication module includes communication sub-modules corresponding to each functional component; The first component is used to send the signal to be transmitted to the corresponding communication submodule through the corresponding runtime environment; The communication submodule corresponding to the first component is used to encapsulate the signal to be transmitted into a target protocol data unit and send it to the routing module; The routing module is used to forward target protocol data units to the communication submodule corresponding to the second component when the target transmission path includes the first path; The communication submodule corresponding to the second component is used to parse the signal to be transmitted from the target protocol data unit and send the signal to be transmitted to the second component through the runtime environment corresponding to the second component.
[0013] In some embodiments, the second component is used to trigger a state machine transition based on a received signal to be transmitted.
[0014] In some embodiments, the plurality of functional components include a number of the following: a battery management system, a smart battery system, an electric vehicle communication controller, and a DC-DC converter.
[0015] In a second aspect, a vehicle is provided, including a domain controller as described in any implementation of the first aspect.
[0016] Beneficial effects: In the solution provided in this application embodiment, the domain controller includes multiple functional components, multiple runtime environments, and a basic software layer. The basic software layer includes a communication module and a routing module. Each functional component is connected to its corresponding runtime environment, each runtime environment is connected to the communication module, and the communication module is also connected to the routing module. Any first component among the functional components is used to send a signal to be transmitted to the communication module through its corresponding runtime environment. The communication module is used to encapsulate the signal to be transmitted into a target protocol data unit and send it to the routing module. The routing module is used to determine the target transmission path corresponding to the target protocol data unit based on a preset routing configuration table. If the target transmission path includes a first path pointing to a second component among the functional components, the routing module forwards the target protocol data unit to the communication module. The communication module is also used to parse the signal to be transmitted from the received target protocol data unit and send the signal to be transmitted to the second component through the runtime environment corresponding to the second component. This solution decouples the functional components at the basic software layer, allowing for component functional development without understanding the system topology, greatly improving development efficiency and effectively shortening the development cycle. It is applicable to scenarios where traditional distributed ECU architectures are migrated to centralized domain controllers. Attached Figure Description
[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 This is a schematic diagram of the architecture of the relevant scheme one; Figure 2 This is a schematic diagram of the architecture of the second related scheme; Figure 3 This is a schematic diagram of the architecture of related scheme three; Figure 4 This is a schematic diagram of the structure of a domain controller provided in an embodiment of this application; Figure 5 This is a schematic diagram of the signal transmission process provided in an embodiment of this application; Figure 6 This is another schematic diagram of the domain controller provided in the embodiments of this application; Figure 7 This is a schematic diagram of the interaction process between components provided in the embodiments of this application; Figure 8 This is a timing diagram of the transmission process of the charging mode signal provided in the embodiments of this application. Detailed Implementation
[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0020] In the description of this application, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.
[0021] "A and / or B" includes the following three combinations: A only, B only, and a combination of A and B.
[0022] The use of "applies to" or "configured to" in this application implies open and inclusive language, which does not exclude the applicability to or configuration of devices to perform additional tasks or steps. Additionally, the use of "based on" implies openness and inclusivity, because processes, steps, calculations, or other actions "based on" one or more conditions or values may in practice be based on additional conditions or values beyond those stated.
[0023] In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.
[0024] In the migration of traditional distributed ECUs to domain controllers, one relevant solution is the upgrade of the traditional ECU architecture, such as... Figure 1 As shown, the four functional components—BMS (battery management system), IBS (intelligent battery system), EVCC (electric vehicle communication controller), and DCDC (direct current to direct current converter)—are physically isolated and deployed across four independent cores of a single multi-core chip. Each component runs on its own dedicated core, with no resource-sharing mechanism, and cross-component communication is only achieved through an external hardware CAN (controller area network) bus. Figure 1 This is a schematic diagram of the architecture of the first related scheme.
[0025] like Figure 1 As shown, the core containing any one of the four functional components also includes the runtime environment (RTE), basic software layer (BSW), and microcontroller abstraction layer (MCAL) for that functional component. The functional component communicates with the runtime environment, the runtime environment and the microcontroller abstraction layer communicate with the basic software layer, and the microcontroller abstraction layer communicates with hardware resources. Figure 1 While corresponding solutions achieve hardware integration, they suffer from low inter-component interaction efficiency due to off-chip bus latency (milliseconds). Furthermore, the strict isolation of each functional component necessitates separate firmware upgrades and maintenance, significantly increasing the coordination costs and verification overhead of system iterations. More critically, hardware resources are physically bound to specific cores, preventing the formation of a cross-component hardware resource pool. This leads to insufficient peripheral utilization, and the presence of duplicate functional modules among components results in redundant hardware resource design.
[0026] Solution 2 completely abandons the traditional distributed ECU architecture and adopts a multi-component hardware resource-sharing architecture, such as... Figure 2 As shown, four functional components (BMS, IBS, EVCC, and DCDC) are integrated and deployed. All components share hardware resources and achieve microsecond-level latency by replacing the low-speed external bus through on-chip inter-core communication. Figure 2This is a schematic diagram of the architecture of Scheme 2. Due to its significant modifications, this scheme is extremely unfriendly to the integrated development of migrating traditional ECUs to domain controllers. Multiple challenges need to be addressed during development: First, the real-time task scheduling mechanism between components needs to be reconstructed to resolve contention for memory, bus, and computing units; second, a unified state machine must be designed to coordinate the collaborative operation of the four components, replacing the point-to-point communication mode of traditional distributed ECUs; and third, a hardware protection mechanism must be implemented to ensure isolated access to critical resources. This architectural change leads to an exponential increase in development complexity and a significant extension of the development cycle.
[0027] Related Option 3 adopts a master-slave centralized control architecture, such as Figure 3 As shown, the BMS acts as the master control component, uniformly scheduling all hardware resources, while the other components (IBS, EVCC, and DCDC) act as slave components, performing only local logical operations. Figure 3 This is a schematic diagram of the architecture of Scheme 3. This architecture suffers from a significant core flaw: a severe imbalance in master-slave computing power allocation. The master control component, responsible for resource scheduling and core functions, has peak computing power demands exceeding the chip's capacity. Meanwhile, the three slave components, executing only preset logic functions, have insufficient computing power utilization, and redundant computing power cannot be reclaimed by the master control component. A lag in the master control component will block slave component command responses (such as the emergency stop command in a DC-DC converter), creating a single point of failure chain. Furthermore, it fails to address the extended development cycle caused by architecture refactoring.
[0028] In summary, the characteristics of Scheme 1, Scheme 2, and Scheme 3 are shown in Table 1 below.
[0029] Table 1: Characteristics of relevant schemes
[0030] The relevant solutions mainly have the following pain points: During the migration from traditional distributed ECU architecture to centralized domain controller, the original components cannot be reused through simple porting due to fundamental differences in communication protocols, resource scheduling mechanisms and functional coupling modes. It is necessary to redesign the real-time scheduling mechanism and reconstruct the global state machine, which leads to an excessively long development cycle. As an upgrade to the traditional ECU distributed architecture, the domain controller with completely independent functional components cannot solve the problems of excessively long component interaction delay time and redundant design of hardware resources. A master-slave architecture for domain controllers can lead to an imbalance in computing power distribution.
[0031] In view of this, embodiments of this application provide a domain controller and a vehicle that decouple functional components at the basic software layer. Component functional development can be carried out without understanding the system topology, greatly improving development efficiency and effectively shortening the development cycle. It is applicable to scenarios where traditional distributed ECU architectures are migrated to centralized domain controllers, thereby solving at least one of the aforementioned technical problems.
[0032] Figure 4 This is a schematic diagram of the structure of a domain controller provided in an embodiment of this application, as shown below. Figure 4 As shown, the domain controller includes multiple functional components (such as...) Figure 4 The diagram shows functional components A1, A2, A3, and An, multiple runtime environments (such as runtime environment A1_RTE, runtime environment A2_RTE, runtime environment A3_RTE, and runtime environment An_RTE), and a basic software layer. The basic software layer includes a communication module and a routing module. Each functional component connects to its corresponding runtime environment, each runtime environment connects to the communication module, and the communication module also connects to the routing module. Here, n is an integer greater than 1. In one example, functional components A1, A2, A3, and An can be, in sequence, a battery management system, a smart battery system, an electric vehicle communication controller, and a DC-DC converter.
[0033] The runtime environment in this application serves as an intermediate isolation layer for interaction between functional components and the underlying software layer. The underlying software layer provides standardized hardware abstractions for upper-layer applications. The communication module implements standardized encapsulation and parsing of application-layer signals into communication data. The routing module implements the forwarding of protocol data units (PDUs) between buses.
[0034] Figure 5 This is a schematic diagram of a signal transmission process provided in an embodiment of this application. The signal transmission process includes the following steps: S501: Any first component among the functional components sends the signal to be transmitted to the communication module through the corresponding runtime environment; S503: The communication module encapsulates the signal to be transmitted into a target protocol data unit and sends it to the routing module; S505: The routing module determines the target transmission path corresponding to the target protocol data unit based on the preset routing configuration table; S507: When the target transmission path includes a first path pointing to the second component among the functional components, the routing module forwards the target protocol data unit to the communication module. S509: The communication module parses the signal to be transmitted from the received target protocol data unit and sends the signal to be transmitted to the second component through the runtime environment corresponding to the second component.
[0035] Figure 5 The corresponding implementation provides a solution that decouples functional components at the basic software layer, allowing for component development without needing to understand the system topology. This greatly improves development efficiency and effectively shortens the development cycle, making it suitable for scenarios where traditional distributed ECU architectures are migrated to centralized domain controllers.
[0036] Steps S501 to S509 will be explained below.
[0037] In step S501, any one of the functional components (hereinafter referred to as the first component) sends the signal to be transmitted to the communication module through the corresponding runtime environment. This runtime environment may store a predefined communication matrix. The first component can send the signal to be transmitted to this runtime environment, causing the runtime environment to determine the communication configuration information corresponding to the signal to be transmitted based on the predefined communication matrix, and then send the signal to be transmitted and the communication configuration information to the communication module.
[0038] A predefined communication matrix can be a data structure or table used to describe the communication rules between various modules in a network. In automotive electronics, DBC (database CAN) format files are typically used to describe the communication matrix.
[0039] Furthermore, the communication matrix can include message configuration information and signal configuration information. Message configuration information may include message name, message identifier, sending component, receiving component, period (in milliseconds), and message length (in bytes). Signal configuration information may include signal name, associated message, start bit (in bits), length (in bits), scaling factor, offset, and unit. The communication configuration information can also include the message configuration information and signal configuration information corresponding to the signals to be transmitted.
[0040] Assuming the message configuration information includes message name BMS_Info and message name EVCC_Info, the message corresponding to BMS_Info includes a total voltage signal and a total current signal. The signal name of the total voltage signal is BMS_TotalVolt, and the signal name of the total current signal is BMS_TotalCurr. The message corresponding to EVCC_Info includes a charging mode signal, and the name of this charging mode signal is EVCC_DCAC_ChgMode. The message configuration information can be shown in Table 2 below, and the signal configuration information can be shown in Table 3 below.
[0041] Table 2: Example Message Configuration Information
[0042] Table 2 shows that the message identifier corresponding to the message name BMS_Info is 0x100, the sending component is BMS (Battery Management System), and the receiving components are EVCC (Electric Vehicle Communication Controller), IBS (Intelligent Battery System), and DCDC (DC-to-DC Converter). The period is 10 milliseconds, and the message length is 8 bytes. The message identifier corresponding to the message name EVCC_Info is 0x200, the sending component is EVCC, the receiving component is BMS, the period is 50 milliseconds, and the message length is 8 bytes.
[0043] Table 3: Exemplary Signal Configuration Information
[0044] Table 3 shows that the message associated with the total voltage signal named BMS_TotalVolt is BMS_Info, with a start bit of 0 bits, a length of 16 bits, a scaling factor of 0.1, an offset of 0, and the unit is V (volts). The message associated with the total current signal named BMS_TotalCurr is BMS_Info, with a start bit of 16 bits, a length of 16 bits, a scaling factor of 0.1, an offset of 0, and the unit is A (amperes). The message associated with the charging mode signal named EVCC_DCAC_ChgMode is EVCC_Info, with a start bit of 0 bits, a length of 8 bits, a scaling factor of 1, an offset of 0, and no unit (represented by / ).
[0045] In step S503, the communication module encapsulates the signal to be transmitted into a target protocol data unit and sends it to the routing module. Specifically, the communication module can receive the signal to be transmitted and communication configuration information sent by the runtime environment corresponding to the first component, and encapsulate the signal to be transmitted into a target protocol data unit based on the communication configuration information.
[0046] Taking Table 3 above as an example, assuming that the signal to be transmitted includes the BMS_TotalVolt signal and the BMS_TotalCurr signal, the communication module can encapsulate the BMS_TotalVolt signal and the BMS_TotalCurr signal into a frame, and the frame structure can be as shown in Table 4 below.
[0047] Table 4: Exemplary Frame Structure
[0048] Table 4 shows the frame structure, including fields such as PduID, length, and data. PduID represents the identifier of the protocol data unit. Length is the data length of the protocol data unit, in bytes. Reserved indicates reserved space; it represents unused space in the data, reserved for future expansion or alignment, etc.
[0049] In step S505, the routing module determines the target transmission path corresponding to the target protocol data unit based on a preset routing configuration table. The routing configuration table may include a mapping relationship from the source name to the target name of the protocol data unit. The source name includes the message name corresponding to the protocol data unit and the transmission path from the sending module of the protocol data unit to the routing module. The target name includes the message name and the transmission path from the routing module to the receiving module of the protocol data unit; some target names include identification information of functional components. The routing module can search the routing configuration table for a source name matching the target protocol data unit and determine the target transmission path based on the target name corresponding to the found source name.
[0050] The field composition of the routing configuration table can be as shown in Table 5.
[0051] Table 5: Example Routing Configuration Table
[0052] In Table 5, the source Pdu name represents the source name of the protocol data unit, the destination Pdu name represents the destination name of the protocol data unit, Com represents the communication module, and PduR represents the routing module. The source Pdu name field, specifically BMS_Info_Com2PduR, shows the message name BMS_Info and the transmission path from Com to PduR. The destination Pdu name field shows BMS_Info_PduR2CanIf, the message name BMS_Info, and the transmission path from PduR to CanIf; BMS_Info_EVCC_PduR2Com, the message name BMS_Info, the transmission path from PduR to Com, and the EVCC component; BMS_Info_IBS_PduR2Com, the message name BMS_Info, the transmission path from PduR to Com, and the IBS component; and BMS_Info_DCDC_PduR2Com, the message name BMS_Info, the transmission path from PduR to Com, and the DCD component. CanIf represents a component in the basic software layer, and the relevant explanation of CanIf will be introduced below.
[0053] In step S507, the routing module forwards the target protocol data unit to the communication module if the target transmission path includes a first path pointing to the second component among the functional components.
[0054] In some embodiments, the domain controller further includes a microprocessor abstraction layer and hardware resources, including a target bus. The basic software layer also includes an interface abstraction layer corresponding to the target bus. The interface abstraction layer and hardware resources are respectively connected to the microprocessor abstraction layer. The target bus includes, but is not limited to, a CAN bus. When the target bus is a CAN bus, the interface abstraction layer may be called the CAN interface abstraction layer (abbreviated as CANIf). The CAN interface abstraction layer is used to provide a hardware-independent CAN controller abstraction interface for unified management of transmit and receive scheduling. The microprocessor abstraction layer is an isolation layer between the chip and the upper-layer software, eliminating hardware dependencies through standardized driver interfaces. The routing module is also used to forward target protocol data units to the interface abstraction layer when the target transmission path includes a second path pointing to the interface abstraction layer. The interface abstraction layer is used to convert the target protocol data units into physical signals through the microprocessor abstraction layer and send them to the target bus.
[0055] Furthermore, the microprocessor abstraction layer includes a driver component corresponding to the target bus. The interface abstraction layer is used to send target protocol data units to the driver component, and the driver component is used to convert the target protocol data units into physical signals and send them to the target bus. In the case of a CAN bus, the driver component can be referred to as a CAN driver.
[0056] In step S509, the communication module parses the signal to be transmitted from the received target protocol data unit and sends the signal to be transmitted to the second component through the runtime environment corresponding to the second component.
[0057] In some embodiments, the communication module may include communication sub-modules corresponding to each functional component. The first component sends the signal to be transmitted to the corresponding communication sub-module through its corresponding runtime environment. The communication sub-module corresponding to the first component encapsulates the signal to be transmitted into a target protocol data unit and sends it to the routing module. The routing module forwards the target protocol data unit to the communication sub-module corresponding to the second component if the target transmission path includes the first path. The communication sub-module corresponding to the second component parses the signal to be transmitted from the target protocol data unit and sends the signal to be transmitted to the second component through its corresponding runtime environment. In one example, the communication sub-module corresponding to each functional component is a dedicated logic processing instance configured for that functional component; each communication sub-module shares the encapsulation / decoding logic of the communication module.
[0058] In some embodiments, such as Figure 6 As shown, the domain controller includes a battery management system, an intelligent battery system, an electric vehicle communication controller, a DC-DC converter, multiple runtime environments, a basic software layer, a microprocessor abstraction layer, and hardware resources. Among these, Figure 6This is another schematic diagram of the domain controller provided in an embodiment of this application. For example... Figure 6 As shown, the battery management system, intelligent battery system, electric vehicle communication controller, and DC-DC converter are connected to their respective runtime environments. The basic software layer includes a communication module, a routing module, and a CAN interface abstraction layer. Each runtime environment and routing module is connected to the communication module, the routing module and the microprocessor abstraction layer are connected to the CAN interface abstraction layer, and the microprocessor abstraction layer is also connected to hardware resources. This domain controller can be referred to as an automotive electronic domain controller. For a detailed description of the components of the domain controller, please refer to the previous explanations; further details will not be repeated here.
[0059] Taking the interaction between the battery management system's signals and the intelligent battery system, the electric vehicle communication controller, and the DC-DC converter as an example, the interaction process can be as follows: Figure 7 As shown. Among them, Figure 7 This is a schematic diagram illustrating the interaction process between components provided in an embodiment of this application. For example... Figure 7 As shown, the battery management system maps the signals to be transmitted to the communication module according to a predefined communication matrix through the corresponding runtime environment. The communication module performs signal-to-protocol data unit conversion, encapsulating multiple signals in the signal to be transmitted into a frame structure to obtain the target protocol data unit. The routing module performs multi-path decision-making according to the routing configuration table, with the main path pointing to the CAN interface abstraction layer for distribution to the CAN bus. The CAN interface abstraction layer calls the CAN driver of the microprocessor abstraction layer, and the physical signal output is completed by the microprocessor abstraction layer. At the same time, a key bypass mechanism is introduced, and the routing module forwards to the communication module through a sub-path, forwarding to the intelligent battery system, electric vehicle communication controller, and DC-DC converter. The corresponding communication sub-modules of the intelligent battery system, electric vehicle communication controller, and DC-DC converter in the communication module perform PDU decoding in parallel, and the parsed signal is transmitted to the intelligent battery system, electric vehicle communication controller, and DC-DC converter through the runtime environment. The intelligent battery system, electric vehicle communication controller, and DC-DC converter trigger state machine transitions based on received signals to decouple the inter-component interaction logic from the communication matrix; relying on the domain pass-through architecture to avoid the CAN bus, the data latency is stabilized at the microsecond level.
[0060] Taking the charging mode signal in the electric vehicle communication controller as an example, the charging mode signal sent out by the electric vehicle communication controller needs to be forwarded to the battery management system. The timing diagram of this charging mode signal is as follows: Figure 8 As shown. Among them, Figure 8 This is a timing diagram of the transmission process of the charging mode signal provided in the embodiments of this application.
[0061] Figure 8 The explanations of the functions in the code are as follows: Rte_Write_EVCC_DCAC_ChgMode in step 81: EVCC charging mode signal transmission function, used to transmit the charging mode signal in EVCC (Electric Vehicle Communication Controller) to the EVCC runtime environment; In step 82, Com_SendSignal is a signal sending function of the Com (communication module) used to pass signals into the Com. PduR_ComTransmit in step 83: The Com transmission function of PduR (routing module), used to pass data from Com into PduR; CanIf_Transmit in step 84: The Can interface sending function, used to send data to CanIf (Can interface abstraction layer). Can_Write in step 85: The Can driver send interface function, used to send data to the underlying Can driver; In step 86, Com_RxIndication is a Com receiving notification function used to transfer the PduR signal back to Com. In step 87, Rte_ComCbk_EVCC_DCAC_ChgMode is the callback function for receiving the EVCC charging mode signal Com, which is used to pass the Com signal into RTE_BMS (the runtime environment of BMS). The Rte_Read_EVCC_DCAC_ChgMode function in step 88 is used to read the EVCC charging mode signal. It is used by the BMS (Battery Management System) to receive the charging mode signal in the corresponding runtime environment.
[0062] This application also provides a vehicle that includes the domain controller described in the above embodiments.
[0063] Traditional domain controller development often overlooks the inheritance of distributed ECUs, treating the migration process as a completely new development, and historical designs are abandoned: existing functional logic (such as BMS state machines) needs to be completely reconstructed, rather than interface adaptation; communication matrices must be reset; signal interactions between components need to be redefined, rather than protocol compatibility.
[0064] The solution provided in this application embodiment can realize domain controller upgrades based on the AUTOSAR standardized architecture, and has the following advantages in the migration from traditional ECUs to domain controllers: The functional logic is seamlessly inherited. The four major components, including BMS and IBS, fully retain the original processing logic and state machine, and only the communication interface layer needs to be adapted. With zero modification to the signal interface, the components still send signals according to the original definition (such as DBC file) through virtual communication matrix mapping, without the need to redesign the communication protocol; The innovative decoupling of basic software enables dynamic redirection of PDU routes in BSW, reducing the interaction latency between components to the microsecond level, while requiring minimal changes to the functional layer code.
[0065] The four functional components (BMS, IBS, EVCC, and DCDC) maintain completely independent signals, avoiding direct interaction through the RTE layer. Instead, they send raw signals directly to the underlying software layer (BSW). At the BSW's underlying hardware resources, component boundaries are completely broken down, forming a globally shared resource pool. This design retains the advantage of zero modifications to the functional layers while improving resource utilization through hardware resource sharing.
[0066] The integration method provided in this application is applicable to scenarios where traditional distributed ECU architectures are migrated to centralized domain controllers. It innovatively decouples functional components at the BSW layer, enabling component development without needing to understand the system topology, significantly improving collaboration efficiency and achieving a leap in development efficiency. It retains both the high resource utilization advantage of traditional domain controllers and the advantages of physical isolation and functional independence of traditional ECUs.
[0067] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.
[0068] The domain controller and vehicle provided in the embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A domain controller, characterized in that, It includes multiple functional components, multiple runtime environments, and a basic software layer. The basic software layer includes a communication module and a routing module. Each functional component is connected to the corresponding runtime environment, and each runtime environment is connected to the communication module. The communication module is also connected to the routing module. Any one of the functional components is used to send the signal to be transmitted to the communication module through the corresponding runtime environment; The communication module is used to encapsulate the signal to be transmitted into a target protocol data unit and send it to the routing module; The routing module is used to determine the target transmission path corresponding to the target protocol data unit based on a preset routing configuration table, and to forward the target protocol data unit to the communication module when the target transmission path includes a first path pointing to the second component among the functional components. The communication module is further configured to parse the signal to be transmitted from the received target protocol data unit and send the signal to be transmitted to the second component through the runtime environment corresponding to the second component.
2. The domain controller according to claim 1, characterized in that, The domain controller further includes a microprocessor abstraction layer and hardware resources, the hardware resources including a target bus, and the basic software layer further includes an interface abstraction layer corresponding to the target bus. The interface abstraction layer and the hardware resources are respectively connected to the microprocessor abstraction layer. The routing module is further configured to forward the target protocol data unit to the interface abstraction layer when the target transmission path includes a second path pointing to the interface abstraction layer; The interface abstraction layer is used to convert the target protocol data unit into a physical signal and send it to the target bus through the microprocessor abstraction layer.
3. The domain controller according to claim 2, characterized in that, The microprocessor abstraction layer includes a driver component corresponding to the target bus; The interface abstraction layer is used to send the target protocol data unit to the driver component; The driving component is used to convert the target protocol data unit into the physical signal and send it to the target bus.
4. The domain controller according to claim 1, characterized in that, The first component is used to send the signal to be transmitted to the communication module through the corresponding runtime environment, including: The signal to be transmitted is sent to the corresponding runtime environment, so that the runtime environment determines the communication configuration information corresponding to the signal to be transmitted based on a predefined communication matrix, and sends the signal to be transmitted and the communication configuration information to the communication module; The communication module is used to encapsulate the signal to be transmitted into a target protocol data unit, including: Based on the communication configuration information, the signal to be transmitted is encapsulated into the target protocol data unit.
5. The domain controller according to claim 4, characterized in that, The communication matrix includes message configuration information and signal configuration information. The message configuration information includes message name, message identifier, sending component, receiving component, period, and message length. The signal configuration information includes signal name, associated message, start bit, length, scaling factor, offset, and unit. The communication configuration information includes the message configuration information and the signal configuration information corresponding to the signals to be transmitted.
6. The domain controller according to claim 1, characterized in that, The routing configuration table includes a mapping relationship from the source name to the destination name of the protocol data unit. The source name includes the message name corresponding to the protocol data unit and the transmission path from the sending module of the protocol data unit to the routing module. The destination name includes the message name and the transmission path from the routing module to the receiving module of the protocol data unit. Some of the destination names include the identification information of the functional components. The routing module is used to determine the target transmission path corresponding to the target protocol data unit based on a preset routing configuration table, including: The source name that matches the target protocol data unit is searched in the routing configuration table, and the target transmission path is determined based on the target name corresponding to the source name found.
7. The domain controller according to claim 1, characterized in that, The communication module includes communication sub-modules corresponding to each of the functional components; The first component is used to send the signal to be transmitted to the corresponding communication submodule through the corresponding runtime environment; The communication submodule corresponding to the first component is used to encapsulate the signal to be transmitted into the target protocol data unit and send it to the routing module; The routing module is used to forward the target protocol data unit to the communication submodule corresponding to the second component when the target transmission path includes the first path; The communication submodule corresponding to the second component is used to parse the signal to be transmitted from the target protocol data unit and send the signal to be transmitted to the second component through the runtime environment corresponding to the second component.
8. The domain controller according to claim 1, characterized in that, The second component is used to trigger a state machine transition based on the received signal to be transmitted.
9. The domain controller according to claim 1, characterized in that, The multiple functional components include several of the following: battery management system, intelligent battery system, electric vehicle communication controller, and DC-DC converter.
10. A vehicle, characterized in that, Includes the domain controller as described in any one of claims 1-9.