An extensible layered chassis domain control architecture, control method and vehicle

Abstract

The application belongs to the field of chassis domain control, and provides an extended layered chassis domain control architecture, a control method and a vehicle. The six-layer structure is sequentially stacked from bottom to top: a hardware and peripheral layer, including a domain control hardware platform, a chassis sensor cluster, a vehicle-mounted communication bus, a cross-domain interaction interface and an actuator physical node; a basic software layer, including a hardware abstraction sub-layer, a service sub-layer and a runtime interface layer; a perception and signal processing layer, processing sensor signals and outputting vehicle state data; a pluggable functional component layer, including algorithm middleware and a functional component cluster; a collaborative control and arbitration layer, completing collaborative control target calculation of multiple actuators; and an actuator layer, receiving control instructions and feeding back execution status. Data interaction is performed between the layers only through predefined inter-layer interfaces, and the lower layer unidirectionally pushes data to the upper layer, and the upper layer unidirectionally sends control instructions to the lower layer. The hardware platform is replaceable, the functional components are plug-and-play, and the actuator configuration is flexibly adjusted.

Description

Technical Field

[0001] This invention belongs to the field of chassis domain control technology, specifically relating to an scalable hierarchical chassis domain control architecture, control method, and vehicle. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] In intelligent electric vehicles, drive-by-wire braking, steering, drive systems, and active suspension are gradually replacing traditional mechanical structures. Chassis control is evolving towards a centralized domain control architecture, placing high demands on the scalability and versatility of domain controllers. Current domain control architectures often employ a two-layer design of "basic software + application layer," integrating the control of various subsystems into a single domain controller. Sensors collect status data and directly instruct actuators, with some introducing multi-actuator collaboration. However, this collaboration is tied to specific actuator combinations and vehicle model parameters. The problems with this architecture are: unclear hardware and software layering, requiring modifications to the upper-layer software for hardware replacement; tight coupling of functional modules, requiring source code modification for new functions, preventing plug-and-play functionality; and a lack of standardized, configurable frameworks for collaborative control, with control strategies strongly coupled to fixed actuators and vehicle models, resulting in poor versatility. Summary of the Invention

[0004] This invention aims to address the technical problems of ambiguous hardware and software layering, tight coupling of functional modules, and poor versatility of collaborative control in existing chassis domain control architectures. It provides an scalable layered chassis domain control architecture, control method, and vehicle, employing a standardized, decoupled six-layer design stacked from bottom to top. This includes a hardware and peripherals layer, a basic software layer, a perception and signal processing layer, a pluggable functional component layer, a collaborative control and arbitration layer, and an actuator layer. Each layer interacts unidirectionally only through predefined inter-layer interfaces, prohibiting cross-layer calls. The basic software layer is designed based on the AUTOSAR standard, achieving effective decoupling between hardware and software. The pluggable functional component layer enables plug-and-play chassis control functions through unified algorithm middleware and standardized component specifications. The collaborative control and arbitration layer adopts a configurable multi-actuator collaborative control framework, using the Jacobian matrix pseudo-inverse method to complete the coupled calculation of multi-actuator control objectives, achieving universal adaptation for different vehicle models and actuator configurations.

[0005] According to some embodiments, the first aspect of the present invention provides an scalable hierarchical chassis domain control architecture, employing the following technical solution: An scalable hierarchical chassis domain control architecture includes, from bottom to top, a hardware and peripheral layer, a basic software layer, a sensing and signal processing layer, a pluggable functional component layer, a collaborative control and arbitration layer, and an actuator layer. The pluggable functional component layer includes an algorithm middleware and a functional component cluster. The algorithm middleware provides a standardized model call interface to the functional component cluster. Each functional component in the functional component cluster calls the dynamic calculation model provided by the algorithm middleware through the standardized model call interface and outputs control requirements to the collaborative control and arbitration layer.

[0006] In some embodiments, the algorithm middleware incorporates a vehicle coupled dynamics model, a driving stability boundary criterion model, a tire force limit constraint model, and a multi-actuator control gradient calculation model, and provides a standardized model calling interface to the upper level. Each functional component can call the dynamic calculation model as needed through the standardized model call interface.

[0007] In some embodiments, the functional component cluster is divided into five categories of pluggable component clusters, including a braking control component cluster, a steering control component cluster, a drive control component cluster, a suspension control component cluster, and a vehicle dynamics control (VMC) component cluster.

[0008] In some embodiments, the braking control component cluster includes an ABS anti-lock braking system, a TCS traction control system, and a VDC vehicle dynamic control system. The steering control component cluster includes an SBW steer-by-wire component, an RWS active rear wheel steering component, a variable gear ratio component, and a road feel simulation component. The drive control component cluster includes a built-in torque arbitration component, a creep control component, and a drive anti-slip component; The suspension control component cluster includes a damping adjustment component, a height adjustment component, a roll suppression component, and a pitch suppression component. The vehicle dynamic control (VMC) component cluster includes a tire blowout stability control component, a pre-stabilization control component, and a split-slip stability control component.

[0009] In some embodiments, each component cluster has a built-in basic control component and reserves space for functional expansion, supporting plug-and-play functionality for new components.

[0010] In some embodiments, each functional component in the functional component cluster follows a unified specification; The unified specifications include standardized input / output interface definitions, component initialization interfaces, control algorithm execution interfaces, fault feedback interfaces, and configuration parameter interfaces.

[0011] In some embodiments, data interaction between the layers of the architecture follows a one-way dependency rule: the lower layer pushes data to the upper layer in a one-way manner, the upper layer sends control commands to the lower layer in a one-way manner, adjacent layers are allowed to provide status feedback, and direct calls between any non-adjacent layers are prohibited.

[0012] In some embodiments, the hardware and peripheral layer includes a domain control hardware platform, a chassis sensor cluster, an in-vehicle communication bus, a cross-domain interaction interface, and actuator physical nodes; The cross-domain interaction interface is used to receive cross-domain control request signals from the intelligent driving domain, power domain, and cockpit domain, and to transmit standardized cross-domain command data to the upper layer.

[0013] In some embodiments, the basic software layer is located above the hardware and peripherals layer and includes a hardware abstraction sublayer, a service sublayer and a runtime interface layer. It completes the standardized encapsulation of hardware and provides a unique standardized interaction channel to the upper layer through the runtime interface layer. When changing the domain controller hardware platform, only the hardware abstraction sublayer needs to be re-adapted; the service sublayer and all layers above it do not need to be modified.

[0014] In some embodiments, the perception and signal processing layer is located above the basic software layer, and is connected to the basic software layer through a runtime interface layer to process sensor signals and output vehicle status data. The perception and signal processing layer includes a vehicle state dynamics calculation kernel, a chassis multi-source information fusion perception module, and a signal verification and failure management module. The vehicle state dynamics solution kernel is built on an 18-DOF vehicle dynamics model, which includes six degrees of freedom for the vehicle body (longitudinal, lateral, yaw, roll, pitch, and vertical) and three degrees of freedom for each of the four wheels (longitudinal, lateral, and vertical). The chassis multi-source information fusion perception module is used to perform time synchronization and fusion processing on signals from multiple sources such as wheel speed sensors, inertial measurement units, and steering angle sensors, and output standardized vehicle status data. When a signal failure is detected, the signal verification and failure management module completes signal fault-tolerant reconstruction through redundant signal cross-verification.

[0015] According to some embodiments, the second aspect of the present invention provides a chassis domain control method, which adopts the following technical solution: A chassis domain control method, comprising: The vehicle chassis status signals and cross-domain control request signals are collected through the chassis sensor cluster and cross-domain interaction interface of the hardware and peripheral layers. The hardware abstraction sublayer of the basic software layer standardizes and encapsulates the signal. After processing by the service sublayer, the standardized low-level data is passed to the upper layer through the runtime interface layer. The perception and signal processing layer calculates the vehicle state based on the 18-DOF vehicle dynamics model and performs signal verification on the calculated vehicle state data; when an abnormal signal is detected, fault degradation processing is triggered; after the verification is passed, standardized vehicle state data is output. Each functional component in the pluggable functional component layer calls the dynamic calculation model provided by the algorithm middleware through the standardized model call interface, calculates its own control requirements based on the standardized vehicle state data, and outputs them to the collaborative control and arbitration layer. By coordinating and arbitrating the control requirements output by multiple functional components through the collaborative control and arbitration layer, the coupled solution of the control objectives of multiple actuators is completed, and control instructions for each actuator are generated. The control commands are protocol adapted by the communication service submodule of the basic software layer and sent to the actuator layer through the vehicle communication bus. The control commands are received by the actuator layer and the corresponding actuators are driven to execute them. At the same time, the execution status is fed back to the basic software layer through the vehicle communication bus, and then passed up to the collaborative control and arbitration layer through the runtime interface layer.

[0016] According to some embodiments, a third aspect of the present invention provides a vehicle.

[0017] A vehicle equipped with the scalable hierarchical chassis domain control architecture described in the first embodiment.

[0018] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention achieves effective separation of hardware and software, and basic software and business logic, through a six-layer standardized decoupled architecture. The hardware abstraction sublayer completes standardized hardware encapsulation; when changing the domain controller hardware platform, only this sublayer needs to be re-adapted, while the service sublayer and higher layers require no modification, achieving hardware platform replaceability. The runtime interface layer serves as the sole interaction channel between the basic software and upper-layer business logic, shielding the underlying hardware and protocol differences. Each layer interacts unidirectionally through predefined inter-layer interfaces, strictly prohibiting cross-layer calls, ensuring architectural clarity and maintainability. This layered decoupled design fundamentally solves the technical problem of deep hardware-software binding in existing architectures, significantly shortening vehicle model adaptation cycles and reducing development and maintenance costs.

[0019] This invention achieves plug-and-play and high scalability of chassis control functions through a pluggable functional component layer design. The algorithm middleware provides standardized model calling interfaces, incorporating a vehicle coupled dynamics model, a driving stability boundary criterion model, a tire force limit constraint model, and a multi-actuator control gradient calculation model. Each functional component calls model capabilities on demand through standardized interfaces, avoiding redundant development of dynamic models and achieving unified iteration and maintenance of the dynamic models. Functional components adhere to unified specifications, including standardized input / output interfaces, component initialization interfaces, control algorithm execution interfaces, fault feedback interfaces, and configuration parameter interfaces. When adding new functional components, only components conforming to the specifications need to be developed and connected to the standardized interfaces; no modification to the original architecture or other functional components is required. This design fundamentally solves the technical problems of tightly coupled functional modules in existing architectures and the need to modify existing code for new functions, enabling rapid iteration and flexible expansion of chassis control functions, adapting to the rapid iteration needs of intelligent vehicle chassis functions.

[0020] This invention achieves standardized collaborative control and high versatility for multiple actuators through a configurable framework design of collaborative control and arbitration layers. The actuator control gradient calculation module calculates the control gradient, response speed, control authority, and control capability boundary of each actuator based on the vehicle's current state, road adhesion conditions, and the physical limitations and response characteristics of each actuator, providing a quantitative basis for arbitration. The multi-objective, multi-dimensional arbitration module has a built-in configurable priority rule base and adopts an arbitration strategy prioritizing low-energy-consumption, fast-response, and wear-free actuators. It completes the decomposition of multi-actuator participation, configuration of control priorities, and configuration of function degradation strategies, supporting rule adaptation under different driving modes. The actuator objective unification calculation module, based on the arbitration results, uses the Jacobian matrix pseudo-inverse method to complete the coupled calculation and conflict resolution of multi-actuator control objectives, generating the final control objective for each actuator. This design fundamentally solves the technical problems of existing architectures, such as the lack of a standardized and configurable framework for multi-actuator collaborative control, the combination of control strategies with fixed actuators, and the strong binding of vehicle models. It achieves universal adaptation for different vehicle models and actuator configurations. When actuator configurations are changed or vehicle parameters are adjusted, only the configuration parameters need to be modified, without modifying the core arbitration algorithm, which significantly improves the versatility of the architecture and its practicality for engineering implementation. Attached Figure Description

[0021] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0022] Figure 1 This is a schematic diagram of the overall architecture of the scalable hierarchical chassis domain control architecture provided in this embodiment of the invention; Figure 2 This is a schematic diagram of the structure of the pluggable functional component layer in an embodiment of the present invention; Figure 3 This is a flowchart of a chassis domain control method according to an embodiment of the present invention. Detailed Implementation

[0023] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0024] It should be noted that the following detailed description is illustrative and intended to provide further explanation of the invention. Unless otherwise specified, 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 invention pertains.

[0025] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0026] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0027] Terminology Explanation: Chassis Domain Controller Architecture (CDC Architecture): refers to the hardware and software architecture that integrates the control logic of chassis control-related subsystems such as braking, steering, drive, and suspension into a unified domain controller; Hardware Abstraction Sublayer (MCAL, Microcontroller Abstraction Layer): the lowest-level software module in the AUTOSAR standard, which completes the standardized encapsulation of hardware registers and peripherals. Runtime Environment (RTE): A standardized communication interface layer between basic software and application software in the AUTOSAR standard, shielding the differences in underlying hardware and protocols; Algorithm Middleware: A software module that provides unified dynamic model calling capabilities for upper-layer functional components, avoiding redundant development of dynamic models for each component; Functional Components: Pluggable chassis control functional modules that conform to unified specifications, including standardized input / output interfaces, control algorithms, fault feedback, and other core components; Cooperative Control and Arbitration: A control framework that completes the participation decomposition, priority configuration, and control target coupling solution of multiple actuators based on the control requirements of multiple functional components; Jacobian Matrix Pseudo-Inverse: A control allocation method for multi-input multi-output systems, which allocates vehicle motion control targets to each actuator by solving the pseudo-inverse of the Jacobian matrix; Lockstep Core: A redundant core in automotive-grade microcontrollers used for functional safety monitoring. It executes the same instructions synchronously with the main core and cross-compares the results to detect hardware faults. Hardware Security Module (HSM): An independent security chip built into the automotive-grade microcontroller, providing basic security capabilities such as encryption, authentication, and key management. 18-DOF Vehicle Dynamics Model: A high-precision vehicle dynamics model including six degrees of freedom (longitudinal, lateral, yaw, roll, pitch, and vertical) for the vehicle body and three degrees of freedom (longitudinal, lateral, and vertical) for each of the four wheels, used for vehicle state calculation and control.

[0028] As mentioned in the background section, with the development of intelligent electric vehicles, chassis actuators such as brake-by-wire, steering-by-wire, distributed drive, and active suspension are gradually replacing traditional mechanical structures, and chassis control is transforming from distributed independent ECU control to a centralized domain control architecture. Existing chassis domain control architectures are mostly based on fixed actuator configurations for specific vehicle models, integrating the control logic of subsystems such as braking, steering, drive, and suspension into a single domain controller. Current architectures typically adopt a simplified two-layer design of "basic software + application layer." Some solutions decompose the basic layers into a perception layer, control layer, and execution layer, collecting vehicle status signals through sensor arrays, and directly outputting control commands to the actuators after calculation by the application layer control algorithm. Some solutions introduce multi-actuator collaborative control logic, but the collaborative control module is strongly bound to specific actuators and vehicle model parameters.

[0029] However, the existing architecture has significant shortcomings in terms of scalability and versatility. First, the architectural layer boundaries are blurred, and hardware and software are deeply and strongly bound together. Replacing sensors, actuators, or hardware platforms requires simultaneous modifications to the upper-level control logic, making independent iteration of hardware and software impossible and resulting in high development and maintenance costs. Second, the functional modules adopt a tightly coupled design. Control modules such as braking and steering are deeply bound to the underlying logic and vehicle parameters. Adding new functions requires modifying the existing module code, failing to achieve plug-and-play functionality and making it difficult to adapt to the rapid iteration needs of intelligent vehicle chassis functions. In addition, multi-actuator collaborative control lacks a standardized and configurable framework. Control strategies are strongly bound to fixed actuator combinations and vehicle models. Changes to actuator configurations require refactoring the arbitration logic, resulting in poor architectural versatility. At the same time, although the existing architecture is mostly based on the AUTOSAR standard for basic adaptation, it has not performed layered decoupling optimization for the characteristics of chassis domain control. The boundaries between hardware abstraction, functional application, and collaborative control are blurred, and cross-layer calls and strong module binding are common problems.

[0030] This invention addresses the aforementioned technical problems by proposing an scalable, layered chassis domain control architecture. This architecture achieves effective separation of hardware and software, and basic software and business logic, through a standardized six-layer decoupling design; it enables plug-and-play chassis control functions through a pluggable functional component system; it achieves universal adaptation to different vehicle models and actuator configurations through a configurable multi-actuator collaborative control framework; and it meets automotive-grade ASIL-D requirements through a layered functional safety design, providing a standardized platform for multi-actuator collaborative chassis stability control.

[0031] The extended layered chassis domain control architecture provided by this invention adopts a standardized design concept of layered decoupling, unidirectional dependency, interaction between adjacent layers, and prohibition of cross-layer calls. This architecture, from the bottom-level hardware to the top-level execution output, is divided into six core layers: the hardware and peripheral layer serves as the physical bottom layer, providing a standardized hardware foundation; the basic software layer is designed based on the AUTOSAR standard, and from bottom to top, it consists of three major modules: the MCAL hardware abstraction sublayer, the core service and security extension sublayer, and the RTE runtime environment, completing standardized hardware encapsulation and providing a unique standardized interaction channel to the upper layer through the runtime interface layer; the perception and signal processing layer has a built-in vehicle state dynamics calculation kernel, completing vehicle state calculation, multi-source information fusion perception, signal verification, and failure management; the pluggable functional component layer is the core of the architecture's functional extension, and from bottom to top, it consists of a two-level structure: a general dynamics algorithm middleware and a standardized functional component cluster; the cooperative control and arbitration layer adopts a configurable cooperative control framework, completing actuator control gradient calculation, multi-objective multi-dimensional arbitration, and unified actuator target calculation; the actuator layer includes four major categories of chassis actuators: braking, driving, steering, and suspension, receiving standardized control commands and feeding back execution status through the vehicle bus.

[0032] Data interaction between layers follows a one-way dependency rule, strictly prohibiting cross-layer calls. Lower layers push data unidirectionally to upper layers, and upper layers send control commands unidirectionally to lower layers; status feedback is allowed between adjacent layers. This design ensures the clarity and maintainability of the architecture. The hardware abstraction sublayer completes standardized hardware encapsulation; when changing the domain controller hardware platform, only this sublayer needs to be re-adapted, and the service sublayer and above do not need to be modified. The runtime interface layer serves as the sole interaction channel between the basic software and the upper-layer business logic, shielding the differences in underlying hardware and protocols. The algorithm middleware provides standardized model call interfaces, and each functional component calls model capabilities on demand through standardized interfaces, avoiding redundant development of dynamic models. Functional components follow unified specifications; when adding new functional components, only components conforming to the specifications need to be developed and connected to standardized interfaces, without modifying the original architecture or other functional components. The collaborative control and arbitration layer adopts a configurable framework; when actuator configuration changes or vehicle parameters are adjusted, only configuration parameters need to be modified, without modifying the core arbitration algorithm.

[0033] This embodiment proposes an example environment, which includes user equipment, computing devices, and a communication network. The user equipment is an intelligent connected vehicle equipped with the scalable hierarchical chassis domain control architecture of this invention, including hardware components such as chassis sensor clusters, actuator physical nodes, and in-vehicle communication buses; the user is a vehicle driver or maintenance personnel; the computing device is a chassis domain controller, which deploys the six-layer software architecture of this invention.

[0034] The chassis sensor cluster includes various types of sensors such as wheel speed sensors, inertial measurement units, steering angle sensors, pedal travel sensors, and suspension displacement sensors, used to collect vehicle chassis status signals. Actuator physical nodes include chassis actuators such as the brake-by-wire system, steering-by-wire system, distributed drive system, and active suspension system, receiving control commands from the domain controller and driving the corresponding actuators. The vehicle communication bus includes at least two redundant CAN FD buses and one vehicle Ethernet bus, conforming to automotive-grade communication standards, used for sensor signal acquisition, actuator control command issuance, and cross-domain data interaction. The chassis domain controller is an automotive-grade multi-core microcontroller with a built-in lockstep core and application core. The lockstep core handles functional safety-critical tasks, while the application core handles non-safety-critical tasks, with task isolation achieved through a hardware physical isolation mechanism. The domain controller deploys the six-layer software architecture of this invention, including software modules such as a basic software layer, a perception and signal processing layer, a pluggable functional component layer, and a cooperative control and arbitration layer.

[0035] The driver inputs driving intentions to the chassis domain controller through human-machine interfaces such as the pedals and steering wheel. The domain controller calculates the vehicle status through the perception and signal processing layer, calculates the control requirements of each function through the pluggable functional component layer, and completes the collaborative arbitration of multiple actuators through the collaborative control and arbitration layer. Finally, it issues control commands to the actuators through the onboard communication bus. After the actuators execute the control commands, they feed back the execution status to the domain controller through the onboard communication bus, forming a complete closed-loop control. Maintenance personnel can read the domain controller's operating data and fault information through the diagnostic interface for vehicle maintenance and function optimization. This example environment is applicable to various intelligent connected vehicle scenarios, including vehicles with different levels of autonomous driving such as L2-level assisted driving, L3-level autonomous driving, and L4-level autonomous driving, as well as vehicles with different power forms, including pure electric, hybrid, and fuel cell vehicles.

[0036] User equipment can be any type of intelligent connected vehicle, including sedans, SUVs, MPVs, trucks, buses, and other models, as well as special vehicles such as driverless taxis, unmanned delivery vehicles, and unmanned mining trucks. The computing device can be a single domain controller or a distributed domain controller cluster, achieving inter-domain communication via in-vehicle Ethernet. The communication network can be an in-vehicle local area network (LAN) or can access a cloud server via a vehicle-to-everything (V2X) network to achieve functions such as remote monitoring and OTA upgrades. It should be noted that the scalable hierarchical chassis domain control architecture and related methods provided in this embodiment of the invention can be applied to the above-described example environment, as well as other possible application scenarios, and this embodiment of the invention does not limit these applications. The technical solutions provided in this embodiment of the invention comply with relevant national laws and regulations and industry standards, and meet automotive-grade functional safety requirements.

[0037] It should be understood that the example environment is only one possible embodiment. In actual applications, the number and type of user devices, the configuration of computing devices, the form of communication networks, etc., can all be adjusted according to actual needs, and the embodiments of the present invention do not limit this. The scope of protection of the present invention is not limited to the example environment, but covers all application scenarios that adopt the technical solutions of the present invention.

[0038] Example 1 like Figure 1 As shown, this embodiment provides an scalable hierarchical chassis domain control architecture, which includes a six-layer structure stacked from bottom to top: hardware and peripheral layer, basic software layer, perception and signal processing layer, pluggable functional component layer, collaborative control and arbitration layer, and actuator layer.

[0039] The hardware and peripherals layer is located at the bottom of the architecture, serving as the physical carrier and the foundation for signal interaction. The basic software layer is located above the hardware and peripherals layer, including the hardware abstraction sublayer, service sublayer, and runtime interface layer. It completes the standardized encapsulation of hardware and provides a unique standardized interaction channel to the upper layers through the runtime interface layer. The perception and signal processing layer is located above the basic software layer, connecting to the basic software layer through the runtime interface layer. It processes sensor signals and outputs vehicle status data. The pluggable functional component layer is located above the perception and signal processing layer, including algorithm middleware and functional component clusters. The cooperative control and arbitration layer is located above the pluggable functional component layer. It completes the cooperative control target calculation of multiple actuators based on the control requirements output by each functional component. The actuator layer is connected to the basic software layer through the vehicle communication bus, receiving control commands and feeding back the execution status.

[0040] Data interaction between layers follows a unidirectional dependency rule: lower layers push data unidirectionally to upper layers, upper layers send control commands unidirectionally to lower layers, adjacent layers are allowed to provide status feedback, and direct calls between any non-adjacent layers are prohibited. This layered decoupling design ensures the clarity and maintainability of the architecture. The hardware and peripherals layer provides hardware signal input interfaces to the basic software layer; the basic software layer provides standardized data input interfaces to the perception and signal processing layer, and provides a runtime interface layer as the sole interaction channel to the upper layers; the perception and signal processing layer provides standardized vehicle status data interfaces to the pluggable functional component layer; the pluggable functional component layer provides control requirement output interfaces to the collaborative control and arbitration layer; the collaborative control and arbitration layer provides control command output interfaces to the basic software layer; the basic software layer sends control commands to the actuator layer, and the actuator layer provides feedback on the execution status to the basic software layer. Through this layered design, effective separation of hardware and software, and basic software and business logic is achieved.

[0041] The hardware and peripheral layer serves as the physical carrier and signal interaction foundation of the entire architecture, comprising five major functional modules: domain control hardware platform, chassis sensor cluster, vehicle communication bus, cross-domain interaction interface, and actuator physical node. The cross-domain interaction interface is used to receive cross-domain control request signals from the intelligent driving domain, power domain, and cockpit domain, and to transmit standardized cross-domain command data to the upper layer.

[0042] The domain control hardware platform is an automotive-grade multi-core microcontroller, integrating at least one lockstep core for functional safety monitoring and at least one application core for business logic operations. The lockstep core handles functional safety-critical tasks, including vehicle state dynamics calculation, cooperative control and arbitration, and actuator control command output; the application core handles non-safety-critical tasks, including human-machine interaction, data logging, and diagnostic services. Task isolation between the lockstep core and application core is achieved through a physical hardware isolation mechanism, meeting ISO 26262 ASIL-D requirements. The domain control hardware platform integrates a hardware safety module (HSM), a multi-channel acquisition unit, and a multi-channel vehicle bus controller, while reserving sufficient computing power redundancy and hardware interface expansion slots to meet future functional upgrades and hardware expansion needs.

[0043] The chassis sensor cluster includes various types of sensors such as wheel speed sensors, inertial measurement units, steering angle sensors, pedal travel sensors, and suspension displacement sensors, used to collect vehicle chassis status signals. All sensors are connected to the domain controller core via hardwired connections or the vehicle bus. Sensor signals undergo hardware-level low-pass filtering and electrical isolation to prevent signal anomalies caused by electromagnetic interference. Critical safety sensors employ a high sampling frequency design to ensure real-time and accurate status acquisition. The vehicle communication bus includes at least two redundant CAN FD buses and one vehicle Ethernet bus, conforming to automotive-grade communication standards and supporting mainstream vehicle communication protocols. It is used for sensor signal acquisition, actuator control command issuance, and cross-domain data exchange.

[0044] The cross-domain interaction interface receives cross-domain control request signals from the intelligent driving domain, powertrain domain, and cockpit domain, and transmits standardized cross-domain command data to the upper layer. The cross-domain interaction interface employs an electrical isolation design, supporting redundant communication via at least two onboard buses to ensure the safety and reliability of cross-domain data interaction, meeting automotive-grade functional safety requirements. Actuator physical nodes include chassis actuators such as the brake-by-wire system, steering-by-wire system, distributed drive system, and active suspension system, receiving control commands from the domain controller and driving the corresponding actuators. All actuators are connected to the domain controller via redundant onboard buses, supporting real-time feedback of actuator status signals and real-time issuance of control commands. The hardware and peripheral layer provides a standardized hardware foundation for the upper layer; hardware expansion does not affect the upper-layer software architecture.

[0045] The foundational software layer, designed based on AUTOSAR CP 4.4 and above, is the key layer for achieving hardware-software decoupling and standardized encapsulation of core capabilities in the entire architecture. From bottom to top, it consists of three main layers: the MCAL hardware abstraction sublayer, the core service and security extension sublayer, and the RTE runtime interface layer. All modules provide standardized calling interfaces, shielding the differences in underlying hardware and protocols. The MCAL hardware abstraction sublayer is the lowest layer of the foundational software, directly interfacing with the hardware and peripheral layers. It standardizes the encapsulation of hardware registers, peripherals, I / O interfaces, and bus controllers according to the AUTOSAR standard, achieving standardized abstraction of hardware operations. The hardware abstraction sublayer includes GPIO driver modules, CAN bus driver modules, Ethernet driver modules, and ADC acquisition driver modules. Each driver module directly operates the hardware registers of the domain controller hardware platform through register mapping and connects to the service sublayer through standardized driver interfaces.

[0046] Upper-layer software does not need to concern itself with the specific model and configuration of the underlying hardware; it can access the hardware simply through a standardized interface, thus decoupling the hardware platform from the upper-layer software. When changing the domain controller hardware platform, only the MCAL driver module needs to be re-adapted; the upper-layer business software requires no modification. This design achieves hardware platform replaceability. The core service and security extension sublayers reside above the MCAL hardware abstraction sublayer and below the RTE runtime environment, consisting of two parallel units: the core service module and the security extension module. The core service module includes an ECU abstraction submodule, a communication service submodule, a storage service submodule, and a system service submodule. The ECU abstraction submodule further shields the hardware differences of peripherals, providing hardware-independent peripheral access interfaces. The communication service submodule incorporates standardized communication management, routing, and network management units, while also integrating actuator signal adaptation and cross-domain signal adaptation functions. It completes standardized conversion and parsing of signals from different manufacturers and types of actuators, as well as cross-domain signals, through standardized protocol configuration files.

[0047] The storage service submodule provides automotive-grade non-volatile storage management, including configuration parameter storage, fault data storage, and calibration data storage. The system service submodule provides basic system services such as operating system encapsulation, task scheduling, and timer management. The security extension module complies with ISO 26262 standards, deploying safety-critical tasks in the lockstep core and non-safety tasks in the application core. It provides basic encryption and authentication capabilities by calling the hardware security module (HSM) built into the domain controller hardware platform; these capabilities are available for on-demand use by various functional units within the security extension module. The security extension module incorporates program monitoring, data verification, communication protection, and fault management functions, meeting the highest level of functional safety design requirements while supporting configurable expansion of functional safety levels. The RTE runtime interface layer is the top layer of the basic software layer and is the only standardized communication interface between upper-layer business software and lower-layer basic software, enabling independent iteration and decoupling between the two.

[0048] The perception and signal processing layer operates on standardized underlying data output from the RTE interface of the basic software layer. Deployed within the lockstep core of the domain controller, it is configured with a task scheduling cycle according to automotive-grade real-time requirements to ensure the real-time performance and safety of vehicle state calculation and signal processing. This layer consists of three core units: the vehicle state dynamics calculation kernel, the chassis multi-source information fusion perception module, and the signal verification and failure management module. These units provide standardized and highly reliable input data for upper-level control. The vehicle state dynamics calculation kernel is the core algorithm of the entire layer, built upon an 18-DOF vehicle dynamics model. This model includes six degrees of freedom (longitudinal, lateral, yaw, roll, pitch, and vertical) for the vehicle body, and three degrees of freedom (longitudinal, lateral, and vertical) for each of the four wheels. This model comprehensively considers vehicle body motion, suspension motion, and tire mechanical characteristics, accurately describing the vehicle's dynamic behavior under complex operating conditions. The vehicle state dynamics calculation kernel combines the underlying signals collected by sensors to calculate core vehicle state parameters in real time, such as longitudinal velocity, lateral velocity, yaw rate, roll angle, pitch angle, and vertical acceleration. At the same time, based on vehicle dynamics characteristics and tire models, it completes real-time estimation of road slope and road adhesion coefficient.

[0049] The chassis multi-source information fusion perception module is used to synchronize and fuse signals from multiple sources, such as wheel speed sensors, inertial measurement units, and steering angle sensors, to output standardized vehicle state data. Based on the state parameters calculated by dynamics, this module performs three core functions: vehicle state observation, road information estimation, and driver intent recognition. Vehicle state observation improves the accuracy and robustness of state estimation by fusing multi-source sensor signals through an extended Kalman filter algorithm. Road information estimation estimates road information such as road adhesion coefficient and road slope in real time, based on vehicle dynamic response and tire mechanical characteristics. Driver intent recognition identifies the driver's acceleration, braking, and steering intentions based on driver input signals such as pedal travel and steering wheel angle, providing decision-making basis for upper-level control. This module uses configurable fusion rules; when adding new sensors or perception sources, only adaptation rules need to be configured, without modifying the core calculation and fusion logic.

[0050] The signal verification and failure management module completes signal fault-tolerant reconstruction through redundant signal cross-verification when a signal failure is detected. This module simultaneously verifies and manages failures for all input signals and processed data, performing signal redundancy verification, data integrity checks, abnormal data identification, and underlying fault classification processing. Signal redundancy verification detects faults or anomalies in individual sensors through cross-comparison of multiple sensor sources. Data integrity checks ensure the integrity and real-time performance of data transmission through CRC checks, timestamp checks, and other methods. Abnormal data identification is based on multi-dimensional criteria such as physical constraints, historical data, and dynamic models. Underlying fault classification processing categorizes faults into three levels—minor, moderate, and severe—based on fault type and impact scope, triggering corresponding fault-tolerant strategies and degradation controls. This module employs configurable verification rules; when adding a sensor or sensing source, only the corresponding verification parameters need to be configured, without modifying the core calculation and fusion logic.

[0051] like Figure 2 As shown, the pluggable functional component layer is the core layer of this architecture, enabling high functional scalability. It consists of a two-tier structure from bottom to top: a general-purpose dynamics algorithm middleware and a standardized functional component cluster. All modules adopt a unified standardized design, enabling plug-and-play, independent iteration, and flexible expansion of chassis control functions. The general-purpose dynamics algorithm middleware provides unified control dynamics model support for all upper-layer functional components, incorporating a vehicle coupled dynamics model, a driving stability boundary criterion model, a tire force limit constraint model, and a multi-actuator control gradient calculation model, and providing a standardized model calling interface. The vehicle coupled dynamics model describes the coupling relationship between vehicle body motion, suspension motion, and tire mechanics, used for the target solution of multi-actuator cooperative control. The driving stability boundary criterion model, based on stability criteria such as the phase plane method and the β method, evaluates vehicle driving stability in real time.

[0052] The tire force limit constraint model, based on tire models such as the Magic Formula and the Pacejka model, calculates tire force limit constraints for feasibility verification of the control objective. The multi-actuator control gradient calculation model, based on the Jacobian matrix, calculates the control gradient of each actuator on the vehicle's motion state for multi-actuator collaborative arbitration. All functional components can only access the above model capabilities through a standardized model call interface, eliminating the need for developing repetitive dynamic control logic and achieving unified iteration and maintenance of the dynamic model. This design avoids redundant development of dynamic models for each functional component. The standardized functional component cluster adopts a unified component model design, with each functional component strictly adhering to a unified specification. This unified specification includes standardized input / output interface definitions, component initialization interfaces, control algorithm execution interfaces, fault feedback interfaces, and configuration parameter interfaces. All component input / output data uses a standardized format, ensuring component universality, replaceability, and scalability.

[0053] The standardized input interface includes vehicle status data, road information, driver intent, cross-domain control requests, and other input data, all using a unified data structure and unit definition. The standardized output interface includes control requirements, fault status, and execution status, all using a unified data structure and unit definition. The component initialization interface is used for parameter initialization and self-checking during component startup to ensure normal component operation. The control algorithm execution interface is the core functional interface of the component, executing the control algorithm and calculating control requirements according to a fixed call cycle. The fault feedback interface is used for reporting and handling internal component faults, supporting fault classification and degradation control. The configuration parameter interface is used for configuring and calibrating component parameters, supporting parameter adaptation for different vehicle models and actuator configurations. When adding new functional components, only components conforming to the above unified specifications need to be developed and connected to the standardized model call interface; no modification to the original architecture or other functional components is required. This design achieves plug-and-play functionality and high architectural scalability. The standardized functional component cluster is divided into five categories of pluggable component clusters. Each cluster has built-in basic control components and reserves space for functional expansion, supporting plug-and-play addition of new components. Figure 2 As shown, each component cluster connects to the general dynamics algorithm middleware through a unified interface, calling upon the underlying dynamics calculation capabilities. The braking control component cluster integrates ABS anti-lock braking, TCS traction control, and VDC vehicle dynamics control as basic control components; it also reserves slots for expandable components such as hill start assist, automatic parking, and hill descent control, supporting plug-and-play expansion of subsequent functions. The steering control component cluster integrates SBW steer-by-wire, RWS active rear-wheel steering, variable gear ratio, and road feel simulation as basic control components; it also reserves slots for expandable components such as speed-sensitive steering adjustment and parking steering assist, supporting flexible expansion of steering functions. The drive control component cluster integrates torque arbitration, creep control, and traction control as basic control components; it also reserves slots for expandable components such as torque vector control, energy recovery control, and idle speed control, supporting extended adaptation of drive functions. The suspension control component cluster integrates damping adjustment, height adjustment, roll suppression, and pitch suppression as basic control components; it also reserves slots for expandable components such as anti-slip function and off-road mode, supporting differentiated configurations of suspension functions. The Vehicle Dynamics Control (VMC) component cluster integrates tire blowout stability control, pre-stabilization control, and split-slip stability control as basic control components. It also reserves slots for expandable components such as acceleration / deceleration anti-pitch, intelligent drift, and intelligent all-terrain, supporting continuous iteration of vehicle dynamics control functions. All five component clusters, including their basic and expandable components, adhere to a unified specification and connect to a common dynamics algorithm middleware via a unified interface. Adding any new component requires only developing a component that conforms to the unified specification and interfacing with the unified interface; no modifications to the existing architecture or other components are necessary, achieving plug-and-play functionality and high architectural scalability.

[0054] The collaborative control and arbitration layer is the core of this architecture for achieving unified collaborative control of multiple actuators. Deployed in the lockstep core of the domain controller, it is configured with a task scheduling cycle according to automotive-grade real-time requirements to ensure the real-time performance and functional safety of collaborative control. This layer adopts a configurable collaborative control framework, consisting of three core modules: an actuator control gradient calculation module, a multi-objective, multi-dimensional arbitration module, and an actuator objective unified calculation module. The actuator control gradient calculation module calculates the control gradient, response speed, control authority, and control capability boundary of each actuator based on the vehicle's current state, road adhesion conditions, and the physical limitations and response characteristics of each actuator. The control gradient describes the ability of each actuator to influence the vehicle's motion state and is calculated using the Jacobian matrix. The response speed describes the dynamic response characteristics of each actuator and is determined based on the actuator's physical characteristics and control bandwidth. The control authority describes the controllable range of each actuator under the current operating conditions and is determined based on the actuator's physical limitations and safety constraints. The control capability boundary describes the ultimate control capability of each actuator and is determined based on tire force limit constraints, actuator physical limitations, etc.

[0055] The actuator control gradient calculation module provides quantitative basis for subsequent arbitration, clarifying the controllable range and response priority of each actuator under different operating conditions. The multi-objective, multi-dimensional arbitration module, based on the control requirements output by each functional component and combined with the actuator control gradient calculation results, completes the participation decomposition, control priority configuration, and function degradation strategy configuration for multiple actuators. The multi-objective, multi-dimensional arbitration module has a built-in configurable priority rule base, adopting an arbitration strategy that prioritizes low-energy, fast-response, and wear-free actuators, supporting rule adaptation for different driving modes. Participation decomposition calculates the participation of each actuator under the current operating condition based on the control requirements of each functional component and the actuator control gradient, determining the control weight of each actuator. Control priority configuration configures the control priority of each actuator based on factors such as the priority of functional components, actuator response speed, and control capability boundaries. Function degradation strategy configuration configures corresponding function degradation strategies based on the fault type and impact range, ensuring the basic driving stability of the vehicle under fault conditions. When actuator configuration changes or vehicle model parameters are adjusted, only the configuration parameters of the arbitration module need to be modified to complete the strategy adaptation, without modifying the core arbitration algorithm, enabling flexible expansion of the collaborative control logic.

[0056] The actuator target unified calculation module integrates the control requirements of each actuator based on the arbitration result, completing the coupled solution and conflict resolution of multi-actuator control objectives. The coupled solution is implemented based on the Jacobian matrix pseudo-inverse method, including: establishing a Jacobian mapping matrix between actuator control inputs and vehicle motion state outputs according to the vehicle dynamics model; and calculating the optimal control objective of each actuator by solving the pseudo-inverse of the Jacobian matrix based on the deviation between the current vehicle state and the target state. The Jacobian matrix describes the influence capability of each actuator on the vehicle motion state and is obtained by linearizing the vehicle dynamics model. The Jacobian matrix pseudo-inverse method transforms the multi-input, multi-output control allocation problem into an optimization problem, solving for the optimal control objective of each actuator while satisfying actuator physical limitations and safety constraints, thus achieving coordinated control of multiple actuators. Conflict resolution is based on a priority rule base. When the control requirements of multiple functional components conflict, conflict resolution is completed according to the priority configuration, ensuring the consistency and feasibility of control objectives.

[0057] The actuator layer serves as the architecture's execution output, encompassing four main categories of chassis actuators: braking system, drive system, steering system, and suspension system. Each type of actuator is compatible with multiple mainstream technologies and product types. The braking system includes types such as brake-by-wire and electro-hydraulic braking systems, receiving braking torque control commands. The drive system includes types such as distributed drive systems and centralized drive systems, receiving drive torque control commands. The steering system includes types such as steer-by-wire, electric power steering, and active rear-wheel steering, receiving steering angle control commands. The suspension system includes types such as active suspension and semi-active suspension, receiving damping force and suspension height control commands. All actuators are connected to the domain controller via the vehicle bus, receiving standardized control commands from the basic software layer's communication service submodule, and simultaneously providing real-time feedback to the domain controller on actuator operating status, fault information, and other data.

[0058] After standardized processing by the basic software layer, the execution status feedback is fed back to the collaborative control and arbitration layer and the perception and signal processing layer, forming a complete closed-loop control. The actuator layer is decoupled from the upper-layer core control architecture. When changing, adding, or replacing actuator types, only the corresponding protocol configuration file needs to be updated in the communication service submodule of the basic software layer to complete signal adaptation; no modification to the upper-layer collaborative control logic and functional component code is required. This design achieves both actuator scalability and architectural versatility.

[0059] Example 2 like Figure 3 As shown, this embodiment provides a chassis domain control method, including: S101 collects vehicle chassis status signals and cross-domain control request signals through the chassis sensor cluster and cross-domain interaction interface of the hardware and peripheral layer. S102, the hardware abstraction sublayer of the basic software layer standardizes and encapsulates the signal, and after processing by the service sublayer, the standardized low-level data is passed to the upper layer through the runtime interface layer. S103, the perception and signal processing layer calculates the vehicle state based on the 18-degree-of-freedom vehicle dynamics model and performs signal verification on the calculated vehicle state data; when an abnormal signal is detected, fault degradation processing is triggered; after the verification is passed, the standardized vehicle state data is output. S104, each functional component of the pluggable functional component layer calls the dynamic calculation model provided by the algorithm middleware through the standardized model call interface, calculates its own control requirements based on the standardized vehicle state data, and outputs them to the collaborative control and arbitration layer. S105, through the collaborative control and arbitration layer, performs collaborative arbitration on the control requirements output by multiple functional components, completes the coupled solution of the control objectives of multiple actuators, and generates control instructions for each actuator; S106 adapts the control commands to the protocol through the communication service submodule of the basic software layer and sends them to the actuator layer through the vehicle communication bus. S107 receives control commands through the actuator layer and drives the corresponding actuators to execute. At the same time, it feeds back the execution status to the basic software layer through the vehicle communication bus, and then passes it up to the collaborative control and arbitration layer through the runtime interface layer.

[0060] The above steps are explained in detail below: Step S101: Acquire vehicle chassis status signals and cross-domain control request signals through the chassis sensor cluster and cross-domain interaction interface of the hardware and peripheral layer. The chassis sensor cluster includes various types of sensors such as wheel speed sensors, inertial measurement units, steering angle sensors, pedal travel sensors, and suspension displacement sensors, used to acquire vehicle chassis status signals. Wheel speed sensors acquire four-wheel wheel speed signals for vehicle speed estimation and tire slip ratio calculation. Inertial measurement units acquire vehicle motion state signals such as longitudinal acceleration, lateral acceleration, yaw rate, roll rate, and pitch rate. Steering angle sensors acquire steering wheel angle signals for driver steering intention recognition and front wheel angle estimation. Pedal travel sensors acquire accelerator pedal travel and brake pedal travel signals for driver acceleration and braking intention recognition. Suspension displacement sensors acquire four-wheel suspension displacement signals for road surface roughness estimation and suspension control. All sensor signals are transmitted to the domain controller via hardwired or vehicle bus, and the sensor signal acquisition frequency is configured according to the signal type and control requirements.

[0061] The cross-domain interaction interface is used to receive cross-domain control request signals from the intelligent driving domain, powertrain domain, and cockpit domain. The intelligent driving domain sends autonomous driving control requests to the chassis domain, including motion control targets such as target longitudinal acceleration, target lateral acceleration, and target yaw rate. The powertrain domain sends powertrain system status signals to the chassis domain, including battery level, motor torque, and energy recovery status. The cockpit domain sends driving mode switching requests to the chassis domain, including driving mode selection signals such as Sport mode, Comfort mode, and Eco mode. All cross-domain signals are transmitted via in-vehicle Ethernet using standardized communication protocols to ensure the real-time performance and reliability of cross-domain data interaction.

[0062] Step S102: The signals are standardized and encapsulated by the hardware abstraction sublayer of the basic software layer, processed by the service sublayer, and then passed to the upper layer through the runtime interface layer. The hardware abstraction sublayer receives the raw signals from the hardware and peripheral layers and completes the standardized encapsulation of the signals. The GPIO driver module processes digital signal input and output, including switch signals, pulse signals, etc. The CAN bus driver module processes CAN FD bus signals, including sensor signals, actuator signals, cross-domain signals, etc. The Ethernet driver module processes automotive Ethernet signals, including cross-domain control request signals, diagnostic signals, etc. The ADC acquisition driver module processes analog signal input, including pedal travel signals, suspension displacement signals, etc. After processing by the hardware abstraction sublayer, all raw signals are converted into a standardized software data format and passed to the service sublayer. The communication service submodule of the service sublayer further processes the signals, including signal parsing, unit conversion, coordinate transformation, etc.

[0063] The communication service submodule uses standardized protocol configuration files to standardize and parse signals from different manufacturers, actuators of different types, and cross-domain signals. All signals, after processing by the service sublayer, are passed to the upper layers via the runtime interface layer. The runtime interface layer serves as the sole interaction channel between the underlying software and the upper-layer business logic, shielding it from differences in underlying hardware and protocols. Upper-layer business logic only needs to access the underlying signals through the standardized interface of the runtime interface layer, without needing to concern itself with the specific model and configuration of the underlying hardware. This design achieves decoupling between hardware and software; when changing the domain controller hardware platform, only the hardware abstraction sublayer needs to be re-adapted, while the service sublayer and all layers above remain unchanged.

[0064] Step S103: The perception and signal processing layer calculates the vehicle state based on the 18-DOF vehicle dynamics model, outputs standardized vehicle state data, and performs signal verification on the calculation results. Fault degradation processing is triggered when an abnormal signal is detected. The perception and signal processing layer receives standardized low-level signals transmitted from the runtime interface layer and completes the vehicle state calculation through the vehicle state dynamics calculation kernel. The vehicle state dynamics calculation kernel is built based on the 18-DOF vehicle dynamics model, which includes six degrees of freedom (longitudinal, lateral, yaw, roll, pitch, and vertical) for the vehicle body, and three degrees of freedom (longitudinal, lateral, and vertical) for each of the four wheels. This model comprehensively considers vehicle body motion, suspension motion, and tire mechanical characteristics, and can accurately describe the dynamic behavior of the vehicle under complex working conditions. The vehicle state dynamics calculation kernel combines multi-source signals collected by wheel speed sensors, inertial measurement units, and steering angle sensors for fusion processing, outputting vehicle longitudinal velocity, lateral velocity, yaw rate, roll angle, and vertical force state data for the four wheels. The vehicle longitudinal velocity is estimated by fusing wheel speed signals and longitudinal acceleration signals.

[0065] The vehicle's lateral velocity is estimated by fusing lateral acceleration and yaw rate signals. The yaw rate is directly measured by the inertial measurement unit. The roll angle is estimated by fusing lateral acceleration and suspension displacement signals. The four-wheel vertical force is estimated by fusing suspension displacement and vehicle body vertical acceleration signals. All state estimations employ an extended Kalman filter algorithm, fusing multi-source sensor signals to improve accuracy and robustness. The signal verification and failure management module verifies the calculation results. When a signal failure is detected, cross-validation of redundant signals completes fault-tolerant reconstruction. Signal verification includes steps such as signal redundancy verification, data integrity check, and anomaly detection. Signal redundancy verification detects faults or anomalies in individual sensors through cross-comparison of multiple sources. Data integrity check ensures data transmission integrity and real-time performance through CRC check and timestamp verification. Anomaly detection identifies abnormal data based on multi-dimensional criteria such as physical constraints, historical data, and dynamic models. When an abnormal signal is detected, a fault degradation process is triggered. The fault degradation process includes: determining the fault level, selecting a corresponding degradation control strategy based on the fault level, and inputting the degraded control requirements into the pluggable functional component layer, whereby each functional component calculates the control requirements according to the degradation strategy.

[0066] Fault levels are categorized into three levels: minor, moderate, and severe. A minor fault indicates a single sensor signal anomaly, but redundant signals exist for fault-tolerant reconstruction. In this case, the redundant signal replaces the faulty signal, and normal control continues. A moderate fault indicates multiple sensor signals anomalies, but vehicle state calculations still maintain basic accuracy. A reduced-precision control strategy is employed to limit vehicle acceleration and speed, ensuring basic driving stability. A severe fault indicates all critical sensors fail, and vehicle state calculations cannot guarantee basic accuracy. In this case, an emergency degraded control strategy is implemented, triggering a safe shutdown procedure. Degraded control requirements are input to the pluggable functional component layer, where each component calculates the control requirements according to the degraded strategy, ensuring basic driving stability of the vehicle under fault conditions. This fault degrade handling mechanism achieves fault-tolerant control under fault conditions, meeting automotive-grade functional safety requirements.

[0067] Step S104: Each functional component in the pluggable functional component layer calls the algorithm middleware to calculate its own control requirements based on vehicle state data, and outputs these requirements to the collaborative control and arbitration layer through the control requirement interface. The pluggable functional component layer receives standardized vehicle state data output from the perception and signal processing layer, and each functional component calculates its own control requirements based on the vehicle state data. Each functional component calls the dynamics calculation capabilities of the algorithm middleware through the standardized model call interface. The algorithm middleware has a built-in whole-vehicle coupled dynamics model, a driving stability boundary criterion model, a tire force limit constraint model, and a multi-actuator control gradient calculation model, and provides a standardized model call interface. Each functional component calls the above model capabilities as needed through the standardized model call interface to achieve unified iteration and maintenance of the dynamics model. Taking the VDC vehicle dynamic control component as an example, this component determines whether the vehicle is in an unstable state based on the driving stability boundary criterion model and calculates the additional yaw moment required for stability control based on the whole-vehicle coupled dynamics model.

[0068] Taking the TCS traction control component as an example, this component determines whether the drive wheels have excessive slippage based on the tire force limit constraint model, and calculates the required drive torque adjustment for anti-slip control based on the vehicle coupled dynamics model. Taking the RWS active rear-wheel steering component as an example, this component calculates the rear wheel steering angle required to achieve the target yaw rate based on the vehicle coupled dynamics model. After all functional components have completed their calculations, they output control requirements to the collaborative control and arbitration layer through the control requirement interface. Control requirements include vehicle motion control targets such as target longitudinal force, target lateral force, target yaw moment, and target roll moment, as well as arbitration parameters such as control authority and control priority for each actuator. The control requirement interface uses a standardized data format to ensure that the control requirements output by different functional components have a unified data structure and unit definition. This design achieves plug-and-play functionality and high architectural scalability. When adding a new functional component, only components conforming to the unified specification need to be developed and connected to the standardized model call interface; no modification to the original architecture or other functional components is required.

[0069] Step S105: The collaborative control and arbitration layer performs collaborative arbitration on the control requirements output by multiple functional components, completing the coupled solution of multi-actuator control objectives and generating control commands for each actuator. The collaborative control and arbitration layer receives the control requirements of each functional component output from the pluggable functional component layer and completes collaborative arbitration through the actuator control gradient calculation module, the multi-objective multi-dimensional arbitration module, and the actuator objective unified calculation module. The actuator control gradient calculation module calculates the control gradient and control capability boundary of each actuator based on the vehicle's current state, road surface adhesion conditions, and the physical limitations of each actuator. The control gradient describes the ability of each actuator to influence the vehicle's motion state and is obtained by calculating the partial derivatives of the vehicle dynamics model. The control capability boundary describes the limit control capability of each actuator and is determined based on tire force limit constraints, actuator physical limitations, etc. The multi-objective multi-dimensional arbitration module completes the participation decomposition and control priority configuration of multiple actuators based on a configurable priority rule base. The priority rule base has a built-in arbitration strategy that prioritizes low-energy, fast-response, and wear-free actuators and supports rule adaptation under different driving modes.

[0070] The participation decomposition process calculates the participation of each actuator under the current operating condition based on the control requirements of each functional component and the actuator control gradient, thus determining the control weight of each actuator. Control priority configuration configures the control priority of each actuator based on factors such as the priority of functional components, the response speed of the actuators, and the control capability boundary. The actuator target unification calculation module, based on the arbitration result, uses the Jacobian matrix pseudo-inverse method to complete the coupled solution and conflict resolution of multi-actuator control targets, generating the final control target for each actuator. The Jacobian matrix pseudo-inverse method transforms the multi-input, multi-output control allocation problem into an optimization problem. Under the premise of satisfying the physical constraints and safety constraints of the actuators, it solves for the optimal control target of each actuator, achieving coordinated control of multiple actuators. Specifically, firstly, a Jacobian mapping matrix between the actuator control input and the vehicle motion state output is established based on the vehicle dynamics model; then, based on the deviation between the current vehicle state and the target state, the optimal control target of each actuator is calculated by solving the pseudo-inverse of the Jacobian matrix. The Jacobian matrix describes the influence capability of each actuator on the vehicle motion state and is obtained by linearizing the vehicle dynamics model. The pseudoinverse of the Jacobian matrix is ​​solved by the least squares method, which minimizes the control error while satisfying the physical limitations and safety constraints of the actuator.

[0071] Conflict resolution is based on a priority rule base. When control requirements from multiple functional components conflict, conflict resolution is achieved according to priority configurations, ensuring the consistency and feasibility of control objectives. After collaborative arbitration by the collaborative control and arbitration layer, control commands for each actuator are generated, including braking torque commands for the braking system, driving torque commands for the drive system, steering angle commands for the steering system, and damping force commands for the suspension system. All control commands use a standardized data format and are passed down to the underlying software layer through the runtime interface layer. Through this collaborative arbitration mechanism, standardized collaborative control of multiple actuators is achieved. When actuator configurations change or vehicle parameters are adjusted, only the configuration parameters need to be modified, without modifying the core arbitration algorithm.

[0072] Step S106: The control commands are protocol adapted through the communication service submodule of the basic software layer and sent to the actuator layer via the vehicle communication bus. The basic software layer receives standardized control commands output by the collaborative control and arbitration layer and adapts them through the communication service submodule. Based on the actuator type and manufacturer, the communication service submodule calls the corresponding protocol configuration file to convert the standardized control commands into a communication protocol format recognizable by the actuator. The braking system uses CAN FD bus communication, and the control commands include parameters such as four-wheel braking torque and braking mode. The drive system uses CAN FD bus communication, and the control commands include parameters such as four-wheel drive torque and drive mode. The steering system uses CAN FD bus communication, and the control commands include parameters such as front wheel angle, rear wheel angle, and steering mode. The suspension system uses CAN FD bus communication, and the control commands include parameters such as four-wheel damping force and suspension height.

[0073] All control commands, after protocol adaptation, are sent to the actuator layer via the vehicle communication bus. The vehicle communication bus employs a redundant design, including at least two CAN FD buses, to ensure the reliability and real-time performance of control command transmission. The communication service submodule simultaneously monitors the communication status of the vehicle communication bus. Upon detecting a communication failure, it triggers a fault handling process, switching to redundant bus communication to ensure the normal transmission of control commands. This design achieves actuator scalability and architectural versatility; changing, adding, or replacing actuator types only requires updating the protocol configuration file.

[0074] Step S107: The actuator layer receives control commands and drives the corresponding actuators to execute. Simultaneously, it feeds back the execution status to the basic software layer via the vehicle communication bus, and then transmits it upwards to the collaborative control and arbitration layer via the runtime interface layer. The actuator layer receives control commands from the basic software layer and drives the corresponding actuators to execute. The braking system adjusts the braking pressure of the four wheels according to the braking torque command to achieve braking control. The drive system adjusts the driving torque of the four wheels according to the driving torque command to achieve drive control. The steering system adjusts the front and rear wheel steering angles according to the steering angle command to achieve steering control. The suspension system adjusts the suspension damping of the four wheels according to the damping force command to achieve suspension control. After all actuators execute the control commands, they feed back the execution status to the basic software layer via the vehicle communication bus. The execution status includes data such as the actual output value of the actuator, the operating status of the actuator, and actuator fault information. The execution status feedback adopts a standardized communication protocol and is uploaded to the domain controller in real time via the vehicle communication bus.

[0075] After receiving execution status feedback, the basic software layer performs protocol parsing and data conversion through the communication service submodule, transforming the execution status into a standardized data format, which is then passed up to the collaborative control and arbitration layer via the runtime interface layer. Based on the execution status feedback, the collaborative control and arbitration layer performs closed-loop control verification, determining whether the actuators are executing control commands correctly. When an actuator fault or anomaly is detected, a fault handling process is triggered. Simultaneously, the execution status feedback is also transmitted to the perception and signal processing layer for closed-loop verification of vehicle state calculation and signal fault-tolerant reconstruction. This execution status feedback mechanism forms a complete closed-loop control chain, ensuring the correct execution of control commands and vehicle driving stability. In the event of a single actuator failure, the collaborative control and arbitration layer reallocates control permissions to the remaining actuators, compensating for the control objective and ensuring vehicle driving stability.

[0076] Example 3 This embodiment provides a vehicle equipped with the scalable hierarchical chassis domain control architecture described in Embodiment 1 above.

[0077] The vehicle can be a sedan, SUV, MPV, or other types of vehicle, and its powertrain can be pure electric, hybrid, or gasoline-powered. The vehicle's overall electronic and electrical architecture adopts a domain-centralized architecture, including a chassis domain, intelligent driving domain, powertrain domain, cockpit domain, and body domain. The domains communicate with each other via in-vehicle Ethernet or CAN bus.

[0078] The chassis domain controller, as the core computing unit of the chassis domain, is deployed with the scalable hierarchical chassis domain control architecture described in this application. The chassis domain controller interacts with the intelligent driving domain controller, the power domain controller, and the cockpit domain controller through a cross-domain interaction interface, receives path planning instructions from the intelligent driving domain, torque distribution instructions from the power domain, and driving mode switching instructions from the cockpit domain, and feeds back chassis status information to each domain.

[0079] In typical control scenarios, when a driver performs a sharp turn on a slippery surface, the chassis sensor cluster collects real-time status information such as wheel speed, yaw rate, and lateral acceleration. This information is standardized through the hardware abstraction sublayer and service sublayer of the basic software layer before being transmitted to the perception and signal processing layer. The perception and signal processing layer calculates the vehicle state based on an 18-DOF vehicle dynamics model and determines that the vehicle is about to enter an unstable region. The VDC, TCS, and RWS components in the pluggable functional component layer simultaneously calculate their respective control requirements. The collaborative control and arbitration layer, based on the current road adhesion coefficient and the control capability boundaries of each actuator, uses configurable arbitration rules to decompose the participation of multiple actuators. It prioritizes the use of the fast-responding brake-by-wire system for wheel-to-wheel braking force distribution and simultaneously calls the rear-wheel steering system for steering assistance. Through multi-actuator collaborative control, vehicle stability control is achieved, preventing vehicle skidding or loss of control.

[0080] In different driving modes, the chassis domain controller achieves differentiated control through configurable arbitration rules. In Sport mode, the multi-objective, multi-dimensional arbitration module of the collaborative control and arbitration layer prioritizes response speed and handling, increasing control authority over the steer-by-wire system and distributed drive system, reducing damping of the active suspension system, and improving vehicle handling responsiveness. In Comfort mode, the arbitration module prioritizes ride comfort, increasing control authority over the active suspension system, suppressing changes in vehicle posture through rapid adjustments of the active suspension, and reducing vehicle bumpiness. In Eco mode, the arbitration module prioritizes minimizing energy consumption, prioritizing the use of low-energy actuators, reducing frequent intervention of the brake-by-wire system, and lowering overall vehicle energy consumption through energy recovery strategies.

[0081] In the event of actuator failure, the vehicle possesses redundant control capabilities. When a single actuator fails, the actuator target unified calculation module of the collaborative control and arbitration layer reallocates the control authority of the remaining actuators using the Jacobian matrix pseudo-inverse method, achieving compensation for the control target. For example, when the front wheel steering system fails, the collaborative control and arbitration layer adds control authority to the rear wheel steering system and inter-wheel braking force distribution, achieving vehicle steering control through rear wheel steering assist and differential braking to ensure vehicle driving stability. When multiple actuators fail simultaneously, the signal verification and failure management module of the perception and signal processing layer triggers fault degradation processing. The collaborative control and arbitration layer selects the corresponding degradation control strategy according to the fault level and inputs the degraded control requirements into the pluggable functional component layer to ensure the basic driving stability of the vehicle under fault conditions.

[0082] The vehicle provided by the embodiments of this application achieves high scalability and high reliability of chassis control functions, meeting the control requirements of intelligent connected vehicles.

[0083] Those skilled in the art will understand that embodiments of the present invention can provide methods, systems, or computer program products. Therefore, the present invention can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0084] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0085] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0086] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0087] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0088] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A scalable hierarchical chassis domain control architecture, characterized in that, It includes, from bottom to top, the following layers: hardware and peripherals layer, basic software layer, sensing and signal processing layer, pluggable functional component layer, collaborative control and arbitration layer, and actuator layer; The pluggable functional component layer includes an algorithm middleware and a functional component cluster. The algorithm middleware provides a standardized model call interface to the functional component cluster. Each functional component in the functional component cluster calls the dynamic calculation model provided by the algorithm middleware through the standardized model call interface and outputs control requirements to the collaborative control and arbitration layer.

2. The scalable hierarchical chassis domain control architecture according to claim 1, characterized in that, The algorithm middleware incorporates a vehicle coupled dynamics model, a driving stability boundary criterion model, a tire force limit constraint model, and a multi-actuator control gradient calculation model, and provides a standardized model calling interface to the upper level. Each functional component can call the dynamic calculation model as needed through the standardized model call interface.

3. The scalable hierarchical chassis domain control architecture according to claim 1, characterized in that, The functional component clusters are divided into five categories of pluggable component clusters, including the braking control component cluster, the steering control component cluster, the drive control component cluster, the suspension control component cluster, and the vehicle dynamic control (VMC) component cluster.

4. The scalable hierarchical chassis domain control architecture according to claim 3, characterized in that, The braking control component cluster includes an ABS anti-lock braking system, a TCS traction control system, and a VDC vehicle dynamic control system. The steering control component cluster includes an SBW steer-by-wire component, an RWS active rear wheel steering component, a variable gear ratio component, and a road feel simulation component. The drive control component cluster includes a built-in torque arbitration component, a creep control component, and a drive anti-slip component; The suspension control component cluster includes a damping adjustment component, a height adjustment component, a roll suppression component, and a pitch suppression component. The vehicle dynamic control (VMC) component cluster includes a tire blowout stability control component, a pre-stabilization control component, and a split-slip stability control component.

5. The scalable hierarchical chassis domain control architecture according to claim 3, characterized in that, Each component cluster has built-in basic control components and reserves space for functional expansion, supporting plug-and-play addition of new components.

6. The scalable hierarchical chassis domain control architecture according to claim 1, characterized in that, Each functional component in the functional component cluster follows a unified specification; The unified specifications include standardized input / output interface definitions, component initialization interfaces, control algorithm execution interfaces, fault feedback interfaces, and configuration parameter interfaces.

7. The scalable hierarchical chassis domain control architecture according to claim 1, characterized in that, Data interaction between the layers of the architecture follows a one-way dependency rule: the lower layer pushes data to the upper layer in a one-way manner, the upper layer sends control commands to the lower layer in a one-way manner, adjacent layers are allowed to provide status feedback, and direct calls between any non-adjacent layers are prohibited.

8. The scalable hierarchical chassis domain control architecture according to claim 1, characterized in that, The hardware and peripheral layer includes a domain control hardware platform, a chassis sensor cluster, an in-vehicle communication bus, a cross-domain interaction interface, and actuator physical nodes. The cross-domain interaction interface is used to receive cross-domain control request signals from the intelligent driving domain, power domain, and cockpit domain, and to transmit standardized cross-domain command data to the upper layer.

9. The scalable hierarchical chassis domain control architecture according to claim 1, characterized in that, The basic software layer, located above the hardware and peripherals layer, includes a hardware abstraction sublayer, a service sublayer, and a runtime interface layer. It completes the standardized encapsulation of hardware and provides a unique standardized interaction channel to the upper layer through the runtime interface layer. When changing the domain controller hardware platform, only the hardware abstraction sublayer needs to be re-adapted; the service sublayer and all layers above it do not need to be modified.

10. The scalable hierarchical chassis domain control architecture according to claim 1, characterized in that, The perception and signal processing layer is located above the basic software layer and is connected to the basic software layer through the runtime interface layer. It processes sensor signals and outputs vehicle status data. The perception and signal processing layer includes a vehicle state dynamics calculation kernel, a chassis multi-source information fusion perception module, and a signal verification and failure management module. The vehicle state dynamics solution kernel is built on an 18-DOF vehicle dynamics model, which includes six degrees of freedom for the vehicle body (longitudinal, lateral, yaw, roll, pitch, and vertical) and three degrees of freedom for each of the four wheels (longitudinal, lateral, and vertical). The chassis multi-source information fusion perception module is used to perform time synchronization and fusion processing on signals from multiple sources such as wheel speed sensors, inertial measurement units, and steering angle sensors, and output standardized vehicle status data. When a signal failure is detected, the signal verification and failure management module completes signal fault-tolerant reconstruction through redundant signal cross-verification.

11. A control method based on the scalable hierarchical chassis domain control architecture according to any one of claims 1-10, characterized in that, include: The vehicle chassis status signals and cross-domain control request signals are collected through the chassis sensor cluster and cross-domain interaction interface of the hardware and peripheral layers. The hardware abstraction sublayer of the basic software layer standardizes and encapsulates the signal. After processing by the service sublayer, the standardized low-level data is passed to the upper layer through the runtime interface layer. The perception and signal processing layer calculates the vehicle state based on the 18-DOF vehicle dynamics model and performs signal verification on the calculated vehicle state data; when an abnormal signal is detected, fault degradation processing is triggered; after the verification is passed, standardized vehicle state data is output. Each functional component in the pluggable functional component layer calls the dynamic calculation model provided by the algorithm middleware through the standardized model call interface, calculates its own control requirements based on the standardized vehicle state data, and outputs them to the collaborative control and arbitration layer. By coordinating and arbitrating the control requirements output by multiple functional components through the collaborative control and arbitration layer, the coupled solution of the control objectives of multiple actuators is completed, and control instructions for each actuator are generated. The control commands are protocol adapted by the communication service submodule of the basic software layer and sent to the actuator layer through the vehicle communication bus. The control commands are received by the actuator layer and the corresponding actuators are driven to execute them. At the same time, the execution status is fed back to the basic software layer through the vehicle communication bus, and then passed up to the collaborative control and arbitration layer through the runtime interface layer.

12. A vehicle, characterized in that, The vehicle is equipped with the scalable hierarchical chassis domain control architecture as described in any one of claims 1-10.

Images