Power domain control system of multi-core controller based on AutoSar architecture

Abstract

The invention discloses a power domain control system of a multi-core controller based on an AutoSar framework, and relates to the technical field of automobile electronic control, the system uses a hardware layer of a software platform to obtain an operation signal of a vehicle, and an interface platform obtains a power domain of the multi-core controller based on a preset first corresponding relation between a core and the operation signal. Transmitting the operation signal to a first target Core corresponding to the operation signal in a software layer of a software platform; and the first target Core generates a control instruction corresponding to the operation signal, and the interface platform sends the control instruction to a target function module corresponding to the first target Core in a hardware layer of the software platform 102 based on a preset second corresponding relationship between the core and the function module, so that the target function module performs vehicle control based on the control instruction. The method and the device are used for solving the problems of low task execution efficiency and poor whole vehicle operation safety of a power domain controller in the prior art due to a dispersed framework of the EMS and the TCU, and the task execution efficiency and the whole vehicle operation safety are improved by integrating the EMS and the TCU.

Description

Technical Field

[0001] This application relates to the field of automotive electronic control technology, and in particular to a power domain control system based on a multi-core controller of the AutoSar architecture. Background Technology

[0002] Powertrain domain controllers are widely used in automotive powertrain systems, and their importance is increasingly highlighted, especially against the backdrop of the development of intelligent driving and autonomous driving technologies. They not only improve the integration of the powertrain system but also simplify the vehicle's electronic architecture, reducing the number of electronic control units (ECUs), thereby lowering costs and complexity. Driven by the development of new energy vehicles, traditional gasoline vehicles urgently need intelligent upgrades, and the design of powertrain domain controllers is constantly evolving. Modern gasoline vehicles typically employ high-performance multi-core processors to support complex algorithms and real-time data processing in their powertrain domain controllers.

[0003] However, power domain controllers in gasoline-powered vehicles often employ a distributed architecture where the engine controller (EMS) and transmission control unit (TCU) are deployed independently. This means that only a separate EMS hardware unit is configured for engine control, while the TCU operates as an independent hardware component, with both working in parallel. Under this distributed architecture, there is a lack of a unified functional safety protection carrier at the hardware level, and software-level safety tasks must be deployed separately in the low-computing-power chips of the EMS and TCU. The tasks of each control unit are also mixed, making it impossible to achieve unified safety status awareness or meet the "fault isolation and closed-loop management" requirements of high-level functional safety standards such as ASILD. Some core safety objectives cannot be effectively achieved due to cross-ECU communication delays and insufficient safety computing power. Ultimately, this results in the inability to fully cover the functional safety requirements of the vehicle's powertrain system and to adapt to current high-safety-level vehicle development standards. Summary of the Invention

[0004] To address the aforementioned problems and technical requirements, this applicant proposes a power domain control system based on a multi-core controller of the AutoSar architecture. This system aims to solve the problems of low task execution efficiency and poor vehicle operation safety caused by the decentralized framework of EMS and TCU in existing power domain controllers. By integrating EMS and TCU, the system can improve task execution efficiency and vehicle operation safety.

[0005] This application provides a power domain control system based on a multi-core controller of the AutoSar architecture. The system includes: a hardware platform, a software platform, and an interface platform for data interaction between the hardware platform and the software platform. The hardware platform includes: an integrated circuit board designed based on the physical properties of the EMS and TCU and the control requirements of the vehicle; The software platform includes: a hardware layer integrating EMS and TCU underlying logic control resources, and a software layer integrating EMS and TCU software logic control resources. The software platform includes: Core0, Core1 and Core2; Core0 includes engine control resources corresponding to the underlying logic control resources and software logic control resources, Core1 includes vehicle safety control resources corresponding to the underlying logic control resources and software logic control resources, and Core2 includes transmission control resources corresponding to the underlying logic control resources and software logic control resources. The cores communicate with each other based on the IOC communication mechanism. The hardware layer of the software platform 102 communicates with the vehicle to obtain the vehicle's operating signals and calls the standardized input interface of the interface platform. The interface platform, based on a preset first correspondence between the core and the operating signal, transmits the operating signal to the first target Core corresponding to the operating signal in the software layer of the software platform through the standardized input interface. The first target Core generates control instructions corresponding to the running signal and calls the standardized output interface of the interface platform. Based on a preset second correspondence between cores and functional modules, the interface platform sends the control instructions to the target functional module corresponding to the first target Core in the hardware layer of the software platform 102 through the standardized output interface, so that the target functional module can control the vehicle based on the control instructions.

[0006] According to the power domain control system based on the AutoSar architecture multi-core controller provided in the embodiments of this application, the software layer in Core1 includes: a functional safety unit; When the functional safety unit needs to actively read the engine's operating signal, it generates a data reading command and calls the cross-core standardized interface of the interface platform. Based on a preset third correspondence between the core and the operating signal, the interface platform sends the data reading command to the third target core in the hardware layer of the software platform through the cross-core standardized interface, and transmits the data read by the third target core back to the functional safety unit through IOC inter-core communication.

[0007] According to the power domain control system based on the AutoSar architecture multi-core controller provided in the embodiments of this application, the functional safety unit includes: a business function module, a lightweight monitoring module, and a safety management module; The business function module receives the vehicle's operating signal, generates control commands based on the operating signal, and transmits the control commands to the lightweight monitoring module; the lightweight monitoring module verifies the execution logic of the business function module based on the control commands, and transmits the operating signal and verification result to the safety management module; the safety management module determines whether there is an operating fault based on the operating signal and the verification result.

[0008] According to the power domain control system based on the AutoSar architecture multi-core controller provided in the embodiments of this application, the safety management module includes: a multi-core task scheduler, a clock monitor, a memory integrity tester, a task timing verifier, and a synchronization verifier; Core1 schedules security monitoring tasks through a multi-core task scheduler, a clock monitor monitors the clock stability of Core0 and Core2 in real time, a memory integrity tester verifies the data integrity of the Core0 power control memory segment based on the ECC mechanism, a task timing verifier verifies the task scheduling timing of Core0 and Core2, and a synchronization verifier detects the LockStep core synchronization status. Core1 obtains the running status data corresponding to the security monitoring tasks in Core0 and Core2 through the IOC communication mechanism.

[0009] According to the power domain control system based on the AutoSar architecture provided in the embodiments of this application, the cooperative operation of each core includes: Core0 receives transmission status data from Core2, determines the collaborative operation strategy between the engine and transmission based on the transmission status data and engine status data, and sends engine control commands via the CAN bus to control the engine's power output, and sends transmission control commands via the SPI interface to control the shifting operation of the transmission's shift solenoid valve. Core1 monitors the collaborative work tasks of Core0, determines whether there are any abnormal control commands sent by Core and whether there are any abnormal transmission status data transmitted by Core2; if any one or more abnormalities are found, it generates a safety response command and sends the safety command to Core0, so that Core0 can adjust the real-time collaborative work strategy based on the safety response command.

[0010] According to the power domain control system based on the AutoSar architecture provided in the embodiments of this application, when Core1 determines that a preset high-level anomaly has occurred, it sends an emergency safety command to Core0 and Core2; Core0 stops the preset power control task based on the emergency safety command, controls the engine torque within the preset safety range, and controls the transmission to switch to the preset emergency gear; Core2 stops performing the status acquisition operation and performs the operation of writing the anomaly information to the flash memory.

[0011] According to the power domain control system based on the AutoSar architecture provided in the embodiments of this application, Core1 performs safety monitoring tasks with the highest priority. Core0 determines the execution priority of security monitoring tasks based on the task cycle, where the longer the task cycle, the lower the execution priority. Core2 executes auxiliary tasks based on the lowest priority.

[0012] According to the power domain control system based on the AutoSar architecture multi-core controller provided in the embodiments of this application, the hardware layer of the software platform includes: a service layer, a hardware abstraction layer, and a driver layer; When the hardware layer of the software platform determines that an engine failure has occurred based on the operation signal, it calls the target interface corresponding to the engine failure in the service layer to forward the engine failure to the second target core in the driver layer through the hardware abstraction layer, and writes the engine failure into the flash memory based on the FLS in the storage driver in the second target core.

[0013] According to the power domain control system based on the AutoSar architecture provided in the embodiments of this application, when the system is powered on, the initialization operations of Core0, Core1 and Core2 are performed in the initialization order of Core0 first, then Core1 and finally Core2.

[0014] According to the power domain control system based on the AutoSar architecture multi-core controller provided in the embodiments of this application, the control commands include: fuel injection control commands; The software platform calls the PWM output standardization interface of the interface platform and sends the fuel injection control command to the PWM module corresponding to Core0 based on the second correspondence, so that the PWM module outputs the fuel injection control command to perform vehicle fuel injection control.

[0015] The power domain control system based on the AutoSar architecture provided in this application integrates the EMS and TCU. After integration, the correspondence between cores, hardware resources, and functional modules is set based on the characteristics of the EMS and TCU. Furthermore, memory is partitioned based on power control and safety functions to ensure balanced memory load. Safety functions are distributed separately in Core1 to improve the safety and response speed of task execution, meeting the real-time and safety requirements of engine-transmission coordinated control. At the same time, a low-latency cross-core function communication mechanism is built using the inter-core IOC communication mechanism, ultimately resulting in a highly integrated, highly safe, and highly real-time power domain control system, which improves task execution efficiency and the safety of vehicle operation. Attached Figure Description

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

[0017] Figure 1 This is a schematic diagram of the power domain control system based on the AutoSar architecture multi-core controller provided in the embodiments of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0019] To further clarify the technical issues addressed in this application: 1. It adopts a distributed software architecture, resulting in high integration and maintenance costs.

[0020] The existing power domain controller adopts a distributed software architecture with no unified standard for module interfaces. When integrating different functional modules, the interfaces need to be manually adapted one by one, resulting in a long configuration cycle. Due to the dispersion of EMS and TCU, there are conflicts in the reuse of hardware resources such as CAN and I / O. Additional hardware needs to be added when expanding functions, which cannot meet the flexible iteration requirements of the power domain. When upgrading functions or replacing modules in the later stage, the entire system needs to be re-debugged, resulting in high transformation costs.

[0021] 2. Memory allocation lacks security isolation, posing a high risk of anomalies.

[0022] Existing technology uses a static fixed memory allocation method. When a non-core module experiences a memory overflow, it will directly tamper with the memory data of the power control core module, causing abnormal power output.

[0023] 3. Kernel load distribution is unbalanced, and module communication is inefficient.

[0024] Existing technologies simply distribute basic functions across different kernels, with functional safety modules and EMS / TCU control tasks mixed within the same kernel, lacking hardware-level fault domain isolation. High data transmission latency leads to delayed response to power control commands, easily causing program freezes and execution flow chaos, making it difficult to support the millisecond-level real-time requirements of engine-transmission coordinated control.

[0025] 4. Insufficient functional safety level and weak risk resistance capability.

[0026] The existing power domain controller architecture, memory, and kernel allocation have serious flaws that significantly impact vehicle safety. Specifically, the distributed architecture lacks standardized secure data interaction interfaces, making the transmission of safety signals between modules prone to packet loss and out-of-order delivery, increasing the risk of power system miscontrol. The lack of memory isolation allows local module anomalies to propagate into system-level failures, failing to meet the fault containment requirements of functional safety. High kernel load reduces the real-time performance of power control, hindering timely response to fault detection signals and weakening the system's ability to handle safety faults.

[0027] In summary, existing power domain controllers have many shortcomings, and there is an urgent need to develop a power domain controller platform with high integration, low maintenance cost, and high security.

[0028] This application provides a power domain control system based on a multi-core controller of the AutoSar architecture, such as... Figure 1 As shown, the system includes: a hardware platform 101, a software platform 102, and an interface platform 103 for data interaction between the hardware platform 101 and the software platform 102.

[0029] The hardware platform 101 includes an integrated circuit board designed based on the physical properties of the EMS and TCU and the control requirements of the vehicle.

[0030] Specifically, the hardware platform 101 integrates a multi-core microcontroller (TC3xx), CAN / CAN-FD communication, ADC / I / O peripherals, and a power management unit, serving as the hardware carrier for power control.

[0031] The software platform 102 includes: a hardware layer that integrates EMS and TCU underlying logic control resources, and a software layer that integrates EMS and TCU software logic control resources.

[0032] The software platform 102 includes: Core0, Core1 and Core2; Core0 includes the engine control resources corresponding to the underlying logic control resources and software logic control resources, Core1 includes the vehicle safety control resources corresponding to the underlying logic control resources and software logic control resources, and Core2 includes the transmission control resources corresponding to the underlying logic control resources and software logic control resources.

[0033] The cores communicate with each other based on the IOC communication mechanism.

[0034] The hardware layer of the software platform 102 communicates with the vehicle to obtain the vehicle's operating signals and calls the standardized input interface of the interface platform. Based on the preset first correspondence between the core and the operating signal, the interface platform transmits the operating signal to the first target Core corresponding to the operating signal in the software layer of the software platform 102 through the standardized input interface.

[0035] The first target, the Core, generates control commands corresponding to the operating signals and calls the standardized output interface of the interface platform. Based on a preset second correspondence between cores and functional modules, the interface platform sends the control commands to the target functional module corresponding to the first target Core in the hardware layer of the software platform 102 through the standardized output interface, so that the target functional module can control the vehicle based on the control commands. The functional module is used to execute tasks.

[0036] This application integrates the EMS and TCU, and after integration, sets the correspondence between cores, hardware resources, and functional modules based on the characteristics of the EMS and TCU. Furthermore, it partitions the memory based on power control and safety functions to ensure balanced memory load, and distributes safety functions separately in Core1 to improve the safety and response speed of task execution, meeting the real-time and safety requirements of engine-transmission coordinated control. At the same time, it uses the inter-core IOC communication mechanism to build low-latency cross-core functional communication, ultimately obtaining a highly integrated, highly safe, and highly real-time power domain control system, thereby improving task execution efficiency and the safety of vehicle operation.

[0037] Specifically, based on the AutoSar architecture, the functional modules of the multi-core controller are divided according to layers and cores, as detailed below: The hardware layer includes the basic software layer (BSW), which is a collection of standardized underlying services (integrating underlying logical control resources of EMS and TCU). It is responsible for the basic management of the system and unified control of hardware resources, and is mainly deployed on Core0.

[0038] BSW mainly includes: System Service, Memory Service, Communication Service, I / O Hardware Abstraction, Micro-controller Driver, Memory Driver, and Communication Driver.

[0039] System Service: Includes OS, ECUM, Dem, etc., responsible for multi-core task scheduling, ECU process management, and fault event diagnosis and management. Memory Service: Includes MemIf, Fee, etc., uniformly manages access to different storage media and is responsible for flash memory storage of fault codes and program parameters. Communication Service: Includes CanIf, CanTrcv, etc., responsible for CAN signal encapsulation, transmission, reception, and parsing. I / O Hardware Abstraction (I / O Drivers): Responsible for sensor signal acquisition and actuator control. Micro-controller Driver, Memory Driver, Communication Driver: Includes MCU / GTM responsible for the TC3xx chip's clock and core initialization; Fls flash memory driver, directly operating the chip's flash memory hardware; CAN / LIN bus hardware driver, directly controlling the CAN / LIN transceiver hardware.

[0040] Specifically, the interface platform 103 includes a runtime environment (RTE): providing standardized interfaces so that the software layer of the software platform 102 can use the underlying services simply by calling the RTE interface without directly manipulating the hardware.

[0041] Specifically, the software platform 102 includes the core of the software layer that carries business functions and is responsible for realizing the logic of the fuel vehicle power system, such as engine control, powertrain coordination, and functional safety strategies. It mainly includes the following modules.

[0042] EMS ASW: Engine Management Application Layer Software, located in Core0, is responsible for the core control logic of fuel vehicle engines (such as fuel injection timing, ignition control, and torque calculation), and is the core business module of the power domain.

[0043] FctlSfty_L3: Functional safety application layer software, located in Core1, is responsible for power system fault detection (hardware / software faults) and safety status decisions (such as limiting torque during faults). It is a core module that meets ASIL safety standards.

[0044] IOHwAb: Input / output hardware abstraction functions and low real-time auxiliary tasks are placed in Core2.

[0045] In one specific embodiment, this application performs data transfer through layered invocation and inter-core communication, specifically including: Software layer (ASW) to basic software layer (BSW): The ASW layer calls BSW services through the standardized interface provided by RTE.

[0046] Taking EMS fuel injection pulse width control as an example: when EMS ASW needs to output fuel injection control signal, it will call the predefined PWM output standardization interface of RTE; RTE, based on the preset core and functional module binding rules, directly forwards the request to the Core0 dedicated I / O Hardware Abstraction layer; finally, the PWM module in Core0's I / O Drivers outputs the precise pulse width signal.

[0047] This application allows power control commands to directly reuse the full BSW basic services of Core0 without needing to flow across cores, ensuring the real-time performance of power control.

[0048] In one specific embodiment, the data flow within the BSW layer is as follows: calls are made in the order from the service layer to the hardware abstraction layer and then to the driver layer.

[0049] When the hardware layer of software platform 102 determines that an engine failure has occurred based on the running signal, it calls the target interface corresponding to the engine failure in the service layer to forward the engine failure to the second target core in the driver layer through the hardware abstraction layer, and writes the engine failure to flash memory based on the FLS in the storage driver in the second target core.

[0050] Specifically, taking the secure storage of fault codes as an example: when the Diagnostic Event Management (Dem) of the System Service layer detects an engine fault, it will call the following in a set order: first, the MemIf interface of the Memory Service layer is called, then the request is forwarded through the Memory Hardware Abstraction layer, and finally the Fls in the Core0 dedicated MemoryDriver writes the fault code to the flash memory.

[0051] This application avoids redundant deployment of basic services on different cores by binding all BSW services to Core0, while ensuring unified management and control of fault data storage.

[0052] In one specific embodiment, communication between cores is carried out using core-level isolation and resource reuse.

[0053] When the functional safety unit needs to actively read the engine's operating signals, it generates a data reading command and calls the cross-core standardized interface of the interface platform. Based on the preset third correspondence between the core and the operating signal, the interface platform sends the data reading command to the third target Core in the hardware layer of the software platform 102 through the cross-core standardized interface, and sends the data read by the third target Core back to the functional safety unit through IOC inter-core communication.

[0054] Specifically, taking the fault signal acquisition of the Core1 functional safety unit as an example: when the Core1 functional safety unit (FctlSfty_L3) needs to read the hardware signal of engine speed, it will initiate a request through the cross-core standardized interface of RTE; based on the preset inter-core resource call rules, RTE forwards the request to the I / O HardwareAbstraction layer of Core0. After the I / O Drivers of Core0 complete the signal acquisition, the data is sent back to the Core1 safety unit through the chip IOC inter-core communication.

[0055] This application achieves both physical isolation between the security unit and the power control core, and reuses the basic hardware resources of Core0, avoiding the waste of computing power caused by independently deploying the full BSW on the security core.

[0056] In addition, the hardware layer communicates with external hardware: through bus hardware such as CAN / LIN, it communicates with the vehicle ECU, sensors, and actuators.

[0057] In one specific embodiment, the integrated circuit board of the hardware platform 101 is integrated in the following ways: main chip hardware integration, communication interface hardware integration, I / O peripheral hardware integration, and auxiliary hardware unit integration.

[0058] The main chip hardware integration includes: It adopts a multi-core architecture chip as the core hardware carrier and integrates the hardware peripheral resources built into the main chip.

[0059] Core control peripherals: integrate hardware modules such as GTM, Wdg, and MCU to support basic functions such as timing control and system monitoring in the power domain.

[0060] The communication interface hardware integration includes: It integrates multiple types of vehicle communication hardware interfaces to adapt to signal transmission in different scenarios.

[0061] Basic communication hardware: integrates hardware interfaces such as CAN and SPI for connecting to traditional vehicle-mounted underlying nodes.

[0062] High real-time communication hardware: Integrates FlexRay hardware interface to meet the high real-time data interaction requirements of the power system.

[0063] I / O peripheral hardware integration includes: It integrates multiple types of input / output (I / O) hardware modules to cover the signal interaction needs of the power domain.

[0064] It integrates hardware such as Adc, Dio, PWM, and Port, and also includes GPIO general-purpose input / output hardware for acquiring sensor signals, controlling switching devices, and outputting actuator drive signals.

[0065] The auxiliary hardware unit integration includes: Power management hardware: Integrated power management unit (PMU) enables dynamic power allocation of hardware modules.

[0066] Heat dissipation hardware design: The heat dissipation structure is matched with the thermal simulation to ensure the stable operation of the hardware system under high load.

[0067] In one specific embodiment, the software platform 102 is integrated with the operational system scheduling based on the AutoSar architecture. Through a task scheduling mechanism, the software logic of the multi-functional units runs in parallel without interference. Based on functional division into modules, each module corresponds to the function of the original independent controller, and data interaction is achieved through standardized interfaces.

[0068] Specifically, it is divided into three computing power partitions: Core0, Core1, and Core2. The specific implementation includes: Specifically, Core0 is the main control core of the power domain, responsible for the entire process of engine management. Logic control resources are used to control the execution of these tasks.

[0069] Specifically, the software logic control resources for engine control resources include: The first application software layer (EMS-APP1) is responsible for the core control logic of the engine and is the business decision module for power output.

[0070] The underlying logic control resources (hardware logic control resources) for engine control specifically include: Hardware Abstraction Layer (HAL): Encapsulates hardware interfaces such as system services, memory, communication, and I / O, shielding the differences in underlying hardware physical characteristics and providing an intermediate adapter for unified calling logic between the application software layer and the hardware layer.

[0071] The basic software layer (BSW) of the hardware layer is described in the above embodiment. MemIf is the unified interface for memory access, and Fee is the flash memory abstraction layer responsible for the secure storage of fault codes and control parameters. The CanTrcv / CanIf communication service module includes CanIf, which is the CAN message encapsulation / parsing interface, and CanTrcv, which is the CAN transceiver abstraction layer responsible for signal interaction on the vehicle bus. It also includes some basic peripheral driver modules, such as CAN, QSPI, ADC, and PWM.

[0072] Specifically, Core1 independently carries out security-related functions and meets ASIL security level requirements.

[0073] This mainly includes: FctlSfty_L3, responsible for fault detection and safety degradation decisions; and a knock detection unit, which monitors engine knock risk and triggers adjustment strategies.

[0074] Specifically, Core1 carries out the coordinated control functions of the transmission.

[0075] Specifically, the software logic control resources for transmission control include: The second application software layer (EMS-APP2) of the software layer is responsible for the transmission's shift logic, speed ratio adjustment, and torque matching. It works in conjunction with Core0's EMS_APP1 to achieve powertrain smoothness.

[0076] Complex Device Drive Layer (CDD): This includes the drive modules for the vehicle speed signal (Tcu_Speed) monitored or processed by the transmission control unit and the drive modules for transmission-specific peripherals, which are responsible for controlling the actuators of the transmission.

[0077] In addition, the underlying logic control resources for transmission control also need to be integrated.

[0078] In one specific embodiment, a real-time operating system (RTOS) based on the Vector tool manages tasks. All tasks are scheduled according to priority, and higher-priority tasks can preempt lower-priority tasks. Regardless of task type, all tasks are triggered by a timer.

[0079] When the system is powered on, the initialization operations of Core0, Core1 and Core2 are performed in the order of initialization first Core0, then Core1 and finally Core2.

[0080] After the system is powered on, it first enters the global initialization phase, and each kernel completes its initialization in the order of Core0, then Core1, and finally Core2.

[0081] Core0 prioritizes the initialization of hardware peripherals such as CAN, I / O, and ADC, as well as the basic AutoSar software, including the configuration of the OS_TIM timer, SPI communication driver, and EMS hardware abstraction layer. At the same time, it completes the binding of "core - functional module - hardware resources" and reserves dedicated computing power and memory resources for power control tasks.

[0082] Core1 synchronously executes the initialization tasks in the functional safety unit, completes the initial configuration of safety modules such as clock monitoring (ESM_Clock_Monitoring_Init), memory integrity testing (ESM_Memory_Integrity_Test_Init), and LockStep core synchronization testing (FS_Check_LockStep_CPU_Error), and binds access permissions to the security-dedicated memory segment through the memory protection unit (MPU), which is only open to the security tasks of Core1.

[0083] Core2 completes the initialization of the low real-time I / O hardware abstraction layer and the transmission control unit (TCU) auxiliary communication module, preparing for subsequent auxiliary status acquisition. After confirming the initialization is complete through inter-core communication (IOC), the entire system enters the normal operation phase.

[0084] In one specific embodiment, after entering the normal operation phase, the specific implementations of Core0, Core1, and Core2 include: Core0, as the "basic service and core power control core," undertakes the core task of engine-transmission coordinated control. It is triggered by timers of different cycles and scheduled in a hierarchical manner: the 1ms cycle task (OS_1ms task) runs with the highest priority. It reads core sensor signals such as engine speed and throttle opening through the ADC driver, and generates basic control commands such as fuel injection pulse width and ignition timing after being processed by the EMS_Callback task (the callback mechanism in EMS).

[0085] The 10ms cycle processing CAN communication task (OS_CAN_10ms task) is responsible for CAN bus communication. On the one hand, it sends the control commands generated by Core0 to actuators such as engine injectors and ignition coils, and on the other hand, it receives transmission status data transmitted by Core2.

[0086] In addition, Core0 also runs the Executive system to execute tasks and the SOH power system health status acquisition task. All tasks follow a preemptive scheduling rule. The core power control task can preempt the low-priority health status acquisition task to ensure millisecond-level real-time performance of engine control.

[0087] Core1, as a "dedicated functional safety core," runs safety monitoring tasks with a 2ms cycle at the highest priority throughout the process. The multi-core task scheduler (ESM_L3_Scheduler_Asil) schedules the safety monitoring tasks, the clock monitor (ESM_Clock_Monitoring) monitors the clock stability of Core0 and Core2 in real time, the memory integrity tester (ESM_Memory_Integrity_Test) verifies the data integrity of the Core0 power control memory segment based on the ECC mechanism, the task timing verifier (ESM_Scheduler_Monitoring) verifies the task scheduling timing of Core0 and Core2, and the synchronization verifier (ESM_L2p_Test_Config) detects the LockStep core synchronization status.

[0088] The safety task obtains the running status data of Core0 and Core2 through inter-core communication (IOC), and is completely independent of the power control task, ensuring that safety monitoring is not interfered with by the core task.

[0089] Core2 runs auxiliary tasks; it reads hardware signals from the hardware layer of the software platform through the SPI communication module, and transmits them to Core0 through the IOC communication mechanism after the hardware signals are processed.

[0090] Core2, acting as a "low real-time auxiliary core," runs auxiliary tasks with a 5ms / 10ms cycle, focusing on acquiring the auxiliary status of the transmission control unit (TCU): it reads the current and fault status of the L9305 shift solenoid valve driver chip through the SPI communication module, acquires signals from the transmission oil pressure sensor and shift position sensor, processes them through the I / O Hardware Abstraction layer, and then transmits the transmission status data to Core0 through inter-core IOC.

[0091] Among them, Core2 tasks have the lowest priority and are scheduled only during the intervals between the execution of high-priority Core0 and Core1 tasks to avoid consuming core computing power.

[0092] In one specific embodiment, the implementation of power control of the vehicle through collaborative operation among the cores includes: Core0 receives transmission status data from Core2, determines the collaborative operation strategy between the engine and transmission based on the transmission status data and engine status data, and sends engine control commands via the CAN bus to control the engine's power output, and sends transmission control commands via the SPI interface to control the shifting operation of the transmission's shift solenoid valves.

[0093] Core1 monitors the collaborative work tasks of Core0, determines whether there are any abnormal control commands sent by Core and whether there are any abnormal transmission status data transmitted by Core2; if any one or more abnormalities are found, it generates a safety response command and sends the safety command to Core0, so that Core0 can adjust the real-time collaborative work strategy based on the safety response command.

[0094] Specifically, after receiving the transmission status data from Core2, Core0 calculates the optimal engine-transmission coordination strategy (such as adjusting shift timing based on vehicle speed and adjusting fuel injection pulse width based on load) by combining real-time engine parameters. On the one hand, it sends commands to control engine power output via the CAN bus, and on the other hand, it sends current control commands to the L9305 chip via the SPI interface to drive the transmission shift solenoid valve to complete smooth shifting. Core1 monitors this process throughout. If it detects abnormal control commands from Core0 (such as fuel injection pulse width exceeding a safety threshold) or abnormal transmission status data from Core2 (such as abnormal solenoid valve current), it immediately generates a safety response command through the program flow reset control mechanism (ESM_Pfc_Reset) and transmits it to Core0 via the RTE interface, instructing Core0 to adjust the coordination strategy.

[0095] In one specific embodiment, if Core1 determines that a preset high-level anomaly has occurred, it sends an emergency safety command to Core0 and Core2; Core0 stops the preset power control task based on the emergency safety command, controls the engine torque within the preset safety range, and controls the transmission to switch to the preset emergency gear; Core2 stops performing status acquisition operations and performs the operation of writing the anomaly information to the flash memory.

[0096] Specifically, when Core1 detects a serious anomaly (such as LockStep core synchronization failure or memory data tampering), the system enters the anomaly response phase: Core1 immediately preempts all low-priority tasks, executes fault handling tasks, and sends emergency safety instructions to Core0 through the inter-core communication mechanism; Core0 immediately suspends regular power control tasks, executes fault response tasks, limits engine torque to a safe range, and switches the transmission to an emergency gear; Core2 stops auxiliary status acquisition, retains only the fault code storage task, and writes the anomaly information to flash memory, ultimately achieving a closed loop of "control-monitoring-fault response," which ensures precise control of the vehicle's power system while minimizing driving safety risks.

[0097] In one specific embodiment, the functional safety unit is the core module of the power domain controller that meets the highest safety level of ASIL D. It is independently deployed on Core1 of the chip and physically isolated from Core0 and Core2 to avoid interference from unsafe tasks. Relying on the chip's hardware safety features and the AutoSar software architecture, it achieves full-process safety control.

[0098] In one specific embodiment, based on the complexity of security functions and the scope of risk control, security monitoring tasks are divided into three levels: Level 1, Level 2, and Level 3.

[0099] Level 1 (Functions) is the core business function module of the ECU, responsible for the basic control logic of the power domain (such as engine fuel injection / ignition calculation, transmission shift strategy, etc.), directly receiving input signals and generating actuator control commands.

[0100] Level 2 (Functions Monitoring) is a lightweight monitoring module for basic functions, performing preliminary verification of the execution logic of Level 1. It includes a Program Flow Check (PFC) module to ensure that the task execution flow of Level 1 conforms to preset logic (preventing program crashes and flow disruptions), and simultaneously transmits monitoring information to Level 3 (Functions Controller) through the inter-level communication interface (L2L3Com).

[0101] The third level is a high-risk security management module defined within the project, responsible for comprehensive security testing and fault response for both hardware and software.

[0102] The third level specifically includes: Hardware Resource Monitoring (CCF): including Power, Clock, RAM, ROM, and Core, which senses the operating status of the main processor core hardware in real time and transmits the hardware status signals to the Detection Mechanisms module.

[0103] Detection Mechanisms are divided into hardware faults (HW faults) and software faults (SW faults), such as verifying RAM data integrity, kernel runtime sequence, clock stability, etc., and sending the detection results (fault signals) to the Safety Management Unit.

[0104] The Safety Management Unit receives fault signals, generates safety instructions (such as "limit power output" and "cut off power to unnecessary actuators"), and transmits them to the power stage interface.

[0105] In one specific embodiment, the functional safety unit also includes an independent redundant monitoring module, which is at a slightly lower level than ASIL D of the main computing unit, in order to avoid safety failure due to the failure of a single module.

[0106] It communicates with the Microprocessor via the FC Interface, transmitting reset signals (FC Rst, MMRst) and bus data (Bus) to achieve cross-module synchronization of safe states. Power and Clock are used to redundantly monitor the ECU's power and clock states, forming a dual hardware state verification with the third-level CCF. Safe State Monitoring is used for closed-loop verification of safe states; it monitors both the safety commands output from the power stage interface and receives feedback on the actual execution state, ensuring that the actuator has indeed entered safe mode.

[0107] The functional safety unit of this application interacts with other levels and modules of the power domain through standardized interfaces, forming a full-link process of "detection-decision-execution-feedback", and realizing the full-link connection of safety control.

[0108] This application reduces the integration and maintenance costs of hardware and software.

[0109] At the hardware level: a multi-core chip is used as the main carrier, integrating a variety of hardware resources and peripherals to replace the traditional decentralized hardware solution of multiple independent ECUs. This reduces the number of independent ECUs in the power domain, simplifies the vehicle wiring harness, and designs a power domain controller platform that directly reduces hardware procurement and vehicle assembly costs. At the software level: Through the AutoSar standardized layered architecture and the dedicated binding design of cores and functional modules, the pain points of traditional distributed architectures, such as "no standard interfaces and manual adaptation required for integration", are solved, avoiding conflicts in the reuse of hardware resources such as CAN and I / O. Function expansion does not require the addition of new hardware, and later module upgrades / replacements do not require full system debugging, which greatly shortens the software integration cycle and reduces maintenance costs.

[0110] This application achieves balanced kernel load, improving the real-time performance and computing efficiency of power control.

[0111] By adopting a core-level dedicated division of labor of "basic service core (Core0) - functional safety dedicated core (Core1) - power function core (Core2)," the power control, functional safety, and transmission coordination tasks are split and run on different cores to avoid single-core computing power overload. At the same time, relying on the native IOC of multi-core chips to replace the traditional bus, low-latency cross-core data interaction is achieved, allowing power control, safety detection and other tasks to run in parallel without interference. This not only solves the problems of "instruction response delay and process chaos" in traditional solutions, but also meets the millisecond-level real-time requirements of engine-transmission coordinated control.

[0112] This application implements memory-safe isolation, eliminating the risk of system anomalies.

[0113] By using the MPU's memory partitioning strategy, dedicated memory areas are divided according to functional safety levels: functional safety tasks have independent memory read / write / execution permissions, while application tasks can only access protected memory in read-only mode. This completely avoids the problem of non-core module memory overflows and tampering with power control data, and significantly improves system stability.

[0114] This application enhances functional safety protection and meets high-level safety requirements.

[0115] The functional safety unit (FctlSftyLevel3) is deployed independently on Core1. Through high-priority preemptive scheduling of 2ms / 10ms periodic safety tasks, it achieves full-dimensional fault detection such as clock monitoring and program flow verification. At the same time, it avoids signal packet loss and out-of-ordering through standardized safety interfaces, and combines memory isolation to achieve fault domain containment. It can quickly trigger the safety degradation mode to limit engine torque, meet ASIL level functional safety requirements, and significantly improve the risk resistance capability of the power system.

[0116] Finally, it should be noted that the above descriptions are merely preferred embodiments of this application, and this application is not limited to the above embodiments. It is understood that other improvements and variations directly derived or conceived by those skilled in the art without departing from the spirit and concept of this application should be considered to be included within the protection scope of this application.

Claims

1. A power domain control system based on a multi-core controller of the AutoSar architecture, characterized in that, The system includes: a hardware platform, a software platform, and an interface platform for data interaction between the hardware platform and the software platform; The hardware platform includes: an integrated circuit board designed based on the physical properties of the EMS and TCU and the control requirements of the vehicle; The software platform includes: a hardware layer integrating EMS and TCU underlying logic control resources, and a software layer integrating EMS and TCU software logic control resources. The software platform includes: Core0, Core1 and Core2; Core0 includes engine control resources corresponding to the underlying logic control resources and software logic control resources, Core1 includes vehicle safety control resources corresponding to the underlying logic control resources and software logic control resources, and Core2 includes transmission control resources corresponding to the underlying logic control resources and software logic control resources. The cores communicate with each other based on the IOC communication mechanism. The hardware layer of the software platform 102 communicates with the vehicle to obtain the vehicle's operating signals and calls the standardized input interface of the interface platform. The interface platform, based on a preset first correspondence between the core and the operating signal, transmits the operating signal to the first target Core corresponding to the operating signal in the software layer of the software platform through the standardized input interface. The first target Core generates control instructions corresponding to the running signal and calls the standardized output interface of the interface platform. Based on a preset second correspondence between cores and functional modules, the interface platform sends the control instructions to the target functional module corresponding to the first target Core in the hardware layer of the software platform 102 through the standardized output interface, so that the target functional module can control the vehicle based on the control instructions.

2. The power domain control system based on the AutoSar architecture multi-core controller according to claim 1, characterized in that, The software layer in Core1 includes: a functional safety element; When the functional safety unit needs to actively read the engine's operating signal, it generates a data reading command and calls the cross-core standardized interface of the interface platform. Based on a preset third correspondence between the core and the operating signal, the interface platform sends the data reading command to the third target core in the hardware layer of the software platform through the cross-core standardized interface, and transmits the data read by the third target core back to the functional safety unit through IOC inter-core communication.

3. The power domain control system based on the AutoSar architecture multi-core controller according to claim 2, characterized in that, The functional safety unit includes: a business function module, a lightweight monitoring module, and a security management module; The business function module receives the vehicle's operating signal, generates control commands based on the operating signal, and transmits the control commands to the lightweight monitoring module; the lightweight monitoring module verifies the execution logic of the business function module based on the control commands, and transmits the operating signal and verification result to the safety management module; the safety management module determines whether there is an operating fault based on the operating signal and the verification result.

4. The power domain control system based on the AutoSar architecture multi-core controller according to claim 3, characterized in that, The security management module includes: a multi-core task scheduler, a clock monitor, a memory integrity tester, a task timing verifier, and a synchronization verifier; Core1 schedules security monitoring tasks through a multi-core task scheduler, a clock monitor monitors the clock stability of Core0 and Core2 in real time, a memory integrity tester verifies the data integrity of the Core0 power control memory segment based on the ECC mechanism, a task timing verifier verifies the task scheduling timing of Core0 and Core2, and a synchronization verifier detects the LockStep core synchronization status. Core1 obtains the running status data corresponding to the security monitoring tasks in Core0 and Core2 through the IOC communication mechanism.

5. The power domain control system based on a multi-core controller of the AutoSar architecture according to any one of claims 1-4, characterized in that, The collaborative work of each core includes: Core0 receives transmission status data from Core2, determines the collaborative operation strategy between the engine and transmission based on the transmission status data and engine status data, and sends engine control commands via the CAN bus to control the engine's power output, and sends transmission control commands via the SPI interface to control the shifting operation of the transmission's shift solenoid valve. Core1 monitors the collaborative work tasks of Core0, determines whether there are any abnormal control commands sent by Core and whether there are any abnormal transmission status data transmitted by Core2; if any one or more abnormalities are found, it generates a safety response command and sends the safety command to Core0, so that Core0 can adjust the real-time collaborative work strategy based on the safety response command.

6. The power domain control system based on the AutoSar architecture multi-core controller according to claim 5, characterized in that, If Core1 determines that a preset high-level anomaly has occurred, it sends an emergency safety command to Core0 and Core2. Based on the emergency safety command, Core0 stops the preset power control task, controls the engine torque within the preset safety range, and controls the transmission to switch to the preset emergency gear. Core2 stops performing status acquisition operations and performs the operation of writing exception information to flash memory.

7. The power domain control system based on a multi-core controller of the AutoSar architecture according to any one of claims 1-4, characterized in that, Core1 executes security monitoring tasks with the highest priority. Core0 determines the execution priority of security monitoring tasks based on the task cycle, where the longer the task cycle, the lower the execution priority. Core2 executes auxiliary tasks based on the lowest priority.

8. The power domain control system based on a multi-core controller of the AutoSar architecture according to any one of claims 1-4, characterized in that, The hardware layer of the software platform includes: a service layer, a hardware abstraction layer, and a driver layer; When the hardware layer of the software platform determines that an engine failure has occurred based on the operation signal, it calls the target interface corresponding to the engine failure in the service layer to forward the engine failure to the second target core in the driver layer through the hardware abstraction layer, and writes the engine failure into the flash memory based on the FLS in the storage driver in the second target core.

9. The power domain control system based on a multi-core controller of the AutoSar architecture according to any one of claims 1-4, characterized in that, When the system is powered on, the initialization operations of Core0, Core1 and Core2 are performed in the order of initialization first Core0, then Core1 and finally Core2.

10. The power domain control system based on a multi-core controller of the AutoSar architecture according to any one of claims 1-4, characterized in that, The control commands include: fuel injection control commands; The software platform calls the PWM output standardization interface of the interface platform and sends the fuel injection control command to the PWM module corresponding to Core0 based on the second correspondence, so that the PWM module outputs the fuel injection control command to perform vehicle fuel injection control.

Images