A domain controller-based vehicle multi-mode working system and vehicle

Abstract

The application provides a domain controller-based vehicle multi-mode working system and a vehicle; the system comprises: a power supply module, which is used for converting an output voltage of a vehicle storage battery and outputting a preset voltage; a domain controller, which comprises a main MCU and at least one SOC connected with the main MCU; a communication access module, which is used for outputting a wake-up signal to the main MCU, and comprises a cellular communication module, a near field communication module, a short-distance wireless communication module used for realizing a digital key function and a hard-wire GPIO module connected between the main MCU and an ignition switch; a plurality of sensor modules, which are in communication connection with the domain controller; and a vibration detection module, which is used for detecting vehicle vibration and / or a proximity event. The application realizes multi-mode working which takes into account extremely low power consumption and remote on-demand wake-up.

Description

Technical Field

[0001] This application relates to the field of vehicle domain controllers, and in particular to a multi-mode vehicle operating system and vehicle based on a domain controller. Background Technology

[0002] With the development of intelligent connected vehicles, the vehicle's electronic and electrical architecture has evolved from distributed ECUs (Electronic Control Units) to centralized domain controllers. Intelligent driving domain controllers typically integrate multi-core heterogeneous processors and hierarchical power management units, providing the hardware foundation for refined power consumption management of the entire vehicle.

[0003] Currently, domain controllers generally support normal driving mode and sentry mode. In normal driving mode, all chips and sensors are active, resulting in high system power consumption; in sentry mode, some chips are in sleep mode but the monitoring sensors continue to run, resulting in moderate power consumption. To further reduce static power consumption, existing technologies have proposed an ultra-low power mode where only the main microcontroller unit operates, while the remaining chips and all sensors are in sleep mode.

[0004] However, the above solutions still have significant shortcomings in terms of power consumption and functional coordination: in the ultra-low power mode, all communication modules are in sleep mode, which makes the vehicle unable to respond to external remote wake-up requests, and it is difficult to balance ultra-low power state and on-demand wake-up capability; the existing mode lacks a smooth transition from ultra-low power to full-function operation, and the mode switch often directly wakes up all chips and sensors, causing unnecessary energy loss; at the same time, the existing wake-up strategies are mostly designed separately for specific wake-up sources, making it difficult to uniformly identify and adapt to various heterogeneous wake-up requests, and after wake-up, all sensors are usually activated directly, making it impossible to differentiate the scheduling of sensors according to the actual task scenario, which further aggravates power waste. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides a multi-mode vehicle operating system and vehicle based on a domain controller.

[0006] This application provides a multi-mode vehicle operating system based on a domain controller, the system comprising: The power supply module is used to convert the output voltage of the vehicle battery into a preset voltage and then output it. A domain controller, comprising a main MCU and at least one SOC connected to the main MCU; A communication access module for outputting a wake-up signal to the main MCU includes a cellular communication module, a near-field communication module, a short-range wireless communication module for implementing digital key functionality, and a hardwired GPIO module connected between the main MCU and the ignition switch; and Multiple sensor modules that are communicatively connected to the domain controller; A vibration detection module is used to detect vehicle vibration and / or proximity events, and wakes up the main MCU via an interrupt signal; The main MCU, communication access module, and vibration detection module are all powered by the power supply module or directly by the vehicle battery. The power supply status of the multiple sensor modules and the power supply status of at least one SOC are controlled by the main MCU.

[0007] Preferably, this application also provides a vehicle including the domain controller-based vehicle multi-mode operating system described above, wherein the system is deployed in the vehicle's intelligent driving domain controller or body electronic domain controller.

[0008] The beneficial effects of this application are as follows: On the one hand, by designing a collaborative power supply architecture between the main MCU and the communication access module inside the domain controller, the external communication monitoring capability is retained while maintaining extremely low static power consumption. This achieves a balance between extremely low power consumption and remote on-demand wake-up capability, resolving the contradiction that the communication modules are all in sleep mode in the existing extremely low power mode, which prevents them from responding to external wake-up requests.

[0009] On the other hand, by using the main MCU to uniformly receive and distinguish the multiple wake-up signals and the differentiated power supply control strategy of the sensor module and system-on-a-chip, a smooth transition path from extremely low power standby to full-function operation is constructed, avoiding energy loss caused by the indiscriminate activation of all resources during mode switching, and significantly improving the energy utilization efficiency of the whole vehicle.

[0010] On the other hand, by mapping the wake-up source type to the scene task requirements, the system achieves fine-grained on-demand scheduling of sensor resources, enabling the system to activate the minimum necessary sensor set according to the specific task scenario. This overcomes the power consumption waste caused by powering on all sensors at the same time after wake-up in the existing technology. At the same time, the architecture design of the multi-level operation mode reduces the R&D and maintenance costs of cross-scene function expansion. Attached Figure Description

[0011] Figure 1 This is a signal link diagram of a domain controller-based vehicle multi-mode operating system according to one embodiment.

[0012] Figure 2 This is a power architecture diagram of a domain controller-based vehicle multi-mode operating system according to one embodiment.

[0013] Figure 3 This is a schematic representation of the power supply status and control strategy of the power domain under various operating modes in one embodiment.

[0014] Figure 4 This is a flowchart of a multi-mode vehicle operation method based on a domain controller, according to one embodiment. Detailed Implementation

[0015] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0016] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0017] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0018] This application provides a vehicle that includes the aforementioned multi-mode operating system based on a domain controller. The system can be configured in the vehicle's intelligent driving domain or body electronics domain. Its specific installation location, interface connection method with other electronic and electrical architectures of the vehicle, and the vehicle platform it is adapted to are not limited. Any vehicle that adopts the aforementioned multi-mode operating system architecture to achieve ultra-low power consumption and remote on-demand wake-up function should fall within the protection scope of this application.

[0019] This domain controller-based vehicle multi-mode operating system mainly includes a power supply module, a domain controller, a communication access module for outputting wake-up signals to the main MCU of the domain controller, a vibration detection module, and multiple sensor modules connected to and controlled by the domain controller. The main MCU, vibration detection module, and communication access module are all powered by the power supply module or directly by the vehicle battery. The power supply status of the multiple sensor modules and the SOC of the domain controller are controlled by the main MCU.

[0020] The domain controller may include a main MCU, a memory connected to the main MCU, and at least one System-on-a-Chip (SOC). In this embodiment, there are two SOCs. Both SOCs are powered and controlled by the main MCU. The first SOC is used to implement perception-guided functions, including but not limited to low-speed boot and sentinel functions. The second SOC is used to implement high-performance computing functions, including but not limited to GPU / NPU inference functions, multi-sensor fusion perception functions, and global path planning functions. The first SOC is powered by a first power management module controlled by the main MCU, and the second SOC is powered by a second power management module controlled by the main MCU. The enable terminals (i.e., switches) of the first and second power management modules are respectively connected to different GPIO (General Purpose Input / Output) pins of the main MCU, and the main MCU independently controls the power supply status of each SOC.

[0021] Furthermore, the first power management module supports two power supply states: full-power operating mode and low-frequency operating mode. The full-power operating mode provides the first SOC with its rated operating voltage and full clock frequency to support full-performance operation of the perception-guided function. The low-frequency operating mode reduces the clock frequency and supply voltage of the first SOC, significantly reducing power consumption while maintaining basic perception-guided task processing capabilities. The second power management module only supports on / off control, i.e., it only includes two power supply states: full-power operating mode and off state. The main MCU controls the enable pin of the second power management module to fully power on or completely power off the second SOC, thereby completely eliminating the static power consumption of the second SOC when high-performance computing functions are not required.

[0022] The power supply module converts the output voltage of the vehicle battery to a preset voltage before outputting it. The power supply module can employ an existing DC-DC buck converter cascaded with a low dropout regulator (LDO). The DC-DC buck converter steps down the 12V output from the battery to, for example, 5V, and then the LDO steps it down to, for example, 3.3V, supplying the domain controller and the communication access module used to output wake-up signals to the domain controller's main MCU. It is understood that the power supply module can also consist only of an LDO, which steps down the 12V output from the battery to, for example, 3.3V.

[0023] The communication access module used to output a wake-up signal to the main MCU of the domain controller may include a cellular communication module, a near-field communication module, a short-range wireless communication module for implementing digital key functionality, and a hardwired GPIO module connected between the main MCU and the ignition switch.

[0024] The cellular communication module may include 4G and 5G cellular communication modules for receiving 4G and 5G cellular communication signals, such as, but not limited to, remote summoning commands from mobile terminal applications and dispatch commands from vehicle operation platforms.

[0025] The near field communication module, also known as the NFC module, is used to receive near field communication signals from the NFC tag of the charging lock, near field communication signals from the production line, and unlocking signals from authorized near field communication cards (usually NFC signals from smart mobile communication devices registered on the vehicle).

[0026] The short-range wireless communication module used to implement digital key functionality may include an automotive-grade Bluetooth module based on BLE (Bluetooth Low Energy, such as versions 4.0 to the latest 6.0) technology, used to receive Bluetooth unlocking signals (typically from Bluetooth signals from smart mobile communication devices registered in the vehicle).

[0027] The hardwired GPIO module is used to receive the ignition signal from the ignition switch.

[0028] Multiple sensor modules connected to and controlled by the domain controller may include ultrasonic sensors, laser sensors, navigation sensors, and surround-view cameras. The ultrasonic sensors may include multiple short-range and multiple long-range ultrasonic sensors communicating with the main MCU. The short-range ultrasonic sensors have a sensing range of 0.15 meters to 2.5 meters, and the long-range ultrasonic sensors have a sensing range of 2.5 meters to 8 meters. The laser sensors may include lidar communicating with the main MCU. The navigation sensors may include navigation satellite system receivers (e.g., but not limited to, BeiDou Navigation Satellite System receivers, GNSS (Global Navigation Satellite System) receivers), inertial navigation sensors (e.g., accelerometers, gyroscopes), wheel speed sensors, steering angle sensors, and magnetometers, all communicating with the main MCU. The surround-view cameras may include at least four cameras positioned around the vehicle body. The surround-view cameras may communicate with the first SOC via a deserializer.

[0029] The vibration detection module may include a vehicle body vibration sensor and a short-range millimeter-wave radar; the vibration detection module is used to detect vehicle vibration and / or proximity events, and wakes up the main MCU through an interrupt signal.

[0030] The main MCU can be an automotive-grade microcontroller such as the NXP S32K3 series (e.g., S32K344) or the Infineon AURIX TC3xx series (e.g., TC397). The first SOC can be an automotive-grade system-on-a-chip supporting perception guidance functions such as the Texas Instruments Jacinto 7 series TDA4VH or the Qualcomm Snapdragon SA8650. The second SOC can be an automotive-grade system-on-a-chip supporting high-performance computing functions such as the NVIDIA Orin-X or the Qualcomm Snapdragon 8797. The first power management module and the second power management module can be automotive-grade power management chips such as the Texas Instruments TPS65919-Q1 or the LM25143-Q1. The buck converter in the power supply module can be an automotive-grade synchronous buck controller such as the MPQ8875A or the LM25143-Q1. The low dropout linear regulator can be an automotive-grade low dropout linear regulator such as the TPS7A16-Q1 or the TPS7B84-Q1. The chip models mentioned above are merely illustrative examples. In actual applications, other automotive-grade chips that conform to the AEC-Q100 (Automotive Electronics Council-Q100) standard and ISO 26262 functional safety level can be selected according to functional safety level, computing power requirements and power consumption constraints. Their functional implementation is covered within the protection scope of this invention.

[0031] The memory is used to store computer program code and a working mode strategy table, which at least defines standby mode, energy-saving mode, sentry mode and normal driving mode and their corresponding power supply strategies.

[0032] The power supply strategy for the standby mode includes: the at least one SOC going into deep sleep and the multiple sensor modules being powered off.

[0033] The power supply strategy of the energy-saving mode includes: at least one of the multiple sensor modules is powered on.

[0034] The power supply strategy for the normal driving mode includes: all at least one SOC and the plurality of sensor modules are powered on and operating. The power supply strategy for the sentry mode includes: the main MCU enabling the perception guidance domain of the first SOC (SOC1), i.e., the first SOC operates in low-frequency mode and supplies power to the sensor module used for parking safety monitoring. The sensor module for parking safety monitoring may include a surround-view camera.

[0035] The computer program code contains computer instructions, which, when executed by the main MCU, enable a method to wake up the domain controller in standby mode. The wake-up signal for the standby mode is output to the main MCU via a communication access module.

[0036] Figure 1 The signal link diagram of the vehicle multi-mode operating system is shown. According to the signal and data flow, the system can be divided into four functional layers from left to right: wake-up source layer, communication access layer, domain controller processing layer, and sensor data layer.

[0037] The wake-up source layer mainly includes four typical wake-up sources: mobile APP, vehicle operation platform, charging lock NFC tag, and ignition signal. Among them, the remote communication commands generated by the mobile APP and the vehicle operation platform are transmitted to the 4G / 5G cellular communication module of the communication access layer via the cellular network, the radio frequency signal generated by the charging lock NFC tag is received by the NFC module, and the ignition signal is directly triggered through a hardwired GPIO interrupt.

[0038] The communication access layer includes four communication access units: a 4G / 5G cellular communication module, an NFC module, a short-range wireless communication module for implementing digital key functionality (e.g., a Bluetooth module, Bluetooth Low Energy (BLE)), and hardwired GPIO. In specific applications, the 4G / 5G cellular communication module can establish a data connection with the main MCU of the domain controller processing layer via UART (Universal Asynchronous Receiver / Transmitter) / CAN (Controller Area Network) bus; the NFC module can connect to the main MCU via I2C (Inter-Integrated Circuit) / CAN bus; and the hardwired GPIO can report trigger events to the main MCU via direct hardwired GPIO connection.

[0039] The domain controller processing layer uses the main MCU as the core scheduling node, and communicates with the first SOC through different SPI (Serial Peripheral Interface) / UDP (User Datagram Protocol) interfaces. Figure 1 The middle is labeled as SOC1) and the second SOC ( Figure 1 The communication connection (marked as SOC2) connects to the ultrasonic and / or laser sensors in multiple sensor modules via an SPI interface, and to the navigation sensor via a UART interface. Furthermore, the first and second SOCs communicate with each other via IPC (Inter-Process Communication) / UDP / PCIe (Peripheral Component Interconnect Express) interfaces. The output of the surround-view camera communicates with the first SOC via a deserializer integrated within the domain controller. Because... Figure 2 The main focus is on the system's signal links; therefore, the power supply circuits and power supply relationships of each module are not shown.

[0040] Figure 2 The diagram shows the power architecture of the vehicle's multi-mode operating system, and also illustrates the detailed power supply strategies for each functional module under different operating modes in a specific application environment.

[0041] For example, the main MCU, 4G / 5G cellular communication module, NFC module, vibration detection module, and hardwired GPIO (not shown) for the ignition signal are always independently powered, unaffected by the domain controller's operating mode. The domain controller's internal power architecture is centered on the main MCU's always-powered domain, which is directly connected to the 12V battery bus by the power supply module. This domain maintains continuous power supply in all operating modes to support the main MCU's basic communication monitoring, mode scheduling, and power management functions. SOC1 and SOC2 are powered by independent PMIC1 (Power Management Integrated Circuit) and PMIC2, respectively. The enable pins of both PMICs are independently controlled by the main MCU's general purpose input / output (GPIO) pins. Specifically, SOC1 PMIC1 is off in standby mode, on in power-saving mode, on in sentry mode, and on in normal driving mode; SOC2 PMIC2 is off in standby mode, off in power-saving mode, off in sentry mode, and on in normal driving mode, thereby achieving differentiated and hierarchical power supply for the two SOCs. The sensor modules are independently powered and controlled through corresponding load switch arrays: the surround view camera is controlled by SW1 (Switch 1), the long-range ultrasonic sensor is controlled by SW2, the short-range ultrasonic sensor is controlled by SW3, and the navigation sensor is controlled by SW4. The enable terminals of each load switch are driven by the main MCU through GPIO pins via the power switch control bus, enabling the main MCU to precisely control the on / off state of each sensor group at the sensor subset granularity according to the current operating mode and scene requirements.

[0042] For example, in standby mode, the main MCU is kept powered on, while SOC1 PMIC1, SOC2 PMIC2, and all load switches (SW1 to SW4) are off. The domain controller's static power consumption is only in the milliwatt range of the main MCU and the two independent constantly powered communication modules. When the main MCU recognizes and verifies the remote call command from the mobile APP, it enters power-saving mode. The main MCU controls PMIC1 to turn on via GPIO, causing SOC1 to enter a low-frequency operating state. At the same time, SW1 (surround view camera) and SW2 (ultrasonic sensor) are turned on, while SW3 (short-range ultrasonic sensor) and SW4 (navigation sensor) remain off, so that the domain controller only activates the minimum set of sensors necessary for the call scenario. When the main MCU recognizes the NFC signal from the charging lock, it enters power-saving mode and turns on SW1 (surround view camera) and SW3 (short-range ultrasonic sensor). (Ultrasonic), keeping SW2 and SW4 off to adapt to the sensor requirements of charging alignment scenarios; when the main MCU recognizes the operation platform scheduling command and enters the energy-saving mode, it turns on SW4 (navigation sensor) and keeps SW1, SW2 and SW3 off to adapt to the sensor requirements of scheduling scenarios; in sentry mode, the main MCU turns on PMIC1 to make SOC1 work at full power to process monitoring video data, and at the same time turns on SW1 (surround view camera), keeping PMIC2, SW2, SW3 and SW4 off; in normal driving mode, the main MCU turns on PMIC1 and PMIC2 to make both SOCs work at full power, and at the same time turns on SW1 to SW4 to activate all sensors to support full-function autonomous driving tasks.

[0043] It should be noted that, Figure 1 The signal link shown is Figure 2 The power architectures shown are exemplary diagrams intended to clearly illustrate the signal flow and power control logic of the multi-mode operating system described in this application, and are not intended to limit the scope of protection of this application. The specific power supply logic and signal interfaces used can be adjusted according to actual conditions.

[0044] Specifically, Figure 1The wake-up source types shown (mobile APP, operation platform scheduling, charging lock NFC tag, ignition signal) are only typical examples. In actual applications, they can be expanded to other remote communication command sources, near-field communication signal sources, or vehicle status trigger signal sources according to the vehicle's functional configuration. The 4G / 5G cellular communication module, NFC module, and hardwired GPIO interrupt in the communication access layer can also be replaced by other wireless communication units that comply with automotive-grade communication protocols (such as V2X (Vehicle-to-Everything) communication modules, UWB ultra-wideband modules) or wired trigger interfaces (such as LIN (Local Interconnect Network) bus interrupts, Ethernet wake-up signals). The architecture division, interface types (SPI, UART, I2C, CAN, IPC, PCIe, etc.) and data interaction methods of the main MCU and SOC1 and SOC2 in the domain controller processing layer can be adaptively adjusted according to the specific chip selection and domain controller design scheme. The number, placement, and signal processing links of ultrasonic sensors, navigation sensors, surround view cameras, and decoders in the sensor data layer can also be changed according to different vehicle perception schemes.

[0045] Figure 2 The power domain division (main MCU constant power supply domain, SOC1 PMIC1, SOC2 PMIC2) and load switch array (SW1 to SW4) shown in the diagram are exemplary configurations. In practical applications, more or fewer independent power management chips, load switches, or power domain grouping schemes can be used depending on the chip integration of the domain controller and the sensor topology. The switching state configuration (ON / OFF) of each power domain in the four operating modes can also be remapped according to the specific scenario task requirements and power consumption optimization strategies. In addition, the power supply path of the communication modules (4G / 5G cellular communication modules, NFC modules) with independent constant power design can also be equivalently powered by the vehicle battery through other power distribution networks (such as intelligent power distribution units, area controllers), and is not limited to... Figure 2 The direct LDO connection method is shown.

[0046] Those skilled in the art should understand that, without departing from the technical principles of this application, modifications can be made to... Figure 1 and Figure 2 Equivalent replacements and adaptive modifications to the signal links, communication interfaces, power control topologies, and sensor configurations shown are all within the scope of protection of this application.

[0047] It's important to note that in this case, MCU refers to a low-power, always-on core processor within the domain controller, responsible for lightweight tasks such as basic communication monitoring, power management, and wake-up signal reception. In contrast, a system-on-chip (SoC) is the main computing chip that handles high-performance sensing, decision-making, and complex vehicle control tasks.

[0048] Based on the above hardware architecture, a multi-mode vehicle operation method based on a domain controller can be described as follows: Figure 1 As shown. The method mainly includes the following steps: S100: When the domain controller is in the standby mode, when a wake-up signal is received through the communication access module or an interrupt wake-up signal is output by the vibration detection module, the main MCU performs a security verification on the wake-up signal.

[0049] S200: After the security verification is passed, the main MCU queries the working mode strategy table according to the wake-up signal, determines the target operating mode, and executes the corresponding target operating mode activation process; the target operating mode is any one of the energy-saving mode, the sentry mode, or the normal driving mode.

[0050] Preferably, S100 includes S101-S103.

[0051] S101: When the domain controller is in the standby mode, the main MCU listens for the wake-up signal through the communication access module and receives the interrupt wake-up signal output by the vibration detection module.

[0052] Specifically, the communication access module includes a cellular communication module, a near-field communication module, a short-range wireless communication module, and a hardwired GPIO module. In the standby mode, the main MCU maintains power supply to the communication access module to listen for wake-up signals from different wake-up sources.

[0053] Specifically, the cellular communication module is an automotive-grade cellular communication unit integrating a baseband processor and an RF front-end, supporting fourth-generation or fifth-generation mobile communication protocols. In the standby mode, the cellular communication module is configured by the main MCU to listen for paging channels, disabling the data service RF channel and retaining only the control plane receiver to listen for paging messages transmitted via mobile network operator base stations. When the cloud server issues a remote summoning request from a mobile terminal application or a scheduling instruction from the operating platform to the vehicle through the core network, the paging message carries a wake-up identifier code. After parsing the identifier code, the cellular communication module reports the wake-up event to the main MCU through a general-purpose input / output interrupt pin, and simultaneously transmits the instruction payload to the main MCU.

[0054] Specifically, the near-field communication module is an automotive-grade radio frequency communication unit that supports near-field communication protocols or radio frequency identification protocols. Its radio frequency antenna is deployed on the bottom of the vehicle or in a preset near-field sensing area on the vehicle body. In the standby mode, the near-field communication module is configured by the main MCU to a reader listening state, and the radio frequency front end transmits carrier signals at a preset polling frequency and listens for tag responses. When a near-field communication tag for a charging lock, a near-field communication reader / writer at a production line workstation, or an authorized near-field communication card enters the electromagnetic coupling range of the antenna, the near-field communication module reads the scene identification and identity code information stored in the tag through load modulation and demodulation, and transmits the reading result to the main MCU.

[0055] Specifically, the short-range wireless communication module is an automotive-grade wireless communication unit compliant with the Bluetooth Low Energy protocol. In the standby mode, the short-range wireless communication module is configured by the main MCU to broadcast scan mode, and the radio frequency front-end periodically listens to the broadcast channel within the short-range wireless communication range at a preset scanning interval. When an authorized Bluetooth key or a paired mobile terminal enters the preset communication range around the vehicle, the short-range wireless communication module captures its broadcast data packets and extracts the Media Access Control address and device identifier, triggering the main MCU to read the identifier information via an interrupt signal.

[0056] Specifically, in the standby mode, the main MCU continuously monitors the power mode signal of the vehicle ignition switch through the hardwired GPIO module. When the hardwired level is detected to transition from low to high, the main MCU is directly triggered to interrupt the signal to identify the vehicle ignition signal.

[0057] Specifically, the vibration detection module is directly powered by the power supply module or the vehicle battery, independent of the internal power domain of the domain controller. In the standby mode, all power domains within the domain controller are turned off, but the vibration detection module remains powered to continuously detect vehicle vibrations and / or proximity events. When the vibration detection module detects a vibration amplitude exceeding a preset threshold or a nearby object with an effective reflective cross-section exceeding a preset threshold, it outputs an interrupt wake-up signal to the main MCU to wake up the main MCU.

[0058] In some embodiments, the main MCU dynamically schedules the activation state of the communication access module according to a preset communication monitoring strategy in the standby mode. For example, when the vehicle is parked for a long time and the user has bound a mobile terminal application, the main MCU keeps the cellular communication module continuously active and shuts down the power supply to the short-range wireless communication module and the near-field communication module; when the vehicle enters the charging parking area, the main MCU can activate the near-field communication module in advance and maintain the basic monitoring function of the cellular communication module based on vehicle location information or user historical behavior prediction, so as to balance the timeliness of response to multi-source wake-up requests and the control of system static power consumption.

[0059] S102: The main MCU identifies the wake-up source type of the wake-up signal, and the wake-up source type includes at least one of the following: remote communication command, near-field communication signal, short-range wireless communication signal, vehicle ignition signal or interrupt wake-up signal.

[0060] In some embodiments, the main MCU establishes a unified wake-up source type enumeration table, which is used to automatically classify and respond to multi-source wake-up requests based on signal physical layer characteristics and protocol layer identifiers.

[0061] For example, when a user initiates a remote vehicle summoning request through a mobile terminal application, the cloud server encapsulates the request into a remote communication command frame containing a preset protocol header field. This protocol header field carries a wake-up source type identifier code, which is transmitted to the vehicle's cellular communication module via a fourth-generation or fifth-generation mobile communication network. The main MCU reads the command frame via a universal asynchronous receiver / transmitter (UART), parses the wake-up source type identifier code in the protocol header field, and classifies it as a remote summoning subtype within the remote communication command. Similarly, when the operating platform generates a dispatch command based on vehicle dispatching needs, the protocol header field of the dispatch command frame carries a dispatch type identifier code distinct from the remote summoning subtype. This code is transmitted to the main MCU via the same or different cellular communication links, where it is parsed and classified as a platform dispatching subtype within the remote communication command. When a user or platform issues a sentry activation command, the main MCU parses the sentry activation type identifier code in the protocol header field and classifies it as a sentry activation subtype within the remote communication command.

[0062] For example, the near-field communication signal of the charging parking lock is emitted by a near-field communication tag or reader installed on the ground of the charging parking space. When the near-field communication module installed on the bottom of the vehicle enters the tag's communication range, it reads the charging alignment scene identifier and parking lock identification code stored in the tag through electromagnetic coupling. The near-field communication module transmits the read radio frequency data frame to the main MCU. The main MCU parses the device type identifier field in the radio frequency data frame. When it recognizes that the field matches the preset charging parking lock device code library, it classifies the current wake-up signal as the charging parking lock subtype in the near-field communication signal. The production line near-field communication wake-up signal is emitted by a near-field communication reader deployed at the factory production line workstation or test bench. It is used to trigger a guidance task at a specific workstation during vehicle roll-off or rework. Its radio frequency data frame carries a production line workstation identifier code. The main MCU classifies it as the production line wake-up subtype in the near-field communication signal by matching it with the preset production line device code library. The authorized near-field communication card unlocking signal is sent by the physical near-field communication card with pre-set pairing information in the vehicle key management system. After receiving such a signal, the main MCU extracts the key identification information and compares it with the pre-stored authorized device whitelist. After verification, it is classified as the local authorized unlocking subtype in the near-field communication signal.

[0063] For example, the digital unlocking signal is emitted by a low-power Bluetooth device with pre-set pairing information in the vehicle key management system. The short-range wireless communication module captures its broadcast data packets and extracts the media access control address and device identifier. The main MCU extracts the key identification information and compares it with the pre-stored authorized device whitelist. After verification, it is classified as the digital unlocking subtype in the short-range wireless communication signal.

[0064] For example, when the driver turns the ignition switch to the start position or presses the start button, the body control module detects a change in hardwire level and broadcasts a power mode message containing an ignition status identifier via the controller area network bus. The main MCU captures the message through the controller area network bus monitoring module, parses the ignition status identifier field, and when it is determined that the value of the field is a preset valid ignition request value, it classifies the current wake-up signal as a vehicle ignition signal type.

[0065] For example, when the vehicle is in the standby mode, the main MCU continuously receives the low-power standby status signal of the vibration detection module through the general purpose input / output interrupt pin or the controller area network bus monitoring module; when the vibration detection module detects that the vibration amplitude exceeds a preset threshold, or detects an approaching object with an effective reflection cross-section exceeding a preset threshold, it sends an interrupt request to the main MCU; after responding to the interrupt request, the main MCU classifies the current wake-up signal as an interrupt wake-up signal type.

[0066] In some embodiments, after receiving the various wake-up signals mentioned above, the main MCU first extracts the physical layer access characteristics of the wake-up signal, then parses the protocol layer identification field, and matches the predefined entries in the wake-up source type enumeration table by looking up a table, thereby completing the automatic identification and classification of the wake-up source type within a single scheduling cycle. The physical layer access characteristics include the access medium type, such as cellular network, Bluetooth radio frequency, near-field communication radio frequency, or controller area network bus. The protocol layer identification field includes a wake-up source type identification code, a device type identification field, or an ignition status identification field.

[0067] S103: The main MCU performs security verification on the wake-up signal. The security verification includes at least one of digital signature verification, timestamp anti-replay verification, or two-way authentication on the wake-up signal.

[0068] Specifically, the digital signature verification of the wake-up signal refers to the process by which the main MCU uses a preset public key to decrypt and compare the digital signature attached to the wake-up signal to verify that the wake-up signal has not been tampered with during transmission and was indeed generated by a legitimate sender holding the corresponding private key. For example, when generating the wake-up signal, the sender first performs a hash operation on the message body of the wake-up signal to obtain a message digest, then uses its private key to encrypt the message digest to generate a digital signature, and sends the digital signature along with the original wake-up signal. Upon receiving the message digest, the main MCU uses a preset public key in the vehicle's safety element or trusted execution environment to decrypt the digital signature, obtaining the message digest to be verified. Simultaneously, it performs the same hash operation on the received original wake-up signal to obtain a local message digest. The signature verification is completed by comparing the consistency of the two message digests. If the two message digests match, the digital signature verification is deemed successful; if they do not match, the digital signature verification is deemed unsuccessful, and the main MCU refuses to perform subsequent mode switching operations.

[0069] Specifically, the timestamp anti-replay verification of the wake-up signal refers to the main MCU checking whether the timestamp information carried in the wake-up signal is within a preset valid time window, and verifying whether the unique identifier of this wake-up signal has been recently processed, to prevent attackers from intercepting historical valid wake-up signals and retransmitting them to trigger unauthorized mode switching replay attacks. For example, after receiving a wake-up signal, the main MCU extracts the timestamp field from the signal frame and calculates the difference with the real-time clock value maintained by the main MCU, determining whether the difference is less than a preset tolerance threshold. Simultaneously, the main MCU maintains a queue of unique identifiers for recently processed wake-up signals, and confirms whether the signal is being received for the first time by comparing whether the unique identifier of the current wake-up signal exists in this queue. If the difference is less than the preset tolerance threshold and the unique identifier does not exist in the queue, the timestamp anti-replay verification is considered successful; if the difference is greater than or equal to the preset tolerance threshold, or the unique identifier already exists in the queue, the timestamp anti-replay verification is considered unsuccessful, and the main MCU refuses to perform subsequent mode switching operations.

[0070] Specifically, the two-way authentication of the wake-up signal means that the main MCU not only verifies the legitimacy of the sender's identity but also proves the legitimacy of its own vehicle domain controller to the sender, thereby establishing a secure channel of mutual trust. For example, after the main MCU passes the sender's authentication, it generates a random challenge value and sends it back to the sender via the communication link. The sender uses its private key to sign the challenge value, generates a response value, and returns it. The main MCU uses a preset public key to verify the response value, confirming that the sender indeed possesses a legitimate private key. Simultaneously, the main MCU uses the vehicle's private key to sign the challenge value generated by the sender, generates a vehicle response value, and sends it for the sender to verify the vehicle's identity. If both the sender's authentication and the vehicle's authentication pass, the two-way authentication is considered successful; if either authentication fails, the two-way authentication fails, and the main MCU refuses to perform subsequent mode switching operations.

[0071] In some embodiments, the main MCU can select to execute one or more combinations of the above-mentioned security verification methods based on the source type and risk level of the wake-up signal. For example, for wake-up signals transmitted via a wide area network, such as remote summoning commands from mobile terminal applications or scheduling commands from operating platforms, the main MCU sequentially performs digital signature verification, timestamp anti-replay verification, and two-way authentication to form multi-layer security protection; for wake-up signals with short-distance transmission and limited physical contact range, such as near-field communication signals from charging locks or production line workstations, the main MCU only performs digital signature verification and timestamp anti-replay verification; for wake-up signals transmitted via internal vehicle physical links, such as hardwired GPIO signals from vehicle ignition switches or interrupt wake-up signals from vibration detection modules, the main MCU can simplify the security verification process or skip the security verification steps and directly execute subsequent mode switching operations.

[0072] In some embodiments, the main MCU writes the security verification result into its internal status register in the form of a Boolean verification status identifier, where a first logical value indicates that the security verification has passed and a second logical value indicates that the security verification has failed. The main MCU only allows the execution of the mode switching operation in subsequent steps S200 when the verification status identifier is the first logical value; when the verification status identifier is the second logical value, the main MCU maintains the domain controller in the standby mode and sends a security verification failure notification message to the body control module via the controller area network bus, while simultaneously recording a failure log for subsequent security auditing.

[0073] Preferably, S200 includes S201, S210, S220, and S230.

[0074] S201: The main MCU queries the working mode strategy table to determine the target operating mode.

[0075] S210: When the target operating mode is the energy-saving mode, the main MCU executes the energy-saving mode activation process.

[0076] S220: When the target operating mode is the sentinel mode, the main MCU executes the sentinel mode activation process.

[0077] S230: When the target operating mode is the normal driving mode, the main MCU executes the normal driving mode activation process.

[0078] Preferably, S210 includes S211-S214.

[0079] S211: The main MCU queries the wake-up signal and sensor activation strategy mapping table according to the wake-up signal to determine the set of necessary sensor modules for the scene corresponding to the wake-up signal.

[0080] In some embodiments, the wake-up signal and sensor activation strategy mapping table is stored in the memory in the form of structured data, containing multiple mapping records. Each mapping record uses the wake-up source type identifier code as the primary key index and is associated with the corresponding set of sensor modules required for the scene.

[0081] Specifically, the set of required sensor modules for the scene is stored in the form of a sensor bitmap mask or a list of sensor identifiers, clearly defining the minimum subset of sensors required for the execution of the scene task corresponding to the wake-up source type. The set of required sensor modules for the scene corresponding to each wake-up source type configured in the mapping table includes: When the wake-up signal is a remote summoning command from a mobile terminal application, the set of necessary sensor modules for the scene may include a surround-view camera, a short-range ultrasonic sensor, and a long-range ultrasonic sensor. The surround-view camera is used for perception of the surrounding environment of the parking space, the short-range ultrasonic sensor is used for near-range obstacle detection, and the long-range ultrasonic sensor is used for channel environment detection. When the wake-up signal is a scheduling instruction from the operation platform, the set of necessary sensor modules for the scenario may include a navigation sensor, which is used for path planning and positioning of the target scheduling area; When the wake-up signal is a near-field communication signal from the charging lock, the set of necessary sensor modules for the scenario may include a surround-view camera and a short-range ultrasonic sensor. The surround-view camera is used to identify the charging marking lines on the ground, and the short-range ultrasonic sensor is used to measure the longitudinal distance and lateral offset between the vehicle and the charging lock. When the wake-up signal is a near-field communication signal from the production line, the set of necessary sensor modules for the scenario may include a magnetic navigation sensor and a short-range ultrasonic sensor. The magnetic navigation sensor is used for identification of the workstation guidance path on the production line, and the short-range ultrasonic sensor is used for detection of obstacles around the workstation.

[0082] In some embodiments, the mapping table supports remote updates via over-the-air download technology or a diagnostic interface. When a new wake-up source type is added or the sensor requirements of an existing scenario task change, the main MCU receives a digitally signed updated mapping table packet and writes the new mapping record into the corresponding address area in the memory to achieve dynamic adaptation between the wake-up source type and the sensor activation strategy.

[0083] S212: The main MCU control activates only the sensor modules in the set of sensor modules required for the scene, and keeps the remaining sensor modules in sleep mode.

[0084] Specifically, the main MCU connects to the load switch enable terminals of each sensor module via general-purpose input / output pins to achieve independent power supply control at the sensor level. Each load switch controls the power supply circuits of the surround-view camera, short-range ultrasonic sensor, long-range ultrasonic sensor, laser sensor, navigation sensor, and magnetic navigation sensor, respectively. The main MCU outputs the corresponding general-purpose input / output level combination according to the set of sensor modules required for the scene, turning on the power supply path of the corresponding sensor and turning off the power supply path of the other sensors.

[0085] Specifically, when the main MCU activates the sensor modules in the set of necessary sensor modules for the scene, it sends independent power-on control commands and initialization configuration parameters to each necessary sensor in sequence according to the sensor activation timing sequence associated with the mapping table, so as to avoid the instantaneous current surge caused by multiple sensors being powered on at the same time exceeding the power supply capacity limit of the power supply module.

[0086] Specifically, after activating all sensor modules in the set of necessary sensor modules for the scene, the main MCU continuously monitors the initialization completion status codes returned by each sensor through the serial peripheral interface or internal integrated circuit bus. Only when all necessary sensors for the scene return a ready status code will the corresponding scene task execution process be started to ensure the stability of sensor data output and the reliability of task execution.

[0087] S213: The main MCU configures at least one SOC to go into deep sleep; wherein, when the domain controller includes a first SOC and a second SOC, the first SOC is configured to operate at low frequency or go into deep sleep, and the second SOC is configured to be powered off.

[0088] Specifically, the first power management module supports full-power operation mode and low-frequency operation mode, while the second power management module supports on / off control. The main MCU is connected to the enable terminals of the first and second power management modules through different general-purpose input / output pins to independently control the power supply status of the two SoCs.

[0089] Specifically, when the target operating mode is the energy-saving mode, the main MCU sends a low-frequency mode enable signal or a shutdown control signal to the first power management module through the first general-purpose input / output pin, so that the first SOC enters a low-frequency operating state or a deep sleep state; at the same time, the main MCU sends a shutdown control signal to the second power management module through the second general-purpose input / output pin, so that the second SOC is completely powered off.

[0090] For example, when the wake-up signal is a remote call command from a mobile terminal application or a scheduling command from an operating platform, the main MCU sends a low-frequency mode enable signal to the first power management module, causing the first SOC to enter a low-frequency operating state to maintain basic sensing guidance functions, while simultaneously powering down the second SOC completely. In this low-frequency operating state, the central processing unit cluster inside the first SOC operates at a reduced clock frequency, the graphics processor and neural network processor are shut down, and only real-time operating system scheduling and sensor data interface responses are maintained.

[0091] For example, when the wake-up signal is a near-field communication signal from a charging lock or the production line, the main MCU sends a shutdown control signal to the first power management module, causing the first SOC to enter deep sleep mode and simultaneously powering down the second SOC completely. In this deep sleep state, the clock supply to the central processing unit cluster, graphics processor, neural network processor, and peripheral bus within the first SOC is turned off.

[0092] Specifically, after configuring the power supply status of the first SOC and the second SOC, the main MCU continuously monitors the power supply status confirmation signals returned by the first power management module and the second power management module through the power status feedback pin. Only when the actual power supply status is detected to be consistent with the expected configuration will the subsequent scenario task execution process be started.

[0093] S214: The main MCU executes the corresponding scene task, which includes at least one of the following: responding to the remote summoning command of the mobile terminal application or the scheduling command of the operation platform, controlling the vehicle to travel to a designated location at a preset speed; responding to the charging lock or the near-field communication signal of the production line, controlling the vehicle to perform corresponding actions based on the scene-required sensors.

[0094] Specifically, in response to a remote summoning command from the mobile terminal application, the main MCU controls the vehicle to exit the parking space at a preset first speed and travel to the designated shuttle point. For example, the main MCU parses the coordinates of the designated shuttle point carried in the remote summoning command, combines this with the parking space boundary lines and passageway markings identified by the surround-view camera, and the obstacle distance information fed back by the short-range ultrasonic sensor, to plan a local driving path for the vehicle to exit the parking space. It then sends longitudinal speed control commands and lateral steering control commands to the vehicle chassis control unit, controlling the vehicle to automatically exit the current parking space at the preset first speed and travel along the internal passageway of the parking lot to the designated shuttle point. The preset first speed is pre-configured based on the safety level and power consumption constraints of the energy-saving mode and is lower than the road speed limit in normal driving mode.

[0095] Specifically, in response to the dispatch command from the operating platform, the main MCU controls the vehicle to travel towards the target dispatch area at a preset second speed. For example, the main MCU parses the target dispatch area coordinates carried in the dispatch command, obtains the vehicle's current global position coordinates through the navigation sensor, plans a global path from the current position to the target dispatch area, and sends a longitudinal speed control command to the vehicle chassis control unit, controlling the vehicle to automatically travel towards the target dispatch area along the planned path at the preset second speed. The preset second speed is higher than the preset first speed but lower than the road speed limit under normal driving conditions.

[0096] It should be noted that the preset speed is the limited driving speed in the energy-saving mode. Its value is pre-configured by the main MCU according to the safety level and power consumption constraints of the energy-saving mode and stored in the memory, or dynamically determined according to the speed parameters issued by the remote summoning command of the mobile terminal application or the scheduling command of the operating platform. The preset speed includes the preset first speed and the preset second speed, which together constitute the two speed levels of the graded speed limiting strategy in the energy-saving mode.

[0097] Specifically, the preset first speed corresponds to the remote summoning scenario of the mobile terminal application. This scenario typically occurs in parking lots or enclosed parks, where pedestrians and other stationary vehicles are present. Therefore, the preset first speed is set to a low value, or the speed parameter is directly carried by the remote summoning command, to ensure that the short-range ultrasonic sensor can respond promptly to sudden obstacles within the preset detection range. The preset second speed corresponds to the dispatching scenario of the operation platform. This scenario typically occurs on factory roads or main roads within the park, where the road environment is relatively open and there is less pedestrian interference. Therefore, the preset second speed is set to a value higher than the preset first speed but lower than the road speed limit in the normal driving mode, or the speed parameter is directly carried by the dispatching command, to balance dispatching efficiency and power consumption control in the energy-saving mode. Both the preset first speed and the preset second speed are significantly lower than the road speed limit in the normal driving mode, and both are constrained in real time by the main MCU in the energy-saving mode through the vehicle speed closed-loop control loop of the vehicle chassis control unit.

[0098] Specifically, in response to the near-field communication signal of the charging parking lock, the main MCU controls the vehicle to complete parking alignment based on the surround-view camera and the short-range ultrasonic sensor. For example, the main MCU identifies the charging parking space markings and parking lock position markers through the ground image captured by the surround-view camera, and simultaneously measures the longitudinal distance and lateral offset between the vehicle and the charging parking lock using the short-range ultrasonic sensor. It calculates the deviation between the vehicle's current position and the target alignment position, and sends longitudinal fine-tuning speed commands and lateral steering fine-tuning commands to the vehicle chassis control unit, controlling the vehicle to adjust its position so that the planar offset between the onboard wireless charging receiving coil and the ground transmitting coil meets the preset alignment accuracy requirements.

[0099] Specifically, in response to the near-field communication signal of the production line, the main MCU controls the vehicle to perform production line station guidance based on the magnetic navigation sensor and the short-range ultrasonic sensor. For example, the main MCU identifies the magnetic navigation path markers on the production line floor using the magnetic navigation sensor, plans the guidance path for the vehicle from its current position to the target station, and simultaneously monitors obstacles around the station using the short-range ultrasonic sensor. It then sends longitudinal speed control commands and lateral steering control commands to the vehicle chassis control unit, controlling the vehicle to automatically travel along the guidance path to the target station.

[0100] Preferably, S220 includes S221-S223.

[0101] S221: The main MCU activates the sensor module used for parking safety monitoring.

[0102] Specifically, the sensor module for parking safety monitoring includes a surround-view camera. The main MCU sends a power-on control signal to the load switch of the surround-view camera via a general-purpose input / output pin, enabling the surround-view camera to power on; simultaneously, it keeps the load switches of the other sensor modules in the off state, putting them into power-down sleep mode.

[0103] Specifically, the surround-view camera is a digital camera with wide dynamic range and low-light imaging capabilities, which can be deployed in the front, rear, left, and right directions of the vehicle. After activating the surround-view camera, the main MCU configures its image acquisition parameters and monitors the initialization completion status code returned by the surround-view camera through the mobile industry processor interface. Once a ready status code is detected, the parking safety monitoring task is initiated.

[0104] S222: The main MCU configures at least one SOC portion to power on and operate to maintain the sensing guidance function; wherein, when the domain controller includes a first SOC and a second SOC, the first SOC is configured to operate at full power, and the second SOC is configured to power off.

[0105] Specifically, the main MCU sends a full-power mode enable signal to the first power management module through the first general-purpose input / output pin, causing the first power management module to switch to full-power operation mode. The first SOC operates at full power to undertake the real-time processing of video data from the surround-view camera and the function of abnormal event identification. At the same time, the main MCU sends a shutdown control signal to the second power management module through the second general-purpose input / output pin to maintain the second SOC completely powered off.

[0106] Specifically, in the full-power operating mode, the central processing unit cluster, image signal processor, and neural network processor within the first SOC all resume clock and power supply to support target detection and trajectory prediction calculations in the monitored video stream. The main MCU maintains the power supply off to the graphics processor, autonomous driving algorithm acceleration unit, and navigation and positioning unit in the first SOC that are not related to monitoring tasks, in order to limit unnecessary power consumption.

[0107] Specifically, after configuring the first SOC to operate at full power and the second SOC to be powered off, the main MCU monitors the power supply status confirmation signals returned by the first power management module and the second power management module through the power status feedback pin. When it detects that the first power management module returns a full power operation status confirmation and the second power management module returns a shutdown status confirmation, the parking safety monitoring task is started.

[0108] S223: The main MCU performs parking safety monitoring tasks.

[0109] Specifically, in the sentry mode, the main MCU continuously monitors the interrupt signal output by the vibration detection module. When the vibration detection module detects abnormal vibration or a proximity event, it outputs an interrupt wake-up signal to the main MCU. After responding to the interrupt signal, the main MCU confirms that the first SOC is in full-power operation and starts the video recording and real-time analysis process of the surround-view camera.

[0110] Specifically, during the execution of the parking safety monitoring task, the main MCU maintains the second SOC in a power-off state to limit power consumption related to non-monitoring tasks. When the parking safety monitoring task lasts for more than a preset monitoring time limit and no new abnormal events are triggered, the main MCU controls the domain controller to return to the standby mode, disconnects the power supply to the surround view camera, and puts the first SOC into deep sleep, maintaining only the main MCU, the communication access module, and the vibration detection module in the working state.

[0111] Preferably, S230 includes S231-S233.

[0112] S231: The main MCU activates all sensor modules.

[0113] Specifically, the main MCU sends a power-on control signal to the load switch enable terminals of each sensor module via general-purpose input / output pins, enabling the surround-view camera, short-range ultrasonic sensor, long-range ultrasonic sensor, laser sensor, and navigation sensor to power on and operate. The main MCU sequentially sends power-on control commands and initialization configuration parameters to each sensor module according to a preset sensor activation timing sequence to avoid the instantaneous current surge caused by all sensors powering on simultaneously exceeding the power supply module's capacity limit.

[0114] Specifically, after activating all sensor modules, the main MCU continuously monitors the initialization completion status codes returned by each sensor through the serial peripheral interface or internal integrated circuit bus. Only after detecting that all sensors have returned ready status codes will the subsequent SOC power supply configuration and normal driving task startup process be executed.

[0115] S232: The main MCU configures at least one SOC and the plurality of sensor modules to be powered on and working; wherein, when the domain controller includes a first SOC and a second SOC, the first SOC and the second SOC are configured to work at full power.

[0116] Specifically, after configuring the first SOC and the second SOC to operate at full power and all sensor modules to be powered on, the main MCU monitors the status confirmation signals returned by each power management module and load switch. When it detects that all modules have returned a ready status code, it starts the normal driving task.

[0117] S233: The main MCU performs normal driving tasks.

[0118] S300: When the target operating mode is the energy-saving mode, after the scenario task is completed, the main MCU determines whether there is a need to continue driving; if there is, then execute S302; if not, then execute S303.

[0119] S300 is only applicable to energy-saving mode; the Sentinel mode rollback mechanism is described in S223.

[0120] Preferably, S300 includes S301-S303.

[0121] S301: After the scenario task is completed, the main MCU determines whether there is a need to continue driving.

[0122] In some embodiments, the main MCU performs the judgment in collaboration with the task status monitoring logic and the user demand perception logic.

[0123] Specifically, regarding the determination of whether the scenario task has been completed, the main MCU reads the preset task completion determination conditions and performs state matching based on the scenario task corresponding to the currently executing wake-up source type. For example, when the scenario task is a driving task responding to a remote summoning command from a mobile terminal application, the main MCU obtains the vehicle's current position coordinates through navigation sensors, calculates the planar position deviation between the vehicle's current position and the coordinates of the designated docking point, and determines that the scenario task has been completed when the planar position deviation is less than a preset position convergence threshold and the vehicle's longitudinal speed remains below a preset stationary determination threshold for a preset duration. When the scenario task is a parking alignment task responding to a near-field communication signal from a charging lock, the main MCU uses the ranging data fed back by a short-range ultrasonic sensor and the relative position of the ground markings identified by a surround-view camera to determine whether the longitudinal and lateral offsets between the vehicle-mounted wireless charging receiving coil and the ground transmitting coil are both less than a preset alignment accuracy threshold. If both are less than the threshold, the scenario task is determined to be completed. When the scenario task is a task to drive to the target scheduling area in response to the scheduling instruction of the operation platform, the main MCU determines whether the current position of the vehicle falls within the polygonal geofence boundary of the target scheduling area through the navigation sensor. If it does, the scenario task is determined to be completed.

[0124] Specifically, regarding the determination of whether there is a need to continue driving, the main MCU continuously monitors the user's subsequent operation intention signals through communication monitoring and vehicle status detection functions during and after the execution of the scenario task. The need to continue driving refers to the user's intention, expressed through explicit operation commands or implicit behavioral patterns, to prolong the vehicle's active state and enter normal driving mode after completing the current scenario task. For example, the user's subsequent operation intention signals monitored by the main MCU include: the vehicle ignition signal received through the hardwired GPIO module; new remote communication commands received through the communication access module; and explicit driver operation behaviors detected through the vehicle status detection function, including brake pedal signals, accelerator pedal signals, or steering wheel angle signals. When the main MCU detects any of the above-mentioned user subsequent operation intention signals within a preset user intention monitoring time window, it determines that there is a need to continue driving; if no user subsequent operation intention signals are detected within the preset user intention monitoring time window, it determines that there is no need to continue driving.

[0125] Specifically, the main MCU writes the task completion determination result into its internal status register as a Boolean task completion status flag, and writes the continue driving requirement determination result into its internal status register as a continue driving valid flag or a continue driving invalid flag. A continue driving requirement is determined to exist only when the task completion status flag indicates that the task has been completed and the continue driving flag is a continue driving valid flag; a continue driving requirement is determined to not exist only when the task completion status flag indicates that the task has been completed and the continue driving flag is a continue driving invalid flag; if the task completion status flag indicates that the task has not been completed, the scene task execution flow in the current operating mode is maintained, and no mode switching operation is triggered.

[0126] S302: If there is a need to continue driving, the main MCU controls the domain controller to enter the normal driving mode and executes the normal driving mode activation process described in S230.

[0127] Specifically, if there is a need to continue driving, the main MCU controls the domain controller to enter the normal driving mode, executes the normal driving mode activation process described in S231-S233, activates all sensor modules and all system-on-a-chip, and starts the normal driving task.

[0128] S303: If there is no need to continue driving, the main MCU controls the domain controller to return to the standby mode, disconnects the power supply to the sensor activated in the energy-saving mode and the power supply to at least one SOC, and only keeps the main MCU, the communication access module and the vibration detection module in working state.

[0129] Specifically, the main MCU sends a power-off control command to the scene-essential sensors activated in the energy-saving mode, and controls the enable terminal of the corresponding load switch to be disconnected through the general-purpose input / output pin, thereby cutting off the power supply circuit of the scene-essential sensors and causing their image signal processor, RF front-end and microelectromechanical system detection unit to enter a power-down sleep state.

[0130] Specifically, the main MCU shuts down the local computing resources and peripheral interfaces that are temporarily activated in the power-saving mode to perform scene tasks, including shutting down the image data direct memory access channel and video decoding peripherals, shutting down the high-speed analog-to-digital converter sampling channel, and restoring the central processing unit core clock to the low-frequency, low-power reference frequency of the standby mode.

[0131] Specifically, the main MCU sends a shutdown control signal to the first power management module through the first general-purpose input / output pin, causing the first SOC to enter deep sleep mode; and sends a shutdown control signal to the second power management module through the second general-purpose input / output pin, causing the second SOC to be completely powered off. The clock supply and power supply domains of the central processing unit cluster, graphics processor, neural network processor, and peripheral bus inside the first SOC are all turned off, and the static power consumption is reduced to the microampere level.

[0132] Specifically, the main MCU is configured to maintain a low-power operating state through its internal power management register, keeping the real-time clock, general-purpose input / output controller, controller area network bus interface, general-purpose asynchronous transceiver and serial peripheral interface bus interface in a normally enabled state; maintaining the power supply to the communication access module so that it can continue to perform paging channel listening, broadcast scanning or card listening state; and maintaining the power supply to the vibration detection module to continuously detect vehicle vibration and / or proximity events.

[0133] Specifically, after confirming that all necessary sensors for the scenario have been turned off, temporarily activated computing resources and peripheral interfaces have been reset, and both the first SOC and the second SOC are in deep sleep mode, the main MCU updates the mode status flag of the domain controller to standby mode and sends a mode switching completion notification message to the body control module through the controller area network bus, thus completing a smooth transition from energy-saving mode to standby mode.

[0134] Preferably, this application also provides a vehicle including the domain controller-based vehicle multi-mode operating system described above, wherein the system is deployed in the vehicle's intelligent driving domain controller or body electronic domain controller.

[0135] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0136] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. A multi-mode vehicle operating system based on a domain controller, characterized in that, include: The power supply module is used to convert the output voltage of the vehicle battery into a preset voltage and then output it. A domain controller, comprising a main MCU and at least one SOC connected to the main MCU; The communication access module for outputting a wake-up signal to the main MCU includes a cellular communication module, a near-field communication module, a short-range wireless communication module for implementing digital key function, and a hardwired GPIO module connected between the main MCU and the ignition switch. Multiple sensor modules that are communicatively connected to the domain controller; as well as A vibration detection module is used to detect vehicle vibration and / or proximity events, and wakes up the main MCU via an interrupt signal; The main MCU, communication access module, and vibration detection module are all powered by the power supply module or directly by the vehicle battery. The power supply status of the multiple sensor modules and the power supply status of at least one SOC are controlled by the main MCU.

2. The system according to claim 1, characterized in that, The domain controller also includes a memory connected to the main MCU. The memory stores computer program code and a working mode policy table, which defines standby mode, power-saving mode, sentry mode, and normal driving mode, along with their corresponding power supply policies. The power supply strategy for the standby mode includes: the at least one SOC going into deep sleep and the multiple sensor modules being powered off; The power supply strategy of the energy-saving mode includes: at least one of the plurality of sensor modules is powered on and put into operation; The power supply strategy for the normal driving mode includes: all at least one SOC and the plurality of sensor modules are powered on and operating. The power supply strategy for the Sentinel mode includes: powering on at least one SOC component to maintain the perception guidance function and powering the sensor module used for parking safety monitoring.

3. The system according to claim 2, wherein the computer program code includes computer instructions, and when the main MCU executes the computer instructions, it can implement a method for waking up a domain controller in standby mode, the method comprising: When the wake-up signal or the interrupt wake-up signal is received through the communication access module, the main MCU performs security verification on the wake-up signal. After the security verification is passed, the domain controller is switched from the standby mode to the energy-saving mode, the sentry mode, or the normal driving mode according to the wake-up signal; in the energy-saving mode, computing resources and sensor resources are configured according to the wake-up signal, and the corresponding scene tasks are executed.

4. The system according to claim 3, characterized in that, The wake-up signal includes at least one of the following: The remote communication command includes at least one of the following: a remote summoning command received by the cellular communication module from a mobile terminal application, a dispatching command from an operating platform, or a sentinel activation command from a user terminal or platform terminal. Near-field communication signals include at least one of the following: near-field communication signals received by the near-field communication module from the charging lock, near-field communication signals from the production line, and unlocking signals from authorized near-field communication cards; and at least one of the following: near-field control commands or digital unlocking signals from mobile terminals received by the short-range wireless communication module. The vehicle ignition signal received by the hardwired GPIO module; as well as The interrupt wake-up signal output by the vibration detection module when it detects vibration and / or proximity events; The working mode strategy table includes a wake-up signal and sensor activation strategy mapping table, which is configured with a set of scene-required sensor modules corresponding to different wake-up signals.

5. The system according to claim 4, characterized in that, The security verification of the wake-up signal includes: The wake-up signal is subjected to at least one of the following: digital signature verification, timestamp anti-replay verification, or two-way authentication.

6. The system according to claim 4, characterized in that, The scenario task includes at least one of the following: In response to a remote summoning command from the mobile terminal application or a scheduling command from the operating platform, power is supplied to at least one combination of power supplies for the surround-view camera, ultrasonic sensor, laser sensor, and navigation sensor among multiple sensor modules, and the vehicle is controlled to travel at a preset speed to the designated location of the remote summoning command or the scheduling command. In response to the charging lock or the near-field communication signal of the production line, power is supplied to the surround-view camera, ultrasonic sensor and / or laser sensor in the plurality of sensor modules, and the vehicle is controlled to perform corresponding actions based on the surround-view camera, ultrasonic sensor, laser sensor and the received near-field communication signal; In response to the vehicle ignition signal or unlocking signal, power is supplied to the plurality of sensor modules and all SOCs.

7. The system according to claim 6, characterized in that, It includes two SOCs, wherein the first SOC is used to implement the perception guidance function, and the second SOC is used to implement the high-performance computing function. The first SOC and the second SOC are powered by a first power management module and a second power management module controlled by the main MCU, respectively. The first power management module includes a full-power operating mode and a low-frequency operating mode.

8. The system according to claim 7, characterized in that, In the energy-saving mode, in response to the remote summoning command, the scheduling command of the operation platform, the charging lock, or the near-field communication signal of the production line, the first power management module operates in a low-frequency operating mode so that the first SOC can maintain the perception-guided task processing. In the sentry mode, in response to the interrupt wake-up signal or the sentry activation command, the first power management module is in full-power operation mode, and the second SOC remains powered off.

9. The system according to claim 3, characterized in that, After the scenario task is completed, the main MCU determines whether there is a need to continue driving; if so, it switches to the normal driving mode; if not, it returns to the standby mode and disconnects the power supply to the sensors activated in the energy-saving mode and the power supply to at least one SOC.

10. A vehicle, characterized in that, The system includes a multi-mode vehicle operating system based on a domain controller as described in any one of claims 1 to 9, wherein the system is deployed in the intelligent driving domain controller or the body electronic domain controller of the vehicle.

Images